From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 670F73CB3B for ; Thu, 18 Jul 2019 01:24:26 -0400 (EDT) Received: by mail-lf1-x136.google.com with SMTP id q26so18225165lfc.3 for ; Wed, 17 Jul 2019 22:24:26 -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=8H4eo7YDp25USuD/XUVIiUEfy+e3RktLqU04TxMKG2s=; b=LeAzmQCE7CFZlZIekJHr3cCRUqg5KQ+PctOHKTt6lZfRlY+k6HlwHGTQTa8TykJ6GJ HeooHa69WUHICs6DodkMlsaWseENWI8TMDemRp5qGa+xkH6AIKWkjU/MYhaaFwumEze9 95yrbnuGPiMO51N9U71LVxvmEogn1txQNPW8+TVUTia/FTXfp7Tp8f87wg6yBR4ewXCy aH9t3uueP+GHGP/zepCK25reFc8O8i55IAJRL2hPT1oH/971JyBx1Pn7J3sQ7wvtJQ47 TeAXpYG67ojK3CtUCTUJov5OJMEAZ+qkXNF9pqotgDMBsK7xN3cRJmi1W9VY1OGfvR+1 xiRQ== 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=8H4eo7YDp25USuD/XUVIiUEfy+e3RktLqU04TxMKG2s=; b=CwnIemDKHtXcacRla1pgOn2lvp7pJS+MznL1FfiX2QYip4hADK4z+n7dwGPZsEnLMC ALcw7X2U6EbvDVtyDHEtTi/vS9r4k774GCNRqSpP5PrUF04meO3M2EUalZEcfucmBM0a mui0GAfK3NwpSwAf3v+oOA6dXaugrtdCgZiHV9jnh/mdUMKyoCdfyHJkY2knSdOsSjeL oFPP7tgO7qwWzN5GMmGiwcEGzgDRD2OYAcHjokELEz7Uw+r/MKdiuIpA+QF3LCZ//yIt IsdWx0tJyhIuvTYiWp28GTMSv7mEjjY7C0ZbhByV7LEl46xcc9iBgEBgRuWljdW4OF3m LerQ== X-Gm-Message-State: APjAAAVwEsmamLGc5sf7VMOE8oN+V4GH0bTNNBjRpu8nhxr5+7yYJirJ F1V6Nt3pUjnBDjDyp0MqPjI= X-Google-Smtp-Source: APXvYqwgNVVk4U+K9dxx6KPQOMO6ZPzru8Mre0i8BsoUmTQE1JlxAh+FIvXSuHU5pD29qbKSXDoOug== X-Received: by 2002:a05:6512:288:: with SMTP id j8mr21630038lfp.181.1563427464897; Wed, 17 Jul 2019 22:24:24 -0700 (PDT) Received: from [192.168.44.148] (37-219-185-236.nat.bb.dnainternet.fi. [37.219.185.236]) by smtp.gmail.com with ESMTPSA id n1sm3811191lfk.19.2019.07.17.22.24.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jul 2019 22:24:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton X-Priority: 3 (Normal) In-Reply-To: <1563401917.00951412@apps.rackspace.com> Date: Thu, 18 Jul 2019 08:24:18 +0300 Cc: Sebastian Moeller , "ecn-sane@lists.bufferbloat.net" , Bob Briscoe , 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> To: "David P. Reed" 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: Thu, 18 Jul 2019 05:24:26 -0000 Quoting selectively: > On 18 Jul, 2019, at 1:18 am, David P. Reed = wrote: >=20 > This lack of a way to "cooperate" among independent users of a queue = cannot be solved by a purely end-to-end solution. (well, I suppose some = genius might invent a way, but I have not seen one in my 36 years = closely watching the Internet in operation since it went live in 1983.) >=20 > So, what the end-to-end argument would tend to do here, in my opinion, = is to provide the most minimal mechanism in the devices that are capable = of building up a queue in order to allow all the ends sharing that queue = to do their job - which is to stop filling up the queue! > The optimum queueing delay in a steady state would always be one = packet or less. Kleinrock has shown this in the last few years. Of = course there aren't steady states. But we don't want a mechanism that = can't converge to that steady state *quickly*, for all queues in the = network. > The most obvious notion of fairness is equal shares among source host, = dest host pairs. There are drawbacks to that, but the benefit of it is = that it affects the IP layer alone, and deals with lots of boundary = cases like the case where a single host opens a zillion TCP connections = or uses lots of UDP source ports or destinations to somehow "cheat" by = appearing to have "lots of flows". > I write this to say: > 1) some kind of per-flow queueing, during the transient state where a = queue is overloaded before packets are dropped would provide much needed = information to the ends of every flow sharing a common queue. > 2) per-flow queueing, minimized to a very low level, using IP envelope = address information (plus maybe UDP and TCP addresses for those = protocols in an extended address-based flow definition) is totally = compatible with end-to-end arguments, but ONLY if the decisions made are = certain to drive queueing delay out of the router to the endpoints. These are points that I can agree with quite easily, and which are = reflected in my work to date. Although I don't usually quote Kleinrock = by name, the principle of always permitting one MTU per flow in the = queue is fairly obvious. One of the things that per-flow queuing provides to endpoints is = differential treatment in AQM. This is even true of LFQ, although the = mechanism may not be obvious to all since there is only one set of AQM = state; at minimum, AQM signals are suppressed for sparse flows and thus = only provided to saturating flows. SCE marking would be based on = individual packets' sojourn times, which are logically independent from = their physical position in the queue. Careful implementation of a = Codel-type AQM would also suppress CE marks (or drops) from well-behaved = flows whose sojourn times are below the target, even if unresponsive = flows are also present in the same queue, without losing accumulated = state about the latter; this is I think already a property of COBALT (as = implemented in Cake). Other AQMs which convert a sojourn time = more-or-less directly into a marking rate would also be a good fit. I would only quibble that providing per-L4-flow fairness *within* a = per-host or per-subscriber fairness structure is also feasible, in at = least some contexts; Cake implements that, for example. I hope to be = able to amplify the LFQ draft to show how to provide that in a more = lightweight manner than Cake manages, on my way to Montreal. I may also publish CNQ (Cheap Nasty Queuing) as a straw-man draft at the = same time, depending on my mood. It should be good for light relief if = nothing else. It's even lighter-weight than LFQ - but, unlike LFQ, = achieves this at the expense of performance. It maintains only enough = state to prioritise sparse flows, with a rather strict definition of = "sparse". - Jonathan Morton