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

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

Return-Path: <in@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 23F5A3A0C6D; Fri, 1 Oct 2021 05:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, HTTPS_HTTP_MISMATCH=0.1, 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 Pt81uj2sANzy; Fri, 1 Oct 2021 05:43:46 -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 C84343A0C1A; Fri, 1 Oct 2021 05:43:45 -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:References:Cc:To:Subject:From: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=yf8VinxM4PVTZKpOqcH1l4HBORwXfqGZE6GzaMLcNpE=; b=xb/SPgj8a5usWNhg8b4HtQMfMC GilZZ78BWpBCZa7PGD4vEliEbAzWQy9GwafDkM6IP3swZ0CYBl4fnnz4Mr61Uigtdcjq+uBtEtl5z 0femsAYgHN88nOaiMRGXuRXuZSyCfvdbxGvueTJRS1/taFXnevyFYwbNdb+KH5xC/3gl6Fr0omZll Mkifb0oGlyAHsmai+fa/ru78xdreYKwqTgQsO0tt6UCc/rhHLrpl9KaUSIk2KuFKIpKdeRkw1iUW5 bOZn15PbrJOU0aE7iaTg1VczY1b+/45wCWH0kSPH45c/d+WFMEVcO0lcaCsZFVP7BtMwQM5YlUNJX daeEDR/w==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:57600 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 <in@bobbriscoe.net>) id 1mWHtD-00FrU2-Um; Fri, 01 Oct 2021 13:43:43 +0100
From: Bob Briscoe <in@bobbriscoe.net>
To: Praveen Balasubramanian <pravb@microsoft.com>, Vidhi Goel <vidhi_goel@apple.com>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Dave Thaler <dthaler@microsoft.com>, "lars@netapp.com" <lars@netapp.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsv-ads@ietf.org" <tsv-ads@ietf.org>, "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>
References: <20210928071818.BE0D7F40865@rfc-editor.org> <96ce4984-3678-9bdf-6b76-d7ba1bd42dcc@bobbriscoe.net> <AFA32955-1E60-4676-BED4-6F123EF5B593@apple.com> <SA0PR00MB1034ACE031DD2C85567084A2B6AA9@SA0PR00MB1034.namprd00.prod.outlook.com>
Message-ID: <6fc3902a-5f8f-c06b-1f21-2850ec2ea70f@bobbriscoe.net>
Date: Fri, 1 Oct 2021 13:43:41 +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: <SA0PR00MB1034ACE031DD2C85567084A2B6AA9@SA0PR00MB1034.namprd00.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------E77CF93DA8B64F0D430B51C9"
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/8ca70_Xtd-m8fYmuucxfbFg2g3s>
Subject: Re: [tcpm] [EXTERNAL] Re: [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 12:43:55 -0000

Praveen, [re-sending with trimmed distro to avoid rejection by list]

On 30/09/2021 22:14, Praveen Balasubramanian wrote:
>
> Trying to send my old response again as it got stuck in moderation.
>
> Great catch Vidhi!
>
> We don’t need to change the section numbers. ECE is processed on 
> acceptable ACK packets and there is already another bullet 3 which 
> specifies that condition:
>
> 3.  If the ECE flag is set, update the bytes marked:
>
>           DCTCP.BytesMarked += BytesAcked
>
> So all we need is:
>
>   9.  If the ECE flag is set, rather than always halving the 
> congestion window as described in
>
>        [RFC3168 <https://datatracker.ietf.org/doc/html/rfc3168>], the 
> sender SHOULD update cwnd as follows:
>
>           cwnd = cwnd * (1 - DCTCP.Alpha / 2)
>
> I don’t think we need the additional explanation of how to implement 
> the once per window reaction, even RFC 3168 does not specify those 
> details.
>

[BB] OK, maybe we don't need a new subsection. But the problem starts at 
item 4, which says:

    4.  If the acknowledgment number is less than or equal to
        DCTCP.WindowEnd, stop processing.  Otherwise, the end of the
        observation window has been reached, so proceed to update the
        congestion estimate as follows:


This says that the subsequent items in the list are only executed if 
(ackno > DCTCP.WindowEnd).
So, steps 5-8 really needed to be sub-bullets of step 4. And step 9 
would be renumbered step 5.

If we just add  "If the ECE flag is set" to step 9, it will mean that 
both conditions have to be met (ackno > DCTCP.WindowEnd && ECE), which 
is not what was intended. So the structure has to be changed somehow, 
not just some words.

I'm aware that RFC 3168 doesn't say anything about CWR state. Indeed, I 
checked RFC3168 before suggesting this sentence about CWR state, which 
was included to match the level of detail in the previous bullets about 
how the observation window is checked.

I won't fight for the final sentence that I suggested (the one 
explaining that the two periods are unrelated).

I suggest Vidhi would be the best judge of how much detail is needed, 
'cos she's reading it with fresh eyes, so she can say what she didn't 
understand.



Bob


> *From:* Vidhi Goel <vidhi_goel@apple.com>
> *Sent:* Thursday, September 30, 2021 2:07 PM
> *To:* Bob Briscoe <in@bobbriscoe.net>
> *Cc:* RFC Errata System <rfc-editor@rfc-editor.org>rg>; 
> sbens@microsoft.com; Dave Thaler <dthaler@microsoft.com>om>; Praveen 
> Balasubramanian <pravb@microsoft.com>om>; lars@netapp.com; 
> glenn.judd@morganstanley.com; Martin Duke <martin.h.duke@gmail.com>om>; 
> Zaheduzzaman.Sarker@ericsson.com; michael.scharf@hs-esslingen.de; 
> Michael Tuexen <tuexen@fh-muenster.de>de>; nsd.ietf@gmail.com; tcpm@ietf.org
> *Subject:* [EXTERNAL] Re: [tcpm] [Technical Errata Reported] RFC8257 
> (6697)
>
> Thank you Bob for providing a complete suggestion.
>
> Section 3.3 is titled */Processing Echoed Congestion Indications on 
> the Sender, /*so probably this should include Congestion Window 
> Reduction as well. That’s why I suggested to create two sub-sections.
>
>
>
> Alternatively, we can also use your suggestion by re-titling Section 
> 3.3, something like,
>
> Section 3.3 Computing Moving Average of ECN Feedback
>
> Section 3.4 Reducing Congestion Window based on ECN Feedback
>
> Section 3.5 Handling of Congestion Window Growth
>
> …
>
> Thanks,
>
> Vidhi
>
>
>
>     On Sep 30, 2021, at 4:48 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6697&data=04%7C01%7Cpravb%40microsoft.com%7C6adfa975d9744f6a289b08d984564c71%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637686328526119642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xqxUAHtiFNrST8HTP5sWFhpDq2SJ2%2Bsl8tQ%2Byh1OaUM%3D&reserved=0>
>
>         --------------------------------------
>
>         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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=04%7C01%7Cpravb%40microsoft.com%7C6adfa975d9744f6a289b08d984564c71%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637686328526119642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X63EYFpc%2FnO4Px7I61QHgopu4Qs09fOEYOhdWfeo%2F4U%3D&reserved=0>
>
>
>
>     -- 
>
>     ________________________________________________________________
>
>     Bob Briscoehttp://bobbriscoe.net/  <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbobbriscoe.net%2F&data=04%7C01%7Cpravb%40microsoft.com%7C6adfa975d9744f6a289b08d984564c71%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637686328526119642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lG5TRWIlxHSVIj6gDXj1I83tHKCkcfWfcVr%2BgnzzomI%3D&reserved=0>
>
>     _______________________________________________
>     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/