From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-21-ewr.dyndns.com (mxout-117-ewr.mailhop.org [216.146.33.117]) by lists.bufferbloat.net (Postfix) with ESMTP id E01612E06D0 for ; Sun, 20 Mar 2011 04:41:02 -0700 (PDT) Received: from scan-21-ewr.mailhop.org (scan-21-ewr.local [10.0.141.243]) by mail-21-ewr.dyndns.com (Postfix) with ESMTP id 4258A40D8 for ; Sun, 20 Mar 2011 11:41:01 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.215.43 Received: from mail-ew0-f43.google.com (mail-ew0-f43.google.com [209.85.215.43]) by mail-21-ewr.dyndns.com (Postfix) with ESMTP id 55E7D40A5 for ; Sun, 20 Mar 2011 11:40:56 +0000 (UTC) Received: by ewy20 with SMTP id 20so1543883ewy.16 for ; Sun, 20 Mar 2011 04:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :x-priority:in-reply-to:date:cc:content-transfer-encoding:message-id :references:to:x-mailer; bh=tk2WYYuj7889WgtQph69vmk3P6uD2S2qdSWR20c56jI=; b=FiT/xRQwDwt6VOHUj+A9sh4WH1l2lm8xnJtXKw2eaENFiW38h2iL3826/uzh+h1b1e OYhgcY2wY2j7gWFvI6UOZOgn5Io03sN32AvXwud2/LqnhGirclkhrGrjSqjBJnsF2fwv u/AIj+JpnhdPZrm/nMj0jI5lB80jgVNq38zsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; b=k2ETPvk1vobKZuO/dXJZ8Q6bs2zsXQ7wiwTsuVQGgP30Q6wM/BBdnE5kSu1uRQcmc5 eLvW+5PmhhGruLWWKGou+YwcKHSBMbHw7bzUa1SXDUWvmCRaC6/nsycRAyiGiZs/p4kr Y0xR3DEQdJFN6fFaVMbZV4s0t0QllUGGfRZC8= Received: by 10.213.25.72 with SMTP id y8mr1463668ebb.111.1300621254637; Sun, 20 Mar 2011 04:40:54 -0700 (PDT) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id w59sm1168077eeh.3.2011.03.20.04.40.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Mar 2011 04:40:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton X-Priority: 3 In-Reply-To: <7480559F-1F3B-4CE5-939F-FD9FD3E68E52@cisco.com> Date: Sun, 20 Mar 2011 13:40:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D7F4121.40307@freedesktop.org><20110315175942.GA10064@goldfish><1300212877.2087.2155.camel@tardy><20110315183111.GB2542@tuxdriver.com><29B06777-CC5F-4802-8727-B04F58CDA9E3@gmail.com><20110315205146.GF2542@tuxdriver.com><219C7840-ED79-49EA-929D-96C5A6200401@gmail.com><20110315151946.31e86b46@nehalam><1300228592.2087.2191.camel@tardy><1300229578.2565.29.camel@edumazet-laptop><87fwqo54n7.fsf@cruithne.co.teklibre.org><823E2A7B-4F46-4159-8029-BD3B075CC4CE@gmail.com><87bp1b6fo0.fsf@cruithne.co.teklibre.org><87bp1b4yh4.fsf@cruithne.co.teklibre.org> <35010A85-C5A4-4133-8707-4E114C65A8C6@gmail.com> <3F2F5E9B-C710-4C2F-AF99-CDF7C314A50A@cisco.com> <7480559F-1F3B-4CE5-939F-FD9FD3E68E52@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1082) Cc: Stephen Hemminger , bloat Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCPflavours - timestamps? 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, 20 Mar 2011 11:41:03 -0000 On 18 Mar, 2011, at 8:49 pm, Fred Baker wrote: >> How about trying to push for a default, that the logical egress = buffers are limited to say 90% of the physical capacity, and only = ECN-enabled flows may use the remaining 10% when they get marked... >=20 > Lots of questions in that; 90% of the buffers in what? In a host, in a = router, on a card in a router, in a queue's configured maximum depth, = what? One would need some pedagogic support in the form of simulations - = why 90% vs 91% vs 10% vs whatever? >=20 >> Someone has to set an incentive for using ECN, unfortunately... >=20 > Yes. =46rom my perspective, the right approach is probably more like = introducing a mark/drop threshold and a drop threshold. Taking the model = that every M time units we "do something" like >=20 > if queue depth exceeds > reduce M > drop something > else if queue depth exceeds > reduce M > select something > if it is ECN-capable,=20 > mark it congestion-experienced > else > drop it > else is below > increase M >=20 > the advantage of ECN traffic is that it is less likely to be dropped. = That might be a reasonable approach. That does actually seem reasonable. What's the betting that HW vendors = still say it's too complicated? :-D I think we can come up with some simple empirical rules for choosing = queue sizes. I may be half-remembering something VJ wrote, but here's a = starting point: 0) Buffering more than 1 second of data is always unacceptable. 1) Measure (or estimate) the RTT of a full-sized packet over the exit = link and back, then add 100ms for typical Internet latency, calling this = total T1. If T1 is more than 500ms, clamp it to 500ms. Calculate T2 to = be twice T1; this will be at most 1000ms. 2) Measure (or estimate) the throughput BW of the exit link, in bytes = per second. 3) Calculate ideal queue length (in bytes) Q1 as T1 * BW, and the = maximal queue length Q2 as T2 * BW. These may optionally be rounded to = the nearest multiple of a whole packet size, if that is convenient for = the hardware. 4) If the link quality is strongly time-varying, eg. mobile wireless, = recalculate Q1 and Q2 as above regularly. 5) If the link speed depends on the type of equipment at the other end, = the quality of cabling, or other similar factors, use the actual = negotiated link speed when calculating BW. When these factors change, = recalculate as above. I would take the "hysteresis limit" to be an empty queue for the above = algorithm. - Jonathan