![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> 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