From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D369F3BA8E; Tue, 19 Mar 2019 04:07:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1552982834; bh=Y+trpwBDhyQZvkaw0K384l+7KlxIO95hQ9PzMXLunKs=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=FrMF90MDgKBLRwJ9hjw0OKRAXW6ReKtkhjA+R5n4x7jYV58iz3g9GiwbI5w5r8Xha 5p2mJggemvo/pcYSWK1bGpSjJYXwixvBVM/hazzjqmQ8B/zxWQRcC28yzohXZJmBwG aF4kRdIn6qo/wwy3OSHb2S7T3vtmjkjkBBHn/2VQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.16.12.10] ([134.76.241.253]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MYwQh-1hT1px0Z3j-00VeBy; Tue, 19 Mar 2019 09:07:14 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: <3C188730-DCD1-4359-AA19-F7526ECDF111@gmail.com> Date: Tue, 19 Mar 2019 09:07:12 +0100 Cc: Greg White , "ecn-sane@lists.bufferbloat.net" , Vint Cerf , "David P. Reed" , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <779D962D-ED21-43DA-A4B5-6F38D0F892F1@gmx.de> References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> <1552846034.909628287@apps.rackspace.com> <93781542-6DD4-4840-A1C6-A5C28E40A0F7@gmail.com> <3C188730-DCD1-4359-AA19-F7526ECDF111@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:ES8Wb8a/DlOHXuKaJMrpAGktr/Of5tTuF+ZgmosReJ3nCrsPJKj uixZmDLJWiZgCZKqN7MGKCB/27UhOwLq2ybAj2eX42pozHHq8fIsFOSu+VuKrM55vVYO4Xc mhRIHszYb8+xtsqogdnQTNaFW2d0D7QHE52z894cAr5bTv7trmT2uO4bSxQR/2H1uU/V4qb X74v2258sBqZk84+A6OiA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:bCDxBrwv2Gg=:B6K60l/ABGR2BATZwNJQwS wj7VZhaaQ+7zoTRoRzFyAg7QFLp8zeIOsnEReISbD1h3eqDUzqjZYNeayW9Y6P9s6IVKqpH7Y tXklzDZQVx3YxQca2m0GfrtGvlQCPbmmYhTF5+WSbH5hE7Ec1/vCsS22iEIWZl2TJTekxO42v xXAlbRy06bkZTqnVBzU8Ixi1Ye8UN+BeGSpKotseaAUfdUiBtSl50NpQcBaAunrOogaB2CN4x DEjZAlT3XXCzB95W6THadCTraxrb92q4vPga8qitSE3zyRsXXb8DgkZjTz7tSO4j/eIa0MU1T tdRxVGXqXbEjwFIx/x/vL4S6q8RmXFAo7G2yhcFM+uykzG9SNP+gIMvrRWPtzr+nfNCj0l73S ft/aBgjmiODV2AkpJNQckLAqaRMqshi6MpIBScVN4fCOz259bzmKWlZNCRXYk3RyxSrMUIy6x r6UcSSiSSVjNP0zharKIEfDVqe4h954Nqm56ISS6v/t4kA4nNhv7rX9cyhBiy7SeYYy3utVfz 5PJeZPBSVLappJyH+BkqvXpHMAWk2YCzh3Iur9Ooy8y5pkeOHRd5aXI7LE6wg0lV57xg1Mcv3 t9eKyOXh9iJHR7ORaReyFpVLeWG1/8oPf6g1HnpMRBqsvZbRQ6FDAbWoy6UJPmKLSEgPSGqFR Hr5PC4P0B6xJ11k1vnc8WE/jF8TB62yeonbZQY7ncMubgJFrw8qAlXG+v3KhrezltajzGa1AZ /ZnS4F3YmV+Wg8JTA0krSatRoDYi1xgqfffC5NEkb/6Gs+ywsAb7M0MMXvGFsl2tGa3G9oD3Y S6WanyMPsmmSsjLxvL0fCQTVIaJHVETazji/YxbL3MSSW/oHFVlnpVKtmx0pJwydZmaDWcpCg uTT0gtG4QCruRkRL+1jnT4RQc+uedrn3BSJPrmp1eUNa4UI/mDYRMIQ+W8H9eSGYB2zc7NhzB /XUlMJJ4MhA== Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 08:07:24 -0000 > On Mar 19, 2019, at 08:10, Jonathan Morton = wrote: >=20 >> On 19 Mar, 2019, at 7:52 am, Greg White = wrote: >>=20 >> L4S utilizes TCP Prague, which falls back to traditional congestion = control if the bottleneck link doesn't provide isolation. =20 >=20 > You see, this is the part I find difficult to believe that it will = operate reliably. For a start, I have seen no detailed public = description of TCP Prague, even though it has supposedly been in "open" = development for so long. My most recent information is that it's = essentially a slightly modified DCTCP. >=20 > " It would take time for endpoints to distinguish classic and L4S ECN > marking. An increase in queuing delay or in delay variation would = be > a tell-tale sign, but it is not yet clear where a line would be = drawn > between the two behaviours. " IMHO this is caused by the fact that ECT(1) is simply not = suitable as a classifier, as it will only reliably classify unmarked = packets, anything marked CE will looses the destinction whether the flow = considers itself L4S ready or not. Could anyone point me to the section = in the L4S RFCs that discusses this, please? https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/ has the = following: " Given shortage of codepoints, both L4S and classic ECN sides of an AQM would have to use the same CE codepoint to indicate that a packet had experienced congestion. If a packet that had already been marked CE in an upstream buffer arrived at a subsequent AQM, this AQM would then have to guess whether to classify CE packets as L4S or classic ECN. Choosing the L4S treatment would be a safer choice, because then a few classic packets might arrive early, rather than a few L4S packets arriving late;" But how is the L4S queue actually maintaining its low latency if it just = admitted an non-L4S flow? This _might_ work if CE marked packets are = rare, but IMHO this confirms my assessment that ECT(1) is a terrible = choice for a classifier bit. Best Regards Sebastian > Internet history is littered with failed attempts at implementing = delay-sensitive TCPs. I can immediately think of several reasons why = delay can and will vary for reasons other than the bottleneck not = implementing an isolated queue (just ask the BBR devs). The mere = presence of a wifi link on the path, even if it is never the bottleneck, = would be a trivial and common example. >=20 > So please explain (or point to good documentation) how TCP Prague = robustly avoids misbehaving in a standard ECN environment, as is = presently deployed. >=20 >=20 > SCE explicitly does not rely on specific changes in behaviour by = endpoints. It just provides a conduit of information from the network = to the receiver, in addition to standard ECN behaviour. The receiver is = free to ignore that information, without harming the network, and will = naturally behave normally and safely when that information is absent. = We have a proof-of-concept implementation (a trivial mod of sch_codel = and sch_fq_codel) which successfully passes this information across the = Internet and works with (is transparently ignored by) existing endpoints = and middleboxes. >=20 > In short, SCE is incrementally deployable by design. >=20 > The broader system of feedback and modified congestion control, which = I call ELR (Explicit Load Regulation) as an umbrella term, offers = benefits which, yes, have not yet been proved - but which are = straightforward in concept and should be amenable to analysis. It seems = likely that some work from L4S can be used in this context. >=20 > - Jonathan Morton >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat