The application will be using TCP, time to look into MLPPP then!
2009/1/15 Yan Filyurin <[email protected]>: > 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/
