From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 261AF3CBFE; Tue, 5 Apr 2016 16:28:08 -0400 (EDT) Received: from hms-beagle.lan ([93.237.70.232]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MMjgF-1atpdZ2Z6l-008XRD; Tue, 05 Apr 2016 22:28: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: <2415E651-1852-4B48-A9B8-553D1A2507AE@gmail.com> Date: Tue, 5 Apr 2016 22:28: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> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:2iESaExEuOdwE+nGoKVP4P/+rfasZMJrMy5aqnlZraXi0CUloSP xUr6jMl2C4VwAZc6Xq3keh91wkAo15Uv5P2L+3Ja3+xourauYWEKr+K/BXgqN87P/APy0ae H8qgJ+SrtmK+6JWl4rUYQwGtPY0QrpsGSqw/MrYAzhEeQWp0lfvGrruVheyBNLaP0iBuuCW ApFjVLNLr/sLHqJG/gqbA== X-UI-Out-Filterresults: notjunk:1;V01:K0:vLx9XdZCmi4=:YDWNHHJRQjllJDkSlpy/HL epoSR17dlfnQC6zL02+Ah3qQ9dmz21erlCt6spE51EMFytV9/KNBxQXsc7INJpHLYGM/CT42j F+7cg36ZIqBZCOdFG3iivGPPlX3ZswY8LX0+o8WW9XHH4YiPXA+X2egjnpA7+e591CD3FGSOD 6yyh07vADgosUImSkjdM/G5O04hN4VOvDOM6HRFN3Yz6LrQ1rdLfZ6TQt9uv4h9fO92RpFVjn E3yyOvH17dyvpV016awtcZxk+u3y+l78YxkaMb37KAdzZ7ZgCyvPqJM6y8+onWopjNbcaXA2e xQcETViNas9FQcQkgphxc2iVoOn7mcYTMNPfTpB5tLnlSIXQ2DyTTFeQeLemqDGsMTL+0Ag0m 22YPhcNoUvqibVtWahH2dvARAGmBhs1/V3D7KZCI48sVOk7U6dYz0tTV8mPsw8JKAYttl0TAM kNVa1YM9BJJfxNRx4Iy03SXzLq0YKbOQM13y8j+hv0+2zdBU3tv+TFWQq6v/391zqdp6oYCQF oal87Sk7JTf/Kd/0wCINwTwT9o/QTKqLxf0QY39xG2AKHc1MZszCiQszpM2IlEYVFexGSyu4K thFXr1kin2u1CrEenyzVTTtJHkL2Nqfgj0VXoPqQ6xfFpdubhPRAn+Sezc/8Yl/TVTCXcXE7a BOT+Vt6RLwM5ii1h6R0JtpQiAz9M4Q2810NLEWAj7yOeD/FraOYqkzZlEuquJIoFiLI7Ssuu6 iGr27YdsH7TLKiMYKYRFEMhHKXPDth/iagWQIOhq2ZMqhBsMWUCA1Zx1XpwxtCvipjHrT7v6s xDWaTKA 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: Tue, 05 Apr 2016 20:28:09 -0000 > On Apr 5, 2016, at 22:06 , Jonathan Morton = wrote: >=20 >=20 >> On 5 Apr, 2016, at 21:57, Dave Taht wrote: >>=20 >> https://tools.ietf.org/html/draft-you-tsvwg-latency-loss-tradeoff-00 >=20 > Interesting. This is obviously written around the DualQ AQM, but it = seems feasible to implement within Cake=E2=80=99s framework. I=E2=80=99m = somewhat pleased that this appears to mark a move away from using ECN = alone to describe whether DCTCP is in use or not. >=20 > Some of the requirements are written in a way that assumes a single = queue of fixed maximum size for each of =E2=80=9CLa" and "Lo", rather = than a dynamic, flow-isolated system as Cake is. It might be reasonable = to suggest clarifying the language to take these cases into account. >=20 > We can already vary the Codel parameters between tins, which provides = an obvious mechanism to make the queue management much more aggressive = for =E2=80=9CLa=E2=80=9D traffic, and more relaxed for =E2=80=9CLo=E2=80=9D= traffic. I don=E2=80=99t think we need to explicitly limit the queue = allocation to =E2=80=9CLa=E2=80=9D traffic as specified. >=20 > Another detail which differs from Cake=E2=80=99s view of the world is = that neither La nor Lo have priority over each other. While Cake does = not implement strict priority, it does implement soft priority as part = of its effort to minimise latency for the upper tins; the most explicit = part of this is that bandwidth consumed by higher tins is removed from = lower tins=E2=80=99 allocations. However, this effect could be hidden = by making the two DRR weights equal for the lower tin. >=20 > Obviously, traffic marked with the existing =E2=80=9Clow latency = intent=E2=80=9D DSCPs can be treated as =E2=80=9CLo=E2=80=9D traffic = when there is no admission control in place, without any requirement for = re-marking. This is consistent with what Cake does anyway. >=20 > This seems like a good excuse to overhaul Cake=E2=80=99s Diffserv = class allocations. I could propose a 5-class system: >=20 > Tin 0 =3D LLT =E2=80=9CLo=E2=80=9D traffic (inc. existing low-loss & = high-throughput classes), 256/256, 100%, increased target & interval. > Tin 1 =3D Best Effort traffic, 256/256, 100%, standard target & = interval. > Tin 2 =3D LLT =E2=80=9CLa=E2=80=9D traffic (inc. existing low-latency = classes), 256/256, 100%, standard target, reduced interval. This might back fire, as far as I understand interval is the = reaction time window for a flow, this needs to be roughly in the = ballpark of the RTT, reducing it (significantly) will make the AQM quite = trigger happy. This might be in line with the LA proposal, but what if = LA traffic has to cross a satellite link? Best Regards Sebastian > Tin 3 =3D Low Priority traffic, 2048/16, 6.25%, standard target & = interval. > Tin 4 =3D Network Control traffic, 4096/1, 6.25%, increased target & = interval. >=20 > Note that Tin 4 is almost, but not quite, strictly = admission-controlled, discouraging the use of =E2=80=9Cnetwork = control=E2=80=9D DSCPs for general traffic. Tins 0-2 implement LLT as = specified. Tin 3 takes the unusual and counter-intuitive step of = placing =E2=80=9Clow priority=E2=80=9D traffic in a high tin, but the = effect should be very similar to existing behaviour, due to the = soft-priority system and the low bandwidth allocation. >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake