Subject: [aqm] What is a good burst? -- AQM evaluation guidelines

From: Naeem Khademi <[email-masked]>
Date: Sun, 15 Dec 2013 06:35:04 +0100

Hi all

I'm not sure if this has already been covered in any of the other threads,
but looking at http://www.ietf.org/proceedings/88/slides/slides-88-aqm-5.pdfand
draft-ietf-aqm-recommendation-00, the question remains: "what is a
good
burst (size) that AQMs should allow?" and/or "how an AQM can have a notion
of the right burst size?".

and how "naturally-occuring bursts" mentioned in
draft-ietf-aqm-recommendation-00
can be defined?

Regards,
Naeem

---

From: David Collier-Brown <[email-masked]>
Date: Sun, 15 Dec 2013 09:59:25 -0500

It's not been discussed recently (I'm a relatively new lurker) but some
types of burst might be easily classifiable.

In particular, if a video or voice stream requires no less than X KB/S,
has a second's "headroom" in the form of delivered but undisplayed data
and suffers a 1-second outage, then it should be expected to emit a
burst of 2X before settling back down to its previous rate. The AQM
system should permit this, while at the same time defending its stream
of X from bursts from elsewhere that would starve it for a second or more.

In principle, this kind of analysis can be applied to interactive
communications, with latency and user think time taking the place of
throughput and headroom in the logic. For any given stream, a (moving)
average of its needs can be discovered.

Batch transfers are harder to characterize, but at the same time can be
split into "a human is actively waiting for this" and "get it done for
tomorrow" classes (;-))

