Re: [tsvwg] [Editorial Errata Reported] RFC3168 (5966)

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 04 March 2020 10:12 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A833A0B48 for <tsvwg@ietfa.amsl.com>; Wed, 4 Mar 2020 02:12:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNFXjNRapifi for <tsvwg@ietfa.amsl.com>; Wed, 4 Mar 2020 02:12:15 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A383A00AD for <tsvwg@ietf.org>; Wed, 4 Mar 2020 02:12:15 -0800 (PST)
Received: from p200300dee7239a0084809b28d0f22131.dip0.t-ipconnect.de ([2003:de:e723:9a00:8480:9b28:d0f2:2131]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j9R0V-0002rb-Bb; Wed, 04 Mar 2020 11:12:03 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <20200126005704.253B1F406DB@rfc-editor.org>
Date: Wed, 4 Mar 2020 11:12:02 +0100
Cc: kk@teraoptic.com, black_david@emc.com, Magnus Westerlund <magnus.westerlund@ericsson.com>, david.black@dell.com, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Wesley Eddy <wes@mti-systems.com>, Richard Scheffenegger <rscheff@gmx.at>
Content-Transfer-Encoding: quoted-printable
Message-Id: <414A38D3-915C-4C82-AAD6-FDEB1B2929E9@kuehlewind.net>
References: <20200126005704.253B1F406DB@rfc-editor.org>
To: tsvwg@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1583316735;fdd80289;
X-HE-SMSGID: 1j9R0V-0002rb-Bb
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/aYwZaDBLsKW-jiHfcefrq3DnuZI>
Subject: Re: [tsvwg] [Editorial Errata Reported] RFC3168 (5966)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 10:12:17 -0000

Hi tsvwg,

Another errata on RFC3168.

I think this whole errata is a change that goes beyond just being an errata, therefore I would suggest to mark this as “Held for Document Update”.

I guess we could have an errata for only adding the word “new” in section 6.1 but that would need to be a separate errata then. 

Any opinions?

Mirja



> On 26. Jan 2020, at 01:57, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC3168,
> "The Addition of Explicit Congestion Notification (ECN) to IP".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5966
> 
> --------------------------------------
> Type: Editorial
> Reported by: Richard Scheffenegger <rscheff@gmx.at>
> 
> Section: 6.1
> 
> Original Text
> -------------
> Section 6.1 states:
> 
>      * The sender sets the CWR flag in the TCP header of the next
>        packet sent to the receiver to acknowledge its receipt of and
>        reaction to the ECN-Echo flag.
> 
> section 6.1.2 clarifies:
> 
> 
>   We ensure that the "Congestion Window Reduced" information is
>   reliably delivered to the TCP receiver.  This comes about from the
>   fact that if the new data packet carrying the CWR flag is dropped,
>   then the TCP sender will have to again reduce its congestion window,
>   and send another new data packet with the CWR flag set.  Thus, the
>   CWR bit in the TCP header SHOULD NOT be set on retransmitted packets.
> 
>   When the TCP data sender is ready to set the CWR bit after reducing
>   the congestion window, it SHOULD set the CWR bit only on the first
>   new data packet that it transmits.
> 
> Corrected Text
> --------------
> Section 6.1 should say:
> 
> 
>      * The sender sets the CWR flag in the TCP header of the next new 
>        data packet sent to the receiver to acknowledge its receipt of and
>        reaction to the ECN-Echo flag.
> 
> Section 6.1.2 should clarify, that a receiver MUST process an incoming CWR 
> on any incoming segment, and not exclude non-new-data segments.
> 
> This clarification allows new semantics to be used by a sender-side only 
> change, and should be taken into account by all documents updating RFC3168.  
> 
> Notes
> -----
> Discrepancies in the above text lead to poorly interoperating implementations. In NetBSD (and derived implementationd), the "SHOULD set CWR on new data" was used liberal in setting CWR on the very next packet to be sent, regardless of type. While at the same time the Linux implementation performed very stingent tests on the receiver side, if the sender was complying with the "SHOULD" like a "MUST". In request-response session with frequently changing data direction, this leads to a collapse of the congestion window, as the *BSD side will continue to interpret the still latched ECE flag as an indication of another RTT of congestion.
> 
> 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  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC3168 (draft-ietf-tsvwg-ecn-04)
> --------------------------------------
> Title               : The Addition of Explicit Congestion Notification (ECN) to IP
> Publication Date    : September 2001
> Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
> Category            : PROPOSED STANDARD
> Source              : Transport Area Working Group
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG
>