From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (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 1170921F1C9 for ; Mon, 16 Dec 2013 06:05:56 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so3207784vcb.33 for ; Mon, 16 Dec 2013 06:05:56 -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=t0pIS0RizA+FRVrt9IV/QJJUI+3IIP5sYTL9axApK0Q=; b=hzmsfZnsSTJpfL72SfDx6osuWbfDLeE5zY80/hkzInqDjYq34ohsgmE+TQr6mj6x6Y X2WBYWmjku9hvrr3f+N3hpxfW+AUhngOkDa9DD66bKZnKTLR6bwrjMN0BLH9qoyF4PL9 mQM2/O1uugHNLDNF4kMVXPFONBtgwW5DAw6/mZVdYKEaqxsS4uNDKPhSAS+G089gmP6q 7OdhUwTOAMS9f+zj2axZToy5ZDKVhGv9LFN6ljHfYrQOzc9zlpLMhVtq5idj8Q0SoPnO i9S/0DazBh4hTYV0Omn5RM6HVEfI8fYxfNy01ISy4ACi7FDItJQg4VVYwYrEdZpENxbZ TnyQ== MIME-Version: 1.0 X-Received: by 10.58.186.198 with SMTP id fm6mr8472331vec.16.1387202756084; Mon, 16 Dec 2013 06:05:56 -0800 (PST) Received: by 10.221.5.196 with HTTP; Mon, 16 Dec 2013 06:05:56 -0800 (PST) In-Reply-To: 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 15:05:56 +0100 Message-ID: From: Naeem Khademi To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=047d7b677208820c6e04eda74f9e 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 14:05:57 -0000 --047d7b677208820c6e04eda74f9e Content-Type: text/plain; charset=ISO-8859-1 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 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) 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... >> > > --047d7b677208820c6e04eda74f9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
and to clarify more about what else was discussed, it seem= s to me some of us tend to correspond and relate the notion of "good q= ueue" vs. "bad queue" used by KN+VJ ACM queue paper to my qu= estion on "good bursts". While they likely to be correlated (I ha= ve no=A0argument=A0on this now), the notion of "good burst" goes = beyond the "good queue" defined in that paper. Based on their def= inition 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 10= 0 ms) bursts while avoiding the link to get under-utilized. That notion (ag= ain, I have no argument on its correctness for now) is different from my qu= estion on "good bursts" which means that: once we manage to get r= id of the standing queue, what types/sizes of bursts I should let the AQM X= to protect/handle?

Naeem =A0

On Mon, Dec 16, 2013 at 2:47 PM, Naeem Kha= demi <naeem.khademi@gmail.com> wrote:
Bob, Fred and all=A0
I'll copy/paste the question here again:=A0"what is a good burst (si= ze) 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 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...


--047d7b677208820c6e04eda74f9e--