Re: [tcpm] early retransmit done?

[" Ilpo Järvinen " <[e-mail]>]

On Mon, 9 Nov 2009, Mark Allman wrote:

> > We believe we have addressed all comments we received on the early
> > retranmsit ID.  I just went to submit a new version and have missed the
> > cut-off.  I have set a bit to submit when the system opens again on
> > Nov/9.  However, until then I put the version I was going to submit here
> > ...
> > 
> >   http://www.icir.org/mallman/papers/draft-ietf-tcpm-early-rexmt-02a.txt
> > 
> > Comments are very welcome.
> 
> Since TCPM is not meeting this week Lars got this draft approved for
> posting.  So, it is now at the usual place (as "-02" not "-02a).
> 
> Our hit is that it seems finished.  Please yell if there is more to do.

My wish is that it would be slightly more explicit in how to handle a
FIN (only) segment. Through intuition I'd say it is included to ownd and 
oseg but that not mentioned I think. I suppose this flow termination is 
relatively significant case when considering benefits of early rexmit.
The confusion is further reinforced by the example in 3.3 (case 2):

1. 3-way handshake, connect() returns.
2. App sends two "data segments" as per IW=2 using write(), they go 
deep in the stack right away as there is room for that (with IW=1 there 
wouldn't be any reordering possibility so it has to IW=2 or larger!)
3. write() call returns
4. close() is called
5. FIN only segment needs to be sent
...

This third segment does not match to the behavior described in the ID at 
all? ...It would probably be already quite much to address this if just 
this worst case example is converted to have a single data segment and a 
FIN only segment (with persistent reordering between them).

-- 
 i.