[88204] in North American Network Operators' Group
Re: Split flows across Domains
daemon@ATHENA.MIT.EDU (Matt Buford)
Tue Jan 24 20:55:10 2006
From: "Matt Buford" <matt@overloaded.net>
To: "Christopher L. Morrow" <christopher.morrow@verizonbusiness.com>,
"Joe Abley" <jabley@isc.org>
Cc: "Robert E.Seastrom" <rs@seastrom.com>,
"Christopher L. Morrow" <christopher.morrow@verizonbusiness.com>,
"Glen Kent" <glen.kent@gmail.com>, "NANOG list" <nanog@merit.edu>
Date: Tue, 24 Jan 2006 14:17:04 -0500
Errors-To: owner-nanog@merit.edu
On Tue, 24 Jan 2006, Christopher L. Morrow wrote:
> that was my thought... and yes, it could get ugly for tcp services. Why
> would you knowningly induce this complication?
When you want single flows to go faster than a single member link? (not that
I am saying this is a good idea)
Actually, TCP handles out of order packets rather well as long as the
reordering isn't too severe. You see a bunch of SACKs flying around, but as
long as it doesn't get too out of hand it doesn't affect throughput.
It is the non-TCP protocols that often suffer. Many of them implement
sequence numbers and simply drop out of order packets. From my own
experience, RealPlayer UDP streams and PPTP are two examples that fail (or
at least feel like 50% packetloss) under heavy reodering, where TCP
continues to work reasonably well.
Years ago, I had ISDN and IDSL between home and the ISP I worked at, and out
of curiosity I experimented with per-packet load balancing across these
links. Reordering was rather severe, as these links had slow uneven speeds,
and uneven latencies. TCP transfers got about 192kbit (75% total link
capacity, 1.5 times single link capacity), but things like RealPlayer and
PPTP VPNs were downright unusable.
