Re: [tcpm] [Technical Errata Reported] RFC8257 (6697)

Bob Briscoe <ietf@bobbriscoe.net> Fri, 01 October 2021 13:12 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C9D3A0B79; Fri, 1 Oct 2021 06:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 4tmOVyHaGp9G; Fri, 1 Oct 2021 06:12:40 -0700 (PDT)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369413A0AB4; Fri, 1 Oct 2021 06:12:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1kyQzcPrJH1Jd+e8ZP9cM5JN8jB8QyiBeAhfLEvUiYI=; b=b+r/9uLZ3GceRID8wZs3lv96L4 bXrYiJcGgIiiJaXmenTcmV9zKH46Uedx9CZaqGKHdSuCvRRQlYH2CB118JMRaM/zKenld9I92yw9l jN2Y/rWgYjQNjEKS6AvEpNVMhUVG+Rb/SCNCKuc0bT1XpMS9qegNLVWJma9rEMgHIbi9kc3o/yCE/ 8daIqHp9D56WWfn23F/pX3wARVkqPr1K1UjcLdQpSOANGrkW2ihfXAKQPeFo6wlqtlHRfn4vQoezD U7dgjTzyCWw8nlP2xT6lVFuNhS6gYM1MO4Y9SLFJymceKUPnOkl45XZAKxcsIbekium0iwtHgj2fH tP8gRifw==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:57714 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <ietf@bobbriscoe.net>) id 1mWILC-00GN8j-CK; Fri, 01 Oct 2021 14:12:37 +0100
To: Neal Cardwell <ncardwell@google.com>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, dthaler@microsoft.com, pravb@microsoft.com, lars@netapp.com, tcpm@ietf.org, "tsv-ads@ietf.org" <tsv-ads@ietf.org>, "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>, Vidhi Goel <vidhi_goel@apple.com>
References: <20210928071818.BE0D7F40865@rfc-editor.org> <96ce4984-3678-9bdf-6b76-d7ba1bd42dcc@bobbriscoe.net> <CADVnQymMRzvs_4QRuSziYXfwu6ttKfak5cv5G=eBRvX8qOQKWw@mail.gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <d1514f76-fc40-fa73-c953-efcb70fe6901@bobbriscoe.net>
Date: Fri, 1 Oct 2021 14:12:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <CADVnQymMRzvs_4QRuSziYXfwu6ttKfak5cv5G=eBRvX8qOQKWw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------5D3F7E115862704ED90FB9A6"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/53jKv31uE1QM3ZQ9I31aZYy9-rA>
Subject: Re: [tcpm] [Technical Errata Reported] RFC8257 (6697)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Oct 2021 13:12:47 -0000

Neal,

On 30/09/2021 16:43, Neal Cardwell wrote:
> I agree with the points made by Vidhi and Bob, and really like Bob's text.
>
> In the suggested text there may be a typo; I believe we want 
> s/SND.UNA/SND.NXT/.

[BB] Agree (and your next point about solely ECN indications).

I only said SND.UNA 'cos I was looking back at this earlier sentence in 
the RFC, and I copied the idea without engaging brain:

    o  DCTCP.WindowEnd: the TCP sequence number threshold when one
       observation window ends and another is to begin; initialized to
       SND.UNA.

Why does this say SND.UNA? Is this another erratum? I believe the Linux 
code initializes to SND.NXT in dctcp_reset(), which is called from 
dctcp_init():
https://elixir.bootlin.com/linux/v4.7/source/net/ipv4/tcp_dctcp.c#L78

BTW, step 7 correctly says SND.NXT:

    7.  Determine the end of the next observation window:

           DCTCP.WindowEnd = SND.NXT




Bob

