Re: TCP Retransmission timers ?

Craig Partridge <craig@aland.bbn.com> Wed, 18 September 2002 20:44 UTC

Message-Id: <200209182044.g8IKiZlF019680@aland.bbn.com>
To: sebastiano elia <sebastiano.elia@unile.it>
Cc: tcp-impl@grc.nasa.gov
Subject: Re: TCP Retransmission timers ?
In-Reply-To: Your message of "Wed, 18 Sep 2002 18:54:23 +0200." <200209181854.23359.sebastiano.elia@unile.it>
Date: Wed, 18 Sep 2002 16:44:35 -0400
From: Craig Partridge <craig@aland.bbn.com>
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1167
Lines: 30

In message <200209181854.23359.sebastiano.elia@unile.it>it>, sebastiano elia write
s:

>please, can someone tell me what kind of retransmit policy is used, in current
 > 
>implementations of TCP ?
>a)"First only"  with only one retrasmission timer for entire queue;
>b)"Batch" with only one retrasmission timer for entire queue;
>c)"Individual" with one timer for each segment in queue.

I think this classification combines two different issues

    * how the retransmission timer is run (per packet, per window)

    * what happens when the retransmission timer goes off

I think the combination is correct, in that we would not normally think of
sending a whole window if the timer for an individually timed packet went off;
but by splitting them, I can say something useful.

I don't know of any standard for how the retransmission timer is run.

In terms of retransmission, if you've only got cumulative ACKs, the only
rational answer is "send only the 1st outstanding segment" -- and as I recall
there's a terse note from Jon Postel to the TCP-IP list or perhaps E2E
about this subject in 1987 (which I cannot find, alas).

SACK makes the decision tricker.

Craig