On Dec 16, 2013, at 6:05 AM, Naeem Khademi <[email protected]> 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 protected]> > 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 > > On Mon, Dec 16, 2013 at 8:34 AM, Fred Baker (fred) <[email protected]> wrote: > > On Dec 15, 2013, at 2:57 PM, Bob Briscoe <[email protected]> > 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... > > Make things as simple as possible, but not simpler. Albert Einstein
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
