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

Yan Filyurin yanf787 at yahoo.com
Thu Jan 15 11:08:01 EST 2009


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/



      


More information about the cisco-nsp mailing list