Re: [tsvwg] [tcpm] L4S status tracking

Sebastian Moeller <moeller0@gmx.de> Mon, 11 November 2019 16:31 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 2FDFD120958; Mon, 11 Nov 2019 08:31:31 -0800 (PST)
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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 lXGezFz6eYow; Mon, 11 Nov 2019 08:31:28 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84215120909; Mon, 11 Nov 2019 08:31:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573489828; bh=RIS0GPQXOa/RHPBoUjOGjDMJhEDxn3chwuJU9/5Q11c=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=V2Ov/JwSQuRp7PRn+iC/T10NyyvxrFYjUTofTsMIIMFcJoRv1v7CwV83Yle7kwFns n430oPrkGrT2M/Jszx/ygQp+LvbS/Xka+O23oFvxRYPLq9mnK4kedB6hN4Ds98CuVf T3okp+dIm0ls1za4x+daIScIkZQvyHo7WZHptLOY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MF3He-1ifFCW1B8a-00FVJC; Mon, 11 Nov 2019 17:30:28 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <73220cb8-2e36-cf87-276a-f67c425a7752@bobbriscoe.net>
Date: Mon, 11 Nov 2019 17:30:26 +0100
Cc: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AE74B84-95FB-46E0-A6A1-C424CEBEEB96@gmx.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <0F339755-A4C6-486B-8751-23DFB50C7280@gmx.de> <3488c7a8-0b78-f7f9-bb9d-64062e401e59@bobbriscoe.net> <985D623F-8B16-4DB0-A675-5A726EF6753F@gmx.de> <73220cb8-2e36-cf87-276a-f67c425a7752@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:N8ugG19aja3NirpQs1KM3IdE5xKn8Oi93AYwCvxiYW+t/nD4wW2 sOcAFWYxPY+BcX0Sr0XAv3S3DNyR4qrhIJr9bc8WnFkYhwoLv2sy0GnDimY2M/JY7skI3ei sX9NETHx9YYNgG0bdMKJIHlk9N1/cfxfQvOqu7XZrsiSMwMqMuY+88TlbJvKTyzKq/JlAte fKY9x+IsuPdjVQDAACpNQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:I9rqCj3pGQA=:oUlJ5Zy8r0OW+8k6TlRF2p 4MgEsFe8G1QTYSewadXZo75wubmy/QFL2KoV4y0Cdr3bUVqW/VJaeFR2kD4mM1BayoKPKubVK oQ3mmZoEvusvPdeVkCzCdD1R64H9YRi/L0mNLxmi9UZCjq3H7u8vpjVjHuCmJFZXUo92a9Vlr HOgvetb8fJduVR9Pg0zeKRTzXqcib87NkUDKmOUDNURrsPA4qj4WMwf3GMoE5ydjys2BnIUa5 lHT5L7SkiPul4Fk3HUl8cl09tOOPQRFcOQxUzdjgNysdHT926EpsVbQUxaJyjCoK9Yc+7a2RV CVtMDgfmWg+cYWZAm9GIj0sznfAwhISKGRqDonw1k4f/fhs2eLk0LCDie62fqyhJBmEO8SKKN joWnacnVA4b/bV4+ENAGVd2n6npzwGJ+gR/gnVF8N6zXBFyFbyN+sVY2aRmQmQCf3qWqz+W7a JcXljSXfn1ssfAsP88DtAVcpF36ns9V60vpvuA9wtFC1bJR9gNJEogLC0302zoHhxwzKg0e/J 4BZgSv2uqmNpz4V3xsebgt/yhzNaOxcVjxtEJbX5o9k8by1/w/PQEvF4kLLwKls5Xg87eB3qc clPKltR7vCrtIPI6IY9K5ayh7Er/VaF3OgsQ/CNzSHVHhxXV1L3CD6f2gKWIludRu9v9zDICo UIwExs7kl/NQCFUMSPz6moxS49glF2BWfp//Xy6L49jK4cnvNT/PDRynGp9+iwjRC/C5XHvGq 5IVrfrc4hY1dfnURQ7bYk8mG+KgTOeJvX7KutmxhafzrmgUyb+UxjKme3CSo1UL14h+lKy/+0 9dcCSd7SSbq+5KKwL6fpGCSNBG7zeZPZzFpbJ1NBzIxLH7Pjos1nN+aO8yI35xwVH/cV4V83+ tTW+jPHZPF2oO19I6OY94ia7okBENpInDE2/TUZlRcHHZB9IgTAa7Ck7TtscMrsKWY7/4O0pP FtanDiE3ob+c2ASxdvmj+EgwYRF0ZowK48YCLc4nwkVhWayvSPnqDFI/dLW/QoA1CIqJlwXWh F5vlFSwSjzVnuKEOngm3hVBcUYRUk77ZdKL0z/8hZHGIzKwB4Hz/xLzacLDhj4Os/5HbK3IR+ nG4DrPAijArrZE4QTJ6qC7n2ZFMWbdIPk1OLlI6MNvqQyni+gvGdZNhtMO60wuXf0mnh0G8gf nOvo/DeZgoxDLh5j2txCfsmj2y8GBJFOedsMIQYRyReEDmZc2+0WDw7lTEB/7adqD2IAKt5Lt ctajAIuq2huJv5Dmly7KMNj/bjKzROC3Dd/dh5qLEUCHJrKEM3pXboDNn50w=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/4trLiJ0CI_xasE_3nMX-AlnR090>
Subject: Re: [tsvwg] [tcpm] L4S status tracking
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: Mon, 11 Nov 2019 16:31:31 -0000

