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 874913CB36 for ; Sat, 6 Apr 2019 10:38:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1554561468; bh=UFAaUSIAufOWAhAevQoBWQf4eHNHUGZQoP2+7MMlCEk=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=A4D6O6bQuxbu6Xofz/ii1xqY1dC86qyhFex2NKGwdSEJyClGHHq9kDDJymqOwU23a LXOoERLGZJqjf4ulAYLNF/NyMQSbd2N7DfXgzhlPOWkCZn7mF0DO7QaSUKyjJuxqsM 1qg0xgFGncSIjlWaAeCdeSQAlBqM/n0VdEtA2he0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.206.254.162] ([80.187.112.132]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MNqcR-1hFmS72jlL-007WwI; Sat, 06 Apr 2019 16:37:48 +0200 Date: Sat, 06 Apr 2019 16:37: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: flent-users@flent.org, Neal Cardwell , Jonathan Morton CC: BBR Development , flent-users , ECN-Sane From: Sebastian Moeller Message-ID: X-Provags-ID: V03:K1:7gAgdB6WFLgO4qzeT/kMhNQp0XUogF+fMRWtb925pIeXQlOLtg/ OcMf7PL5VM8Kjr+nOkIYJi899RgiJiVCdyXAyhlKkuJLuNbRwZVLoR5wfqMIWuUYiA6qzCP VxbBEHcXRBUDcPVvDazbEV5+xgu7YE7cJIs5dfggyC04I3U0fC6vJo6PGMwRBw2t78sKh5G pxYh3Cmwpl8jB44O89Rxw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:2rMU37xLiHs=:XCIAKtof3oBBmpCQ3Q8Gh+ 5034QAhdMdtemXypUjKgu2VqFgoj9E0reP4Mh4bT0IzUo0IAszg8zXweleK0ZbY0nwvX8+Z0+ TrRlq0nV9SoFru+qmBDuWwH2TL69FQ/kMh65X+DcgbbJDfAs6jNtNesf7FtEKMGf+L6UI8+AA WSL1kzOZGblFooY9LM5YpiHC5OgobgOKFuVjU8ufywxY6ROG7uC+OUHZjOGto5Kv1n7yHNiAV b24v2eIWHSfRdR1jsyeZWLoPYP1HUNd9k0ZdkIt1FVbGisPi4GcXjSRRz5SLCXuVrct3K/SV8 BCwjSDZFPtkZ5GPnAigFzQ17u1waGShq4NmVOk15wK39Ub5a5xA7pP9czGD++M/vZBgHLVT4e or+v/LgYBxIvPHqiDAbMU3x0Lk2zWw2DPtuMvkYAvoUJRW3Q9J98ncP8xx8ad8Qn4e+2FlUf+ M5BNTe38HeRYOgTPPblGLSneV+hLZy7Elg4UK+/k5ZhEOWdfc0G2woXR14WbMjPb3xIZMBR9j 92m2c+esuaD0dxfhfJkcKjj398fjgRtT+MGkUKzRIsiCAbXuuXjW3DnRXPeXegNMDrjfkSfnm vU7gimPpOFLpcwJpKoxC7uKzHXsSUqnl1KBr0k8Tspf89eMIQ7f+of3olgbtd0ZGrR9evllVT sGuli7PTQjRIiubaIO/bRP5yDvgb+PTwIfZRMsy6Eyyd8XgvaqEY6py7ZpIjMEPpg6GVaS6w/ IobEpTOj/7DRW15+4GjRxJzyQRRiyYBTjd/8McPPBNrvV/phwRTVOC722DeZC85h/7ac6n5Xs dfgH9RWjjaT2vD+oMTdXPFBlu3i8sZ4+klugiCaAvaLcMthiF6KRbeRuNNgLex+cX1Wu3h6Tp FQ6k21JeqiMvU+vz3vfMPLp80KHWs80vqGHQnf2FUg6rOvhxWAGYcX3+yr9UazTFjMq7ulYOK smzjg5ls5ww== 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: Sat, 06 Apr 2019 14:38:39 -0000 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 pac= kets as a lossy path instead of a signal send by an AQM to slow down, why d= o think that dctcp style ECN is a good fit? In classic ECN the CE mark is e= xactly 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 sam= e 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 explici= t signal for emergency brake? I can't help but notice that both dctcp and t= cpprague face the same problem, but at least they seem to be willing to tak= e a Paket drop at face value=2E=2E=2E Best Regards Sebastian > >> SCE allows providing that sort of high-fidelity congestion signal >without >> losing interoperability with RFC-3168 compliant flows=2E >> > >Noted, thanks=2E > >neal --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E