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" <[email protected]>
>> To: <[email protected]>; <[email protected]>
>> 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: [email protected]
>>> [mailto:[email protected]] On Behalf Of Mauritz
>>> Lewies Sent: Friday, January 16, 2009 12:40 AM
>>> To: [email protected]
>>> 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 <[email protected]>
>>>> To: Brad Hedlund <[email protected]>
>>>> Cc: "[email protected]" <[email protected]>
>>>> 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 <[email protected]>:
>>>>> On 1/15/09 6:25 AM, "William" <[email protected]> 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
>>>>> [email protected]
>>>>> http://www.internetworkexpert.org
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> cisco-nsp mailing list [email protected]
>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-nsp mailing list [email protected]
>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>> _______________________________________________
>>> cisco-nsp mailing list [email protected]
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list [email protected]
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>> _______________________________________________
>> cisco-nsp mailing list [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