Hi Bob,

to be quite honest, the definitions you seem to insist upon are annoying and your rationale to explain your choices do not really convince me as given in good-faith.
To repeat once more before I move on to more substantial issues:
	You use classic in a sense of "The stuff that has stood the test of time up to publication of this RFC", and I believe it is very pretentious to assume that "this RFC" is going to replace the status quo especially given that the drafts seem to be in the experimental track. 

But my bigger problem is not how you name non-L4S traffic, but what L4S does to non-L4S traffic,
According to recently the measured and posted data L4S/dualQ/ AQMTCP Prague simply does not work as advertised.

Not sure about the consensus opinion here, but the reported unfairness at low RTTs does indicate that at least the tested dualQ aqm implementation does not actually manage to make "Scalable and Classic flows competing under similar conditions run at roughly the same rate." 

Neither ~10:1 @~0ms RTT (https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.png) nor 3:1 @ 10ms RTT (https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-10ms_var.png) qualify as "roughly the same rate" in my opinion. Oliver argued that this might be to be expected behavior due to the different RTTS under load for both queues, but he also admitted that he posed the same question, indicating that even members of the L4S development team consider traffic on the same path as "under similar conditions".

	This imbalance could be caused by (hopefully fixable) inefficiencies/bugs in the dualQ and/or TCP Prague implementations, or it could be part of L4S design; in which case I argue that this needs to be spelled out in excruciating detail in the draft. 
	I find it a bit hard to believe that someone as verbose as you could use the term "run at roughly the same rate" to mean "Scalable traffic does not completely starve non-scalable traffic". 
	The fact that this bias seems to diminish with increasing RTTs could be construed that at typical internet RTTs of ~100ms this effect does not matter much anymore, but that interpretation ignores that a considerable fraction of traffic is delivered from close-by data centers. 

Best Regards
	Sebastian



