From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 CD08C3CB36 for ; Tue, 9 Apr 2019 13:21:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1554830430; bh=lOlJAE2TL2W/nCTs140jiN09AB90XDl9Yx6FFjRHhUc=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=V/73y38JCCJgz+6y0n4Xp23GcDN8AAUfDwhFhN6dPp0jSiUigv8Uzr4fpU5j54+VO yYAWug3iobKjctkA+VUCqJxjqUjjF/M0YDj/YFAMyK3VwJbRa/m9vRSBAbCiiQBpU5 hcs6qkwbW5uGlJPdt6qHOchB59cVLcGRJuhIZ+0A= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.203.215.55] ([80.187.111.166]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lqm3a-1gjVc73oag-00eJ8l; Tue, 09 Apr 2019 19:20:30 +0200 Date: Tue, 09 Apr 2019 19:20:17 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <3EDC8EAC-1EB2-4E64-8973-8AE177D8789C@gmail.com> <29981DF0-B15C-4A74-82F1-F3929F7DE66E@gmx.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----KVDP8GQFHAOP0JN0O29TT68E13C5FA" Content-Transfer-Encoding: 7bit To: Neal Cardwell CC: flent-users , Jonathan Morton , BBR Development , ECN-Sane From: Sebastian Moeller Message-ID: <26E0B1A7-5026-413A-B5A9-A11599BCD465@gmx.de> X-Provags-ID: V03:K1:kocwg3eiiOvfu3KeNsPmnPLUDX3Ro4KgamnlNsVbpzzDG3H5Q2E NN3F00xJc58/wgYQXxRZC/2HWlg3OhAYrt2Aazyr7Ej4RmNIXOTrn5oQpMO3b8hqq/WP/pi oRc9YB1GHa+vV8maBcWL4a9j9xXtJ9fnxWO3yiFH6eoSH/T9aiaiKQQlx2E3iCuLfcXfHS+ HDifu8EbilEPJPckIBBrw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:dC0OQdSCuvM=:NIXmjYKp4SuXdsGVY97o/y nQYkwIuqvHI7GsEUcNM7zsTW7R4DNUhe2qfk7k7k/Az+2kNUAOwa6tI5D3ACkTUM2ZCtJ+a+t Zr9I0U+11dNhRSqMzXcllB186MHO46T1op6sc+PuQG22resdCZ8RZpfLQqdjiBbHp46Iy+CiJ pPe6dTfqz6VShRn8INyRgGMt8YxRWbhViwOHvtzROSqm2hs1jkOibu86dDnMgrbMeEiCJNoqX Otjr4xM/itGfCDSV4gX7ghrIKEj+xLtkLF1EO9+vvYBDXYZrvGfs8cEXZkv6arKzH6jBO49/O EeuiPVm8DvBOOvd07AbQD5nRAOVdJxXarl0/oRKQys0a9IB3CHP5eqqHL9bfR/1EGNOpatWqv QHC89YZvHK1vEI4uuEqKgoqiCqjUhBcmWYdLIjq82RscD0gD6LTV/x/ZCDMwapUDSwObwmmP6 UzSo0qcttLBusc6zjmNhsQtpOo1Oa6ul6JYykX0bQXnS5pFuraxgkY6NPz/fgOH/Z+PKle755 mxVGU3AGHhYjBpeDPW3FPeaI4b78GTmWqS38WZ7vm8wfwgL9gEH7BH7Cz2EzXVm6kg7y4JYdP 6lqBMtS/WIzNnxJgBEDqNeEnVCDwi4SA2eD70bVvRyvVTpj0Jt7tr3t5d/HfLJY+Eztf1IQZ0 6cHq2bZ4otDCZX7ru28pvScQAYHDpXOkj5XYYZ/wG0HhuQL5qRTJTeC/my26YAV7uvLZYg2Hi NdMydmxLRbTpnQNIOrb33M2d3sHnnzGCIY941sI/qSlPs+4wXxcfkD3eK6Dcim2NDiFVt2Rt9 VyNZPetLzgKiz2Nj+u1gnXjR4+meuPw43JwJkmJ1FG9gnSGYdXh2ZJZfGe8qifCR5pVNhhnYa R861R3ZH1ceLadok4l7CPluaXrtO/beKG7w3TPu0q8FbER8Ydnoxqy3EC6/e6i9k6CgCLWr0q +h+F0ozgxxQ== Subject: Re: [Ecn-sane] [Flent-users] [bbr-dev] duplicating the BBRv2 tests at iccrg in flent? X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 17:21:20 -0000 ------KVDP8GQFHAOP0JN0O29TT68E13C5FA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for being to vague the first time around=2E I note, as Jonathan did, = that the SCE RFC has basically the desired properties, it still uses CE wit= h the generally accepted meaning, and basically uses the ECT(1) codepoint t= he same way as current dctcp uses the CE mark, that way it has the backward= compatibility with old AQMs that only use CE as drop equivalent, the desir= ed fiber grained pulse-modulated load signal from the bottleneck, and the "= stop harder" signal that I am advocating for here=2E Basically the only thing that the L4S approach adds is some incomplete iso= lation between tcp-friendly and L4S flows=2E Incomplete as ECT(1) only can = differentiate non-marked packets (all CE-marked packets look the same in re= gards to the two but ECN field); which has two consequences, L4S will treat= all CE marked packets as belonging to an L4S flow (which is probably a) be= nign and b) L4S's problem) and it will not respond timely enough if the mar= king AQM is not of the AQM kind=2E I note that with L4S approaching experim= ental status, basically no AQM in the wider internet will be L4S-friendly, = so the latter incompleteness seems IMHO rather hostile=2E=2E=2E Best Regards Sebastian On April 9, 2019 4:33:55 PM GMT+02:00, Neal Cardwell wrote: >On Tue, Apr 9, 2019 at 2:31 AM Sebastian Moeller >wrote: > >> >> I guess I was too subtle=2E=2E=2E=2E The following is in no way incompa= tible >with >> what I wrote=2E The point I wanted to make is that redefining CE >without also >> introducing an equivalent of 'stop hard, ASAP' is an incomplete >solution=2E >> Once you introduce the missing signal the SCE proposal is a better >fit than >> L4S=2E >> Also both BBR and L4S both aim at basically ignoring drops as >immediate >> signals, both for good reasons like better throughput on links with >> spurious drops and some reordering tolerance=2E >> IMHO it is wonderfully absurd in that light to try to basically >shoehorn a >> dctcp style CE-marker into the internet, which does not allow to >carry as >> quickly a stop hard signal as tcp-friendly ECN does today=2E To repeat >the >> argument is not against finer-grained load information from the >bottleneck, >> but rather against doing only half the job and falling short of >solving the >> problem=2E >> The rationale below would maybe make sense if all the internet's >> bottlenecks would talk dctcp style ECN, but until then the rationale >falls >> apart=2E > > >OK, I think I now understand what you are suggesting=2E I can see the >potential value of having both a DCGCP/L4S/SCE-style signal and a >RFC3168-style signal=2E In your previous e-mail I thought you were >arguing >for a pure RFC3168-style approach; but if the proposal is to have both >styles, and that's what gets deployed, that sounds usable AFAICT=2E > >neal --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------KVDP8GQFHAOP0JN0O29TT68E13C5FA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for being to vague the first time around=2E = I note, as Jonathan did, that the SCE RFC has basically the desired propert= ies, it still uses CE with the generally accepted meaning, and basically us= es the ECT(1) codepoint the same way as current dctcp uses the CE mark, tha= t way it has the backward compatibility with old AQMs that only use CE as d= rop equivalent, the desired fiber grained pulse-modulated load signal from = the bottleneck, and the "stop harder" signal that I am advocating for here= =2E
Basically the only thing that the L4S approach adds is some incomple= te isolation between tcp-friendly and L4S flows=2E Incomplete as ECT(1) onl= y can differentiate non-marked packets (all CE-marked packets look the same= in regards to the two but ECN field); which has two consequences, L4S will= treat all CE marked packets as belonging to an L4S flow (which is probably= a) benign and b) L4S's problem) and it will not respond timely enough if t= he marking AQM is not of the AQM kind=2E I note that with L4S approaching e= xperimental status, basically no AQM in the wider internet will be L4S-frie= ndly, so the latter incompleteness seems IMHO rather hostile=2E=2E=2E
Best Regards
Sebastian

