From nobody Mon Nov 2 00:47:42 2020 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693D13A0D33; Mon, 2 Nov 2020 00:47:29 -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_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 CsfYJMvNswhT; Mon, 2 Nov 2020 00:47:27 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 DF91C3A0CFA; Mon, 2 Nov 2020 00:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604306796; bh=Hn09OegG8Vr6OUWgBzDRanhigKcOZPef+PdWbYWBR+0=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=j6v8WXLIoj7FYsuOGmQroEU+bdqsfp6xPMLMpY7w4jnbOzergVNEg/NLtzCgE623W qNBCAmRv7TybJAdC+/IMKh64wIzX4cHK2jmoyFITA7ewRAHIZeRArV1NrN4buVzK0F 3IcYvglkcOLcSNrugicOR82c/bPSUve2gdQiL3Vk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [134.76.241.253] ([134.76.241.253]) by web-mail.gmx.net (3c-app-gmx-bap61.server.lan [172.19.172.131]) (via HTTP); Mon, 2 Nov 2020 09:46:36 +0100 MIME-Version: 1.0 Message-ID: From: Sebastian Moeller To: Ingemar Johansson S Cc: "Rodney W. Grimes" , Bob Briscoe , tsvwg IETF list , iccrg IRTF list , Christian Huitema , TCP Prague List , "De Schepper, Koen (Koen)" Content-Type: text/plain; charset=UTF-8 Date: Mon, 2 Nov 2020 09:46:36 +0100 Importance: normal Sensitivity: Normal In-Reply-To: References: <69a73308-6718-7304-be24-0eb84f77e50d@bobbriscoe.net> <202011012023.0A1KNkue011764@gndrsh.dnsmgr.net> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:wopUGQ2PPi6PDX/JCZrd8YGKkeR4ldvwKTuFBYmhysrbDjFLx50KYE7OjWKVFX/Us1MAZ az/e+NsE2yNYWESxgb9yZhPcVPEE273nUy1YQ+RTEsOI8+9SkydAkCMXe3CjV5Ab1PXcaasUuCGD ihY8bM+UXoSYdt7w+qq3eLr2AaJdlCnt/efac6I8cv7/2SqWEftCFWFDS8bRxMzEDNcXvVYP2f80 cJIfyHLExPsS64OghsjvZcokxmTQYocZkcFT9wSE5wy+0lx5QG6jGN6kK+/JO6ZUwTtrKCDXrwBy jc= X-UI-Out-Filterresults: notjunk:1;V03:K0:TU7WgeaHMuc=:HxEtn+AjktqqDVQd5xb48z GeAHTpgoT6BqtxsNt0XFeuX5cRq6G1BMN6UHzZHgzBAZRovlmn51v4W/J8EZ2cJEf8VGHaFzX DZRvJbycWcxHo3UQofTxfPHjt5g3sKz9JEwxH/uHG8ezs9knPXyU/oIaNEGsrVVaubN2QBHss ktZLNMYhfGlI6TsXWuLtM4VtDQrS6JLgFhT/r3Adymqgz+7z6/ZLlCrMoZNn6Yqp0W+ahzODn z67HtTgMT1w/m7mN4KVojxjuQ44SaMKEdoC/qy3KRYUWm4/9HoaHBdZfn6MSOmAATYwT+6dP3 wLgEfk/T6l0pFlmLYwacDrdvBXbF8S1lgwqWKT8JHA4z2itQvgnw2SDUGkPWwgcDi3z4NZ+hh G7F/KMEUeOZfQLzCMPEBHpxEqjcjy+O3svrkEAxd0XEwsvU93r4ILkpJkoAhg4MJvpsvm5TEj ykC7eI2yYBFXAYwhBYFblTdy2psFptTHA+YyPTs0BA0M25TeyUIK7HQ550l4NBMNVAPdPGcAK JQhXmjGpwZy0FnPOHkzX25WDNXE57Fa3KOxxJXnHo4FGxmw1095+a+XjM7jiUsQXmOjRSy6zK y3l4230bTwbUY= Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpPrague] [tsvwg] [iccrg] Realistic Queue delay targets X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 08:47:37 -0000 Hi Ingemar, more below in-line, prefixed [SM]. > Gesendet: Montag, 02. November 2020 um 09:30 Uhr > Von: "Ingemar Johansson S" > An: "Rodney W. Grimes" , "Bob Briscoe" > Cc: "tsvwg IETF list" , "iccrg IRTF list" , "Christian Huitema" , "TCP Prague List" , "De Schepper, Koen (Koen)" > Betreff: Re: [tsvwg] [iccrg] Realistic Queue delay targets > > Hi Rodney > > I believe part of the answer to your question is found in > https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-07#section-6.3 . T= he > fact that we begin to see the scheduling jitter does not invalidate L4S = as a > means to reduce the congestion related jitter. [SM] As so often that section does contain some theoretical observa= tions, but fails to empirically show which level of burstyness L4S can dea= l with gracefully and what the consequences are (on the bursty flow itself= , other flows in the shallow-queue and and flows in the deep queue). That = would be meaningful responses to Rodney's concern. As is that section basi= cally just claims without supporting data, that even in the face of bursty= flows, L4S should still be tried, but that must be compared to a FiFO, be= cause compared to say fq_codel with a 5ms default target, traffic with > 5= ms jitter will probably look much better after fq_codel than after L4S (L4= S will conserve the burstyness much more, while fq_codel will smooth it ou= t a bit). I wonder why such verbose but essentially non-actionable (almost u= seless) sections keep getting added to already quite long and verbose int= ernet drafts in the first place? Regards Sebastian > > Scheduling jitter exist also in cellular technology. Scheduling jitter i= s > however generally not evidence of congestion. L4S congestion marking sho= uld > therefore be designed to not trigger on this. The master thesis** the L4= S > marking threshold was set sufficiently high to avoid this but it should = be > understood that L4S marking in cellular can be implemented in smarter wa= ys. > In the master thesis, the L4S marker only inspected the queue on the RLC > layer. > There are other causes to delay jitter in cellular, HARQ retransmissions= and > handover delays are two examples. There is work in progress to reduce al= l > kinds on delay jitter, L4S is a tool to reduce congestion related jitter= . > In any case, non-congestion related jitter is not an argument against L4= S > > /Ingemar > > ** > https://kth.diva-portal.org/smash/record.jsf?dswid=3D-6303&pid=3Ddiva2%3= A1484466 > &c=3D1&searchType=3DSIMPLE&language=3Den&query=3Dbrunello&af=3D%5B%5D&aq= =3D%5B%5B%5D%5D& > aq2=3D%5B%5B%5D%5D&aqe=3D%5B%5D&noOfRows=3D50&sortOrder=3Dauthor_sort_as= c&sortOrder2 > =3Dtitle_sort_asc&onlyFullText=3Dfalse&sf=3Dall > > > -----Original Message----- > > From: Rodney W. Grimes > > Sent: den 1 november 2020 21:24 > > To: Bob Briscoe > > Cc: Christian Huitema ; tsvwg IETF list > > ; iccrg IRTF list ; TCP Prague List > > ; De Schepper, Koen (Koen) > > > > Subject: [iccrg] Realistic Queue delay targets > > > > Bob, > > > > > Christian, > > > > > > I've changed the subject line given it's no longer appropriate. > > > See inline tagged [BB]... > > > > And I am changing it again... as only addressing a statement that I ha= ve > great > > concerns about. > > > > See inline ragged [RWG] > > > > > On 01/11/2020 01:07, Christian Huitema wrote: > > ... [ much text deleted ] ... > > > > > [BB] Yes, once the IETF assigns the codepoint, BBRv2 will be 'allowe= d' > > > to send packets over the Internet as ECT(1). Then, yes, an L4S DualQ > > > Coupled AQM will classify BBRv2 packets into the L4S queue. This > > > should have a very shallow ECN marking threshold (500us - 1ms), so > > > even if the flow (whether QUIC or TCP) is flying just under the > > > available capacity, bunching of packets means it is unlikely to > > > completely avoid ECN marking between probes. If it could avoid ECN > > > marking, you are right that it would get a bump of ECN marks during > > > the probe. I haven't studied the code, but when it experiences ECN > > > marking I believe it switches into an L4S ECN mode for a while, and > > > uses ECN rather than delay probing to track available capacity. I > > > assume it switches back to BBR's delay probing mode if it gets no EC= N > > > for a while (e.g. the bottleneck might have moved). But I haven't lo= oked > at > > BBRv2's ECN behaviour in detail. > > > > [RWG] I have great concern about this 500uS to 1mS ECN marking thresh= old > > given that I have recently learned the latest WiFi standards actually = run > with a > > packet aggregation time of 4mS thus making it probably impossible to h= ave > > such traffic work in such a targeted low latency queue. > > > > [RWG] Has any consideration been given to what is already deployed on= the > > Internet as link layer technologies that would preclude the operation = of > the > > L4S low latency queue? > > > > Regards, > > -- > > Rod Grimes > rgrimes@freebsd.org > > > >