Re: [tsvwg] [tcpm] L4S status tracking
"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Mon, 11 November 2019 10:30 UTC
Return-Path: <Michael.Scharf@hs-esslingen.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 F19AA120059; Mon, 11 Nov 2019 02:30:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 b7eyNBMHKsFc; Mon, 11 Nov 2019 02:30:35 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DCB12012E; Mon, 11 Nov 2019 02:30:34 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id BE97D25A17; Mon, 11 Nov 2019 11:30:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573468232; bh=mASq9UAZYkcUF20v7hPScn0RNy+B5Rx1eiBOoOZtg40=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=mIvsCzDDZV0OeAYt+icNzIHk1uMqXBZPQW+l24jqMsTJbajTDyLrXDADc3AmlcbnG dtDu/7XqbpIl8iOHc4tmjW1jDRYweWYOvIm5C2e8cWSTqU6+48ATujtI0nfRIjetLQ iLTJkDV8glkZtB9BcaqQOKIl7qMR7thn/u7OnYFU=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIP6_4w8tPl2; Mon, 11 Nov 2019 11:30:30 +0100 (CET)
Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 11 Nov 2019 11:30:30 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Mon, 11 Nov 2019 11:30:30 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, Sebastian Moeller <moeller0@gmx.de>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>
CC: "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] [tcpm] L4S status tracking
Thread-Index: AQHVlHDo/QyQY/CFY0WIa8bThLkPwaeBc3oAgAAjRRCABBjMAIAAHI2Q
Date: Mon, 11 Nov 2019 10:30:29 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4FA3A2@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <HE1PR07MB4425250E0E10522A4574210FC2790@HE1PR07MB4425.eurprd07.prod.outlook.com> <E0CE23BB-F1B4-4CB0-8415-16AEB8730B12@gmx.de> <HE1PR07MB44252042E5B7743B81B55529C27B0@HE1PR07MB4425.eurprd07.prod.outlook.com> <6EC6417807D9754DA64F3087E2E2E03E2D4EDE27@rznt8114.rznt.rzdir.fht-esslingen.de> <HE1PR07MB442569B09E4D7120BBE427DDC2740@HE1PR07MB4425.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB442569B09E4D7120BBE427DDC2740@HE1PR07MB4425.eurprd07.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/TnuZr9wGx0o76ZOUkJljbO315jQ>
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 10:30:39 -0000
Indeed, we will find a way to figure out what the consensus is. @all: Input to the TCPM (and TSVWG) chairs is welcome, so that we can prepare a well-structured discussion and hopefully find a solution that works reasonably well for all. Michael > -----Original Message----- > From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com> > Sent: Monday, November 11, 2019 10:44 AM > To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Sebastian Moeller > <moeller0@gmx.de>; Ingemar Johansson S > <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>; > 4bone@gndrsh.dnsmgr.net > Cc: tcpm@ietf.org; tsvwg@ietf.org; Ingemar Johansson S > <ingemar.s.johansson@ericsson.com> > Subject: RE: [tsvwg] [tcpm] L4S status tracking > > Hi > I believe that it is best that I leave this discussion for the time being, I guess > that it will be brought up again in some organized fashion. Hopefully then it will > not eat up all the meeting time :-| > > /Ingemar > > > -----Original Message----- > > From: Scharf, Michael <Michael.Scharf@hs-esslingen.de> > > Sent: den 8 november 2019 19:41 > > To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; Sebastian > > Moeller <moeller0@gmx.de>; Ingemar Johansson S > > <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>; > > 4bone@gndrsh.dnsmgr.net > > Cc: tcpm@ietf.org; tsvwg@ietf.org > > Subject: RE: [tsvwg] [tcpm] L4S status tracking > > > > Hi Ingemar, > > > > A question for clarification, given that the term "classic" is used for different > > aspects in L4S: > > > > Does your preference include the terms 'Classic' TCP and 'Classic' congestion > > control, specifically when referring to a state-of-the-art TCP stack as > currently > > shipped by major operating systems? > > > > If so, can you provide references for use of the terms 'Classic' TCP and > 'Classic' > > congestion control for what is currently widely deployed in the Internet? > > > > Thanks > > > > Michael > > > > > > > > > -----Original Message----- > > > From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com> > > > Sent: Friday, November 8, 2019 6:04 PM > > > To: Sebastian Moeller <moeller0@gmx.de>; Ingemar Johansson S > > > <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>; Scharf, Michael > > > <Michael.Scharf@hs-esslingen.de>; 4bone@gndrsh.dnsmgr.net > > > Cc: tcpm@ietf.org; tsvwg@ietf.org; Ingemar Johansson S > > > <ingemar.s.johansson@ericsson.com> > > > Subject: RE: [tsvwg] [tcpm] L4S status tracking > > > > > > Hi Sebastian > > > > > > I clearly mentioned that I would prefer that the term "classic" is > > > kept, the earth will likely continue to spin around its axis even if > > > it is changed to something else > > > 😊. But then it should be something that the group can agree on, I > > > don't however see any consensus. > > > > > > /Ingemar > > > > > > > -----Original Message----- > > > > From: Sebastian Moeller <moeller0@gmx.de> > > > > Sent: den 6 november 2019 08:08 > > > > To: Ingemar Johansson S > > > > <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>; > > > > Michael.Scharf@hs- esslingen.de; 4bone@gndrsh.dnsmgr.net > > > > Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; > > > tcpm@ietf.org; > > > > tsvwg@ietf.org > > > > Subject: Re: [tsvwg] [tcpm] L4S status tracking > > > > > > > > Hi Ingmar, > > > > > > > > IMHO this is a slippery slope argument. Because if minor changes to > > > > the > > > naming > > > > are "impossible" how will changed to the underlying concepts and > > > > methods > > > be > > > > acceptable to you. Because surely these other organizations already > > > committed > > > > to what is proposed to the IETF as an experiment? > > > > My gripe with the classic moniker is that this term is not outcome neutral. > > > What > > > > I mean is, that while in itself not necessarily negative, it implies > > > > that the new > > > kid > > > > on the block is the way into the future, while the classic version > > > > should head > > > into > > > > it's well-deserved retirement. And on the facts this simply is not > > > > settled or accepted in the case of L4S. IMHO the testing published > > > > by the L4S/RITE folks always tested conditions that are very > > > > favorable to L4S and completely > > > ignored > > > > to reach out to the actual user community interested in low latency > > > > under > > > load. > > > > It might well be that the L4S approach might also do well in a true > > > > stress test > > > (bi- > > > > directiomal saturation on a asymmetric path with bursty cross > > > > traffic for starters), but I would like to see numbers first. And > > > > the L4S sce back-off data posted to this list in the path seems to > > > > indicate that L4S still has open ends > > > that > > > > IMHO need addressing (independent of whether 3GPP likes this or not). > > > > > > > > Best Regards > > > > Sebastian > > > > > > > > On November 6, 2019 7:12:39 AM GMT+01:00, Ingemar Johansson S > > > > <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote: > > > > >Hi > > > > > > > > > >I would prefer that the term "Classic" is kept. > > > > >L4S is not anymore an IETF only matter. Work is ongoing to get > > > > >support for L4S in 3GPP for 5G and the input papers there use the term > > classic. > > > > >It is of course too late for changing classic to something else, > > > > >but then it is appreciated that It is something that the group can > > > > >agree on and I don't see that we are there, therefore it is better > > > > >to stick to "classic". > > > > >And to me the term "classic" does not sound negative. > > > > > > > > > >/Ingemar > > > > > > > > > >> Message: 3 > > > > >> Date: Wed, 6 Nov 2019 00:22:44 +0000 > > > > >> From: Bob Briscoe <ietf@bobbriscoe.net> > > > > >> 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> > > > > >> Subject: Re: [tcpm] [tsvwg] L4S status tracking > > > > >> Message-ID: <7f1aa4ae-05d6-b07c-50b0- > > ab899c5c30b7@bobbriscoe.net> > > > > >> Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > > > >> > > > > >> 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- > > > > >> hDvWO3I5MudwpNkKyH > > > > >> > > > > > >Y<https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF- > > > hDvWO3I5MudwpNk > > > > >> > KyHY> , I object to the terms ?traditional TCP? and also > > > > >> > KyHY> ?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 > > > > >> > > > > > > >https://protect2.fireeye.com/v1/url?k=9e3cf770-c2e8fb81-9e3cb7eb-86 > > > > >4 > > > > >> > > 685b2085c-4ba6a1960c4f3e7a&q=1&e=bf49c0f0-380b-42d4-93a2- > > > > >> 9ebedff802e > > > > >> > > 0&u=http%3A%2F%2Fbobbriscoe.net%2F > > > > >> > > > > > >> > > _______________________________________________ > > > > >> > > tcpm mailing list > > > > >> > > tcpm@ietf.org > > > > >> > > https://www.ietf.org/mailman/listinfo/tcpm > > > > >> > > > > > >> > -- > > > > >> > Rod Grimes rgrimes@freebsd.org > > > > >> > > > > >> -- > > > > >> > > > > > > > > > > ________________________________________________________________ > > > > >> Bob Briscoe > > > > >https://protect2.fireeye.com/v1/url?k=861241a8- > > > > >> dac64d59-86120133-864685b2085c- > > > 16120a27ab4a751a&q=1&e=bf49c0f0- > > > > >> 380b-42d4-93a2-9ebedff802e0&u=http%3A%2F%2Fbobbriscoe.net%2F > > > > >> > > > > >> -------------- next part -------------- An HTML attachment was > > > > >> scrubbed... > > > > >> URL: > > > > >> > > > > ><https://mailarchive.ietf.org/arch/browse/tcpm/attachments/20191106 > > > > >/de7 > > > > >97 > > > > >> fd1/attachment.html> > > > > >> > > > > >> ------------------------------ > > > > >> > > > > >> Subject: Digest Footer > > > > >> > > > > >> _______________________________________________ > > > > >> tcpm mailing list > > > > >> tcpm@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/tcpm > > > > >> > > > > >> > > > > >> ------------------------------ > > > > >> > > > > >> End of tcpm Digest, Vol 187, Issue 15 > > > > >> ************************************* > > > > > > > > -- > > > > Sent from my Android device with K-9 Mail. Please excuse my brevity.
- [tsvwg] L4S status tracking Wesley Eddy
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Jonathan Morton
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Greg White
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Jonathan Morton
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Greg White
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Jonathan Morton
- Re: [tsvwg] L4S status tracking Scharf, Michael
- Re: [tsvwg] L4S status tracking Black, David
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Wesley Eddy
- Re: [tsvwg] L4S status tracking Wesley Eddy
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Pete Heist
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Greg White
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Pete Heist
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Pete Heist
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Jonathan Morton
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] [tcpm] L4S status tracking Bob Briscoe
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] [tcpm] L4S status tracking Rodney W. Grimes
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] [tcpm] L4S status tracking Sebastian Moeller
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] [tcpm] L4S status tracking Bob Briscoe
- Re: [tsvwg] [tcpm] L4S status tracking Ingemar Johansson S
- Re: [tsvwg] [tcpm] L4S status tracking Sebastian Moeller
- Re: [tsvwg] [tcpm] L4S status tracking Sebastian Moeller
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] [tcpm] L4S status tracking Dave Taht
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Greg White
- Re: [tsvwg] [tcpm] L4S status tracking Bob Briscoe
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Dave Taht
- Re: [tsvwg] [tcpm] L4S status tracking Bob Briscoe
- Re: [tsvwg] [tcpm] L4S status tracking Rodney W. Grimes
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] [tcpm] L4S status tracking Wesley Eddy
- Re: [tsvwg] [tcpm] L4S status tracking Sebastian Moeller
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Jonathan Morton
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs alex.burr@ealdwulf.org.uk
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Pete Heist
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Jonathan Morton
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Jonathan Morton
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- [tsvwg] fq_codel deployment size Dave Taht
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Pete Heist
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Tilmans, Olivier (Nokia - BE/Antwerp)
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] [tcpm] L4S status tracking Ingemar Johansson S
- Re: [tsvwg] [tcpm] L4S status tracking Gorry Fairhurst
- Re: [tsvwg] [tcpm] L4S status tracking Gorry Fairhurst
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] [tcpm] L4S status tracking Black, David
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Pete Heist
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Tilmans, Olivier (Nokia - BE/Antwerp)
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Tilmans, Olivier (Nokia - BE/Antwerp)
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Tilmans, Olivier (Nokia - BE/Antwerp)
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Tilmans, Olivier (Nokia - BE/Antwerp)
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Dave Taht
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Bless, Roland (TM)
- Re: [tsvwg] [tcpm] L4S status tracking Ingemar Johansson S
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] [tcpm] L4S status tracking Bob Briscoe
- Re: [tsvwg] [tcpm] L4S status tracking Bob Briscoe
- Re: [tsvwg] [tcpm] L4S status tracking Bob Briscoe
- Re: [tsvwg] [tcpm] L4S status tracking Bob Briscoe
- Re: [tsvwg] [tcpm] L4S status tracking Sebastian Moeller
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Pete Heist
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Greg White
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Greg White
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Sebastian Moeller
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] [tcpm] L4S status tracking Rodney W. Grimes
- Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs Pete Heist
- Re: [tsvwg] [tcpm] L4S status tracking Bob Briscoe
- Re: [tsvwg] [tcpm] L4S status tracking Bob Briscoe
- Re: [tsvwg] [tcpm] L4S status tracking Scharf, Michael
- Re: [tsvwg] [tcpm] L4S status tracking Sebastian Moeller