Re: [tcpm] early retransmit done?

[Mark Allman <mallman at icir.org>]

> > 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.
> 
> Is it really that well defined that pure FINs are not "segments"?

I didn't mean to say or indicate that.

> > I basically don't see anything to be done here short of making the
> > sender explicitly track that a pure FIN is outstanding.
> 
> My guess is that most of the implentations will know this already
> (indirectly if not even directly). Nevertheless, I don't see what is
> the harm if FIN is included to "outstanding" segments/sequences.

I would be surprised if stacks retain an understanding of whether they
transmitted a FIN with a data packet or without.  There isn't harm, per
se, except for complexity (and perhaps a small bit of extra state).  

> > My inclination here is that this is enough of a corner case that the
> > document is fine how it is.
> 
> ...and you still boldly claim in the intro that "A particular case
> when all connections become application limited is as the connection
> ends"? :-)

Yeah... I don't see that at odds with calling the separate-FIN a corner
case. 

> > (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's certainly possible yes.
>
> But I would argue that if early retransmit would be made useful here,
> short transfers would greatly benefit from sending it separately
> because of the increased likelyhoods of avoiding RTO at the end which
> is very significant for their latency.

That's not a half bad thought---although it still to me seems like it'd
help only a very small fraction of things.

So, how about a note in section 2.2 that just says an implementation
could also track a dataless FIN as an outstanding segment if explicitly
tracking outstanding segments?  Will that work?  

allman

Attachment: pgpgyCbWdzXm7.pgp
Description: PGP signature