[PATCH] TCP window tracking retransmission handling

[Jozsef Kadlecsik]

Hi Phil,

On Mon, 24 Jan 2005, Phil Oester wrote:

> Under certain circumstances (high latency WAN links for instance), ack
> packets get stacked up and arrive in bulk.  The current TCP window
> tracking code interprets these numerous acks as retransmits, and
> if there are >= 3 retransmits sequentially, it resets the timeout on
> a conntrack to 5 minutes.
>
> This is trivially reproducible on a high latency link by an 'ls -lR'
> on a large-ish tree.  In my test case, 8 ack packets arrived sequentially
> at the end of the listing.  While the seq numbers on those packets
> were indeed identical (which the current code tests for), they were acking
> unique packets, and thus clearly do not qualify as retransmissions.
>
> The problem lies in the fact that the code currently only examines
> the seq number of the arriving packet, but does not also look at the
> seq number being acked.  The patch below adds this additional check.
> Unfortunately, it adds another int32 to ip_ct_tcp, but I could think
> of no other fool-proof way of fixing it (short of ripping out the
> retransmission test altogether).

If we really want to attempt to detect resent packets, then I agree with
you and the proposed solution. I was reluctant to add another field to
ip_ct_tcp, but that cannot be avoided in order to do the job properly.

[However, from another point of view, we actually could get rid of the
feeble attempt of detecting resent packets (and thus the retrans and
last_end fields) with the price of possible dangling connections in the
conntrack table. The current code handles just fine "reopening" stuck
connections.]

Best regards,
Jozsef
-
E-mail  : kadlec at blackhole.kfki.hu, kadlec at sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary