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

Richard Scheffenegger <rscheff@gmx.at> Wed, 04 March 2020 10:47 UTC

Return-Path: <rscheff@gmx.at>
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 C5B193A0C47 for <tsvwg@ietfa.amsl.com>; Wed, 4 Mar 2020 02:47:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.46
X-Spam-Level:
X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 tbDhcsRiKL0q for <tsvwg@ietfa.amsl.com>; Wed, 4 Mar 2020 02:46:59 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 508833A0C1A for <tsvwg@ietf.org>; Wed, 4 Mar 2020 02:46:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1583318796; bh=zBjOp6cgHDffXQ7CfbSnBMQHQlHXO2ab9y74fZAPqGU=; h=X-UI-Sender-Class:From:To:Cc:References:Subject:Date; b=aJy8e6ikWovINz9oCIYZlt55z/QO0P5HgKFFZPEX7h8l3stEMppWkplCFIQo3F3U6 qeA2ByTHUQbXcX0v26XJIi3k5J0CS4VcOAAwGPQzCPlXUbkI3E/SJuJdoL9vpWL8F3 1rbwMAIc1wX9HTjM3GUwu+v2llqffiF0mrv31VAM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from srichardlxp2 ([185.236.167.136]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MJVHU-1ipipo0JWy-00JsBd; Wed, 04 Mar 2020 11:46:36 +0100
Message-ID: <32AD4D853B034B2EA08C71260781C3AC@srichardlxp2>
From: "Richard Scheffenegger" <rscheff@gmx.at>
To: "Mirja Kuehlewind" <ietf@kuehlewind.net>, <tsvwg@ietf.org>
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>
References: <20200126005704.253B1F406DB@rfc-editor.org> <414A38D3-915C-4C82-AAD6-FDEB1B2929E9@kuehlewind.net>
Date: Wed, 4 Mar 2020 11:45:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Provags-ID: V03:K1:VtkMUkdF+VHZWwNdogXuFiucmLXXizF9BICGYGuXLpNFlmLk9kx u1vMX59gB7Zma0BaCMTG9Pk8mgywJUzOCVAF/HWU47t2zkod1A6walXI+yCLBT+LD6K29WK 3azUHG5ll7hlc2ImJFde4OAH1NiVFm7vfzRCEDd2P2YQXJqbASdCKDYKUFow5qDBm1X1lNR UKYIo/AYiriq3mPWhKWDw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:UgNn6ttsQPY=:p3urHYkuMV4UZ1A24mFM8Z RsSzbDlYA30Qij8rx+uhs9hstK59NeYmJAkz8EKldq68JFNZucsqBt3QXTsM13TyaG1FRadkk fiNH5Q5BZl0EHNBTTDayVewxMxoJltCKf4LiQKePrxOA1yWgZq+ck8e7OeR5jtXV8+6qFpmuW G48OCRMh7fipbzRc1sOMKFaPV8c5sY10fyWYXwbMzzLxZ0RwXGPn9XsjHLgCoNrCipeoJooUg 1XnZDOo0vVBLmdVuKYd8y/VidH+1Cr7LIS5qel6gEXRKcnHO/M5/FO6nKoPOGYa7rADYb+eBe LLKJrn/+/kSY4c1Pja4gLUvAijySM35RXSiC9oJcI4Mo0PC5uf0U4tZKdh3P0GgxuROvk/MaP WquIhLino9Qcj8jnEZYatRorAtLBzyJHzvAKBUCU4shRurBitBxvyrseOWO6T5sG0gzPynjkQ yPTJ4zeW3D3JgjZsVzSRWCWHsMJsxmcmtrzBCf5vS46dm8DEKUE0TTcdcwCS0NahY5xxlOjav EEsBms6BkSVgUg7VAcFLOvflJ+z74Sy2qyRFrtpHXePZHfkNujgzGN0AK3f4UH+IVpyA1hRub 1FBa2fUD9TzzzZWuayexTjpTl94ND9ChVNGngEW+2vpCq+bgfTWUrrT7ORVEgIwaf+qgJYVfs +P/ZYlrZwv+iTBmum/9bpS87RwmhfeNjZIZcBJY07YvfkdHESRGe7Ivz3qrr2o6Ho/thkagCB ukl7brMtgzzrVRI3gAXXP5Hx81MDYvjMrULngfRwgMf/Hxo41CHgjLLJLPcEuxn3JTnITWv7c 9ykrgtf7vUVrn9nBrRoYImSb7Bn6s5ddfVPbd1jCXSnwE5tF3OYwMbexn/PIZTd1du+s40e7m Rb8CR9usx8EHxz4V42/Xkhm18SZR2Axn+6IXR+esQNdTJuxn+nAuxWtSLbiwv8wMYo15YGG4x KHBJ23CW4H7EuoJujcFpoYrCt1U6jTDorC3O+t2Xv6953x/NaTclrV1nQThvLml0Hpz89QhwA rp96pVQTo7f2Gd9Xn3YDwOOR1ICkJr+jckx3ZU8iZJbYIAT6gVe585M8N+55dXk0ko75bGW2V 15+7+1qj/W761ulB5QZn04fUhWSD6nYFld7XHxOSYPmd9xyYEE8s5xGAK7OJd05XpxZgvnjjs VBC0qHBWw+4DCm2x1E8qhALttHeYQSt2PUMdZArH2048kCF5MJmSRPLyM5c30Typ67qdH1BQr lwgO5HKCaCC/es8sC
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/FZZiwQXbX2mrrA83LFpEPJsWs90>
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:47:09 -0000

I think clarification of the CWR handling should also be mentioned in ECN++,
since ECT setting there is allowed on every packet.

In the fbsd environment, as 3168 allows ECT only on new data packets while
sending, it is easy to send out CWR only when ECT is also set (in the same
check).

Simply enhancing this in ECN++ to allow setting ECT on any packet, may
result in also sending CWR on control packets without data. And Bob made a
compelling case, a sender needs to reliably know when a window, during which
congestion occured, ends (that is, sending cwr only with new data, or
differently, setting cwr when the octete snd_max+1 is sent in the stream.

E.g. in ecn++, the below corrected text would be prudent to have.

Best regards,
   Richard

----- Original Message -----
From: "Mirja Kuehlewind" <ietf@kuehlewind.net>
To: <tsvwg@ietf.org>
Cc: <kk@teraoptic.com>om>; <black_david@emc.com>om>; "Magnus Westerlund"
<magnus.westerlund@ericsson.com>om>; <david.black@dell.com>om>; "Gorry Fairhurst"
<gorry@erg.abdn.ac.uk>uk>; "Wesley Eddy" <wes@mti-systems.com>om>; "Richard
Scheffenegger" <rscheff@gmx.at>
Sent: Wednesday, March 04, 2020 11:12 AM
Subject: Re: [Editorial Errata Reported] RFC3168 (5966)


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
>