From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "alln-iport.cisco.com", Issuer "Cisco SSCA2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 82080201B02 for ; Mon, 16 Dec 2013 09:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13539; q=dns/txt; s=iport; t=1387215011; x=1388424611; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=k21gh1wJ6qibYymk9hqLMMKhBSyeWiJ8IxkcwELTc84=; b=QTu0BMrnrbGeI3dMTJWmhhPDx7ChnT/PGfRp9o5fw0AAIwl1kKmRDmDp oLyJz0DLyg7Aeo8bb/6BMOdZohzj30/o9JmTcnXKTGrWoQRbvdM4/npK1 WRChNneF0Pw5ceyWuyuZxK41JRG/fyqTHu074qaVYwUV57100VGG0DXZw U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAG04r1KtJXG9/2dsb2JhbABZgkZEOFW4coElFnSCJQEBAQMBDlcUBQsCAQgYLiERJQIEDgUOh2IDCQjBJQ2HAReNBoITB4MjgRMBA5AzgTGER4FrjFqFOoMqgio X-IronPort-AV: E=Sophos;i="4.95,496,1384300800"; d="asc'?scan'208,217";a="7127202" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-7.cisco.com with ESMTP; 16 Dec 2013 17:30:04 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBGHU4BA010476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 17:30:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 11:30:03 -0600 From: "Fred Baker (fred)" To: Naeem Khademi Thread-Topic: [e2e] [aqm] What is a good burst? -- AQM evaluation guidelines Thread-Index: AQHO+oR0UVOioGtzyEG2i2aMc7ccUw== Date: Mon, 16 Dec 2013 17:30:03 +0000 Message-ID: <84929DB4-4034-4B45-8BAA-D262076E9986@cisco.com> References: <9660C545-473C-4039-AB42-A12B7C761FC8@cisco.com> <201312152257.rBFMveZO022075@bagheera.jungle.bt.co.uk> <80CEFF86-8687-4266-B87C-8FB5B894D4DF@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_5B40FC2B-5987-41B4-BDDF-D1B901097025"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: bloat , "aqm@ietf.org" , "" Subject: Re: [Bloat] [e2e] [aqm] What is a good burst? -- AQM evaluation guidelines X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:30:11 -0000 --Apple-Mail=_5B40FC2B-5987-41B4-BDDF-D1B901097025 Content-Type: multipart/alternative; boundary="Apple-Mail=_EB4E5CD8-3CF7-422F-85EA-5E7217571769" --Apple-Mail=_EB4E5CD8-3CF7-422F-85EA-5E7217571769 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 16, 2013, at 6:05 AM, Naeem Khademi 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 =20 >=20 >=20 > On Mon, Dec 16, 2013 at 2:47 PM, Naeem Khademi = wrote: > Bob, Fred and all=20 >=20 > 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?" >=20 > 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. =20 >=20 > 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? =20 >=20 > Regards, > Naeem >=20 > On Mon, Dec 16, 2013 at 8:34 AM, Fred Baker (fred) = wrote: >=20 > On Dec 15, 2013, at 2:57 PM, Bob Briscoe > wrote: >=20 > > 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?". >=20 > 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?" >=20 > 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. =46rom 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... >=20 >=20 Make things as simple as possible, but not simpler. Albert Einstein --Apple-Mail=_EB4E5CD8-3CF7-422F-85EA-5E7217571769 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 naeem.khademi@gmail.com>
 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 <naeem.khademi@gmail.com> 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) <fred@cisco.com> wrote:

On Dec 15, 2013, at 2:57 PM, Bob Briscoe <bob.briscoe@bt.com>
 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. =46rom 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

    = --Apple-Mail=_EB4E5CD8-3CF7-422F-85EA-5E7217571769-- --Apple-Mail=_5B40FC2B-5987-41B4-BDDF-D1B901097025 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSrziZbjEdbHIsm0MRAgd9AKDckCgnYG1DGKMkJ0emyiRQ3OzuDgCfWc7Y YncxnOjtRhXPHgi6A0oifIM= =Em55 -----END PGP SIGNATURE----- --Apple-Mail=_5B40FC2B-5987-41B4-BDDF-D1B901097025--