LAUTENSCHLAEGER, Wolfram (Wolfram) <[email protected]> wrote: > > Shouldn't we more concentrate on what we expect from a good AQM?
I'd love to... > The only thing we might expect from an AQM is to prevent greedy TCP > sources from drawing buffers permanently towards full state, I'm not the least bit sure that's possible. :^( However, it might be possible to separate the queue(s) of "greedy" TCP flows from other queues. There's a lot of room for discussion about how to do that... > instead of the much better almost empty state, Consider the class of real-time flows, which hardly ever want to stand in line for more than a millisecond or two. (They can generate redundancy to compensate for packet loss, or ideally have ECN-marked packets get through quickly.) > while maintaining full link utilization. That's a concern of _some_ traffic, but not real-time flows. > In all other situations, I'm convinced, AQM cannot improve a lot. "All other situations" covers a lot of ground... :^( And we may not all mean the same thing by "greedy TCP". Standard TCPs probe for additional capacity if they have anything to send. I consider that enough to call them "greedy"; but I'm sure others don't agree. > But at least, in these cases, it should not make things worse. "Make things worse" is perhaps insufficiently defined. Any delay at all "makes things worse" for real-time traffic. Failure to discover unused capacity "makes things worse" for TCP. > Of course the greedy TCP case can be overlaid by others (unresponsive > flows, application paced flows, a renewal process of short lived flows, > synchronized start of flows etc.etc.), These cover quite different situations... Unresponsive flows are a problem iff we buffer too much/many of them. Application-paced flows are a problem only if they're probing for increased capacity. Revewal flows are a problem if they guess badly at remaining capacity. > and we should take this into account. But we should not expect a lot > if those "others" dominate the scenario. I speculate that none of these would be a problem if we limited the extent which we buffer them. -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
