Re: [tcpm] early retransmit done?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tcpm] early retransmit done?



> My wish is that it would be slightly more explicit in how to handle a
> FIN (only) segment.

So, the issue here is that a FIN with no data could be useful for ER?

So, ...

  (1) You send two data packets plus a pure FIN.

  (2) Lose the second data packet.

  (3) Get a cumulative ACK for the first data packet.

  (4) Get a FIN-triggered duplicate ACK.

At this point the sender will think there is one outstanding segment and
set the dupthresh to zero and so not really useful in using the dupack
as a trigger for a retransmit.

I basically don't see anything to be done here short of making the
sender explicitly track that a pure FIN is outstanding.

My inclination here is that this is enough of a corner case that the
document is fine how it is.  (Note in the particular scenario you played
out the TCP implementation may or may not send a payload-less FIN.
Depending on the timing and etc. it could well be tacked on the second
data packet.)  That said, if the WG thinks it is important to address
this corner case at the last minute then we will obviously do so.

allman



Attachment: pgpVU4XtxD7rY.pgp
Description: PGP signature


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.