Re: [tcpm] early retransmit done?

["Ilpo Järvinen" <ilpo.jarvinen at helsinki.fi>]

On Wed, 11 Nov 2009, Mark Allman wrote:

> 
> > > 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).  

I don't perhaps fully follow what is the problem here. If it wasn't sent 
separately, there won't be that dup ACK then either because both FIN and 
final data are either lost or delivered in unison. But then it would have 
been counted as one outstanding segment anyway (if it was counted as two 
for some reason, I'd say the implementation is just broken).

Secondly, if one counts window in segments, I cannot see how it can be 
done robustly without knowing segment boundaries (after all, negative 
in-flight isn't that nice thing) and there is very little need to create 
exception for FIN but treat its boundary the same way. ...Plus I suppose 
the implentation still wants to know that FIN was acked :-). Once segment 
boundaries are known, it is insignificant in context of early rexmit 
whether the last segment is pure-FIN or not..

> > > 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?  

A note sounds reasonable to me. 

-- 
 i.