> And probably we want to be more specific about only suppressing 
> further ECN-based reductions (further loss-triggered reductions would 
> be good to allow). I'm posting my suggested tweaks in blue, starting 
> from Bob's nice green text:
>
> SUGGESTED:
> ==========
>
> *3.4. Congestion Window Reduction*
>     Rather than always halving the congestion window as described in
>     [RFC3168]*, on the arrival of ECNcongestion feedback,*  the sender SHOULD
>     update cwnd as follows:
>
>        cwnd = cwnd * (1 - DCTCP.Alpha / 2)
>     Just as specified in [RFC3168], DCTCP does not react to congestion
>     indications more than once for every window of data.*Therefore, as for RFC3168 ECN, it sets the variable for the end of 
> congestion  window reduced (CWR) state to SND.NXTand suppresses 
> further ECN-triggeredreductions until this TCP sequence number is 
> acknowledged. Periods  of CWR state are triggered by congestion 
> feedback, and therefore  occur at times unrelated to the continuous 
> cycle of observation  windows used to update DCTCP.Alpha in Section 3.3.*
>
>     The setting of the CWR bit is also as per [RFC3168].  This is
>     required for interoperation with classic ECN receivers due to
>     potential misconfigurations.
>
> 3.*5*.  Handling of Congestion Window Growth...
>
> neal
>
>
> On Thu, Sep 30, 2021 at 11:22 AM Bob Briscoe <in@bobbriscoe.net 
> <mailto:in@bobbriscoe.net>> wrote:
>
>     Vidhi,
>
>     You're right. It's incorrect to have the window reduction hanging
>     off the end of the list of steps for updating the EWMA.
>
>     To make this concrete, here's some specific additional text (in
>     green for those with HTML mail readers). Also, rather than
>     splitting into sub-subsections, I have suggested that Item 9. of
>     the list in subsection 3.3 is moved out of the list, and instead
>     forms the basis of a new subsection 3.4. entitled "Congestion
>     Window Reduction".
>
>     CURRENT:
>     ========
>
>         9.  Rather than always halving the congestion window as described in
>             [RFC3168], the sender SHOULD update cwnd as follows:
>
>                cwnd = cwnd * (1 - DCTCP.Alpha / 2)
>
>         Just as specified in [RFC3168], DCTCP does not react to congestion
>         indications more than once for every window of data.  The setting of
>         the CWR bit is also as per [RFC3168].  This is required for
>         interoperation with classic ECN receivers due to potential
>         misconfigurations.
>
>     3.4. Handling of Congestion Window Growth...
>
>     SUGGESTED:
>     ==========
>
>     *3.4. Congestion Window Reduction*
>
>         Rather than always halving the congestion window as described in
>         [RFC3168]*, on the arrival of congestion feedback,*  the sender SHOULD
>         update cwnd as follows:
>
>            cwnd = cwnd * (1 - DCTCP.Alpha / 2)
>
>         Just as specified in [RFC3168], DCTCP does not react to congestion
>         indications more than once for every window of data.*Therefore, as for RFC3168 ECN, it sets the variable for the end
>     of congestion  window reduced (CWR) state to SND.UNA and
>     suppresses further  reductions until this TCP sequence number is
>     acknowledged. Periods  of CWR state are triggered by congestion
>     feedback, and therefore  occur at times unrelated to the
>     continuous cycle of observation  windows used to update
>     DCTCP.Alpha in Section 3.3.*
>
>         The setting of the CWR bit is also as per [RFC3168].  This is
>         required for interoperation with classic ECN receivers due to
>         potential misconfigurations.
>
>     3.*5*. Handling of Congestion Window Growth...
>
>
>     Then the of numbering all subsequent subsections of section 3.
>     will increment by 0.1.
>
>
>
>     Bob
>
>     On 28/09/2021 08:18, RFC Errata System wrote:
>>     The following errata report has been submitted for RFC8257,
>>     "Data Center TCP (DCTCP): TCP Congestion Control for Data Centers".
>>
>>     --------------------------------------
>>     You may review the report below and at:
>>     https://www.rfc-editor.org/errata/eid6697  <https://www.rfc-editor.org/errata/eid6697>
>>
>>     --------------------------------------
>>     Type: Technical
>>     Reported by: Vidhi Goel<vidhi_goel@apple.com>  <mailto:vidhi_goel@apple.com>
>>
>>     Section: 3.3
>>
>>     Original Text
>>     -------------
>>     The below pseudocode follows after DCTCP.Alpha is updated on ACK processing. This is wrong as cwnd should only be reduced using DCTCP.Alpha when ECE is received.
>>
>>     9. Rather than always halving the congestion window as described in
>>             [RFC3168], the sender SHOULD update cwnd as follows:
>>
>>                cwnd = cwnd * (1 - DCTCP.Alpha / 2)
>>
>>     Corrected Text
>>     --------------
>>     Instead, a new paragraph for Congestion Response to ECN feedback would be much clearer. First start with RFC 3168's response to ECE and then provide DCTCP's response to ECE.
>>
>>     I am thinking splitting section 3.3 into two sub-sections -
>>     3.3.1 Computation of DCTCP.Alpha
>>     3.3.2 Congestion Response to ECE at sender
>>
>>
>>
>>     Notes
>>     -----
>>     Although RFC 8257 refers to RFC 3168 congestion window halving at step 9, but it is confusing to put it right after step 8.
>>
>>     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.
>>
>>     --------------------------------------
>>     RFC8257 (draft-ietf-tcpm-dctcp-10)
>>     --------------------------------------
>>     Title               : Data Center TCP (DCTCP): TCP Congestion Control for Data Centers
>>     Publication Date    : October 2017
>>     Author(s)           : S. Bensley, D. Thaler, P. Balasubramanian, L. Eggert, G. Judd
>>     Category            : INFORMATIONAL
>>     Source              : TCP Maintenance and Minor Extensions
>>     Area                : Transport
>>     Stream              : IETF
>>     Verifying Party     : IESG
>>
>>     _______________________________________________
>>     tcpm mailing list
>>     tcpm@ietf.org  <mailto:tcpm@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/tcpm  <https://www.ietf.org/mailman/listinfo/tcpm>
>
>     -- 
>     ________________________________________________________________
>     Bob Briscoehttp://bobbriscoe.net/  <http://bobbriscoe.net/>
>
>     _______________________________________________
>     tcpm mailing list
>     tcpm@ietf.org <mailto:tcpm@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tcpm
>     <https://www.ietf.org/mailman/listinfo/tcpm>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/