Re: TCP limitations (was Re: ISCSI: Urgent Flag requirement violates TCP.)

[Glen Turner <glen.turner@aarnet.edu.au>]

Vern Paxson quoted someone who's mail I had already deleted:

> > Your assumptions about reordering is not accurate for WAN.  Should there be
> > more than one long-haul fiber in use, common in metro areas, the disparate
> > physical routes may induce out of sequence events.  Is such a case, SACK
> > reduces the negative effect.

The reordering events should only occur on protection or
route changes.  Of course, some ISPs can't manage to configure
stable routes :-)

It was recognised very early that per-packet load sharing across
parallel links leads to packet reordering, so MAC address hashing
for switches or IP address hashing for routers has long been standard
practice and the default configuration setting.  Packets in the same
flow are then sent through the same forwarding path.

> SACK as currently deployed does not actually help all that much with
> reordering.  The receiver will still generate duplicate acks and the
> sender will misinterpret them as indicating packet loss, leading to
> a congestion response of halving the sending rate.

Our upstream provider misconfigured their links to use per-packet
load sharing to the US, believing that maximising link utilitisation
improved the end-to-end performance.

After we got them to change back to the manufacturer's default setting
we got a 70% decrease in FTP times for large files between our performance
monitoring systems (Linux 2.2, which has SACK).

-- 
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised