Re: [tsvwg] What TCP to target in TCP-friendly [was:A word for "does not have a significantly negative impact on traffic using standard congestion control"?]

Sebastian Moeller <moeller0@gmx.de> Tue, 16 March 2021 09:40 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095293A2058 for <tsvwg@ietfa.amsl.com>; Tue, 16 Mar 2021 02:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 5rf_EIqqaDSl for <tsvwg@ietfa.amsl.com>; Tue, 16 Mar 2021 02:40:16 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 3EF213A2056 for <tsvwg@ietf.org>; Tue, 16 Mar 2021 02:40:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615887570; bh=2N6h3oNVZCG1ZDWrBwkzzj7clBSLDwu9OAXv9kWTNTs=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=bJBW81D3QDfyQ2FNYDhjZ5An3XcyYE0X2wFzmm1adYuPoVawYqNiv06SekjeVAV4r aiW6s8oVqkjkaoelipe4nXnrztIxMG/qHN7xP3GNCowTZEzZ7ZBu9MdI8C8QpNyTgR KFQ6dwBKnBRoxGOlog8MOdeNnP7CyzB2IKwp2ncA=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.250.106] ([134.76.241.253]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N2mBQ-1lpokP3sbs-0134Bf; Tue, 16 Mar 2021 10:39:29 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <eb9a54c8-3883-0bb2-d213-fdbe2707cafc@bobbriscoe.net>
Date: Tue, 16 Mar 2021 10:39:27 +0100
Cc: tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <136274F6-5B94-49EC-8338-9A6D81E400D2@gmx.de>
References: <9d807812-78a7-6066-5c5f-6f2b02507439@bobbriscoe.net> <457E3F32-CE3D-4B15-A067-C476DC1F5434@gmx.de> <eb9a54c8-3883-0bb2-d213-fdbe2707cafc@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:E57IClQIuJpvvxvjtcnYZRjaRDc7sod0RWzei7ndp+uyW/rtmkh zhEVI1bqs9enWLb7dAvJNnnw1mNtCOqx8kV0Skupf3KrFsd1Hs2q9hLhftgiLCmYcpnqQQA 38J1tKoCS8+ausoDt+E8+dmSok0HC3dnDIGBxkKMHoquy9g55oGDpGq0uHuE49PttBddmcR xRDxe1mxqqqsuboFFhZ6A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:rX5XLLHzBqo=:CQ8Yf5L61WIOf9GVMgwN4g FIUktVNq6efm6WslWfIEp4kZ/c4jCcJ/57KIs3d5+ZZKRIC6j+T9jRox9YITPsUH+lDT5Lrsa rk5uZBn/8j1SPX3orzjBoBpqICVa5zMwqgncfeEcZbVb92oeF30+X4bA7qIv//ab/Q5JgYTdw sxsGMvd0j5KWrHL4OhcM7FRSQPip0tPRqngF0m5GHYXBFofddEwjSXW1/cmOyPd/CaJjlw3+I Wvjx+tglObpUlfmie1voBPIlezxqaiS/YI3gqpegciC+XYTHInGsEPvBeN0U/PY4xOkP4nA7b PDzfWgPzysM+XsZzsaeOQPpmuKrQxF44qYIUg3k2hOYqZeoNK+xNOFOF25Q4hHBjFCTvO8ljq eSQ0MDZbxM4W361Cvi+6zJ5gm5liOrMSowDuShqLPbexUVVA51smC059x2vrpo6GthCtWHmdt nlO9B43rfXHRYBgwNPyuo13xCvFbsZrPboOvbAG5GC0jVoQ12CBD+p4ft7QkJq73i5m3PrCmg Mj7XETC7zq/V/uRJyT/nloTreuBRsR4ROVzsH4+PRFACGmAhIb9Uoel9NbQ2ZsyiweemVEhd+ yq+yps+Wu1RXHdn1ANsjBlm+FXMUdkVTt1tmGnnz1X3CKCtbnfjnqZQpohj3t2uncJ+M0VQ9y B8bwIplShSukcjxsq4K9BUSB9iQ3+3gXBRmYztjQMUn7GRLS/Dj9Ysx+/YPQllLSx+a+wFPlv qlUOYs8x2z3OZxz8vg8/+51BaQcV4t7sVezVEv19rruxq7IIu0bKM7rQhHW2+zsL2IW0TwV2Q SWWhCzL5EVtqGi93A/kUaR20w5Qc7eMUh1jYQi+RlqdA2q/oCxwOwBku5cTg36uMnFoPqG0R/ PHWRDMy5tz+NiyzyhOPw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/kBQ6Wj291kMDiQ4kWRqAEt3yXcE>
Subject: Re: [tsvwg] What TCP to target in TCP-friendly [was:A word for "does not have a significantly negative impact on traffic using standard congestion control"?]
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2021 09:40:19 -0000

Dear All,

in the cited response Bob proposes to define TCP Reno as the reference TCP all TCP-friendly protocols need to be compatible with. I had a quick look at what TCP CCs are actually in use, and according to wikipdia, all major operatig systems, Windows10 (since 1709, 2017), MacOs (since Yosemite, 2014), Linux (since 2.6.19, 2006) converged on CUBIC as the default TCP congestion control algorithm.
Given that data, I propose to not enshrine YCP Reno's behavior as the current applicable reference, but instead TCP CUBIC. 
	For the L4S drafts that does not change much, because the dualQ's unfairness towards non-L4S-CCs does not seem to care for the exact way a CC is NOT L4S, (and related, but not totally on topic: TCP Pragues abysmal (self)-fairness in FIFO buffers is also independent of the exact nature of the competing CC). That is to say, L4S fails to meet its promises on both fronts, the network bits and the protocol bits are not fit for purpose (neither in safety nor functionality).


Best Regards
	Sebastian



> On Mar 10, 2021, at 15:05, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> Sebasitan
> 
> On 10/03/2021 08:27, Sebastian Moeller wrote:
>> Dear All,
>> 
>> while I appreciate the attempt to strive for better nomenclature, I think here it is best to stick to the existing terms. Sure add a paragraph that explicitly spells out what it exactly means, but do not muddy the water with slightly different terms. Also, be as accurate and descriptive as possible.
>> 
>> The argument that there are more protocols than TCP is a rather weak one, becauseIMHO " TCP-friendly" really just conveys that all internet-wide congestion response should strive to not harm TCP (still being one of the major traffic types in the net). Also this needs a strict definition of harm, so that congestion responses can be tested against this requirements and simply judged friendly or non-friendly.
>> 
>> Bob later hints at a similar thought with:
>> "Something that's not as sensitive to single losses as Reno. Which means it could push Reno down (somewhat more than say Cubic in Reno mode would), but not "significantly"."
>> 
>> But IMHO this is a slippery slope (the scare quotes around significantly indicate a non-objective assessment), so please define the amount of harm that is permissible. And also, if that boils down to "do not starve" add an explicit definition of starvation that can be used in a statistical test, the old "I know starvation when I see it" definition is clearly in the eye of the beholder and hence pretty useless for designing and testing CC algorithms against.
>> 
>> With all that said, how about something along the lines of:
>> 
>> New congestion control algorithms, will share the internet with existing CCs for the foreseeable future, and hence need to c o-exist peacefully with existing CCs. Given TCP's importance in the early internet(?) such behaviour has been called TCP-friendly, and boils down to that new CCs do not do more harm to existing CC-flows than such existing flows would do to each other. In addition to the "no more harm" principle new CCs should also avoid driving other TCP-friendly flows into starvation. In this context starvation means a reduction of a flows capacity share, below 1/8 (3 orders of magnitude) its equitable capacity share if no new-CC flows would be present.
> 
> [BB] (I assume you mean 'Reno' here, each time you say 'TCP'.)
> 
> Whatever, the question was looking for a word that describes more harm than none.
> We saw in the survey at the last Nov '20 ICCRG that Reno is becoming a small minority. I suspect this is because it's over-sensitive to noise that often isn't really congestion (accepting that it's hard for any CC to know what caused a loss).
> 
> We're looking for a way to describe the congestion controls that do actually do some harm to such "over-sensitive" congestion controls, but not significant harm.
> 
>> 
>> IMHO that captures the gist of the issue:
>> 1) do no harm: is a concise phrasing of "does not have a significantly negative impact"
> 
> [BB] That would be "do no significant harm", as explained above.
> 
>> 2) giving a definition of clearly acceptable harm (what TCP-friendly CCs already inflict on each other).
>> 3) tackles the so far under defined starvation issue heads on by giving a definition of starvation that can be empirically confirmed during tests
>> 4) uses a reference rate for the starvation calculation that effortlessly allows for prioritization and selective shaping on each node where the sharing behaviour is explored.
>> 5) by having a numerical definition of starvation and of the reference sharing behaviour, it becomes possible to statistically test whether the new CC significantly harms existing TCP-friendly traffic or not (getting rid of the subjective components of "significantly").
> 
> [BB] I'd like to work on this.
> 
> I believe the problem is similar to relative poverty. It depends on some notion of average (long-running, capacity-seeking) flow rate in a deployment environment, not solely the other rates in one bottleneck.
> 
> 
> Bob
> 
>> 
>> This blurb clearly is not perfect, but IMHO worth discussing.
>> 
>> 
>> Best Regards
>> 	Sebastian
>> 
>> 
>>> On Mar 9, 2021, at 02:19, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>> 
>>> tsvwg-ers,
>>> 
>>> In the survey of the L4S Prague Requirements, we got quite significant push-back from developers about our two requirements to fall back to Reno-Friendly (which the draft defines as a translation of 'TCP-Friendly' into transport-agnostic language, 'cos TCP isn't the only transport these days).
>>> 
>>> Basically, people don't want to have to fall back to something as lame a Reno (apologies if that's disparaging, but I'm just the messenger).
>>> 
>>> I was hoping people would interpret 'Reno-Friendly' liberally. But everyone takes Reno-Friendly to mean quite close to Reno behaviour - not surprising really, given the definition of TCP-Friendly in TFRC is roughly within 2x of Reno [RFC5348] (pasted at the end).
>>> 
>>> What I'm looking for is a word that means "does not have a significantly negative impact on traffic using standard congestion control", which
>>> RFC5033 allows for experimental congestion controls.
>>> 
>>> 
>>> 
>>> ==Details from the RFCs==
>>> 
>>> RFCRFC2914 (borrowing from RFC2309) defines TCP-compatible to mean the same behaviour as Reno (essentially).
>>> 
>>> RFC5348 defines the term TCP-Friendly, which was originally intended for real-time media - to allow the rate to temporarily stray from TCP-compatible because it needed to remain more stable as available capacity varied. But it was also used for regular elastic congestion controls like Cubic. Here's the TFRC definition.
>>> 
>>>    TFRC is designed to be reasonably fair when competing for bandwidth
>>>    with TCP flows, where we call a flow "reasonably fair" if its sending
>>>    rate is generally within a factor of two of the sending rate of a TCP
>>>    flow under the same conditions.  However, TFRC has a much lower
>>>    variation of throughput over time compared with TCP, which makes it
>>>    more suitable for applications such as telephony or streaming media
>>>    where a relatively smooth sending rate is of importance.
>>> 
>>> 
>>> In RFC5033, Sally Floyd wrote this, which is a useful turn of phrase. I'd just like to find a shorter way of saying it:
>>> 
>>>        Alternate congestion controllers that have a
>>>        significantly negative impact on traffic using standard
>>>        congestion control may be suspect
>>> 
>>> 
>>> 
>>> Bob
>>> -- 
>>> ________________________________________________________________
>>> Bob Briscoe
>>> http://bobbriscoe.net/
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>