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 6B91521F1F5 for ; Sun, 15 Dec 2013 04:26:16 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id c11so440428lbj.1 for ; Sun, 15 Dec 2013 04:26:14 -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=uKHInBZEwQ7yJBcFGTB67m8yd1qLBz4/TeksaldYgf4=; b=pWTYJmQVBb0JRT/0XRTcMs2uuwLft6Al7IlXF5wI586MHb1TolTj69vFcbvOG2k5L/ sdLhL6akIOkubEa3h6soHSZ/KplJLkdtU9uYqT+9J54PnZDJB54DKrJXyiQqTspBV8V6 8KlbzSZ+R7N8l+JXGgBaI5iyrufFO5AdwN5tGqQLoARcZ2cjwo3BQidjZSbyBudL2DMW TkfANnU1yIHodmdrF6ggWZNToTxPIQmSEAv+kJo9SjQbfPLjDgERWbzG1PiohrAJKNbt 9SIQCEzeOESOAGWK4oWP9fEPQThFhruIDe7KW6OsebBOdIFYooRSrsKRaXleqJFB97Ub /acA== X-Received: by 10.112.181.3 with SMTP id ds3mr1038249lbc.54.1387110374038; Sun, 15 Dec 2013 04:26:14 -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 mq10sm5780464lbb.12.2013.12.15.04.26.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Dec 2013 04:26:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: Date: Sun, 15 Dec 2013 14:26:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33D65DCB-B4CC-4D2C-8ED9-E3685AF7D820@gmail.com> References: To: Naeem Khademi X-Mailer: Apple Mail (2.1085) Cc: bloat Mainlinglist Subject: Re: [Bloat] 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: Sun, 15 Dec 2013 12:26:16 -0000 On 15 Dec, 2013, at 7:35 am, Naeem Khademi wrote: > the question remains: "what is a good burst (size) that AQMs should = allow?" The ideal size of a TCP congestion window - which limits the size of a = burst on a TCP flow - is equal to the natural bandwidth-delay product = for the flow. That involves the available bandwidth and the natural RTT = delay - ie. without added queueing delay. Codel operates on this basis, making an assumption about typical RTT = delays, and permitting queue residency to temporarily rise to that value = without initiating marking operations. A larger burst would be evidence = of a congestion window that is too large, or an overall sending rate = that exceeds the bandwidth at the link the codel queue controls. A = persistent queue is always taken as evidence of the latter. In a datacentre or on a LAN, natural RTT delays are much shorter = (microseconds) than on the general Internet (milliseconds) - conversely, = available bandwidth is typically much higher (Gbps vs. Mbps). The two = factors approximately cancel out, so the bandwidth-delay product remains = roughly the same in typical cases - although, of course, atypical cases = such as satellite links (seconds of latency) and major backbones = (extreme aggregate bandwidth and Internet-scale delays) also exist. = However, RTT is more consistent between installations than bandwidth is = (factor of ten difference in typical range of ADSL link speeds, factor = of a hundred in WiFi), so Codel uses a time basis rather than a = byte-count basis for regulation, and is by default tuned for typical = overland Internet latencies. Fq_codel, as with other FQ-type qdiscs, tends to improve pacing when = multiple flows are present, by interleaving packets from different = queued bursts. Pacing is the general absence of bursts, and can be = implemented at source by a TCP sender that spreads packets within a = congestion window through an interval of time corresponding to the = measured RTT. AFAIK, very few TCP implementations actually do this, = probably due to a desire to avoid interrupt overheads (the CPU would = have to be woken up by a timer for each packet). It strikes me as = feasible for NIC hardware to take on some of this burden. - Jonathan Morton