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
smime.p7s
Description: S/MIME Cryptographic Signature
