Re: [tcpm] Proceeding CUBIC draft - thoughts and late follow-up

Vidhi Goel <vidhi_goel@apple.com> Mon, 04 July 2022 00:59 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 9D12FC14CF17; Sun, 3 Jul 2022 17:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level:
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.745, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=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 Z7cMRt4b722A; Sun, 3 Jul 2022 17:59:07 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp24.apple.com (rn-mailsvcp-ppex-lapp24.rno.apple.com [17.179.253.38]) (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 D71CAC157B45; Sun, 3 Jul 2022 17:59:07 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp24.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp24.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 2640nS9h030670; Sun, 3 Jul 2022 17:59:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=hlNEqypCBZwdwggAMJGMc3Yjbm6AWWIap01JELrMDpE=; b=FCStSkJLV+a6kP3UK0Im/vv89M4qLSZ+VZ0RJp1LoXoVNUSAHyINfzrs2cXI1cbTJXwv Hg8ADjW2ogYQNuQ6scecseE/dasl4noI1hUFxTPQWZBWCwYsm6aKxiZr963PowA0mhTz tVuxlMDqGANt98KXC+ckOlmtZlJdhnLy6bctnfkqObvAMF2Fj8y8EsgXQQqI9Pf3DEMK s6cNzjeSEd3QbsGhGYbpou/Itvt58BzLdHhfZTjO8WwI+3/6WO1WrKg0BLDD63+yJQfF 43jtjP/eGzSE2A9VtEKnHHsq0bqxTuBlzJQrXli8Or70FPmDcZh81zar10AijsRqG2M2 NA==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp24.rno.apple.com with ESMTP id 3h2p193jv0-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 03 Jul 2022 17:59:07 -0700
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPS id <0REH00PTX1EGIUB0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Sun, 03 Jul 2022 17:59:04 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) id <0REH00G0012RCS00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sun, 03 Jul 2022 17:59:04 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 3995b166a75559493a3d304aae4b10d4
X-Va-E-CD: 6621601d3d149359d50ba5bc0c9103a3
X-Va-R-CD: 7b9f05427bd5f11b08962be52d5c8096
X-Va-CD: 0
X-Va-ID: 6df4766c-eee3-45b0-832e-def9f314651a
X-V-A:
X-V-T-CD: 3995b166a75559493a3d304aae4b10d4
X-V-E-CD: 6621601d3d149359d50ba5bc0c9103a3
X-V-R-CD: 7b9f05427bd5f11b08962be52d5c8096
X-V-CD: 0
X-V-ID: 8f7c96ca-6e5b-44ed-a5e6-94e1b10bfb63
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-03_18:2022-06-28, 2022-07-03 signatures=0
Received: from smtpclient.apple (unknown [17.11.28.224]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPSA id <0REH001D11EF5U00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sun, 03 Jul 2022 17:59:03 -0700 (PDT)
Content-type: multipart/alternative; boundary="Apple-Mail-CD9BFD12-49F6-4426-9E3E-EF9919C42235"
Content-transfer-encoding: 7bit
From: Vidhi Goel <vidhi_goel@apple.com>
MIME-version: 1.0 (1.0)
Date: Sun, 03 Jul 2022 17:58:52 -0700
Message-id: <AEE43039-8EA0-4FB9-A605-C5C845DF4355@apple.com>
References: <alpine.DEB.2.21.2206301429210.7292@hp8x-60.cs.helsinki.fi>
Cc: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>
In-reply-to: <alpine.DEB.2.21.2206301429210.7292@hp8x-60.cs.helsinki.fi>
To: Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>
X-Mailer: iPhone Mail (20A5312d)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-03_18:2022-06-28, 2022-07-03 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/IOcPCOXQtKqpbzmGyf-HODk1V1E>
Subject: Re: [tcpm] Proceeding CUBIC draft - thoughts and late follow-up
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: Mon, 04 Jul 2022 00:59:11 -0000

> Could you elaborate a bit why you think there is a major change in congestion control for any congestion event? 


In Appendix B.6, ssthresh is set using previous cwnd instead of bytes_in_flight. I think this is a major deviation from 5681.
ssthresh = congestion_window * kLossReductionFactor

We fixed this in Cubic bis draft to use bytes_in_flight.

Vidhi

> On Jul 3, 2022, at 5:05 PM, Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org> wrote:
> 
> 
> 
>> On Mon, 20 Jun 2022, Vidhi Goel wrote:
>> 
>> If we are talking about RFC 9002 New Reno implementations, then that already modifies RFC 5681 and doesn’t comply with RFC 5033. Since it has a major change from 5681 for any congestion event, I wouldn’t call it closely following new Reno.
> 
> Could you elaborate a bit why you think there is a major change in congestion control for any congestion event? To my understanding RFC 9002 is very clear in that cwnd (and ssthresh) is halved which is essentially Reno CC that RFC 5681, RFC 6582 and RFC 6675 all follow. Sure RFC 9002 differs from RFC 5681 in the way a loss is detected and recovered but that is not congestion control. There is also a difference in how Fast Recovery period ends but effectively that differs only slightly from TCP Fast Recovery with SACK enabled (QUIC is essentially SACK-enabled).
> In the quite usual case with a typical CA cycle where a single packet is lost, this results in exactly the same CC behavior. And often when multiple packets are lost in a single window of data, SACK allows recovery in one RTT (or in a few RTTs) in which case the difference is minor.
> 
> Am I missing something?
> 
>> Also, in another email, you said that you didn’t follow discussions on QUIC WG for RFC 9002, so how do you know whether QUIC implementations are using New Reno or CUBIC congestion control?
>> It would be good to stay consistent in our replies, if you agree RFC 9002 is already non compliant with RFC 5033, then why use it as a reference to cite Reno implementations!
> 
> I am not insisting anything about which CC QUIC implementations are using. RFC 9002 says:
> 
> "If a sender uses a different controller than that specified in this
>  document, the chosen controller MUST conform to the congestion
>  control guidelines specified in Section 3.1 of [RFC8085]."
> 
> And RFC 8085 requires that UDP-based bulk-transfer applications comply with the congestion control principles (i.e., RFC 2914). Therefore, it is even more important to ensure that CUBIC draft is published without any notable issues and that it follows the congestion contol principles. At the time when RFC 9002 was published the issues with CUBIC were unknown, so I think it was inherent that CUBIC is mentioned as an alternative CC and many implementations have adopted it.
> 
> BR,
> 
> /Markku
> 
>> Vidhi
>> 
>>>> On Jun 20, 2022, at 5:06 PM, Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org> wrote:
>>> Hi Lars,
>>> 
>>>> On Sun, 19 Jun 2022, Lars Eggert wrote:
>>> 
>>>> Hi,
>>>> 
>>>> sorry for misunderstanding/misrepresenting  your issues.
>>>> 
>>>>> On Jun 6, 2022, at 13:29, Markku Kojo <kojo@cs.helsinki.fi> wrote:
>>>>> These issues are significant and some number of people have also said
>>>>> they should not be left unaddressed. Almost all of them are related to
>>>>> the behaviour of CUBIC in the TCP-friendly region where it is intended
>>>>> and required to fairly compete with the current stds track congestion
>>>>> control mechanisms. The evaluation whether CUBIC competes fairly
>>>>> *cannot* be achieved without measuring the impact of CUBIC to the
>>>>> other traffic competing with it over a shared bottleneck link. This
>>>>> does not happen by deploying but requires specifically planned measurements.
>>>> 
>>>> So whether CUBIC competes fairly with Reno in certain regions is a
>>>> completely academic question in 2022. There is almost no Reno traffic
>>>> anymore on the Internet or in data centers.
>>> 
>>> To my understanding we have quite a bit QUIC traffic for which RFC 9002 has just been published and it follows Reno CC quite closely with some exceptions. We have also some SCTP traffic that follows very closely Reno CC and numerous proprietary UDP-based protocols that RFC 8085 requires to follow the congestion control algos as described in RFC 2914 and RFC 5681. So, are you saying RFC 2914, RFC 8085 and RFC 9002 are just academic exercises?
>>> 
>>> Moreover, my answer to why we see so little Reno CC traffic is very simple: people deployed CUBIC that is more aggressive than Reno CC, so it is an inherent outcome that hardly anyone is willing to run Reno CC when others are running a more aggressive CC algo that leaves little room for competing Reno CC.
>>> 
>>>> I agree that it in an ideal world, the ubiquitous deployment of CUBIC
>>>> should have been accompanied by A/B testing, including an investigation
>>>> into impact on competing non-CUBIC traffic.
>>>> 
>>>> But that didn’t happen, and we find ourselves in the situation we’re in. What is gained by not recognizing CUBIC as a standard?
>>> 
>>> First, if the CUBIC draft is published as it currently is that would give an IETF stamp and 'official' start for "a spiral of increasingly
>>> aggressive TCP implementations" that RFC 2914 appropriately warns about. The little I had time to follow L4S discussions in tsvwg people already insisted to compare L4S performance to CUBIC instead of Reno CC. The fact is that we don't know how much more aggressive CUBIC is than Reno CC in its TCP friendly region. However, if I recall correctly it was considered Ok that L4S is somewhat more aggressive than CUBIC. So, the spiral has already started within the IETF as well as in the wild (Internet).
>>> 
>>> Second, by recognizing CUBIC as a standard as it is currently written would ensure that all issues that have been raised would get ignored and forgotten forever.
>>> 
>>> Third, you did not indicate which issue are you referring to. A part of the issues have nothing to do with fair competition against Reno CC in certain regions. E.g, issue 2 causes also self-inflicted problems to a flow itself as Neal indicated based on some traces he had seen. And there is a simple, effective and safe fix to it as I have proposed.
>>> 
>>> As I have tried to say, I do not care too much what would be the status of CUBIC when it gets published as long as we do not hide the obvious issues it has and we have a clear plan to ensure that all issues that have not been resoved by the time of publishing it will have a clear path and incentive to get fixed. IMO that can be best achieved by publishing it as Experimental and documenting all unresolved issues in the draft. That approach would involve the incentive for all proponents to do whatever is needed (measurements, algo fixes/tuning) to solve the remaining issues and get it to stds track.
>>> 
>>> But let me ask a different question: what is gained and how does the community benefit from a std that is based on flawed design that does not behave as intended?
>>> 
>>> Congestion control specifications are considered as having significant operational impact on the Internet similar to security mechanisms. Would you in IESG support publication of a security mechanism that is shown to not operate as intended?
>>> 
>>> Could we now finally focus on solving each of the remaining issues and discussing the way forward separately with each of them? Issue 3 a) has pretty much been solved already (thanks Neal), some text tweaking may still be needed.
>>> 
>>> Thanks,
>>> 
>>> /Markku
>>> 
>>>> Thanks,
>>>> Lars
>>>> 
>>>> --
>>>> Sent from a mobile device; please excuse typos.
>>> _______________________________________________
>>> 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