Subject: Re: [tcpm] [Technical Errata Reported] RFC5681 (2269)

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 18 May 2010 12:02:39 -0500

I think this errata should be rejected, as 3042 behavior
is referenced as a SHOULD on page 9, when implementing
fast retransmit + fast recovery, and this material is
new for 5681 (it was not part of 2581), but I think we
need to discuss this on the TCPM list and let our ADs
know how to handle it.

--
Wes Eddy
MTI Systems

>-----Original Message-----
>From: RFC Errata System [mailto:[email-masked]]
>Sent: Tuesday, May 18, 2010 12:28 PM
>To: [email-masked]; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: [Technical Errata Reported] RFC5681 (2269)
>
>
>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=2269
>
>--------------------------------------
>Type: Technical
>Reported by: Nikolai Malykh <[email-masked]>
>
>Section: 7
>
>Original Text
>-------------
>   The description of fast retransmit and fast recovery has been
>   clarified, and the use of Limited Transmit [RFC3042] is now
>   recommended.
>
>
>Corrected Text
>--------------
>   The description of fast retransmit and fast recovery has been
>   clarified.
>
>
>Notes
>-----
>Really using of Limited Transmit [RFC3042] is not recommended anywhere
>in RFC 5681.
>
>Instructions:
>-------------
>This errata 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: RFC Errata System <[email-masked]>
Date: Tue, 18 May 2010 09:27:38 -0700 (PDT)

Section: 7

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

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

Notes
-----
Really using of Limited Transmit [RFC3042] is not recommended anywhere in RFC 5681.

Instructions:
-------------

---

From: Mark Allman <[email-masked]>
Date: Thu, 20 May 2010 15:57:19 -0400

I request this report be rejected.

It is simply wrong.  On page 9 of RFC 5681:

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

That, in effect, says we recommend using Limited Transmit by saying you
SHOULD do what [RFC3042] says to do (send on the first and second dups).
SHOULD and RECOMMENDED are basically equivalent.  Even if the words "we
recommend Limited Transmit" don't appear in the document this has the
same effect.

Further, the note in question is in a non-normative list of changes so
this is at best needless nit picking.

allman

---

From: Lars Eggert <[email-masked]>
Date: Fri, 21 May 2010 08:57:53 +0300

It looks like we have consensus. I rejected the errata. Thanks for the quick resolution.

Lars

---

From: Vern Paxson <[email-masked]>
Date: Thu, 20 May 2010 20:01:06 -0700

> It is simply wrong.  On page 9 of RFC 5681:

(I read this independently and came to the exact same conclusion.)

		Vern