Re: [tcpm] finalizing CUBIC draft (chairs' view)

Vidhi Goel <vidhi_goel@apple.com> Sat, 10 September 2022 01:16 UTC

Return-Path: <vidhi_goel@apple.com>
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 D8079C1522BE; Fri, 9 Sep 2022 18:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.676
X-Spam-Level:
X-Spam-Status: No, score=-7.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-RV4yi0JVW4; Fri, 9 Sep 2022 18:16:50 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.rno.apple.com [17.179.253.48]) (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 348B7C1522BF; Fri, 9 Sep 2022 18:16:45 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 28A15DTR007064; Fri, 9 Sep 2022 18:16:35 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=0rWoafHtsC8qWoLAndRM5ZrmQu/4LiY7AvC8bSwFaT0=; b=AHnrOaclHZtMHlD9pmMjEYiZPG8pg7f/Jhb6cthmyY/tj0bN0jQgVJAUbM1yw52p5I/q msK7Z4XkDF4UbSy7HaHy5sbg7qiID1WaTmVWCMA5CC6UVul746mNErKIYGuDV2Zfy9Lk JVntaJiR572EoyCJwWlu1i1jRMWfEliD+qQt5rKFRaphlUEZyUaNL2ZE0LJiw5SVxymI aHwuRTDZ0PRz2/Y5qpv58rLqSPVFcRY7FsthQEgUWSJdo1KEph2O/QGuKx7WY6Gr2u53 k2wKrKXyG97pp+R1G8pBfAY4yb0cpfDMb3RXQskWPJtMmS8nf9gn2baHuKJTTFToJKls Ww==
Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3jcphv641j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 09 Sep 2022 18:16:35 -0700
Received: from rn-mailsvcp-policy-lapp01.rno.apple.com (rn-mailsvcp-policy-lapp01.rno.apple.com [17.179.253.18]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPS id <0RHY00XZLZJNGI00@rn-mailsvcp-mta-lapp02.rno.apple.com>; Fri, 09 Sep 2022 18:16:35 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-policy-lapp01.rno.apple.com by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) id <0RHY00W00Z75GS00@rn-mailsvcp-policy-lapp01.rno.apple.com>; Fri, 09 Sep 2022 18:16:35 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 7da9072df45f3e2430767b5aae1f1b1e
X-Va-E-CD: 2c480f7b23ce5a40323d08d68a76c059
X-Va-R-CD: 0c6adb0f42dedfc172b1202202661e9a
X-Va-CD: 0
X-Va-ID: 7888ae58-9919-4cb5-b8d7-bcbeb9fcc8ab
X-V-A:
X-V-T-CD: 7da9072df45f3e2430767b5aae1f1b1e
X-V-E-CD: 2c480f7b23ce5a40323d08d68a76c059
X-V-R-CD: 0c6adb0f42dedfc172b1202202661e9a
X-V-CD: 0
X-V-ID: 21cc7f92-5603-4ad3-83ad-2c1840ce60da
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.528, 18.0.895 definitions=2022-09-09_12:2022-09-09, 2022-09-09 signatures=0
Received: from smtpclient.apple (unknown [17.234.37.201]) by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPSA id <0RHY00T9RZJNKB00@rn-mailsvcp-policy-lapp01.rno.apple.com>; Fri, 09 Sep 2022 18:16:35 -0700 (PDT)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <82C74854-E163-492E-AE87-752547485F7B@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_CC51466A-431E-4752-B249-CC9103BFD47D"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Date: Fri, 09 Sep 2022 18:16:34 -0700
In-reply-to: <8095f93b-0563-e227-5f70-ab96801c8da8@bobbriscoe.net>
Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>, "draft-ietf-tcpm-rfc8312bis@ietf.org" <draft-ietf-tcpm-rfc8312bis@ietf.org>
To: Bob Briscoe <in@bobbriscoe.net>
References: <CAAK044T0chaZeTy1MAksoohmsqO03LF4bxMqGcxb6FFHVrt3DA@mail.gmail.com> <8E1E098D-F28F-4997-9B60-57CF8702547D@apple.com> <F7D4560A-9FAB-4E84-AD7A-18C731B05BB4@apple.com> <8095f93b-0563-e227-5f70-ab96801c8da8@bobbriscoe.net>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.528, 18.0.895 definitions=2022-09-09_12:2022-09-09, 2022-09-09 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/cQ-SBh3eRMyV6jhtJH4wqZsedo8>
Subject: Re: [tcpm] finalizing CUBIC draft (chairs' view)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 10 Sep 2022 01:16:54 -0000

Hello Bob,

Thank you for the suggested text. I have updated the PR to include your suggestion. Please take a look.

We can wait for the arXiv link before merging this PR.

Vidhi

> On Sep 9, 2022, at 10:16 AM, Bob Briscoe <in@bobbriscoe.net> wrote:
> 
> Vidhi and co-authors, Yoshi, tcpm,
> 
> 1/ I'm happy with all three PRs being marked as resolved, with one caveat...
> The ref to the AIMD fairness paper we've produced in order to help get this through will need to be updated with a new URL once I submit it to arXiv (arXiv is a preprint archive that is acceptable to the RFC Editor). I'll do that once I tie up the remaining minor ToDo notes in the paper (hopefully over the weekend).
> 
> 2/ I do have a question, on the following text in the intro.
> I'm afraid this prolongs the "WGLC" on rfc8312bis even more. But I've also suggested how I think the question should be answered, in the expectation that this will resolve a contradiction between RFCs, which might in future close off some of the debate we've been through.
> 
> 
> rfc8312bis, section 1:
>    ...Based on the extensive
>    deployment experience with CUBIC, it also moves the specification to
>    the Standards Track, obsoleting [RFC8312 <https://datatracker.ietf.org/doc/html/rfc8312>].  This requires an update
>    to [RFC5681 <https://datatracker.ietf.org/doc/html/rfc5681>], which limits the aggressiveness of Reno TCP
>    implementations in its Section 3 <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis#section-3>.  Since CUBIC is occasionally more
>    aggressive than the [RFC5681 <https://datatracker.ietf.org/doc/html/rfc5681>] algorithms, this document updates
>    [RFC5681 <https://datatracker.ietf.org/doc/html/rfc5681>] to allow for CUBIC's behavior.
> 
> My question is, what is the new rule that section 3 of RFC5681 has been updated to, in order to allow CUBIC's behaviour?
> Here's the text in RFC5681 that is being updated:
> 
> RFC5681, Section 3:
>    ...In some situations, it may be
>    beneficial for a TCP sender to be more conservative than the
>    algorithms allow; however, a TCP MUST NOT be more aggressive than the
>    following algorithms allow (that is, MUST NOT send data when the
>    value of cwnd computed by the following algorithms would not allow
>    the data to be sent).
> Are we saying the new rule is that a TCP MUST NOT be more aggressive than CUBIC now? 
> Or are we still saying that a TCP MUST NOT be more aggressive than Reno [RFC5681] unless it's CUBIC?
> 
> It's like the Government has been enforcing a lockdown. Then the same Government publishes an invitation to a party saying "bring your own booze, lockdown rules do not apply." Does it mean the rules no longer apply at all, or only for this one party?
> 
> I think the problem here is that RFC5681 inherited this section 3 text from RFC2581, but without recognizing that, in the intervening time, RFC5033 had been published, precisely to allow for congestion controls like CUBIC. So I suggest we ought to say this:
> 
> rfc8312bis, section 1:
>    ...Based on the extensive
>    deployment experience with CUBIC, it also moves the specification to
>    the Standards Track, obsoleting [RFC8312 <https://datatracker.ietf.org/doc/html/rfc8312>].  This requires an update
>    to [RFC5681 <https://datatracker.ietf.org/doc/html/rfc5681>], which limits the aggressiveness of Reno TCP
>    implementations in its Section 3 <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis#section-3>.  Since CUBIC is occasionally more
>    aggressive than the [RFC5681 <https://datatracker.ietf.org/doc/html/rfc5681>] algorithms, this document updates
>    the first paragraph of section 3 of [RFC5681 <https://datatracker.ietf.org/doc/html/rfc5681>], replacing it with a 
>    normative reference to guideline (1) in section 3. of [RFC5033], 
>    which allows for CUBIC's behavior.
> 
> This could be considered as correcting an error in RFC5681, which otherwise contradicts RFC5033 (and doesn't even reference it).
> 
> Later in the intro, rfc8312bis says that it's not clear whether /the process/ in RFC5033 applies to CUBIC. 
> But I think that is not incompatible with invoking one of the guidelines in RFC5033 to update RFC5681, in order to clarify what the new rule is that we are following in order to publish rfc8312bis.
> 
> 
> 
> Bob
> 
> On 09/09/2022 02:29, Vidhi Goel wrote:
>> For all remaining issues, PR is here - https://github.com/NTAP/rfc8312bis/pull/152 <https://github.com/NTAP/rfc8312bis/pull/152>
>> 
>> Michael,
>> I have added some changes to replace the ambiguous “convergence” word with text that clearly states what is the impact of 0.7. 
>> 
>> 
>> Looking forward to hear feedback/comments.
>> 
>> Thanks,
>> Vidhi
>> 
>>> On Sep 8, 2022, at 8:39 AM, Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org> <mailto:vidhi_goel=40apple.com@dmarc.ietf.org> wrote:
>>> 
>>> Thank you Neal and Yoshi.
>>> 
>>> I will create PRs today and add you as reviewers. Will send PR links on the mailing list as well.
>>> 
>>> Vidhi 
>>> 
>>>> On Sep 7, 2022, at 10:55 PM, Yoshifumi Nishida <nsd.ietf@gmail.com> <mailto:nsd.ietf@gmail.com> wrote:
>>>> 
>>>> 
>>>> Hi Vidhi, Neal,
>>>> 
>>>> Thank you so much for the proposed texts.
>>>> I personally might want to add some minor updates on them, but overall they look good to proceed.
>>>> Once pull requests have been made, I will make some comments on them to finalize.
>>>> 
>>>> Thanks,
>>>> --
>>>> Yoshi
>>>> 
>>>> On Wed, Sep 7, 2022 at 8:50 AM Neal Cardwell <ncardwell@google.com <mailto:ncardwell@google.com>> wrote:
>>>> 
>>>> 
>>>> On Tue, Sep 6, 2022 at 7:46 PM Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>> wrote:
>>>> Hi Yoshi,
>>>> 
>>>> Thank you for summarizing the last two remaining issues.
>>>> 
>>>>> Point 1: TCP friendly model in the cubic draft 
>>>>>      We can admit that the model is not valid as the paper describing the model uses some simplified presumptions. 
>>>>>      But, it doesn't not mean the model will pose serious issues on the Internet as we haven't seen any evidence yet.   
>>>> 
>>>> It’s not that the model is not valid at all, but it is not very precise. Copying a part of Bob’s response for this issue:
>>>> 
>>>> Summary: so far we show that the model that was used to calculate the cubic_alpha value of 0.53 is not absolutely precise, but it gives equal rate flows to a good approximation (within about 10% from analysis and even closer in experiments over an AQM). So it is extremely unlikely that there is any danger to the Internet here. Even if you believe flow equality is critical, this is in the noise.
>>>> 
>>>> 
>>>> Do you think we should add some text similar to above? We can reference Bob’s paper if it is already published.
>>>> 
>>>> Sounds good. A stab at some possible text:
>>>> 
>>>> ---
>>>> The model that was used to calculate the alpha_cubic value here is not absolutely precise, but analysis and simulation[1], as well as over a decade of experience with CUBIC in the public Internet, show that this approach produces acceptable levels of rate fairness between CUBIC and Reno flows, in practice.
>>>> 
>>>> [1] https://raw.githubusercontent.com/bbriscoe/cubic-reno/main/creno_tr.pdf <https://raw.githubusercontent.com/bbriscoe/cubic-reno/main/creno_tr.pdf>
>>>> ---
>>>> 
>>>> In addition the draft could change "which achieves the same average window size as Reno" to be something like "which achieves approximately the same average window size as Reno in many cases".
>>>>  
>>>> 
>>>>> Point 2: Multicative decrease factor during slow-start phase
>>>>>      We think using the current value: 0.7 may cause more packet losses in certain cases, but it can work efficiently in other cases.
>>>>>      We think this is a part of design choices in CUBIC as we haven't seen any tangible evidence that it can cause serious problems.
>>>> 
>>>> There is text already covering this. But if you think we need to add more, let us know.
>>>> 
>>>> Multiplicative decrease section
>>>> A side effect of setting βcubic to a value bigger than 0.5 is slower convergence. We believe that while a more adaptive setting of βcubic could result in faster convergence, it will make the analysis of CUBIC much harder.
>>>> 
>>>> Slow start section
>>>> Whichever start-up algorithm is used, work might be needed to ensure that the end of slow start and the first multiplicative decrease of congestion avoidance work well together.
>>>> 
>>>> Once I hear from you, I can create pull requests for these two, if changes are needed.
>>>> 
>>>> IMHO these two sound like nice steps forward, and worth creating pull requests.
>>>> 
>>>> Thanks, Vidhi!
>>>> 
>>>> neal
>>>> 
>>>>  
>>>> 
>>>> Thanks,
>>>> Vidhi
>>>> 
>>>>> On Sep 5, 2022, at 11:13 PM, Yoshifumi Nishida <nsd.ietf@gmail.com <mailto:nsd.ietf@gmail.com>> wrote:
>>>>> 
>>>>> Hi folks,
>>>>> 
>>>>> We're looking for some feedback on this to finalize the CUBIC draft. 
>>>>> Based on the previous discussions, I am thinking that one way to proceed is to add some explanations (not a solution!) for the points below in the draft.
>>>>> If you have some proposed texts on this point or you have different ideas, please let us know.
>>>>> If there's no opinion, I might propose some texts for them.
>>>>> --
>>>>> Yoshi
>>>>> 
>>>>> On Fri, Aug 26, 2022 at 12:40 AM Yoshifumi Nishida <nsd.ietf@gmail.com <mailto:nsd.ietf@gmail.com>> wrote:
>>>>> Hello everyone,
>>>>> Based on the feedback from the last meeting, the chairs have been discussing how to finalize the cubic draft.
>>>>> The below is our current view on the draft. 
>>>>>  
>>>>> The slide for the CUBIC draft from the last WG meeting listed 4 discussion points in the draft. 
>>>>> > https://datatracker.ietf.org/meeting/114/materials/slides-114-tcpm-revised-cubic-as-ps <https://datatracker.ietf.org/meeting/114/materials/slides-114-tcpm-revised-cubic-as-ps>
>>>>> 
>>>>> In these items, we think that the last two points are already addressed now.
>>>>> With regard to the remaining two points, our views are the following.
>>>>> 
>>>>> Point 1: TCP friendly model in the cubic draft 
>>>>>      We can admit that the model is not valid as the paper describing the model uses some simplified presumptions. 
>>>>>      But, it doesn't not mean the model will pose serious issues on the Internet as we haven't seen any evidence yet.     
>>>>> 
>>>>> Point 2: Multicative decrease factor during slow-start phase
>>>>>      We think using the current value: 0.7 may cause more packet losses in certain cases, but it can work efficiently in other cases.
>>>>>      We think this is a part of design choices in CUBIC as we haven't seen any tangible evidence that it can cause serious problems.
>>>>> 
>>>>> We concluded this will require more detailed analysis and evaluations which can take a longer time. 
>>>>> Based on this, we think these points are NOT needed to be addressed in the draft while it will be good to add some more explanations for them. 
>>>>> We saw there were several opinions about documenting these points in the draft during the last meeting. If you have some suggestions here, please share your opinions.
>>>>> 
>>>>> Please note that this doesn't mean we'll ignore them. we will try to publish a new version of the CUBIC draft if we find some things on them. 
>>>>> 
>>>>> If you have any opinions or comments on the views, please share them with us.
>>>>> 
>>>>> Thanks,
>>>>> --
>>>>> Yoshi on behalf of tcpm co-chair
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
>>>> 
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
>> 
>> 
>> 
>> _______________________________________________
>> 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/ <http://bobbriscoe.net/>