Re: [aqm] AQM schemes: Queue length vs. delay based

[Andrew Mcgregor <[e-mail]>]

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) <[e-mail]> wrote:

>
> On Nov 13, 2013, at 2:43 PM, Anoop Ghanwani <[e-mail]> wrote:
>
> On Wed, Nov 13, 2013 at 12:14 PM, Naeem Khademi <[e-mail]>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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>
>
> ------------------------------------------------------
> 8 issues in virtual infrastructure
> http://dcrocker.net/#fallacies
>
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>
>


-- 
Andrew McGregor | SRE | [e-mail] | [phone]