Strongly agree!!! I suspect it might be useful to think of the probing as a "greedy algorithm" that is stopped by drops, so that a nutso-evil scheme gets stopped by drops the same way. I just don't know much about what I've now defined as nutso-evil TCP (:-))
--dave [This is *not* suggested as a new term of art] On 04/22/2014 02:47 PM, John Leslie wrote: > 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]> > -- 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
