Subject: Re: [tcpm] NewReno revision (RFC3782bis)

From: Alexander Zimmermann <[email-masked]>
Date: Thu, 20 Jan 2011 18:27:10 +0100

Hi Yoshifumi,

some *late* comments on your draft (draft-nishida-newreno-modification-02)

* Page 6, Case 1:

  - I wonder if the case is also possible when the sender use Limit Transmit.
    I'm to lazy to replay the example with a pen and a sheet of paper ;-)

  - You say "Since the two segments in line 8 and 9 are usually transmitted almost
    at the same time, the receiver may send back only one ACK for these
    two segments (line 10)".

    However, according RFC5681 this is not recommended." To
    provide feedback to senders recovering from losses, the receiver
    SHOULD send an immediate ACK when it receives a data segment that
    fills in all or part of a gap in the sequence space."

    What TCP stack did you dump?

* Page 7, Case 2:

  - You say "However, these duplicated ACKs sent from B have zero advertised
    window because of buffer overflow."

    Are you sure about your statement? See DUPACK definition in RFC5681, rule (e)

* Page 8, Case 3:

  - Again, is this example valid with Limited Transmit in use?

* Page 9, Discussion:

  - The first paragraph, I understand. I also notice that Linux call "open cwnd"
    after FRec. However, what do want to say with the first sentence of the
    second paragraph? (Or the whole paragraph) I don't get this...

Alex

Am 24.11.2010 um 06:07 schrieb Wesley Eddy:

> We had previously polled the working group on revising RFC3782 (NewReno) in order to account for the reported errata and Yoshifumi's modification.
> 
> Since TCPM's charter already includes maintaining existing pieces of TCP (like NewReno), and given that there was a small amount of support on the list, no resistance, and all of the authors of RFC 3782 plus Yoshifumi have expressed interest and energy, we asked the authors to submit the next revision of their 3782bis document as a WG draft.  The
> prior revision is:
> http://datatracker.ietf.org/doc/draft-henderson-tcpm-rfc3782-bis/
> which will be replaced by the working group document.
> 
> Since the known updates are fairly simple, we set a charter milestone only a few months away (April 2011) for submission to the IESG (still as a Proposed Standard).
> 
> 
> _______________________________________________
> 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-22222
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 21 Jan 2011 01:37:20 -0800

Hello Alexander,
Thanks for your comments.

>    I'm to lazy to replay the example with a pen and a sheet of paper ;-)

How about this one?

         1  10:41:00.000001 A > B: . 1000:2000(1000) ack 1 win 32768
         2  10:41:00.001001 A > B: . 2000:3000(1000) ack 1 win 32768
         3  10:41:00.002001 A > B: . 3000:4000(1000) ack 1 win 32768
         4  10:41:00.010001 B > A: . ack 1000 win 16384
         5  10:41:00.011001 B > A: . ack 1000 win 16384
         6  10:41:00.011001 A > B: . 4000:5000(1000) ack 1 win 32768
         7  10:41:00.012001 B > A: . ack 1000 win 16384
         8  10:41:00.013001 A > B: . 1000:2000(1000) ack 1 win 32768
         9  10:41:00.014001 A > B: . 5000:6000(1000) ack 1 win 32768
       10  10:41:00.024001 B > A: . ack 6000 win 16384
       11  10:41:00.025001 A > B: . 6000:7000(1000) ack 1 win 32768

>    fills in all or part of a gap in the sequence space."

I don't see any discrepancy here.
Because in my interpretation, "immediate" does not necessarily mean
don't aggregate other ACKs
and there is no clear definition of immediate.

>    Are you sure about your statement? See DUPACK definition in RFC5681, rule (e)

Hmm. To me, line 7-9 and 11-12 still look dup acks. You could argue
line 7 might not, but I guess this is not your point..
If I misunderstand something here, please let me know.

>    second paragraph? (Or the whole paragraph) I don't get this...

OK. Please let me explain.
My point here is on the arrival of the first Full ACK, a certain TCP
exits FR and adjusts cwnd, then call opencwnd to adjust cwnd again.
This means the TCP adjusts cwnd twice on a single ACK reception. But,
I prefer that TCP calls opencwnd on the next ACK arrival.

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: Alexander Zimmermann <[email-masked]>
Date: Mon, 24 Jan 2011 19:18:07 +0100

Hi Yoshifumi,

what I really miss to indicate last time was that I support your doc.
In my opinion your fix is one right approach to tackle the problem.
My comments below are only related to your examples, so not that
important. 

Alex

>       11  10:41:00.025001 A > B: . 6000:7000(1000) ack 1 win 32768

LTransmit/Retransmit/LTransmit is somehow weird. I never saw this in
real life. (However, I dump only linux boxes)

> and there is no clear definition of immediate.

IMO "immediate" means "don't aggregate", since if want to aggregate something
you have to wait. Linux for example goes with Quick Ack one step further (but
I think you know that)

> line 7 might not, but I guess this is not your point..

This was my point.

> I prefer that TCP calls opencwnd on the next ACK arrival.

AFAIK this is not the point for Linux (as you wrote in you draft). Here, the
"Burst Protection" is insurance that you send more that one segment. Pasi
wrote a nice paragraph is his Linux paper about that:

"There are occasions where the number of outstanding packets decreases suddenly
by several segments. For example, a retransmitted segment and the following forward
transmissions can be acknowledged with a single cumulative ACK. These situations
would cause bursts of data to be transmitted into the network, unless they are taken
into account in the TCP sender implementation. The Linux TCP sender avoids the bursts
by limiting the congestion window to allow at most three segments to be transmitted
for an incoming ACK. Since burst avoidance may reduce the congestion window size below
the slow start threshold, it is possible for the sender to enter slow start after
several segments have been acknowledged by a single ACK."

I attached a nice example, which came my across.
PS: Forget about the annotation in the plot, its plot for my thesis. I know that
know how NewReno works ;-)

//