See comments in line > > 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...
You are talking about scheduling, not AQM. I agree with you that perfect scheduling everywhere could obsolete any AQM. But as long ... > > > 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. That's a concern for _all_ traffic if _some_ greedy traffic is involved, no matter if real-time flows are there, too. > > > 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. I mean with "greedy TCP" a flow that is probing for additional capacity _at_this_ queue. Many TCP flows are bandwidth restricted elsewhere (up- or downstream), and as such not greedy to my understanding. > > > 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. That's what I meant. > > > 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. Unresponsive flows are a problem if they absorb the AQM's drop/mark signals, so that the responsive flows miss these and continue to grow their sending rates. > > 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. You missed my point: A renewal process of TCP flows is not a problem for AQM. But it is a problem for AQM _evaluation_. The 100% capacity utilization cannot be reached, no matter how good or bad the AQM is. The capacity utilization is solely defined by the traffic definition and not by the AQM. Nevertheless we have such traffic in reality. If we want to evaluate this, we first should be clear what we expect. > > > 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]> Wolfram _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
