Re: [tsvwg] [tcpm] L4S status tracking

Bob Briscoe <ietf@bobbriscoe.net> Wed, 06 November 2019 18:36 UTC

Return-Path: <ietf@bobbriscoe.net>
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 E2D5312011C; Wed, 6 Nov 2019 10:36:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 CS_NdBtBxXEU; Wed, 6 Nov 2019 10:36:42 -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 840111200F1; Wed, 6 Nov 2019 10:36:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=d5XXrySn0WiTqFbYB0jY9DUcnk9Cvt7MkaqI/Jv+PpM=; b=59rB5cwDJBGyc5nQZauGoJdGq dZlEXwaHqazHUpMBxxuOCpJa/k5t4S3Ysh+kIJ4Wkoj8JB+LEUPzEQSZrGxx21NybNK9vtzT1mhtU E9O9pWbVMGQf0VeLeWWUlU+7uMvQqXaJgzq4mgTgN+l2710Gu5lNE5Ia9CDmHDETtdYHfY7R/VnhK sFXKmhTAi1RRhCPrae+KiiKebnV5xHdAob/xiF0Q/Eekij3/a206PLu8mukwtDoMnvJIvmiss02Qa NvQ6V8kf3fjKKoWUeLNRQsAZs0LL86m0IVsR0ojcKDEKr9CnmASpvnLLRXz4hEfNbWyyyjbzPFZwj /nZtO8qtA==;
Received: from [31.185.128.31] (port=39542 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 1iSQAY-00047m-4g; Wed, 06 Nov 2019 18:36:38 +0000
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: Wesley Eddy <wes@mti-systems.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "tcpm@ietf.org" <tcpm@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> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <bc12fc37-2c7a-d6c4-8372-3b341682c4bf@bobbriscoe.net>
Date: Wed, 6 Nov 2019 18:36:37 +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: <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: multipart/alternative; boundary="------------55C4F94FFDD19FAEF04A8A6D"
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/tsvwg/q_eWhWfaWKo1M3oHIVGGOR5js3k>
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: Wed, 06 Nov 2019 18:36:46 -0000

Michael,

Regarding the only usage you say you do object to, I've already said...

On 04/11/2019 18:09, Bob Briscoe wrote:
> I have never, to my knowledge, used the term classic TCP, or classic 
> TCP congestion control.

...because Classic is intended as a a description of a set of congestion 
controls. The protocol is relatively irrelevant.

Pls see my response to Sebastien concerning the slightly positive 
connotation of the word 'classic'.
And how even a nonsense word coined for "something intended to be 
superseded" will develop a negative connotation as soon as it is defined.
This implies that the problem you've raised is impossible to solve 
without upsetting certain sensitive people.


Bob

On 06/11/2019 07:23, Scharf, Michael wrote:
>
> Bob,
>
> I am not convinced by any of your statements.
>
> There are more than 500.000 hits in Google for „non-iPhone“ and I see 
> many that are not about fakes.
>
> Certainly, I don’t insist in the term „non-L4S“. This is just an 
> example. I already proposed „non-L4S-enabled“ as well. I fail to 
> understand how „non-L4S-enabled TCP“ could be confused with „non-L4S 
> traffic“. But, as outlined below, anyway there are other solutions.
>
> Also, I don’t object to the term „Classic“ when referring to ECN and 
> other related concepts if that use of the term has strong TSVWG 
> consensus. For instance, "classic“ ECN feedback, „classic“ queue, 
> „classic“ traffic would work for me in case TSVWG strongly supports 
> that term.
>
> Thus, personally, I am not asking for any disruptive change. I don’t 
> ask to avoid „Classic“ in general.
>
> What does **not** work for me is the term „Classic“ TCP, in particular 
> when refering to TCP as standardized by TCPM. I also don’t agree to 
> the term „classic“ congestion Control for Reno, CUBIC, CTCP, i.e., 
> work of the TCPM working group. To me, the authors of this document do 
> not have the right to tag work of the TCPM working group with a term 
> such as „classic“ that is used in marketing language.
>
> And there are plenty of simple ways to avoid that problematic term 
> „Classic“ TCP. Here are some more examples:
>
>   * TCP without the L4S extension
>   * TCP (senders/stacks/connections) not using L4S
>   * TCP without support of L4S
>   * TCP (senders/stacks/connections) lacking L4S support
>   * TCP (senders/stacks/connections) not participating in the L4S
>     experiment
>   * … and more and also permutations thereof
>
> You can also try to reword text to just to avoid the term „Classic“ 
> TCP to work around the problem.
>
> Regarding congestion control, you can refer instead to
>
>   * specific algorithms such as Reno or CUBIC
>   * „high-speed loss-based congestion control“
>   * or any of the above terms, e.g., „congestion control without L4S
>     support“ and the like
>
> My ask is a simple editorial change that will IMHO only affect few 
> occurences of the term „Classic“. Can you please propose next steps 
> that addess my concern?
>
> Thanks
>
> Michael
>
> *Von: *Bob Briscoe <mailto:ietf@bobbriscoe.net>
> *Gesendet: *Mittwoch, 6. November 2019 01:22
> *An: *Scharf, Michael <mailto:Michael.Scharf@hs-esslingen.de>; Rodney 
> W. Grimes <mailto:4bone@gndrsh.dnsmgr.net>
> *Cc: *Wesley Eddy <mailto:wes@mti-systems.com>; tsvwg@ietf.org 
> <mailto:tsvwg@ietf.org>; tcpm@ietf.org <mailto:tcpm@ietf.org>
> *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking
>
> Michael, Rod,
>
> Altho non-L4S is a reasonable idea, I think it has more of a negative 
> connotation than classic. For instance, consider describing Android 
> phones as non-iPhones.
>
> Also, in the ecn-l4s-id draft, we introduce the possibility that some 
> operators might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) 
> into the same queue as L4S traffic (and we say that in this case the 
> queue would be called the Low Latency queue). This shows that the term 
> non-L4S is not a good choice for a name, because the words it is made 
> from already give it a meaning of its own that conflicts with the 
> definition you want it to have in certain contexts.
>
> 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.
>
> The term Classic for the non-L4S service, its queue, its traffic, its 
> congestion control, etc. is defined in the terminology section of the 
> drafts, so I think it's best to live with this - it's not a 
> significant problem. Indeed, it has become widely used and widely 
> understood since 2015, and changing it to non-L4S now would cause 
> unnecessary confusion.
>
>
>
> Bob
>
>
>
> On 04/11/2019 19:21, Scharf, Michael wrote:
>>
>> I agree. „non-L4S“ may be even better.
>>
>> Michael
>>
>> *Von: *Rodney W. Grimes <mailto:4bone@gndrsh.dnsmgr.net>
>> *Gesendet: *Montag, 4. November 2019 20:17
>> *An: *Scharf, Michael <mailto:Michael.Scharf@hs-esslingen.de>
>> *Cc: *Bob Briscoe <mailto:ietf@bobbriscoe.net>; Wesley Eddy 
>> <mailto:wes@mti-systems.com>; tsvwg@ietf.org <mailto:tsvwg@ietf.org>; 
>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>> *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking
>>
>> > You can e.g. use ?non-L4S-enabled TCP?.
>> >
>> > Terminology does matter to me given that I strongly disagree to any 
>> use of ?marketing language? when it comes to TCP.
>>
>> My concern here of use of terms like, legacy, classic, new, old
>> is that they are pretty much all of the relative from and thus
>> ambiguous over time.
>>
>> newReno is new only relative to Reno, that is fairly clear,
>> but if I said newTCP or oldTCP with what frame should the
>> reference be evaluated.
>>
>> I believe in the case of L4S the time invariant term would be,
>> as Michael suggests above, "non-L4S".   Note that enabled
>> for me is a noise word in this context, and TCP may or may
>> not be needed depending on context, but for literal replacement
>> of Legacy or Classic "non-L4S" is invariant over time.
>>
>> Rod
>>
>> > Michael
>> >
>> >
>> > Von: Bob Briscoe<mailto:ietf@bobbriscoe.net>
>> > Gesendet: Montag, 4. November 2019 19:09
>> > An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>; Wesley 
>> Eddy<mailto:wes@mti-systems.com>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>
>> > Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>
>> > Betreff: Re: [tcpm] [tsvwg] L4S status tracking
>> >
>> > Michael,
>> >
>> > Previously, I have been told not to use the term standard for RFCs 
>> that are not standards. RFC5681 is 'only' a draft standard. This is 
>> why, in the IETF at least, I avoid using the term "standard TCP 
>> congestion control". I generally call it Reno when referring to the 
>> congestion control.
>> >
>> > I have never, to my knowledge, used the term classic TCP, or 
>> classic TCP congestion control.
>> >
>> > And I rarely use the term legacy, and if I do I'm happy to have 
>> alternatives suggested.
>> >
>> > I've checked the L4S drafts, and there is one phrase that I shall 
>> leave in ecn-l4s-id: "the traditional TCP Reno additive increase", 
>> because this is correctly used to mean the traditional increase (in 
>> numerous AIMD CCs), not traditional TCP. There was one other 
>> occurrence of "traditional TCP senders" in a whole para in an 
>> appendix that has just been deleted anyway. And in aqm-dualq-coupled 
>> there was one "legacy TCP flows" (changed to "Classic traffic" now in 
>> my local copy, using the defined term in all the L4S drafts).
>> >
>> > l4s-arch is getting a complete make-over for terminology, so I will 
>> check that next.
>> >
>> > inline...
>> >
>> >
>> > On 23/08/2019 15:01, Scharf, Michael wrote:
>> >
>> > Hi Wes,
>> >
>> >
>> >
>> > I?d like to add a smaller item that is mostly editorial and can 
>> hopefully be sorted just out by re-wording, albeit it may require a 
>> careful analysis of all documents.
>> >
>> >
>> >
>> > As already noted in 
>> https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY<https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY> 
>> , I object to the terms ?traditional TCP? and also ?classic TCP? or 
>> ?legacy? TCP when referring to a TCP implementation according to IETF 
>> standards-track RFCs.
>> >
>> >
>> >
>> > To me as a non-native native speaker, all these terms have a 
>> negative connotation. I also think this language is typical to 
>> marketing material.
>> >
>> > You're entitled to your opinion but, as a native speaker, I don't 
>> think 'classic' or 'traditional' are particularly pejorative, tho 
>> they can be when used in a context that intends them to be. They also 
>> mean "stood the test of time". I find 'legacy' has a connotation of 
>> marketing-speak, but it's not that bad.
>> >
>> > This is an enduring problem when trying to improve on the good work 
>> that other people have done before you (which is the context of 
>> everything we are doing). We need a word that distinguishes the old 
>> from the new, but we don't want to completely trash the thing that 
>> has already been successful, but had its day.
>> >
>> > Nonetheless, it is also important not to be too precious about past 
>> work. We all recognize that Reno TCP is unscalable and has problems. 
>> IMO, it is OK to describe technologies that have had their time with 
>> negative connotations. Indeed, you have been an author (with me) of 
>> an RFC on open issues in congestion control.
>> >
>> > I notice you haven't suggested an alternative term for "the 
>> thing(s) we are trying to improve on". Not surprising, because it's 
>> difficult.
>> >
>> > When we (the L4S developers) were first looking for a term for the 
>> non-L4S queue and the non-L4S service, we didn't want to use 'legacy' 
>> for the above reasons, but we did want to imply pre-existing, so we 
>> decided on 'classic', which we all felt had a generally neutral 
>> connotation, but said what we meant.
>> >
>> > Finally, I do not want this issue to take up any time that would 
>> detract from technical issues.
>> >
>> >
>> >
>> > Bob
>> >
>> >
>> >
>> >
>> > My prefered term when referring to TCP according to standards-track 
>> specification is ?standard TCP?. I would also be fine with other 
>> terms as long as they are neutral and make clear that experiments do 
>> not replace, deprecate, or outperform standards.
>> >
>> >
>> >
>> > Similarly, I think that term such as ?classic? is not appropriate 
>> for the TCP standard congestion control (?Reno?). As of today, this 
>> is the TCP congestion control algorithm on standards track that has 
>> IETF consensus. The term in the TCPM charter is ?TCP standard 
>> congestion control?. I also think that terms such as 
>> ?Reno-compatible? or the like would be neutral.
>> >
>> >
>> >
>> > Note that I do not object to the terms ?classic ECN?, ?legacy ECN?, 
>> ?legacy AQM? or the like, i.e., if the context is ECN and not 
>> specifically TCP or the TCP congestion control. I believe it is up to 
>> the TSVWG do decide if this term shall be used for compliance to RFC 
>> 3168. I have no strong opinion on that. As far as I can see, most use 
>> of the term ?classic? is in this context and I don?t ask for changes 
>> in those cases.
>> >
>> >
>> >
>> > Some use of the term ?Classic Service? may also require careful 
>> review to clearly separate it from TCP Standard behavior.
>> >
>> >
>> >
>> > Note that some use of the term ?Classic TCP? would probably also 
>> apply to ?Classic QUIC? once the QUIC standard is finished. To me as 
>> a non-native speaker, it would be really strange to use the term 
>> ?classic? in the context of a brand-new transport protocol. IMHO in 
>> that case the term ?classic? would be even more confusing.
>> >
>> >
>> >
>> > I also add the TCPM list in CC to ensure consistency.
>> >
>> >
>> >
>> > Thanks
>> >
>> >
>> >
>> > Michael (with no hat)
>> >
>> >
>> >
>> >
>> >
>> > Von: Wesley Eddy<mailto:wes@mti-systems.com>
>> > Gesendet: Sonntag, 11. August 2019 07:08
>> > An: tsvwg@ietf.org<mailto:tsvwg@ietf.org>
>> > Betreff: [tsvwg] L4S status tracking
>> >
>> >
>> >
>> > I created tickets in the TSVWG "trac" tool in order to help keep track
>> > of the individual things that look like they should be addressed in
>> > progressing L4S document set:
>> >
>> > https://trac.ietf.org/trac/tsvwg/report/1?sort=ticket&asc=1&page=1
>> >
>> > I'll try to update these based on the ongoing discussions, updates,
>> > etc., but it will make it very easy if you happen to mention the ticket
>> > numbers or some key words in threads and messages, when significant.
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > tcpm mailing list
>> > tcpm@ietf.org<mailto:tcpm@ietf.org>
>> > https://www.ietf.org/mailman/listinfo/tcpm
>> >
>> >
>> >
>> > --
>> > ________________________________________________________________
>> > Bob Briscoe http://bobbriscoe.net/
>>
>> > _______________________________________________
>> > tcpm mailing list
>> > tcpm@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tcpm
>>
>> -- 
>> Rod Grimes rgrimes@freebsd.org
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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