Re: [Ecn-sane] per-flow scheduling

[Bob Briscoe <ietf@bobbriscoe.net>]

[-- Attachment #1: Type: text/plain, Size: 5215 bytes --]

Folks,

As promised, I've pulled together and uploaded the main architectural 
arguments about per-flow scheduling that cause concern:

Per-Flow Scheduling and the End-to-End Argument 
<http://bobbriscoe.net/projects/latency/per-flow_tr.pdf>


It runs to 6 pages of reading. But I tried to make the time readers will 
have to spend worth it.

I have to get on with other stuff for a while. I've caught up with 
/reading/ this thread (after returning from my break), but refrained 
from responding to some individual points, Will try to do that soon.


Finally, I want to emphasize that the purpose is for advocates of 
per-flow scheduling to understand that there is a coherent world view 
that agrees with the arguments in this paper. If you have a different 
set of assumptions and perspectives that leads you to advocate per-flow 
scheduling and disagree with some of these arguments, that's to be 
expected.

The purpose is to explain why some people don't want FQ, and therefore 
why it's important to leave the choice open between FQ and DualQ. That 
has always been the intent of L4S, which supports both.



Bob

On 18/07/2019 06:24, Jonathan Morton wrote:
> Quoting selectively:
>
>> On 18 Jul, 2019, at 1:18 am, David P. Reed<dpreed@deepplum.com>  wrote:
>>
>> 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.)
>>
>> 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
>
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/


[-- Attachment #2: Type: text/html, Size: 6792 bytes --]