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 63B703CB39 for ; Tue, 9 Apr 2019 02:31:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1554791419; bh=egyg+akIV5U0s/7/vlLx+96fVbwpnqdQyIlUkvkGFfw=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=MR3YSU2sDxr/8VPqdewCcUKdwEO52c2ys4olLkrFe8UrdidAhNdARgVAI+x3LN73e jG08vb6O1ROuvOvZVsWnXBwrbTdVEVwUq4JWs6Q4PsCm9C3e2Eeg4f1FnVoEjzfR/7 4N2hn09noe6LVFuCrvhFytoTtKhIB17NFrxODHGA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.205.250.74] ([80.187.111.129]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MADqP-1h2ycl3yQ5-00BJqY; Tue, 09 Apr 2019 08:30:19 +0200 Date: Tue, 09 Apr 2019 08:30:14 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <3EDC8EAC-1EB2-4E64-8973-8AE177D8789C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Neal Cardwell CC: flent-users , Jonathan Morton , BBR Development , ECN-Sane From: Sebastian Moeller Message-ID: <29981DF0-B15C-4A74-82F1-F3929F7DE66E@gmx.de> X-Provags-ID: V03:K1:g6F5Qd9duHyI0T9nbtucincgrv51Y4fJdqH9XW4v8QiK+7hn5id qMEdHKFL2DmKDrkevVAvAOYA6M9MJrVk1NIkfyNDgGhpjd+87n0ECD+AizDOtv01uDEnng4 gHI4iB/KJesB4Ho7nLiU5iYHcVttoqFyqTyONRwSdylaaItA7r1/FTYdl8JP/cOJr5gHQ4z IMigR9sZhGS49RiDzdb4A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:A/kfv4kqiPo=:DQ3zyy9CLj220MTbuKxj6i RvLO5edJ8w7G25TvTSOUZDbuaJtTDwSs6rTolQAq7NOs9k0CPJX/l973qE/g8TeCeLP0RTo2I UCmO61GrvwMfGAI13hiutWs17z73IZEvVhwtkRy7i209V1OurxnCdzBUWyHlXfui8+w5vyezz jHwosrKUgDFLUc3P2nh3LPsH4OAHP6aCWXxkNjNmfcdkv85Aq6Z9u77FWYj5tS3aOQlF3uwzs oHDde/0+eab+iiV6MNIR4OXFcmevG2+NFyb4sBFqicPOZu2rfKv5HsYIqdeXY8BFyclmLrfHE CQH9CKIGpei0oUUE8rKgHiy6t3q/L3CYEC2LyBmerb883jl4Z+1cu+lQ8hW8TRY2xwlQQ4jGl b1p1DIZ5TP/6zdV93gfzg0iRG0iDXkfuH9dJU9qVxZLLkIHHtjUmcUuWgIpr2MY9i9IQ4I7nM 2vawmPAvIUjtdDnxRLJK4h6KsSd8RC7Q5lh0MBqzdFh+jTHPTxgfRZwxpr0Tf0u3wfi30SJAG kVWEqtrnwDNEtRYH7FVq2khTvHocJiiMiS39bY+4NqTwt8ffbADJ2tiHi0UYZoNfq76opX5sd 5EwYEQDt6CMMGcqg8mQAEaMhIAdxEkiZlThcAymfqFeLyBdVM7OPCCm2bMi1mh+hnwGemvln2 xwHwcRasOdGcxG+fmHMIN+p98iWjUFOF+Kz801Esvpg8OZ8TqVsN+n+mjSTzPwZYdYVXQt5Nk lIlVvnc/6gmAi2D8A0I3XZsxsvCAbQ6T1kG7axJrfhYM1//Gsbpg8AL2q6n7MbHV3M3zGVsIg xyb5/ucofsqEt1Nnh5MCbt3/0GUSc908zSyzHeQ/VZQpbESbrSuJmVCvQLvoxiTVEePrVxrH+ onJml/cNEf6T5mQ/0h2TQ7wzKc/4sFp7WG28d0BHw7iY+1NpoAcyp9gdFKDzthZoDWTvOtHDI 1Iiw9DlPaBA== 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 06:31:08 -0000 Hi Neal, On April 9, 2019 3:33:13 AM GMT+02:00, Neal Cardwell wrote: >On Sat, Apr 6, 2019 at 10:38 AM Sebastian Moeller >wrote: > >> Hii Neal, >> >> >> On April 6, 2019 1:56:06 PM GMT+02:00, Neal Cardwell > >> wrote: >> >On Fri, Apr 5, 2019 at 12:20 PM Jonathan Morton > >> >wrote: >> > >> >> > On 5 Apr, 2019, at 6:10 pm, 'Neal Cardwell' via BBR Development >< >> >> bbr-dev@googlegroups=2Ecom> wrote: >> >> > >> >> > Right=2E I didn't mean setting the codel target to 242us=2E Where >the >> >slide >> >> says "Linux codel with ECN ce_threshold at 242us sojourn time" I >> >literally >> >> mean a Linux machine with a codel qdisc configured as: >> >> > >> >> > codel ce_threshold 242us >> >> >> >> I infer from this that BBR's new ECN support won't work properly >with >> >> standard CE marking behaviour, only with the sort of signal that >> >DCTCP >> >> requires=2E Is that accurate? >> >> >> > >> >Yes, that's correct=2E Thus far BBR v2 is targeting only >DCTCP/L4S-style >> >ECN=2E >> >> Out of curiosity, given that BBR intentionally interprets >lost >> packets as a lossy path instead of a signal send by an AQM to slow >down, >> why do think that dctcp style ECN is a good fit? In classic ECN the >CE mark >> is exactly the signal BBR should get to have a higher confidence that >> ignoring lost packets is acceptable, in dctcp it will take a while to >> convey the same signal, no? I wonder if one is willing to change ECN >> semantics already, by making CELighter weight than a packetdrop, why >not >> also using an explicit signal for emergency brake? I can't help but >notice >> that both dctcp and tcpprague face the same problem, but at least >they seem >> to be willing to take a Paket drop at face value=2E=2E=2E >> > >I think the L4S team has done a nice job of outlining the problems with >RFC-3168-style ECN, so I will just quote their explanation: 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=20 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 Best Regards > >https://tools=2Eietf=2Eorg/html/draft-briscoe-tsvwg-l4s-arch-01#section-5= =2E1 > >5 >=2E >Rationale >5=2E1 >=2E >Why These Primary Components? > > Explicit congestion signalling (protocol): Explicit congestion > signalling is a key part of the L4S approach=2E In contrast, use of > drop as a congestion signal creates a tension because drop is both > a useful signal (more would reduce delay) and an impairment (less > would reduce delay)=2E Explicit congestion signals can be used many > times per round trip, to keep tight control, without any > impairment=2E Under heavy load, even more explicit signals can be > applied so the queue can be kept short whatever the load=2E Whereas > state-of-the-art AQMs have to introduce very high packet drop at > high load to keep the queue short=2E Further, TCP's sawtooth > reduction can be smaller, and therefore return to the operating > point more often, without worrying that this causes more signals > (one at the top of each smaller sawtooth)=2E The consequent smaller > amplitude sawteeth fit between a very shallow marking threshold > and an empty queue, so delay variation can be very low, without > risk of under-utilization=2E > > All the above makes it clear that explicit congestion signalling > is only advantageous for latency if it does not have to be > considered 'the same as' drop (as required with Classic ECN > > [RFC3168 ])=2E =2E=2E=2E > >best, >neal --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E