TCP out-of-order packets.
andre at freebsd.org
Thu Jan 13 13:40:43 PST 2005
Julian Elischer wrote:
> Brooks Davis wrote:
> >On Wed, Jan 12, 2005 at 05:07:36PM -0800, Julian Elischer wrote:
> >>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
> >>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.
> >>I was thinking of writing a hacked up version of NATD that
> >>instead of doing NAT, just did a pre-sort on packets from each session,
> >>so that the receiver would
> >>see a stream of IN-order packets, with occasional delays.
> >>firstly, does anyone have any tools to do this already (why build when
> >>you can borrow)
> >>and secondly, does anyone have any experience with this sort of problem?
> >>I have no control over or access to the link.. all I have is a promise
> >>that they will deliver
> >>14Mb/Sec. with approc 300mSec. RTT to me but there is no promise about
> >>packet order.
> >>I just get a 100Mb ethernet cable.
> >Have you tried Andre's TCP reassembly rewrite? He says he saw
> >significant improvements in the face of major reordering.
> I don't think it's a problem with reassembly overhead, but rather a
> symptom of sender
> backoff when confronted with multiple duplicate acks due to the receiver
> getting the packets out of order.
> I wonder if there's a way to turn off the sender backoff?
Not directly. What you actually want is to delay the generating of
ACK's for a certain amount of time (some milli-seconds) to aggregate
the out-of-order packets into one ACK and to avoid the backoff from
the other side.
More information about the freebsd-net