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

[William]

The application will be using TCP, time to look into MLPPP then!

2009/1/15 Yan Filyurin <yanf787 at yahoo.com>:
> 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/
>
>