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 DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1D5823B2B7; Wed, 6 Apr 2016 14:00:08 -0400 (EDT) Received: from hms-beagle.lan ([93.237.70.232]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MGip3-1b0qIx2tYf-00DVhV; Wed, 06 Apr 2016 20:00:06 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <3C097824-8754-4169-8FAB-7C802C2FB5D8@gmail.com> Date: Wed, 6 Apr 2016 20:00:05 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <2415E651-1852-4B48-A9B8-553D1A2507AE@gmail.com> <4A573483-5188-4893-82B3-721AEF527534@gmail.com> <5031EE38-920A-4B08-858A-5DC4302450AA@gmx.de> <3C097824-8754-4169-8FAB-7C802C2FB5D8@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:oAfnYA9dKSU1BAJrpYW0lCvQxc4DRHMZsbm1zaQJM5joM/JSUXs 3JcKEDcBJhIskFBjbgjYh18FnEty87k32W4UJx/4ngzeWqkgUt5KUoWTBbWhrQ12rbIY+0G 0yMuraM229u6ds6TjzyEe8utkNUC3PgWr8QwgsDTKexyyakkkuP8/cqbiTkw2Y9JvPb5Gyw QJURFnnFRtKKRFK1J8v2w== X-UI-Out-Filterresults: notjunk:1;V01:K0:jp+x9TM9Dmw=:yzKKZjvJC1a/qqpRKGTz4J FwftWnqGJOKuVzGXDWbVJwWWk7rTmtMZjaorbTCS99krUhkjf2LGuf3hnti11+vg+OBaPGY0Z QcyS+zcZG4OYrC05ISxZ1oX6+15cr6VqAoN2y8UVeITmrkqreNjYyv8jH0WySBWMDQoQFejoQ WycnLseB+FaYnwqu3r9T+SomX9l60qKmk8A8G62BytN3NExbwKg+ofitwYimXc2RiHsKH6rKf 0yM7G4uT4yBJJ/lsM94RpImhC3gqVSv+GRKgy+ngzV8Vh5kIn//qK21TOhEfwXf0L227xDc/r uUAOKIDF5ykblQrB5ItjMltL++x+w/V+lpEQzI7MEYi3LNc4U9ruzEQGqMgNIEGV3phoF/WRo gXVvC3h+gNJB/EcDUMNKEowgGo2/ousZT4qMFEZdC8zyhtYhANXnVXtJ2zu13Oj8UWcffBdHW 7PdhylP31pzF18adM4EYvsyJqfiBS1Wy/bi37Xdld5mBGXdolzS6dTk3zcPn6oiRZKlU0DM3a A3Ii8R6oj2JBQBdbHEQBJXcyXDeNqxdD3/CuE1cjchyxru0mYTajJmUKoWf07N47SU5AUXWpF XHOdk/uNeIRWACSD0az3F1j6+t+fJc0Mwm7rAn32+FcU13cCu8puSCCG8jtw++hHBpsP06CG8 563s0A2psosBDulJLPbWBa4Ypgki7NIQA8Mto0o+BArwGrDN0Sx1UU6v5thbSKdTZ8KetRHWF hHmNHixxuAGOSm0Z/jh+4Zr9epl18XBAeizS/nSYbkJnSkEG0sw0+Xizyw1DrrCI4aM5JrJ5R lwRy6jA Subject: Re: [Cake] new code point proposed X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:00:09 -0000 Hi Jonathan, > On Apr 6, 2016, at 19:16 , Jonathan Morton = wrote: >=20 >=20 >> On 6 Apr, 2016, at 13:30, moeller0 wrote: >>=20 >>> Latency-sensitive traffic generally doesn=E2=80=99t use conventional = TCP, so the usual assumptions go out of the window. =20 >>=20 >> I fear this is not correct. Ssh is mostly using TCP and is latency = sensitive (to some degree), I agree that it would not be too well served = with LA though. >=20 > SSH is not so latency-sensitive as to require =E2=80=9CLa=E2=80=9D = service; round-trip response times of a quarter second are acceptable, = though multiple seconds are not. With flow isolation, best-effort = service is sufficient. >=20 > Even in the best-effort tin, Cake provides flow isolation and host = isolation, so any remaining latency (assuming we=E2=80=99re not in = severe overload) is self-induced by the flow itself. LLT, as I read it, = allows traffic to explicitly indicate that even self-induced latency is = unacceptable, using the =E2=80=9CLa=E2=80=9D codepoint. Hence the more = aggressive AQM setting. >=20 > However, SSH will work quite happily in an =E2=80=9CLa=E2=80=9D class = if ECN is used. The marking rate may be high in some circumstances, but = packets will not be dropped, so application latency remains low. Some = applications may benefit from this behaviour. Okay, thanks. >=20 >> Regarding UDP the challenge I see is to differentiate between = responsive and unresponsive flows. >=20 > Which we fundamentally can=E2=80=99t do quickly enough to control the = queue to =E2=80=9CLa=E2=80=9D standards, so it=E2=80=99s not worth = trying for this purpose. >=20 > So we should pessimistically assume that =E2=80=9CLa=E2=80=9D marked = traffic is unresponsive, and control all of it aggressively. Responsive = traffic which uses an =E2=80=9CLa=E2=80=9D mark will run at lower = throughput, which is exactly the expected tradeoff. Color me sceptic here.as all the other DSCPs this will only ever = work reliable on egress (and in lab settings). I like the implied = trade-offs of LA and LO, but I guess they will get as much = exposure/distribution as all the other DSCP schemes (namely, not = universal enough to be really useful). I looks like a =E2=80=9Ccute=E2=80=9D= new mode to teach cake though to allow actual testing. >=20 >> DCTCP will require much tighter target and interval settings anyway = and does not seem to be fit for the wider internet (with its assumption = of ZERO % ack packet loss). >=20 > This is actually a very good point. =20 Sorry, that was an accident then ;) > DualQ is supposedly designed to allow DCTCP to coexist with = conventional traffic, and LLT is essentially a spec for DualQ. But to = maintain minimum latency for DCTCP, both the forward and reverse paths = need to be marked =E2=80=9CLa=E2=80=9D. So if DCTCP really assumes zero = reverse-path loss, it will incur a higher round-trip delay due to the = reverse path being marked =E2=80=9CLo=E2=80=9D. But the DCTCP traffic is assumed to not leave the building, so = to speak? Best Regards Sebastian >=20 > I do sometimes wonder what those guys are smoking. >=20 > - Jonathan Morton >=20