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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
