Re: [tcpm] [Editorial Errata Reported] RFC5681 (6233)

Charles Deng <cdeng@greatbeam.net> Tue, 21 July 2020 10:35 UTC

Return-Path: <cdeng@greatbeam.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 D47633A093C for <tcpm@ietfa.amsl.com>; Tue, 21 Jul 2020 03:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, MSGID_FROM_MTA_HEADER=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 l1H1G0uZl-fP for <tcpm@ietfa.amsl.com>; Tue, 21 Jul 2020 03:35:48 -0700 (PDT)
Received: from smtpbg501.qq.com (smtpbg501.qq.com [203.205.250.101]) (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 E91E73A0845 for <tcpm@ietf.org>; Tue, 21 Jul 2020 03:35:47 -0700 (PDT)
X-QQ-GoodBg: 0
X-QQ-SSF: 0010000000000020
X-QQ-FEAT: 7560NedJMvtze9AsuBIuek5yFrYVe907T2yGPjEyd41CF2/xJloRgvfbjHK2Z XGrwdxbB/h/BT2zcwDuWUiAom028iAOJgL0ZouupDJzit253KN2skxfmzux+Ax+VWGRA9/d e+yRkyxrz/Sm3F346GSSuRYYFGzbKIGIGhzanV9Mm3Gad8OnFQtboD3qafbzmTRo3JNXw4j OzyZHnMlQdpA5w9kMUhfp+TJ/9DGEw0zyMF8wGdKTNZ+hCGipiON8ZXvdxL0NrpgiXvWkBK 88xcE8XtF0lp3pTAlDtJmmNoiIAnqu88gpeg==
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 219.128.53.23
X-QQ-STYLE:
X-QQ-mid: llogic42t1595327636t6544147
From: Charles Deng <cdeng@greatbeam.net>
To: Mark Allman <mallman@icir.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Cc: vern <vern@icir.org>, eblanton <eblanton@cs.purdue.edu>, "martin.h.duke" <martin.h.duke@gmail.com>, "magnus.westerlund" <magnus.westerlund@ericsson.com>, "michael.scharf" <michael.scharf@hs-esslingen.de>, tuexen <tuexen@fh-muenster.de>, "nsd.ietf" <nsd.ietf@gmail.com>, tcpm <tcpm@ietf.org>, Ethan Blanton <elb@psg.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_5F16C494_1633CD28_45C45F21"
Content-Transfer-Encoding: 8bit
Date: Tue, 21 Jul 2020 18:33:56 +0800
X-Priority: 3
Message-ID: <tencent_22405F91254B415F5520AF1B@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
References: <20200720144303.4A497F40759@rfc-editor.org> <4A9C6361-639D-459A-818B-7F2027CF5384@icir.org>
In-Reply-To: <4A9C6361-639D-459A-818B-7F2027CF5384@icir.org>
X-QQ-ReplyHash: 2241690902
X-QQ-SENDSIZE: 520
Received: from qq.com (unknown [127.0.0.1]) by smtp.qq.com (ESMTP) with SMTP id ; Tue, 21 Jul 2020 18:33:58 +0800 (CST)
Feedback-ID: llogic:greatbeam.net:qybgweb:qybgweb11
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/zSZvCeX3aSIcLSmTR5nJgJci3uY>
X-Mailman-Approved-At: Wed, 22 Jul 2020 10:03:39 -0700
Subject: Re: [tcpm] [Editorial Errata Reported] RFC5681 (6233)
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: Wed, 22 Jul 2020 12:14:58 -0000

Hi Mark,


&nbsp; &nbsp;Thanks for your clarification. I got understand that the cwnd should be set to no more than ssthresh.


&gt;&gt;And, it may well be that we actually meant to use CA in this case even if cwnd < ssthresh for some reason I am mis-remembering.&nbsp;


&nbsp; &nbsp;but can you kindly clarify that a scenario TCP need get following CA rules when cwnd < ssthresh ?&nbsp; if there is a such scenario, it means TCP cannot only following rules of CA or SS according to values of cwnd and ssthresh but state flags something like SS state and CA state.


Best wishes
charles
&nbsp;
------------------&nbsp;Original&nbsp;------------------
From: &nbsp;"Mark Allman"<mallman@icir.org&gt;;
Date: &nbsp;Mon, Jul 20, 2020 11:08 PM
To: &nbsp;"RFC Errata System"<rfc-editor@rfc-editor.org&gt;; 
Cc: &nbsp;"vern"<vern@icir.org&gt;; "eblanton"<eblanton@cs.purdue.edu&gt;; "martin.h.duke"<martin.h.duke@gmail.com&gt;; "magnus.westerlund"<magnus.westerlund@ericsson.com&gt;; "michael.scharf"<michael.scharf@hs-esslingen.de&gt;; "tuexen"<tuexen@fh-muenster.de&gt;; "nsd.ietf"<nsd.ietf@gmail.com&gt;; "cdeng"<cdeng@greatbeam.net&gt;; "tcpm"<tcpm@ietf.org&gt;; "Ethan Blanton"<elb@psg.com&gt;; 
Subject: &nbsp;Re: [Editorial Errata Reported] RFC5681 (6233)

&nbsp;


&gt; The following errata report has been submitted for RFC5681,
&gt; "TCP Congestion Control".
&gt;
&gt; --------------------------------------
&gt; Type: Editorial
&gt; Reported by: Charles Deng <cdeng@greatbeam.net&gt;

This is not editorial as it would change the allowed operation of
the algorithms.

&gt; Section: 4.3
&gt;
&gt; Original Text
&gt; -------------
&gt; Finally, after all loss in the given window of segments
&gt; has been successfully retransmitted, cwnd MUST be set to no more than
&gt; ssthresh and congestion avoidance MUST be used to further increase
&gt; cwnd.
&gt;
&gt; Corrected Text
&gt; --------------
&gt; Finally, after all loss in the given window of segments
&gt; has been successfully retransmitted, cwnd MUST be set to no less than
&gt; ssthresh and congestion avoidance MUST be used to further increase
&gt; cwnd.
&gt;
&gt; Notes
&gt; -----
&gt; if set cwnd no more than ssthresh, it will using slow start
&gt; algorithm instead of congestion avoidance algorithm. so it should
&gt; say "cwnd no less than ..." instead of "cwnd no more than ...".

This is incorrect and the errata should be rejected.

The wording isn't particularly great, but the idea is that at the
end of the loss period we want cwnd to be half of the outstanding
data when we first detected loss.&nbsp; And, in particular, we
**certainly do not want** cwnd to be LARGER than half the
outstanding data when loss occurred.&nbsp; And, by saying "cwnd MUST be
no **LESS**" we are specifying that it must be larger-than-half.
So, this language is a clearly both (a) a non-editorial algorithm
change and (b) wrong.

The wording leads to the confusion, however, I think.&nbsp; If one were
to set cwnd to less than ssthresh (hence being more conservative)
then we'd probably slow start to ssthresh before entering congestion
avoidance, as the proposed errata notes.

If I were to do anything here I think I'd strike "and congestion
avoidance MUST be used to further increase cwnd" from the end of the
sentence.&nbsp; I.e., just let what naturally happens happen.&nbsp; But, the
current text is conservative.&nbsp; And, it may well be that we actually
meant to use CA in this case even if cwnd < ssthresh for some reason
I am mis-remembering.&nbsp; So, I'd want to page all that back in before
agreeing with any errata.&nbsp; I am not sure it's really that big of a
problem to worry about.

allman