Just a clarification: a greedy TCP will try to send more packets than will fit, and with a bad queuing algorithm will fill buffers, while with a good one will cause drops.
The buffer-filling is a secondary effect, and can be avoided. The harm to other streams caused as a direct effect is the problem, and may indeed be hard to deal with, or distinguish from a flow enthusiastically probing to see if it can go faster through the bottleneck link. The fix for the latter is drops, of course. The fix for a TCP who ignores drops is ... maybe *lots* of drops? (:-)) --dave [I'm not being /totally/ serious, but improving the existing bottleneck signalling is worth discussing. Someone with knowledge of a bad TCP, please comnent] On 04/22/2014 03:39 AM, LAUTENSCHLAEGER, Wolfram (Wolfram) wrote: > 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 > > -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest [email protected] | -- Mark Twain _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
