[e2e] TCP retransmissions at end of data stream

[Angelo Dell'Aera]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 15 Jun 2003 14:09:52 -0400
Eric Travis <travis at gst.com> wrote:


>I believe  that the common (but  not the most  agressive) solution to
>this - and  a simple tweak for your implementation  - is to recognize
>the *special case* where you experience a timeout while the FIN is in
>flight.  Since  you've already sent the  FIN, you know  that you will
>not have any new data to send: Upon receipt of an ACK for the initial
>retransmitted segment,  you should be able to  *immediately* send the
>next segment (the new snduna); When this segment is ACKed, you get to
>repeat this  cycle (snduna moving  toward your segment  that contains
>the FIN) until you've gotten an ACK covering the FIN.  (Being able to
>go  into   slow-start  at   this  point  is   of  no  help   in  most
>implementations, as  there is  nothing at send_next).   Assuming that
>*all* the in-flight  segments were lost, this will  still require one
>rtt per segment  in flight, but this is still  better than waiting an
>RTO between retransmitting each of the outstanding segments.


I found no  rationale in this. If all the  in-flight packets are lost,
RTO will fire. When it  happens (in the classical Reno implementation)
ssthresh is set to max(FlightSize/2, 2*SMSS) and cwnd to 1. This leads
the sender to retransmit *just the first segment* in the retrasmission
queue while being in the slow start phase. When it receives the ACK it
increments  cwnd to  2 thus  being able  to send  two packets.  If the
packets are both ACKed, cwnd will be set to 4 and so on until ssthresh
is reached as stated in RFC2581.  In this perspective, I'm not able to
understand  what you  propose. In  fact, I  think there's  actually no
meaning for any `special case'. Moreover,  slow start is really useful
since if you lose f.e. 7 packets your solution takes 7 RTTs to recover
from this situation. Otherwise, using slow start you need just 3 RTTs.
There's no reason IMHO for a special case for a FIN packet since 

- - if  the receiver  receives the  FIN packet  after an  hole,  it will
simply send a  DUPACK not caring about  FIN flag (RFC 793 -  page 69 :
"If an incoming segment is not acceptable, an acknowledgment should be
sent in reply (unless  the RST bit is set, if so  drop the segment and
return)" ).

- - if  the receiver doesn't  receive it,  it's just  like it  was never
transmitted.

Regards.


- --

Angelo Dell'Aera  
Antifork Research, Inc.	  	http://buffer.antifork.org

PGP information in e-mail header


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+72ngpONIzxnBXKIRAgExAKDF2CmpxjcTMAvuLe9VmNzGCjLpGgCfSNJ7
KHOFprGzh/PlI1gH5pItyKQ=
=BSLH
-----END PGP SIGNATURE-----