Re: [Bloat] [e2e] [aqm] What is a good burst? -- AQM evaluation guidelines

[dpreed@reed.com]

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


End-to-end queueing delay (aggregate of delays in all queues except for the queues in the endpoints themselves) should typically never (never means <99.9% of any hour-long period)  exceed 200 msec. in the worst case, and if at all possible never exceed 100 msec.   in networks capable of carrying more than 1 Mbit/sec to and from endpoints (I would call that high-bitrate nets, the stage up from "dialup" networks).
 
There are two reasons for this:
 
1) round-trip "RPC" response time for interactive applications > 100 msec. become unreasonable.
 
2) flow control at the source that stanches the entry of data into the network (which can be either switching media codecs or just pushing back on the application rate - whether it is driven by the receiver or the sender, both of which are common) must respond quickly, lest more packets be dumped into the network that sustain congestion.
 
Fairness is a different axis, but I strongly suggest that there are other ways to achieve approximate fairness of any desired type without building up queues in routers.  It's perfectly reasonable to remember (in all the memory that *would otherwise have caused trouble by holding packets rather than discarding them*) the source/dest information and sizes of recently processed (forwarded or discarded) packets.  This information takes less space than the packets themselves, of course!  It can even be further compressed by "coding or hashing" techniques.  Such live data about *recent behavior* is all you need for fairness in balancing signaling back to the source.
 
If all of the brainpower on this list cannot take that previous paragraph and expand it to implement the solution I am talking about, I would be happy (at my consulting rates, which are quite high) to write the code for you.  But I have a day job that involves low-level scheduling and queueing work in a different domain of application.
 
Can we please get rid of the nonsense that implies that the only information one can have at a router/switch is the set of packets that are clogging its outbound queues?  Study some computer algorithms that provide memory of recent history....  and please, please, please stop insisting that intra-network queues should build up for any reason whatsoever other than instantaneous transient burstiness of convergent traffic.  They should persist as briefly as possible, and not be sustained for some kind of "optimum" throughput that can be gained by reframing the problem.
 
 
 


On Thursday, January 2, 2014 1:31am, "Fred Baker (fred)" <fred@cisco.com> said:



> 
> On Dec 15, 2013, at 10:56 AM, Curtis Villamizar <curtis@ipv6.occnc.com>
> wrote:
> 
> > So briefly, my answer is: as a WG, I don't think we want to go there.
> > If we do go there at all, then we should define "good AQM" in terms of
> > acheving a "good" tradeoff between fairness, bulk transfer goodput,
> > and bounded delay.  IMHO sometimes vague is better.
> 
> As you may have worked out from my previous comments in these threads, I agree
> with you. I don't think this can be nailed down in a universal sense. What can be
> described is the result in the network, in that delays build up that persist, as
> opposed to coming and going, and as a result applications don't work as well as
> they might - and at that point, it is appropriate for the network to inform the
> transport.
>

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