From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 298953CB35 for ; Tue, 23 Jul 2019 18:24:57 -0400 (EDT) Received: by mail-qt1-x829.google.com with SMTP id w17so43478470qto.10 for ; Tue, 23 Jul 2019 15:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s64tPHGKhckNBszrCAtgWZsuRhbQ5keiO+5ycPsHpRk=; b=nulcMKpORTeu5Lxe5/c9sWQNdSCCBrSbohNBT9tfq0J9f1gv2smHVNdD5eJJwE4yrg 4aCgZPq2p3j+jAtCAMP4Z0PPTt5q/hzTdTSKvvYFxqK4gvUOLx3S5WiTkmJRPP7j7z+Z JlqJadmd/fJjfb8Hf0Ek8RZvpnEPK2ptGUHeVctSwNR9KY2Pfn0r0Pz0NcjRQ7I+BjD3 Zo1Wg7LNreaRFykXTzC7q28NbiXuCKX6aY8qKen1dlGO6VahfxQ8J/75BHb3udh9cWpi 4+PHlvtUkinleWgmO3JarHYLQh0mCzmT9yqwGdHTWCFRjVzS95iEkfx8K6NQ0LH/TZuS n62Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s64tPHGKhckNBszrCAtgWZsuRhbQ5keiO+5ycPsHpRk=; b=coNM1KFNsZ+NObvQpfxLIAT/0p/bawcIQcviPtu4nVan9pYMP7lT0FW9Ft6GS+aU5R ZNeZj3xtbj08+Zz6ZQOEzYoy1yVhfEKMlBsuJicOBz3Dx4Ymllg2OQty5u7UZp5tau6X JAQ1vioVWcXID7dKCEx0TNpAd+9+9azEtpT1mGSBDwn7bTIQziXt0roVsy4rhi5sokIV VioBCVxd0KI7EfB7MA66YWVGYNUpZbIe+FWR+Cp/bfVJSpWL3MN2MsrfNvtAf7u4sN5N OfwQBkBOOkW89u2m9UmRxNXusZEuYwNCEQdDK5HTaQtjIDPwwMMXSS/arWNOavQj175Q pn6A== X-Gm-Message-State: APjAAAW6tnT18NN7S4APgbEuApE4nbjEWegg1XsbOyr5NL05mQWZ9wSt 3W5Q2Ja2QWVSjFgqx6JL3a0= X-Google-Smtp-Source: APXvYqwF/ha3Z9qSI+zGYnHG8ruIw9V+qKeDEvn0MFMUfeU5JN85HzhV3GCU3dXdoAgdtn6sd3PShg== X-Received: by 2002:ac8:520e:: with SMTP id r14mr54853850qtn.50.1563920696720; Tue, 23 Jul 2019 15:24:56 -0700 (PDT) Received: from jonathartonsmbp.lan (173-246-8-242.qc.cable.ebox.net. [173.246.8.242]) by smtp.gmail.com with ESMTPSA id a23sm18547030qtp.22.2019.07.23.15.24.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 15:24:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: <629a1cef-d49c-b6dc-b495-5dd8087b849f@bobbriscoe.net> Date: Tue, 23 Jul 2019 18:24:55 -0400 Cc: "ecn-sane@lists.bufferbloat.net" , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <350f8dd5-65d4-d2f3-4d65-784c0379f58c@bobbriscoe.net> <40605F1F-A6F5-4402-9944-238F92926EA6@gmx.de> <1563401917.00951412@apps.rackspace.com> <8741152A-EBF0-48F4-A123-B34A638322A1@gmail.com> <629a1cef-d49c-b6dc-b495-5dd8087b849f@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Ecn-sane] per-flow scheduling 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, 23 Jul 2019 22:24:57 -0000 > [BB] The objective measure of famine/plenty that all congestion = controls use is a combination of the loss level, ECN level, queue delay, = etc. In the paper, I referred to BBRv2's distinction between famine and = plenty (which is at 1% loss) and in a footnote I expressed a preference = for a more gradual transition. Coincidentally, 1% loss corresponds to about 1.5Mbps goodput at an = Internet-scale 80ms RTT, assuming a Reno transport. Obviously at = different RTTs it corresponds to different goodputs, and you might argue = that shorter RTTs are also common. But now we have a common reference = point. Oh, and under similar conditions, 1% marking corresponds to about 30Mbps = with L4S (ie. cwnd=3D200). That's a 20:1 ratio versus Reno, which you = might want to think about carefully when it comes to fair competition. > The use of the two words famine and plenty wasn't intended to imply = only two states. It's a continuum (like the spectrum between famine and = plenty). Okay. I still happen to disagree with the argument, but single-queue AQMs are = still a valid improvement over single dumb FIFOs. They improve = reliability by reducing losses and timeouts, and help to reduce lag in = online games. That's the practical problem facing most Internet users = today, and that's where my solutions are focused. >> Regardless, my assertion is not that FQ is required for ultra-low = latency, but that flows requiring ultra-low latency must be isolated = from general traffic=E2=80=A6 >>=20 >> It is true that SCE doesn't inherently carry a label distinguishing = its traffic from the general set, and thus DualQ cannot be directly = applied to it. But there is a straightforward way to perform this = labelling if required, right next door in the Diffserv field. The = recently proposed NQB DSCP would likely be suitable. I don't think that = the majority of potential SCE users would need or even want this = distinction (the primary benefit of SCE being better link utilisation by = eliminating the traditional deep sawtooth), but the mechanism exists, = orthogonally to SCE itself. > To enable SCE and RFC3168 in two queues rather than per-flow queues, = if you required SCE packets to be identified by a DSCP, if the DSCP got = wiped (which it often does), your SCE traffic would mix with 3168 = traffic and starve itself. Under certain simplifying assumptions, yes. But those assumptions would = include that the 3168 queue was also providing SCE marking in the FQ = style, which might not be appropriate for what is effectively a single = queue carrying mixed traffic. It would be as if your DualQ was = providing L4S-style signalling in its Classic queue, which I'm sure you = would not advocate. As a de-facto representative of the cable industry, I hope you are aware = of the irony that it is chiefly cable ISPs who are bleaching Diffserv = information out of consumer traffic? The starvation problem can be eliminated entirely by providing SCE = marking only on the queue intended for SCE traffic (so only CE marks on = the 3168 queue). Mis-marked traffic would then revert to purely 3168 = compliant behaviour, which SCE does naturally when given only CE marks. = This option is an important advantage of having a clear distinction = between the two signals; there is no ambiguity at the receiver about = what type of signal it's receiving and thus which response is demanded. As a reminder, we *also* have a solution specifically for single-queue = AQMs implementing SCE. It's not a knobs-free solution as the FQ version = is, but it exists and it seems to work. I expect we will need to = explore its dynamic characteristics more thoroughly in the near future. >> I have also drawn up, as a straw-man proposal, CNQ - Cheap Nasty = Queuing: >>=20 >> = https://tools.ietf.org/html/draft-morton-tsvwg-cheap-nasty-queueing-00 > OK. Can you say whether you've tested this exhausitvely? Need to know = before we all spend time reading it in too much depth. To quote Knuth: "I have only proved the above code correct, not tried = it." But we may get time to quickly implement CNQ and/or LFQ, in = between preparations for Friday. (By which I mean implementing it in = Linux.) This stuff is not central to our work on SCE, since we already = have Cake for running experiments. I think Pete Heist wants to try putting CNQ in his offline simulator as = well, which already has LFQ. So that should provide an early sanity = check. - Jonathan Morton