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

Vidhi Goel <vidhi_goel@apple.com> Tue, 06 September 2022 23:45 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 CF13EC14CE24; Tue, 6 Sep 2022 16:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.677
X-Spam-Level:
X-Spam-Status: No, score=-7.677 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, 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 3n5tkSg_iWbK; Tue, 6 Sep 2022 16:45: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 0C720C14CF17; Tue, 6 Sep 2022 16:45:49 -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 286Ngqlq028640; Tue, 6 Sep 2022 16:45:48 -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=xmCW6G8ETrwYB8X/nm1l+kp0CSye6LjEk/H5rydCYv4=; b=qTMj7Ap7GrQK4NzS+1/BeWS7YCfetAMu3ByoAjJR7fvMlaAThOcaSjMy7TsXhBkO+ZLZ cUHzTKSQSuqv4jfEMD5Yn5WC74EKJnIXCNhFv+3jlkvNrkb/ohNYsOIVuTyYoM6h7DtF AmKZUmdiaEZ5bvj4XBXvQlsp9CBGyOHQt09QCekaIHl10xA3+DJyogOBCvPLfs5bQghC MmenLucQ8DuvaCheq2V//cV8DtkyL8vwXLgexxAJf/XIVrI4PkobZBIEfWQw23DFNtnl iAL+uYLxflNWpufcf6JJpSbgktXVMscLXjrtoFivwGhYcy91ofIfjYrxRGvRrK2C/MYe bA==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3jcphu0qsr-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 06 Sep 2022 16:45:48 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPS id <0RHT00A9EBCB96V0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Tue, 06 Sep 2022 16:45:47 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) id <0RHT00900BB3N100@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 06 Sep 2022 16:45:47 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 201b35371ed429fb4e4fc3ed10b3bd6f
X-Va-E-CD: 2c480f7b23ce5a40323d08d68a76c059
X-Va-R-CD: 0c6adb0f42dedfc172b1202202661e9a
X-Va-CD: 0
X-Va-ID: fa29b8f9-bc34-4554-aded-02d0502d8f1e
X-V-A:
X-V-T-CD: 201b35371ed429fb4e4fc3ed10b3bd6f
X-V-E-CD: 2c480f7b23ce5a40323d08d68a76c059
X-V-R-CD: 0c6adb0f42dedfc172b1202202661e9a
X-V-CD: 0
X-V-ID: f88b7dda-9c9c-422e-b7aa-78d00d0f2880
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.528, 18.0.895 definitions=2022-09-06_10:2022-09-06, 2022-09-06 signatures=0
Received: from smtpclient.apple (vimac.scv.apple.com [17.192.154.53]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPSA id <0RHT01197BCB9S00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 06 Sep 2022 16:45:47 -0700 (PDT)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <34786894-6F94-49E9-B733-0FAFFC5C977D@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_DC442D61-76D3-481B-99A9-367356CC02CC"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3726.0.9.1.22\))
Date: Tue, 06 Sep 2022 16:45:36 -0700
In-reply-to: <CAAK044TMHQo1Rfy1_6Yms1_tT3hKmKBJBeA9Qu5_r85df4xkKw@mail.gmail.com>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
References: <CAAK044QnUTW3Zr5sBZ3wv5e0A=q2OGdooHSZHAKRHmo5qMrSkg@mail.gmail.com> <CAAK044TMHQo1Rfy1_6Yms1_tT3hKmKBJBeA9Qu5_r85df4xkKw@mail.gmail.com>
X-Mailer: Apple Mail (2.3726.0.9.1.22)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.528, 18.0.895 definitions=2022-09-06_11:2022-09-06, 2022-09-06 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/kjb1cUg5pysDY3dGhDAYd6FQPRc>
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: Tue, 06 Sep 2022 23:45:53 -0000

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.

>> 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.


Thanks,
Vidhi

> On Sep 5, 2022, at 11:13 PM, Yoshifumi Nishida <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
>> 
>> 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
> https://www.ietf.org/mailman/listinfo/tcpm