From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (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 2766F3B2CE; Tue, 5 Apr 2016 16:06:11 -0400 (EDT) Received: by mail-lb0-x235.google.com with SMTP id u8so16609704lbk.0; Tue, 05 Apr 2016 13:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CuZ/D5RmkHwIFWQCEIUhTS9mqUUxK1Sz7V+/dVFrx6w=; b=F/CwZr1vAWbeEDh/7PiUMeG14c+cpVLeETJAG2YiJsPYmHC/1tRugt2MpoWaGYsELy tu6NeukWVFarrkPEzlx91TBbDThVZ4/2kGXt2COKe8CyYETYnQ9LJGNtwMoNgCnNnxB0 r2MClsG3tmbDLKyA7Ullv22h4TAXobUM+puBdm4qtqr4gcnFe6vyGhYpfarD365nWXru ehaVIQT4rojYAlTSPs/v2Jp/dUKjzMlHz9bPb5UDqJIh/cvARvGEvPfWPq21TuZ/EJFM Qy5nVsgTX+Rw+SuGNJX2g6HiZ9dM/earUXG4WQqhZOM9bTZXvmRVnl9qYNOurm94kq+1 ot9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CuZ/D5RmkHwIFWQCEIUhTS9mqUUxK1Sz7V+/dVFrx6w=; b=iIw6H8Q0clcWHIBYSIyXXyVXwb6AknnpcDCxawUuFQgDp+tw1ZIp+PhuFWP0acM1Aw r37g8OBSzqzuN7qUo3IsZdS4QkIGobBuRPHXsyJK89JrnPNbMV+7QCCRSyZ0lM771zrQ TA9sWmYRoX+HnJ0QQWWUA31fO3DLwIB8owwcxAR6mpdFJ51a36PP9wS1aEXSfeJvJ86v 92zeK1QLdZ7ANBtZcoka6SGNRLIWH3FIz0fqCdy7pMASFcqUF4m/0Rt2u86MDE5SMvG0 T/qBcbLwLDwWt9g7wCu5mE+iKXpCWhT38s8hGwYm7aXgl8JE7a1wRnV/5IcvYq0BwFon t+7g== X-Gm-Message-State: AD7BkJJ1VjjCCR9rQXp3zagsJAUf8mZwCixE9ApreldcSIUkDBwjbo4WL0WevxM9QMPZpw== X-Received: by 10.112.35.162 with SMTP id i2mr5071844lbj.107.1459886769575; Tue, 05 Apr 2016 13:06:09 -0700 (PDT) Received: from bass.home.chromatix.fi (37-33-67-252.bb.dnainternet.fi. [37.33.67.252]) by smtp.gmail.com with ESMTPSA id qh4sm5796386lbb.43.2016.04.05.13.06.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2016 13:06:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Jonathan Morton In-Reply-To: Date: Tue, 5 Apr 2016 23:06:04 +0300 Cc: make-wifi-fast@lists.bufferbloat.net, cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <2415E651-1852-4B48-A9B8-553D1A2507AE@gmail.com> References: To: Dave Taht X-Mailer: Apple Mail (2.3112) 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:06:11 -0000 > On 5 Apr, 2016, at 21:57, Dave Taht wrote: >=20 > https://tools.ietf.org/html/draft-you-tsvwg-latency-loss-tradeoff-00 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. 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. 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. 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. 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. This seems like a good excuse to overhaul Cake=E2=80=99s Diffserv class = allocations. I could propose a 5-class system: 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. 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. 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. - Jonathan Morton