David Collier-Brown <[email protected]> wrote: > > Just a clarification: a greedy TCP will try to send more packets than > will fit,
Clarification is good! However, I'd like to work out a sufficiently precise definition of "greedy TCP" here. My personal preference would be to call a TCP "greedy" when it is probing for additional capacity, and only then. (I'm quite willing to work with a different definition; but I think we need _one_ definition when we talk of "greedy TCP". > and with a bad queuing algorithm will fill buffers, while with a > good one will cause drops. Please forgive me if you can: I like to think in terms of whether packets are arriving faster than they can be forwarded, or slower -- not in terms of what's in the buffer(s). > The buffer-filling is a secondary effect, and can be avoided. I'd say it SHOULD be avoided, except in limited cases. When TCP is _not_ probing for additional capacity, buffering helps TCP. When TCP _is_ probing for additional capacity, buffering increases the depth of the sawtooth. Buffering _always_ tends to increase delay for real-time flows. > The harm to other streams caused as a direct effect is the problem, > and may indeed be hard to deal with, Maintaining multiple buffers can help _a_lot_ here. > or distinguish from a flow enthusiastically probing to see if it can > go faster through the > bottleneck link. Yes, distinguishing the probing is hard. :^( I suggest we think in terms of assuming TCP is probing, absent any actual indicator that it isn't. > The fix for the latter is drops, of course. Dropping packets is a _poor_ fix -- though often it's the best fix available. :^( In an "ideal" world, we'd be able to identify the next packet of that flow to go out and ECN-mark it as Congestion Experienced. That's hard, of course, but it would be a better fix if everything worked that way. > The fix for a TCP who ignores drops is ... maybe *lots* of drops? (:-)) Excellent question! But first we should ask, can we tell that's happening? If we could, I'd suggest turning off all buffering for that flow. That would probably drop *lots* of packets when we turn it off. And it seems quite fair to deny the benefits of buffering to any TCP flow that doesn't cut back its sending rate. -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