This kind of "no less than" resource management is something that has
been well-studied, and substantial work (IBM's "goal mode") was done as
long ago as the mainframe era. 

In capacity planning, one often sets guarantees that a database write
process get no less than a certain amount of resources, and then
constructs trend watchers to ensure that the database's own growth in
activity doesn't render the guarantee too small. This is quite ordinary
"state of practice" work for a planner,  and is often applied
holus-bolus to short-run networks like cluster interconnects.

Researchers in queuing-network models will know much more about the
state of the art, and how it can be applied to AQM.

--dave (a capacity planner and user of queuing networks) c-b

On 12/15/2013 12:35 AM, Naeem Khademi wrote:
> Hi all 
>
> I'm not sure if this has already been covered in any of the other
> threads, but looking at
> http://www.ietf.org/proceedings/88/slides/slides-88-aqm-5.pdf
> and draft-ietf-aqm-recommendation-00, the question remains: "what is a
> good burst (size) that AQMs should allow?" and/or "how an AQM can have
> a notion of the right burst size?". 
>
> and how "naturally-occuring bursts" mentioned
> in draft-ietf-aqm-recommendation-00 can be defined? 
>
> Regards,
> Naeem 
>
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
[email-masked]           |                      -- Mark Twain
(416) 223-8968

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 15 Dec 2013 21:42:12 +0000

On Dec 14, 2013, at 9:35 PM, Naeem Khademi <[email-masked]> wrote:

> Hi all 
> 
> I'm not sure if this has already been covered in any of the other threads, but looking at http://www.ietf.org/proceedings/88/slides/slides-88-aqm-5.pdf and draft-ietf-aqm-recommendation-00, the question remains: "what is a good burst (size) that AQMs should allow?" and/or "how an AQM can have a notion of the right burst size?". 
> 
> and how "naturally-occuring bursts" mentioned in draft-ietf-aqm-recommendation-00 can be defined? 

Imagine, if you will, that you have a host and a network in front of it including a first hop switch or router.The host gas a TCP offload engine, which is a device that accepts a large chunk of data and sends as much of it as it has permission to send as quickly as it can. The host has, for sake of argument, a 10 MBPS interface, and everything else in the network has interfaces whose rate are measured in gigabits. The host gives its TSO one chunk of data, so that can't  be called a "burst" - it's one message. The TSO sends data as quickly as it can, but presumably does little more than keep the transmission system operating without a pause; while it might queue up 45 messages at a crack, there is no requirement that it do so, so the term "burst" there doesn't have a lot of meaning. And as the data moves through the network, the rate of the particular session is absolutely lost in the available capacity. So a burst, in the sense of the definition, never happens.

Now, repeat the experiment. However, in this case the host as a gig-E interface, and the next interface that its router uses is 10 or 100 MBPS. The host and its TSO, and for that matter the router, do exactly the same thing. As perceived by the router, data is arriving much more quickly than it is leaving, resulting in a temporarily deep queue. If the propagation delay through the remainder of the network and the destination host are appropriate, acknowledgements could arrive at the TSO, soliciting new transmissions, before that queue empties. In that case, it is very possible that the queue remains full for a period of time. This network event could last for quite some time.

The second is clearly a burst, according to the definition, and I would argue that it is naturally occurring.

I imagine you have heard Van and/or Kathy talk about "good queue" vs "bad queue". "Good queue" keeps enough traffic in it to fully utilize its egress. "Bad queue" also does so, but does so in a manner that also materially increases measured latency. This difference is what is behind my comment on the objective of a congestion management algorithm (such as TCP's but not limited to it) that its objective is to keep the amount of data outstanding large enough to maximize its transmission rate through the network, but not so large as to materially increase measured latency or probability of loss. 

I would argue that this concept of "Good Queue" is directly relevant to the concept of an acceptable burst size. In the first transmission in a session, the sender has no information about what it will experience, so it behoves it to behave in a manner that is unlikely to create a significant amount of "bad queue" - conservatively. But it by definition has no numbers by which to quantify that. Hence, we make recommendations about the initial window size. After that, I would argue that it should continue to behave in a manner that doesn't led to "bad queue", but is free to operate in any manner that seeks to keep the amount of data outstanding large enough to maximize its transmission rate through the network, but not so large as to materially increase measured latency or probability of loss. At the point that it sends data in a manner that creates a sustained queue, it has exceeded what would be considered a useful burst size.

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 15 Dec 2013 22:57:39 +0000

Fred,

Jonathan Morton, Michael Scharf & I took Naeem's question to mean 
"What should an AQM assume the size of a good burst is?" whereas I 
think you and David C-B took the question to mean "What should an 
end-system take the size of a good burst to be?".

Naeem, could you clarify which you were asking?

Bob

At 21:42 15/12/2013, Fred Baker (fred) wrote:

> http://www.ietf.org/proceedings/88/slides/slides-88-aqm-5.pdf and 
> good burst (size) that AQMs should allow?" and/or "how an AQM can 
> have a notion of the right burst size?".
> >
> draft-ietf-aqm-recommendation-00 can be defined?
>
>
>Imagine, if you will, that you have a host and a network in front of 
>it including a first hop switch or router.The host gas a TCP offload 
>engine, which is a device that accepts a large chunk of data and 
>sends as much of it as it has permission to send as quickly as it 
>can. The host has, for sake of argument, a 10 MBPS interface, and 
>everything else in the network has interfaces whose rate are 
>measured in gigabits. The host gives its TSO one chunk of data, so 
>that can't  be called a "burst" - it's one message. The TSO sends 
>data as quickly as it can, but presumably does little more than keep 
>the transmission system operating without a pause; while it might 
>queue up 45 messages at a crack, there is no requirement that it do 
>so, so the term "burst" there doesn't have a lot of meaning. And as 
>the data moves through the network, the rate of the particular 
>session is absolutely lost in the available capacity. So a burst, in 
>the sense of the definition, never happens.
>
>Now, repeat the experiment. However, in this case the host as a 
>gig-E interface, and the next interface that its router uses is 10 
>or 100 MBPS. The host and its TSO, and for that matter the router, 
>do exactly the same thing. As perceived by the router, data is 
>arriving much more quickly than it is leaving, resulting in a 
>temporarily deep queue. If the propagation delay through the 
>remainder of the network and the destination host are appropriate, 
>acknowledgements could arrive at the TSO, soliciting new 
>transmissions, before that queue empties. In that case, it is very 
>possible that the queue remains full for a period of time. This 
>network event could last for quite some time.
>
>The second is clearly a burst, according to the definition, and I 
>would argue that it is naturally occurring.
>
>I imagine you have heard Van and/or Kathy talk about "good queue" vs 
>"bad queue". "Good queue" keeps enough traffic in it to fully 
>utilize its egress. "Bad queue" also does so, but does so in a 
>manner that also materially increases measured latency. This 
>difference is what is behind my comment on the objective of a 
>congestion management algorithm (such as TCP's but not limited to 
>it) that its objective is to keep the amount of data outstanding 
>large enough to maximize its transmission rate through the network, 
>but not so large as to materially increase measured latency or 
>probability of loss.
>
>I would argue that this concept of "Good Queue" is directly relevant 
>to the concept of an acceptable burst size. In the first 
>transmission in a session, the sender has no information about what 
>it will experience, so it behoves it to behave in a manner that is 
>unlikely to create a significant amount of "bad queue" - 
>conservatively. But it by definition has no numbers by which to 
>quantify that. Hence, we make recommendations about the initial 
>window size. After that, I would argue that it should continue to 
>behave in a manner that doesn't led to "bad queue", but is free to 
>operate in any manner that seeks to keep the amount of data 
>outstanding large enough to maximize its transmission rate through 
>the network, but not so large as to materially increase measured 
>latency or probability of loss. At the point that it sends data in a 
>manner that creates a sustained queue, it has exceeded what would be 
>considered a useful burst size.

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 16 Dec 2013 07:34:52 +0000

On Dec 15, 2013, at 2:57 PM, Bob Briscoe <[email-masked]>
 wrote:

> Fred,
> 
> Jonathan Morton, Michael Scharf & I took Naeem's question to mean "What should an AQM assume the size of a good burst is?" whereas I think you and David C-B took the question to mean "What should an end-system take the size of a good burst to be?".

I can't comment on what he means. I took the question as "what should a system that is in receipt of what it might consider a 'burst', and more especially a 'good burst', to be?"

I don't know that a sending transport (which is to be distinguished from the queueing arrangement in that same system) or a receiving system *has* a definition of a "good" or "bad" burst. The one is sending data, which in the context of y two examples might be a good or bad idea, and the other is receiving it. From the receiver's perspective, the data either arrived or it didn't; if it arrived, there is no real argument for not delivering it to its application...

---

From: Naeem Khademi <[email-masked]>
Date: Mon, 16 Dec 2013 14:47:34 +0100

Bob, Fred and all

I'll copy/paste the question here again: "what is a good burst (size) that
AQMs should allow?" and/or "how an AQM can have a notion of the right burst
size?"

So, obviously, as Bob mentioned, I'm concerned about what AQMs should or
shouldn't do. The mission of dealing with packet bursts in addition to the
task of keeping the standing queue very low or minimal is part of an "AQM
evaluation criteria" I envision. While I do agree with all Fred's remarks,
I'm more concerned to have an answer for this, for where AQMs might get
deployed.

An example: when designing my AQM X should I care about 64K TSO-generated
bursts to safely pass without dropping or not?  Does the answer (whatever
it is) also apply to the burst sizes typical of multimedia traffic, etc.?
if the answer is "yes", should an AQM design be actively aware of what
application layer does in terms of sending bursty traffic or not? and to
what extent if yes?

Regards,
Naeem

On Mon, Dec 16, 2013 at 8:34 AM, Fred Baker (fred) <[email-masked]> wrote:

> > Jonathan Morton, Michael Scharf & I took Naeem's question to mean "What
> should an AQM assume the size of a good burst is?" whereas I think you and
> David C-B took the question to mean "What should an end-system take the
> size of a good burst to be?".
>
> I can't comment on what he means. I took the question as "what should a
> system that is in receipt of what it might consider a 'burst', and more
> especially a 'good burst', to be?"
>
> I don't know that a sending transport (which is to be distinguished from
> the queueing arrangement in that same system) or a receiving system *has* a
> definition of a "good" or "bad" burst. The one is sending data, which in
> the context of y two examples might be a good or bad idea, and the other is
> receiving it. From the receiver's perspective, the data either arrived or
> it didn't; if it arrived, there is no real argument for not delivering it
> to its application...
>

---

From: Naeem Khademi <[email-masked]>
Date: Mon, 16 Dec 2013 15:05:56 +0100

and to clarify more about what else was discussed, it seems to me some of
us tend to correspond and relate the notion of "good queue" vs. "bad queue"
used by KN+VJ ACM queue paper to my question on "good bursts". While they
likely to be correlated (I have no argument on this now), the notion of
"good burst" goes beyond the "good queue" defined in that paper. Based on
their definition a good queue is a queue that minimizes the standing queue
(or gets rid of it entirely) while allowing a certain amount of (sub-RTT?
typical 100 ms) bursts while avoiding the link to get under-utilized. That
notion (again, I have no argument on its correctness for now) is different
from my question on "good bursts" which means that: once we manage to get
rid of the standing queue, what types/sizes of bursts I should let the AQM
X to protect/handle?

Naeem

On Mon, Dec 16, 2013 at 2:47 PM, Naeem Khademi <[email-masked]>wrote:

> Bob, Fred and all
>
> I'll copy/paste the question here again: "what is a good burst (size)
> that AQMs should allow?" and/or "how an AQM can have a notion of the right
> burst size?"
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 16 Dec 2013 17:30:03 +0000

On Dec 16, 2013, at 6:05 AM, Naeem Khademi <[email-masked]>
 wrote:

> and to clarify more about what else was discussed, it seems to me some of us tend to correspond and relate the notion of "good queue" vs. "bad queue" used by KN+VJ ACM queue paper to my question on "good bursts". While they likely to be correlated (I have no argument on this now), the notion of "good burst" goes beyond the "good queue" defined in that paper. Based on their definition a good queue is a queue that minimizes the standing queue (or gets rid of it entirely) while allowing a certain amount of (sub-RTT? typical 100 ms) bursts while avoiding the link to get under-utilized. That notion (again, I have no argument on its correctness for now) is different from my question on "good bursts" which means that: once we manage to get rid of the standing queue, what types/sizes of bursts I should let the AQM X to protect/handle?

I think your question has a problem in it.

Going back to my thought experiment, suppose that we have a queuing point whose egress speed is X and a sender that is sending data in a CBR fashion at (1 + epsilon)*X. In a very formal sense, the entire transmission stream is a single burst, and one could imagine it taking hundreds or thousands of packets being sent and forwarded before the queue built up to a point that AQM would push back. In that case, I would expect an "acceptable burst" to be hundreds or thousands of packets. If on the other hand you have a new TCP session in slow-start that is using an intermediate link that is at the time fully utilized and on the cusp of AQM pushing back on it, the new session is very likely to tip the balance, and a burst of a few packets might well push it over the top.

So to my mind, the question isn't about the size of the burst. It is about the rate of onset and the effect of that burst on the latency and probably of loss for itself and competing sessions.

And it will never come down to a magic number N in that N is somehow "right", N-1 is "better", and N+1 is "over the top." There are no such magic numbers.

> Naeem  
> 
> 
> On Mon, Dec 16, 2013 at 2:47 PM, Naeem Khademi <[email-masked]> wrote:
> Bob, Fred and all 
> 
> I'll copy/paste the question here again: "what is a good burst (size) that AQMs should allow?" and/or "how an AQM can have a notion of the right burst size?"
> 
> So, obviously, as Bob mentioned, I'm concerned about what AQMs should or shouldn't do. The mission of dealing with packet bursts in addition to the task of keeping the standing queue very low or minimal is part of an "AQM evaluation criteria" I envision. While I do agree with all Fred's remarks, I'm more concerned to have an answer for this, for where AQMs might get deployed.   
> 
> An example: when designing my AQM X should I care about 64K TSO-generated bursts to safely pass without dropping or not?  Does the answer (whatever it is) also apply to the burst sizes typical of multimedia traffic, etc.? if the answer is "yes", should an AQM design be actively aware of what application layer does in terms of sending bursty traffic or not? and to what extent if yes?    
> 
> Regards,
> Naeem
> 

Make things as simple as possible, but not simpler.
Albert Einstein

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 15 Dec 2013 13:56:56 -0500

In message <[email-masked]>
Naeem Khademi writes:
 
> http://www.ietf.org/proceedings/88/slides/slides-88-aqm-5.pdfand

It is probably best not to try to define "naturally-occuring bursts"
since these are dependent on the type of traffic on the Internet, or
the target network.  This will vary with the type of target network
and will vary as services evolve on the Internet.  Therefore it may
not be definable beyond the words that make up this term and it may be
a disservice to try to define it.

If the draft is to attempt to define a target for burst tolerance (not
implying that leaky bucket is used even though it shares that term),
then the definition should be in terms of end results and it should
not be specific to any particular type of service.  For all services,
and perhaps most important is fairness among flows.  Beyond that the
criteria for "good end results" differs by traffic type.  For example,
for non-interactive bulk transfer high goodput and fairness are
desireable.  On the other side of the continuum, For interactive
bounded delay is important, though throughput is still important as is
fairness.

<slightly-off-topic>

The whole fairness thing is a sticky point and goes beyond AQM alone.
Today fairness on the Internet and most networks relies on the good
behavior of end-system protocols such as TCP.  There are
hyper-aggressive TCP variants and also real time applications that
don't reduce load when loss is detected.  In order for there to be
enforceable fairness something like SFQ or some variant such as
cascaded SFQ is needed to better isolate flows.  SFQ just breaks the
queue up into groups of flows and many unlucky ones will end up in a
queue with a flow behaving badly.  In cascaded SFQ if any specific
queue SFQ is growing, then that queue is broken down further.  Depth
and/or total number of queue in cascaded SFQ is generally bounded but
the end result is to very well isolated poorly behaving flows with far
less queues than would be needed for one queue per flow.

No one AFAIK has tried to allow flows to pick a type of queue (small
queue vs deep).  For SFQ or cascaded SFQ it might be best if before
loss occurs high variation in delay and/or growing delay causes the
delay sensitive application to back off.  This way if fairness is
acheived, "bounded delay" may be better acheived without forcing a
small queue.  This may also be related but slightly off topic.

</slightly-off-topic>

Back to AQM.  Some forms of AQM do better at spcific criteria or do
better at finding a good tradeoff among the commonly cited criteria:
fairness, bulk transfer goodput, bounded delay.  Where the tradeoffs
should be set is maybe not a good thing for the AQM WG to try to
define as the optimal point will depend on perspective - on what mix
of services are being used and on which services are of greater
importance to a specific individual or organization.

So briefly, my answer is: as a WG, I don't think we want to go there.
If we do go there at all, then we should define "good AQM" in terms of
acheving a "good" tradeoff between fairness, bulk transfer goodput,
and bounded delay.  IMHO sometimes vague is better.

Curtis