TCP as deployed can be pretty bursty; TSO often results in 44 packet bursts (later in connections, once the window has opened wide enough), which is one reason IW10 caused very little harm. I wouldn't say Google favours that; as Yuchung's presentation in TCPM showed, the TCP team here is working hard to reduce that burstiness. However, that is deployed reality, and will be for some years on the net at large, no matter how undesirable it is in terms of excessive packet loss and buffer pressure.
I very much think we should be thinking about DCTCP-style ECN; that seems more deployable and a significant benefit, unlike the ambiguous benefit of classic ECN. On 15 November 2013 08:03, Fred Baker (fred) <[email protected]> wrote: > > On Nov 13, 2013, at 2:43 PM, Anoop Ghanwani <[email protected]> wrote: > > On Wed, Nov 13, 2013 at 12:14 PM, Naeem Khademi > <[email protected]>wrote: > >> >> Agreed only in general terms -- but what would be considered as "packet >> burst" and how would it be defined? This will probably have a subjective >> answer e.g. one can argue that a size of TCP sawtooth of data is a burst >> and therefore we need a BDP of buffering for that (that's what had actually >> happened implicitly over the past decade). On the other hand, the >> definition of the "burst" may likely to correspond to the application >> generating it (e.g. video frames, IW10, etc) and therefore its size (and >> even pattern) is application/transport dependent somehow. >> > > There's one more case...the incast problem. The sources themselves may > not be "bursty" but in a high port count switch, you could have 10's (or > more) ports sending traffic to a single output port at around the same time. > > Perhaps it is useful to add a description of what we mean when we say > bursty. > > > Possibly, but what you just highlighted is that there are at least two > definitions. At the Transport layer, it's not unusual for TCP to send a > number of segments back to back - our specifications say 2-4, but Google > seems to favor as many as ten, and I'm told that measurements suggest that > some on the net are sending as many as 44. That would be in a single > session. What you're discussing is what I call "lemmings"; a single thread > in a map/reduce or multi-cache application might simultaneously open short > sessions (either opening new TCP sessions or using standing TCP sessions) > with hundreds or thousands of neighbors, each of which now sends a > transport-layer burst with effects as you describe. That is an > application-layer burst. > > Bob's DCTCP suggestion could be useful in that. > > I wonder if we need a separate term for the application layer behavior, > however. Maybe "flash crowd"? > > Anoop > > Anoop > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > > > ------------------------------------------------------ > 8 issues in virtual infrastructure > http://dcrocker.net/#fallacies > > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > > -- Andrew McGregor | SRE | [email protected] | +61 4 8143 7128
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
