Subject: Re: [tcpm] [Editorial Errata Reported] RFC5681 (4068)

From: Mark Allman <[email-masked]>
Date: Mon, 04 Aug 2014 15:46:58 -0400

I think "new data" is context sensitive in this case.  The RFC uses it
as the community has used it for a long time.  I wouldn't be surprised
to find such usage in a fair number of TCP RFCs.

That said, I have no problem with the errata.  The document could be
more precise and if we ever update the document we could certainly take
care of this nit.

allman

---

From: RFC Errata System <[email-masked]>
Date: Mon, 4 Aug 2014 10:41:07 -0700 (PDT)

The following errata report has been submitted for RFC5681,
"TCP Congestion Control".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5681&eid=4068

--------------------------------------
Type: Editorial
Reported by: Michael Taylor <[email-masked]>

Section: GLOBAL

Original Text
-------------

Corrected Text
--------------

Notes
-----
The problem is the use of the phrase "new data" in an imprecise manner to sometimes mean "previously unacknowledged data" and other times mean "never before sent data".

For example, in Section 3.1

   During slow start, a TCP increments cwnd by at most SMSS bytes for
   each ACK received that cumulatively acknowledges new data. 

This should read 

   During slow start, a TCP increments cwnd by at most SMSS bytes for
   each ACK received that cumulatively acknowledges previously 
   unacknowledged data.

I believe that throughout Section 3.1 "new data" refers to "previously unacknowledged data".

However, in Section 3.2 we have

   After the fast retransmit algorithm sends what appears to be the
   missing segment, the "fast recovery" algorithm governs the
   transmission of new data until a non-duplicate ACK arrives.

I believe that here "new data" refers to "previously unsent data".  

This is clearer in the following paragraph from Section 3.2

   1.  On the first and second duplicate ACKs received at a sender, a
       TCP SHOULD send a segment of previously unsent data per [RFC3042]
       provided that the receiver's advertised window allows, the total
       FlightSize would remain less than or equal to cwnd plus 2*SMSS,
       and that new data is available for transmission.

Here we can see the use of "previously unsent data" followed by "new data" 
which refers to the aforementioned "previously unsent data".

While the meaning of "new data" might be clear to those with extensive experience
in TCP it is imprecise and therefore may be quite confusing to those who are learning about the protocol.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5681 (draft-ietf-tcpm-rfc2581bis-07)
--------------------------------------
Title               : TCP Congestion Control
Publication Date    : September 2009
Author(s)           : M. Allman, V. Paxson, E. Blanton
Category            : DRAFT STANDARD
Source              : TCP Maintenance and Minor Extensions
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Ethan Blanton <[email-masked]>
Date: Wed, 6 Aug 2014 14:40:59 -0400

RFC Errata System spake unto us the following wisdom:
> The problem is the use of the phrase "new data" in an imprecise manner
> to sometimes mean "previously unacknowledged data" and other times
> mean "never before sent data".

I concur with Mark.  New data has a different meaning for TCP as a
receiver versus TCP as a sender.  I don't think this is anything we
introduced.  That said, when 5681 is next revved I see no harm in
differentiating the terms (or, at the very least, explicitly defining
the difference).

This errata seems inoffensive to me.

Ethan

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 7 Aug 2014 15:03:30 +0300

Yep, I agree. This seems an obvious "Hold for Document Update" case to me.

- Pasi