From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 0A95021F1C8 for ; Mon, 16 Dec 2013 06:28:51 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id c11so891033lbj.15 for ; Mon, 16 Dec 2013 06:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gEV8MpU5060JQ4WYifZXmgMLW4JxA9kqWrPjKKN6qLk=; b=Z4xW5b+VImP5fuQt6F46OU79gkwYDCrEQKgtaUV4TslEDdWxrcrMvCqby0VPbY96tT lRqj91cb3qQZVqT2kV8nLDtkSgKnTTWuEWlq/qa1/dqvkCA0mhzjRUG6gKZudHbdBboo SONEok81IT0HNILS+Tjou9P89ZkKgKgr9GPdvcohK6gvlLK4a9lXQANeTGnfWq8G4yfG 3jt80t5tdfRcd4XsIqk20n1N/iU3OyyvKYOnGoWhOtU0fZq0PbOswZQqYFpSbE3KznE3 36uQDsd7tbkq/gWNB7dJ6pCdOrKlUTPLh94uYL9Ooiy2UN5dgOHvs1sUeL3PSbrKYgor b2Pg== X-Received: by 10.152.23.39 with SMTP id j7mr6905815laf.28.1387204129597; Mon, 16 Dec 2013 06:28:49 -0800 (PST) Received: from bass.home.chromatix.fi (37-136-95-34.nat.bb.dnainternet.fi. [37.136.95.34]) by mx.google.com with ESMTPSA id a8sm21211703lae.5.2013.12.16.06.28.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 06:28:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: Date: Mon, 16 Dec 2013 16:28:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9660C545-473C-4039-AB42-A12B7C761FC8@cisco.com> <201312152257.rBFMveZO022075@bagheera.jungle.bt.co.uk> <80CEFF86-8687-4266-B87C-8FB5B894D4DF@cisco.com> To: Naeem Khademi X-Mailer: Apple Mail (2.1085) Cc: bloat Mainlinglist 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:28:52 -0000 On 16 Dec, 2013, at 3:47 pm, Naeem Khademi wrote: > An example: when designing my AQM X should I care about 64K = TSO-generated bursts to safely pass without dropping or not? If there is at least 6Mbps bandwidth downstream of your queue, then = codel at least will pass such a burst in isolation. If you have ECN, then you should mark instead of dropping as long as you = have queue space, and use FQ semantics to minimise latency impact on = other flows. > 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 That's a more interesting question. IMHO the extremely bursty behaviour = of certain popular video streaming systems is broken, and should not be = worked around by the multitude of receivers - it should be corrected = sender-side. Relatively simple pacing algorithms which do this = effectively are not difficult to design and, like much in the networking = world, I am constantly surprised to find that they have not yet been = deployed in earnest. I am also reminded of the livestreamed demoscene event from a couple of = years ago, which was producing enormous aggregate bursts every time a = frame group completed encoding (multiple times a second). This wasn't = enough on a single flow to impact individual end-users much, but it = overwhelmed the local and gateway buffers chronically, thereby crippling = the entire livestreaming exercise until a workaround could be = implemented. So in short... no. Bursts of that magnitude need to be clipped, to = signal to senders that they are problematic. As an aside, networking infrastructure is unusual in that hardware = innovation (bandwidth, buffer sizes) proceeds at a much faster pace than = the associated software elements (which would normally develop in = response to increased CPU power). To some extent conservatism is = explainable by a desire not to break things, but when things are already = broken and need to be fixed... - Jonathan Morton