> On Nov 11, 2019, at 16:22, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> Sebastien,
> 
> Chambers (British English)
> 
> 
> classic adj 1 made of or belonging to the highest quality; established as the best. 2 entirely typical. 3 simple, neat and elegant, especially in a traditional style. noun 1 an established work of literature. 2 an outstanding example of its type. 3 something, eg an item of clothing, which will always last, irrespective of fashions and fads • the little black dress, a classic of the 50s. 4 (Classic) a celebrated annual sporting event, especially a horse race. See also the Classics. classically adverb 1 in a classic or classical way. 2 so as to be classical. 
> ETYMOLOGY: 17c: from Latin classicus relating to classes, especially the best.
> 
> Merriam Webster (US English)
> 
> 
> clas·​sic | \ ˈkla-sik 
> 1a : serving as a standard of excellence : of recognized value classic literary works a classic case study on hysteria
> b : traditional, enduring classic designs
> c : characterized by simple tailored lines in fashion year after year a classic suit
> 2 : of or relating to the ancient Greeks and Romans or their culture : classical
> 3a : historically memorable a classic battle
> b : noted because of special literary or historical associations Paris is the classic refuge of expatriates
> 4a : authentic, authoritative a classic study of eyewitness accounts
> b : typical a classic example of chicanery a classic error
> 
> Responses inline...
> 
> 
> On 06/11/2019 23:04, Sebastian Moeller wrote:
>> Dear Bob,
>> 
>> 
>>> On Nov 6, 2019, at 19:12, Bob Briscoe <ietf@bobbriscoe.net>
>>>  wrote:
>>> 
>>> Sebastien,
>>> 
>>> On 06/11/2019 07:18, Sebastian Moeller wrote:
>>> 
>>>> Hi Bob,
>>>> 
>>>> On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe 
>>>> 
>>>> <ietf@bobbriscoe.net>
>>>> 
>>>>  wrote:
>>>> 
>>>> 
>>>>> Michael, Rod,
>>>>> 
>>>>> Altho non-L4S is a reasonable idea, I think it has more of a negative 
>>>>> connotation than classic. 
>>>>> 
>>>>> 
>>>>         [SM] It does have the advantage though of being a testable, with classic all we know is you are talking about something that came before.
>>>> 
>>> Which is a good starting point, because that's what is intended. 
>>> 
>> 	[SM] I know that this is what you intend, but it is the test of time that makes classics classics, no amount of wishful thinking of the new-kid-on-the-block will relegate the reigning champion into classic mode, your solution really has to a) be better, and more importantly b) supersede that champion in the first place.
> [BB] Not at all. Because classic has no hint of inferior. Quite the opposite according to the dictionaries.
> 
> This is an excellent demonstration of how any term, even a good positive one, attracts a negative connotation as soon as it is used to mean "the things that are claimed to be improved on". This says to me that the quest for a better word than classic will be fruitless.
> 
> Just like how kids quickly started to use the word 'special' as a term of abuse soon after the phrase "children with special needs" was introduced by well-meaning people.
> 
>> 
>> 
>> 
>>> Plus it already has a slightly positive natural meaning of "something robust that has stood the test of time". Then it is defined precisely for the context of each L4S doc, e.g.:
>>> 
>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2
>> "Classic service:  The 'Classic' service is intended for all the
>>       behaviours that currently co-exist with TCP Reno (e.g.  TCP Cubic,
>>       Compound, SCTP, etc)."
>> 
>> Reading this implies that TCP Reno is not in the classic set, as you define that set as those co-existing with Reno and that is does not include Reno. But really =you can define what ever you want, but to have others accept your definition it better be useful.
>> 
> [BB] Good point. I'll certainly fix that along with the problems that Rod pointed out.
> 
> 
>>>>> For example, if you did define the name "non-iPhone" to mean phones
>>>>> such 
>>>>> as Android, Windows, etc, then you would expect the phrase "non-iPhone 
>>>>> knock-off products" to mean "fake Android and Windows phones". However 
>>>>> the constituent elements "non" and "iPhone" already have a meaning of 
>>>>> their own, so in the context of this phrase, it means "fake iPhones", 
>>>>> which is the opposite of what you wanted.
>>>>> 
>>>>> 
>>>>         [SM] That is completely besides the point, it made me smile though and think about that passage in Alice in Wonderland about the meaning of words.
>>>> 
>>> [BB] Please try to understand why this is very much the critical issue (more important than the negative connotation question, which is subjective).
>>> 
>> 	[SM] Your are debating me to score points here, are you? 
> [BB] Not at all. We need a context-independent meaning. I am raising a practical problem with choosing a name that contains an element ("non-") with a natural meaning that will change the presumed meaning of "non-L4S" dependent on context.
> 
>> You sort all flows into two categories, those that show L4S-style response to ECN signals and those that do not. The first group is reasonably homogenous, the second is not. So calling the second set non-L4S-style seems totally reasonably to me, unless you find another PROPERTY that defines that set, and no "classic" is not a property. 
> [BB] Non-L4S would be reasonable, were it not for its context-dependence problem. On what basis can you say that classic is not a property, when it is (both as defined for the L4S drafts, and as a well-understood adjective)?
> 
> 
>> This is getting as ridiculous as your 17 year old car example....
>> 
>> 
>> 
>>> I believe you are thinking in the context of all traffic. Let's call that set A. And let's call the set of all L4S traffic L1.
>>> Then in this context, "Non-L4S" naturally means A - L1.
>>> 
>>> However, consider another context, say the context of all Low Latency traffic, that we'll call L2. This was the context of the example I found in the draft. In that context, the term "Non-L4S" already naturally means L2 - L1.
>>> 
>> 	[SM] Well, for me L4S traffic is traffic that show a "linear" response to CE markings instead of a "multiplicative" (we can argue whether that is the correct definition, but it sure beats the what ever I feel is L4S definition you seem to propose)
> [BB] Are you really meaning to say that I don't know the theoretical grounding of my own research as well as you do? 
> 
> BTW, Reno, Cubic and L4S responses to congestion are all multiplicative.
> 
>>  and in that sense the set theoretical observations boil down to your first formulation. The fact that the L4S draft allows for your second formulation is a defect in that draft. The other stuff is not L4S but rather LoW-Latency traffic (which might be qualified to share L4S low latency queue with true L4S traffic).
>> 
>>> So the term "Non-L4S" already has the intended meaning of Classic, but only in one context (A), and it has other meanings in every other context.
>>> 
>> 	[SM] If you insist on overloading definitions, be my guest to keep the pieces once things break.
> [BB] The current draft does not overload any definition of 'non-L4S'. It uses its natural meaning of "traffic that is not L4S" in the reduced context of the low latency queue. That's why I picked it as an example of a context-dependent word that would not be useful as a context-independent name.
> 
> 
>> 
>> 
>> 
>>> It's a very bad idea to choose a name that already has a natural meaning that can be different to what you want to define the name to mean.
>>> 
>> 	[SM] I apologize I was not thinking about "in Wonderland" but about Through the Looking Glass (https://sabian.org/looking_glass6.php
>> ) :
>> "'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I always pay it extra.'"
>> L4S has exactly zero natural meaning, so please stop pretending it does.
>> 
> [BB] When expanded it completely describes what it means: "Low Latency Low Loss Scalable throughput".
> 
> 
> 
> Bob
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/