Subject: Re: [tcpm] early retransmit done?

From: Alexander Zimmermann <[email-masked]>
Date: Wed, 11 Nov 2009 15:06:22 +0100

Hi Mark,

here my

*** Comments:

* Line 150-153. On Joe's request, you added some lines about ACK compression...
Ah sorry, Delay ACKs ;-). The first new sentence is fine and IMHO sufficient.
The second one confuse me (a litte bit). Why do you write "we assume that
receivers send immediate ACKs when there is a gap in the received sequence
space"? If a TCP would not send a DUPACK directly when OOO segment is received,
Early Rexmit wouldn't work? Maybe one or two sentence more could me "un-puzzle".

*  Line 252-253. 'We call this reduced ACK threshold enabling "Early
Retransimission"'. Maybe it's my limited english knowledge, you are the native
speaker, but IMHO the sentence sounds strange. What about this: "We call this
reduced duplicate ACK threshold "Early Retransmit".

* Line 222-224. In my last review I mentioned that we could probably better
specify the "entry point" of the algorithm. Example:

   Upon the arrival of an ACK, a sender employing byte-based Early
   Retransmit MUST use the following two conditions to determine
   when an Early Retransmit is sent:

* Line 226. Concerning Joe's question where magic *4* comes from. What do you
think about this?

   (2.a) The amount of outstanding data (ownd)---data sent but not yet
         acknowledged---is less or equal than 3*SMSS bytes, where is
         the lower bound of DupThresh from [RFC5681, RFC3517].

Mark, the last two point are really peanuts. If you don't like them, skip them.

*** Nits:
Missing Reference: 'RFC4653' is mentioned on line 419, but not defined

There are 5 instances of too long lines in the document, the longest one
being 2 characters in excess of 72.

*** Misspellings:
Line 91: s/implemention/implementation
Line 253: s/Retransimission/Retransmission (I know that it was Joe's misspelling ;-))
Line 312: s/Retransimission/Retransmission

Am 27.10.2009 um 15:30 schrieb Mark Allman:

> 
> 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.
> 
> 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: Mark Allman <[email-masked]>
Date: Wed, 11 Nov 2009 11:21:51 -0500

> Ah sorry, Delay ACKs ;-). The first new sentence is fine and IMHO
> sufficient.  The second one confuse me (a litte bit). Why do you write
> "we assume that receivers send immediate ACKs when there is a gap in
> the received sequence space"? If a TCP would not send a DUPACK
> directly when OOO segment is received, Early Rexmit wouldn't work?
> Maybe one or two sentence more could me "un-puzzle".

I don't follow this.  The point here is that delayed ACKs could perhaps
reduce the number of ACKs the sender gets back.  But, a counter-point
(per RFC5681) is that when ACKing out-of-order arrivals the receiver
SHOULD NOT be using delayed ACKs.  I just read the text a few times and
I think it is OK.  But, I might be too close to it and so am open to
suggestions. 

> Retransimission"'. Maybe it's my limited english knowledge, you are
> the native speaker, but IMHO the sentence sounds strange. What about
> this: "We call this reduced duplicate ACK threshold "Early
> Retransmit".

This language was added for Joe.  I don't think it is either necessary
or harmful.  And, I am not going to get into making excessively small
tweaks to it.

>    when an Early Retransmit is sent:

OK.

>          the lower bound of DupThresh from [RFC5681, RFC3517].

I didn't address this directly because I think it is clear from the
entire document why the number is what it is.  And, as I understood it
this was a minor comment from Joe.  The above suggested sentence does
not parse for me.

> Missing Reference: 'RFC4653' is mentioned on line 419, but not defined

Added.

> Line 312: s/Retransimission/Retransmission

Fixed.

I know the chairs are getting ready to forward this.  I can send off
another version just before they do that encompasses this and any other
feedback folks want to send.

Thanks!

allman