Re: [tcpm] [tsvwg] L4S status tracking

Bob Briscoe <ietf@bobbriscoe.net> Wed, 13 November 2019 09:48 UTC

Return-Path: <ietf@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 2800F1201AA; Wed, 13 Nov 2019 01:48:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 kDP3fB6Ya3Pb; Wed, 13 Nov 2019 01:48:03 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 1F3AF1201B7; Wed, 13 Nov 2019 01:48:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=lIlJpLheegegmst6gbOp55Aaeom/4y2PqvCgH6flgHk=; b=1iCeJzsNjaB1CRQnf9EtUT0K3X q/yIMurKy7ip9W2/nlpVSKjRsPjgImdV/ALy5cjVC9P3+A8KpuPaKd9fvSexyLJ9uheYhGYxN/wjI ylgbrHJUBi7nJ/wxcLHOuVcHNljO+iP12ywypsKTyXufjNcwqxn+LS8Ie7hggXKuIiYF2NMfwuFgB R04gzIjKVSiciu8kqT9tUac4kKfd2ek3nltA+EHtFqbnC7Kw+gOPWZvj7L+KvYFSxbPCckS3OaBI6 Q81yx/rIO9K+Cc+R0cYyN1+BIOgTFhGKw96DeZGritt2JQ1b6b4kafzguWlF0bRNxNvaYgZv7Uxyb DUFbIbKw==;
Received: from [31.185.128.31] (port=49820 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <ietf@bobbriscoe.net>) id 1iUpFo-0007lh-OD; Wed, 13 Nov 2019 09:48:01 +0000
To: Sebastian Moeller <moeller0@gmx.de>
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>
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> <6AE74B84-95FB-46E0-A6A1-C424CEBEEB96@gmx.de>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <438350af-e5ff-88a4-21d8-2cc30d1030bb@bobbriscoe.net>
Date: Wed, 13 Nov 2019 09:47:59 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6AE74B84-95FB-46E0-A6A1-C424CEBEEB96@gmx.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/siQlVOY_LiJMgyG9Dt_wWFgVa_k>
Subject: Re: [tcpm] [tsvwg] L4S status tracking
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 13 Nov 2019 09:48:06 -0000

Sebastian,

I am very much arguing in good faith about the term 'Classic', because I 
care about the comprehensibility and correctness of RFCs. So I am always 
willing to change text (or technology) in the face of successfully 
argued reasoned constructive criticism.

In order to keep each thread to its topic, I'll respond on that thread 
to the points about flow rates (unless others have already made the 
points I would make). {Note 1}

It is not pretentious for an experiment to state what it aims to achieve 
in its specification. That is how everyone writes and reads experimental 
specs. I can certainly say that L4S is ambitious. But that is a feature, 
not a bug, and it was well-understood when the work was adopted onto the 
experimental track. It will only have been pretentious if it eventually 
fails to deliver on its promises. Nonetheless, when problems are found, 
there should be a presumption that the proponents might be able to fix 
them, and space should be allowed for that process.

Regards


Bob

{Note 1}: These mailing lists are for co-ordinating a large amount of WG 
work. Please yourself try not to merely repeat the arguments of others 
when posting (unless the chairs have asked for a consensus call). Rough 
consensus requires every substantive objection to be addressed. So 
're-tweeting' just leaves everyone less time for technical progress.


On 11/11/2019 16:30, Sebastian Moeller wrote:
> 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/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/