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

Bob Briscoe <in@bobbriscoe.net> Fri, 09 September 2022 17:16 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 09ACAC1522C9; Fri, 9 Sep 2022 10:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 La7l33EAU12L; Fri, 9 Sep 2022 10:16:54 -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 7FC4AC152716; Fri, 9 Sep 2022 10:16:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Content-Type: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=pTod0MUWh58i2LBgobWKd2o94yA8J5r7NwPV5YdM1hs=; b=UbJoQt0EtE45IDVYbM4gfaaNA8 pfiPfyLB/Ap+hc3q3y7aoYqs4LHATJ/xvL4qm5RTaNccK1zIf7w0pD3K8YEiowpGZQZQrUiOrmD+Z fExRY64UOJcvGVKhJcpbXsVlveaFd/tIqe59UmtRSEpMAVJVkohDTFHFLvhDQRTIZZlSTFJ7dsn7d htQ033kT7M+opos7wEROxm7FK2DPL/sqVGCsV/AVf4TGT0z59VOpmcu879cUBZ+ZSKeBSbs8HkaZC ugoBpZDsJGkaBluCzbzyM0AokHgxfsCphE8zNppTcVNxMB6p68XMDef38KOw7CNdCSrQSgmkWGrlE 7hfbKETg==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:40504 helo=[192.168.1.4]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from <in@bobbriscoe.net>) id 1oWhcK-00020q-Ko; Fri, 09 Sep 2022 18:16:31 +0100
Content-Type: multipart/alternative; boundary="------------hMc0quVTkablB6zFy0YAmx5o"
Message-ID: <8095f93b-0563-e227-5f70-ab96801c8da8@bobbriscoe.net>
Date: Fri, 09 Sep 2022 18:16:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-GB
To: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>, Yoshifumi Nishida <nsd.ietf@gmail.com>
Cc: "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>
References: <CAAK044T0chaZeTy1MAksoohmsqO03LF4bxMqGcxb6FFHVrt3DA@mail.gmail.com> <8E1E098D-F28F-4997-9B60-57CF8702547D@apple.com> <F7D4560A-9FAB-4E84-AD7A-18C731B05BB4@apple.com>
From: Bob Briscoe <in@bobbriscoe.net>
In-Reply-To: <F7D4560A-9FAB-4E84-AD7A-18C731B05BB4@apple.com>
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/GikU6jSsdgOpdbz38cRBYjcg0a8>
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: Fri, 09 Sep 2022 17:16:59 -0000

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 itsSection 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 itsSection 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 allow*s*  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
>
> 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> 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> 
>>> 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> 
>>> wrote:
>>>
>>>
>>>
>>>     On Tue, Sep 6, 2022 at 7:46 PM Vidhi Goel
>>>     <vidhi_goel=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
>>>     ---
>>>
>>>     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> 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> 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
>>>
>>>         _______________________________________________
>>>         tcpm mailing list
>>>         tcpm@ietf.org
>>>         https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/