On Ap= ril 9, 2019 4:33:55 PM GMT+02:00, Neal Cardwell <ncardwell@google=2Ecom&= gt; wrote:
On Tue, Apr 9, 2019 at 2:31 AM Sebastian= Moeller <moeller0@gmx=2Ede>= wrote:

I guess I was too subtle=2E=2E=2E=2E The following is in no way incompatib= le with what I wrote=2E The point I wanted to make is that redefining CE wi= thout also introducing an equivalent of 'stop hard, ASAP' is an incomplete = solution=2E Once you introduce the missing signal the SCE proposal is a bet= ter fit than L4S=2E
Also both BBR and L4S both aim at basically ignoring drops as immediate si= gnals, both for good reasons like better throughput on links with spurious = drops and some reordering tolerance=2E
IMHO it is wonderfully absurd in that light to try to basically shoehorn a= dctcp style CE-marker into the internet, which does not allow to carry as = quickly a stop hard signal as tcp-friendly ECN does today=2E To repeat the = argument is not against finer-grained load information from the bottleneck,= but rather against doing only half the job and falling short of solving th= e problem=2E
The rationale below would maybe make sense if all the internet's bottlenec= ks would talk dctcp style ECN, but until then the rationale falls apart=2E<= /blockquote>

OK, I think I now understand what you are s= uggesting=2E I can see the potential value of having both a DCGCP/L4S/SCE-s= tyle signal and a RFC3168-style signal=2E In your previous e-mail I thought= you were arguing for a pure RFC3168-style approach; but if the propos= al is to have both styles, and that's what gets deployed, that sounds usabl= e AFAICT=2E

neal


--
Sent from my Android device with K-9 Mail=2E= Please excuse my brevity=2E ------KVDP8GQFHAOP0JN0O29TT68E13C5FA--