From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gateway0.ipv6.occnc.com (unknown [IPv6:2001:470:88e6:1::135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id A492D21F1C8 for ; Sun, 15 Dec 2013 10:57:12 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.orleans.occnc.com [IPv6:2001:470:88e6:1::137]) (authenticated bits=128) by gateway0.ipv6.occnc.com (8.14.7/8.14.7) with ESMTP id rBFIuuea043478; Sun, 15 Dec 2013 13:57:02 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201312151857.rBFIuuea043478@gateway0.ipv6.occnc.com> To: Naeem Khademi From: Curtis Villamizar In-reply-to: Your message of "Sun, 15 Dec 2013 06:35:04 +0100." Date: Sun, 15 Dec 2013 13:56:56 -0500 X-Mailman-Approved-At: Wed, 18 Dec 2013 13:42:43 -0800 Cc: end2end-interest@postel.org, "aqm@ietf.org" , bloat Subject: Re: [Bloat] [aqm] What is a good burst? -- AQM evaluation guidelines X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 18:57:14 -0000 In message Naeem Khademi writes: > 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 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. 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. 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