TCP out-of-order packets.

[lars.eggert at netlab.nec.de (Lars Eggert)]

>>> I have a link which is provided by someone else that is 7 x E1s 
>>> aggregated. At leat it looks that way to me when I get to see it.
>>> however I have only been able to get 60kB.sec across this,
>>> despite having a tcp window size of 131072 bytes.. After
>>> investigation it appears that the link is massively re-orderring
>>> packets. groups of upto 10 packets may appear in random order.
>>> (Maybe more, bu tI have seen 10) >>>
>>> in fact packets are rarely IN order.
>>> This plays havoc with the tcp sessions.

A gap or jump in the ACK stream looks to TCP like a loss, no matter that 
it's caused by reordering. Multiple such things per window look like 
multiple losses and trigger a slow start under Reno. TCP/SACK should be 
more robust against reorderings (up to a degree, at least.) Does 4.x 
have the SACK code yet?

What sort of link multiplexer is this? Decent ones jump through all 
sorts of hoops to try and reestablish the original packet order.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3360 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20050113/22402081/smime.bin