From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 027D621F1A3 for ; Mon, 16 Dec 2013 05:47:35 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id jw12so3339879veb.10 for ; Mon, 16 Dec 2013 05:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A5LQ/cR04oXmE56hrZ9EA/3JIm8ynYOJiTWwih9WTQo=; b=p5bWnLFslFqZ5UPj7hK9/Ps9zvc8gAOhFSK1ljuKQeFVHB05RgymtLwjfX9mOkv7FY 52xTsb1UauE6DJ70/EoTSlB89SfDM7sQ+E54NU2D5SFCxqX1yhdGyC71wp+t163ebq3L ikgLkdg18fyL+jDQS6ndaHx6sWFyqkIkUz7IaICInRReozo/A7vy05Guqhl3czV9GPO3 PPplZX6653tGmWMgteAG/Jx6TAmrA72AtcD+x+x/qq9cloPNne+lVXByHV6thAo4Ww7V /mPqZMVylhDfXjKhNkm55AkaRPwQwwE3TfmUaZmtkgxkmZLhWOlS8hLu2HgmcIaFse1j tjJQ== MIME-Version: 1.0 X-Received: by 10.52.249.105 with SMTP id yt9mr336365vdc.67.1387201654884; Mon, 16 Dec 2013 05:47:34 -0800 (PST) Received: by 10.221.5.196 with HTTP; Mon, 16 Dec 2013 05:47:34 -0800 (PST) In-Reply-To: <80CEFF86-8687-4266-B87C-8FB5B894D4DF@cisco.com> References: <9660C545-473C-4039-AB42-A12B7C761FC8@cisco.com> <201312152257.rBFMveZO022075@bagheera.jungle.bt.co.uk> <80CEFF86-8687-4266-B87C-8FB5B894D4DF@cisco.com> Date: Mon, 16 Dec 2013 14:47:34 +0100 Message-ID: From: Naeem Khademi To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e01536864df127f04eda70d14 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 13:47:36 -0000 --089e01536864df127f04eda70d14 Content-Type: text/plain; charset=ISO-8859-1 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) wrote: > > On Dec 15, 2013, at 2:57 PM, Bob Briscoe > 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... > --089e01536864df127f04eda70d14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bob, Fred and all=A0

I'll copy/past= e the question here again:=A0"what is a good burst (size) that AQMs should allow?&quo= t; 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 bu= rsts in addition to the task of keeping the standing queue very low or mini= mal is part of an "AQM evaluation criteria" I envision. While I d= o agree with all Fred's remarks, I'm more concerned to have an answ= er for this, for where AQMs might get deployed. =A0=A0

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

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>
=A0wrote:

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

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

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

--089e01536864df127f04eda70d14--