[c-nsp] Per packet load balancing with low latency applications

Tony Varriale tvarriale at comcast.net
Fri Jan 16 12:45:28 EST 2009


I should have been more detailed.

I agree with you regarding the fragmentation.

To ensure minimal jitter and to bypass the serialization delay, some sort of 
QoS should be implemented to ensure the voice traffic goes first onto the 
bundle.

As a somewhat related note, the 7200s have newer DS3 cards that offload the 
MLPPP overhead directly to the cards instead of using the main CPU.

tv
----- Original Message ----- 
From: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
To: <mauritz at three6five.com>; <cisco-nsp at puck.nether.net>
Sent: Friday, January 16, 2009 1:12 AM
Subject: Re: [c-nsp] Per packet load balancing with low latency applications


> Nope. even if the sender doesn't fragment packets, the receiver will
> still make sure packets are put into the correct order (MLPPP considers
> all frames being "fragments" and numbers them accordingly).
> I think disabling fragmentation can lead to slightly increased latency
> (and possibly jitter), for example when a 1500 byte and a 40 byte
> packets are sent in this sequence, and the receiver needs to wait for
> the 1500 byte packet to arrive completely before forwarding the small
> packet..
> I wouldn't consider MLPPP as being especially CPU-hungry these days..
>
> oli
>
> Mauritz Lewies <> wrote on Thursday, January 15, 2009 21:59:
>
>> But then you might as well use per-packet load balancing...
>>
>>
>>
>> On Thu, 2009-01-15 at 14:37 -0600, Tony Varriale wrote:
>>
>>> Turn off fragmentation.  You'll see your CPU drop way down.
>>>
>>> tv
>>> ----- Original Message -----
>>> From: "Andrew Jimmy" <good1 at live.com>
>>> To: <mauritz at three6five.com>; <cisco-nsp at puck.nether.net>
>>> Sent: Thursday, January 15, 2009 2:02 PM
>>> Subject: Re: [c-nsp] Per packet load balancing with low latency
>>> applications
>>>
>>>
>>>> I'm using MLPPP along with CRTP on Juniper routers (using AS PIC),
>>>> And it is working like a charm... yea true MLPPP stuff is
>>>> complicated on Cisco devices which is CPU hungry ...
>>>>
>>>> -----Original Message-----
>>>> From: cisco-nsp-bounces at puck.nether.net
>>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mauritz
>>>> Lewies Sent: Friday, January 16, 2009 12:40 AM
>>>> To: cisco-nsp at puck.nether.net
>>>> Subject: Re: [c-nsp] Per packet load balancing with low latency
>>>> applications
>>>>
>>>> Hi
>>>>
>>>> Out of personal experience MLPPP sounds great in theory and
>>>> technically should be a viable solution. However, Cisco has never
>>>> really been able
>>>> to deliver a bug free MLPPP implementation...
>>>>
>>>> We have had situations of per-packet, moving to MLPPP, going back to
>>>> per-session and eventually having to aggregate into larger single
>>>> links. IOS has just never really worked with MLPPP and I strongly
>>>> advise against.
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, 2009-01-15 at 08:08 -0800, Yan Filyurin wrote:
>>>>
>>>>> Look for ways to aggregate multiple physical circuits into one
>>>>> logical
>>>> that has a native way to load balance and still insure that packets
>>>> are not out of sequence like MLPPP or  MLFR since they have their
>>>> own sequencing that prevents out of order arrival, not to mention a
>>>> bunch of things like fragmentation and interleaving that is great
>>>> for voice.   As far as market data application goes, is it by any
>>>> chance multicast and UDP, which could potentially make it subject
>>>> to the same constraints as voice. You could always do all kinds of
>>>> things to influence various types of traffic going over just a
>>>> single link with redundancy and all or just do per destination. I
>>>> would vote for MLPPP.
>>>>>
>>>>> Like the previous email said, you can use L3 technologies such as
>>>> tunneling with sequence datagrams, but all it will do is drop
>>>> packets that are out of order, thus moving the problem further from
>>>> the application, but still creating it. I've only read about it.  I
>>>> am sure everyone here will vote for MLPPP.
>>>>>
>>>>> Yan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ________________________________
>>>>> From: William <willay at gmail.com>
>>>>> To: Brad Hedlund <brhedlun at cisco.com>
>>>>> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
>>>>> Sent: Thursday, January 15, 2009 10:16:56 AM
>>>>> Subject: Re: [c-nsp] Per packet load balancing with low latency
>>>>> applications
>>>>>
>>>>> Hi Brad,
>>>>>
>>>>> Thanks for your input.
>>>>>
>>>>> Is there anything else I can use to achieve my goal? I'm pretty
>>>>> sure getting a bigger circuit will be a last resort.
>>>>>
>>>>> Regards,
>>>>>
>>>>> W
>>>>>
>>>>> 2009/1/15 Brad Hedlund <brhedlun at cisco.com>:
>>>>>> On 1/15/09 6:25 AM, "William" <willay at gmail.com> wrote:
>>>>>>
>>>>>>> My
>>>>>>> question is what would cause the packets to arrive out of
>>>>>>> sequence?
>>>>>>
>>>>>> Path #1 might have a little more congestion than Path #2, which
>>>>>> would cause Packet #1 sent down Path #1 to sit in a buffer an
>>>>>> extra millisecond or two than Packet #2 sent down Path #2 with no
>>>>>> congestion.  This results in Packet #2 arriving at the
>>>>>> destination before Packet #1.  The result of this being poor
>>>>>> application performance.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Brad Hedlund
>>>>>> bhedlund at cisco.com
>>>>>> http://www.internetworkexpert.org
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>> _______________________________________________
>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>
>>>> _______________________________________________
>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 



More information about the cisco-nsp mailing list