Subject: Re: [tcpm] early retransmit done?

From: Mark Allman <[email-masked]>
Date: Mon, 09 Nov 2009 15:50:48 -0500

Folks-

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

allman

---

From: Alexander Zimmermann <[email-masked]>
Date: Tue, 10 Nov 2009 09:39:49 +0100

Hi Mark,

give me one or two days more to look over the document again...

Alex

Am 09.11.2009 um 21:50 schrieb Mark Allman:

> <ATT00001>_______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Wed, 11 Nov 2009 05:07:58 +0200 (EET)

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

---

From: Mark Allman <[email-masked]>
Date: Wed, 11 Nov 2009 12:46:26 -0500

> 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

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Thu, 12 Nov 2009 03:19:42 +0200 (EET)

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

Yes.

> as a trigger for a retransmit.

Is it really that well defined that pure FINs are not "segments"? 
Probably this too is implementation dpeending whether outstanding 
segments (already) include FIN or not.

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

> 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"? :-)

> (Note in the particular scenario you played
> 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 said, if the WG thinks it is important to address

-- 
 i.

---

From: Mark Allman <[email-masked]>
Date: Wed, 11 Nov 2009 21:28:53 -0500

> Is it really that well defined that pure FINs are not "segments"?

I didn't mean to say or indicate that.

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

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

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Fri, 13 Nov 2009 07:28:14 +0200 (EET)

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

> tracking outstanding segments?  Will that work?  

A note sounds reasonable to me. 

-- 
 i.

---

From: Mark Allman <[email-masked]>
Date: Fri, 13 Nov 2009 08:25:18 -0500

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

I don't really follow this at all.

If you are tracking segments and include the implicit sequence number
consumed by the FIN then this all just works, I guess.  Is that what
you're saying?

allman

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Tue, 17 Nov 2009 13:51:23 +0200 (EET)

> consumed by the FIN then this all just works, I guess.  Is that what

Yes. ...And there's more, I also tried to say that one has to track that 
FIN sequence number anyway in order to be able to discern that the FIN was 
acked.

-- 
 i.