From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-13-ewr.dyndns.com (mxout-128-ewr.mailhop.org [216.146.33.128]) by lists.bufferbloat.net (Postfix) with ESMTP id 384ED2E03C0 for ; Wed, 16 Mar 2011 19:27:02 -0700 (PDT) Received: from scan-11-ewr.mailhop.org (scan-11-ewr.local [10.0.141.229]) by mail-13-ewr.dyndns.com (Postfix) with ESMTP id 65840A49A97 for ; Thu, 17 Mar 2011 02:27:01 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 74.125.82.41 Received: from mail-ww0-f41.google.com (mail-ww0-f41.google.com [74.125.82.41]) by mail-13-ewr.dyndns.com (Postfix) with ESMTP id E326AA498D5 for ; Thu, 17 Mar 2011 02:27:00 +0000 (UTC) Received: by wwi18 with SMTP id 18so4839889wwi.4 for ; Wed, 16 Mar 2011 19:27:00 -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 :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=nZUjk3HHvJZATysSm2/eFRIT1hmdiWk9V2k6IsPwCnA=; b=ZteB/TEZw1IAY5N9Zd2oFeEH7Bn6u5lF8x//+Pfq6lAOLcMeeZC3AtakSAspon/95N mOcB0hELKSGAgSB67ljNlVsgCaUUaMQ2dkpEk3c9YykVar9HaCqg8I22ztuOBDRxwGU8 D41fcp9l0hhSHwP5qjoBdaYKOPoFiK5JReAVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=vsrYuZprVVIrVLfOov7P3xfDSN2wf70SAqEq/9CDONmMDWSv/PkB/7rkl9HSd1+wl2 CAencqzmFf7oWPxv8WPpCnPX73RC7xdhc/5eWz6WHOyLAwOrGSE4edDWgayxy0u4gHQ8 yCd5+gsdShNHSEXthOxENPcjn8OSbv5FUGAks= Received: by 10.216.171.133 with SMTP id r5mr201208wel.91.1300328820036; Wed, 16 Mar 2011 19:27:00 -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 p5sm339679wbg.62.2011.03.16.19.26.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2011 19:26:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: Date: Thu, 17 Mar 2011 04:26:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66469263-763A-4D5A-B689-026D0603C170@gmail.com> 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> <20110316004722.GD28663@tuxdriver.com> To: Jim Gettys X-Mailer: Apple Mail (2.1082) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - 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: Thu, 17 Mar 2011 02:27:02 -0000 On 16 Mar, 2011, at 10:07 pm, Jim Gettys wrote: > each cellular link is made more efficient through multi-user = diversity gain that exploits fading channel peaks of independent users = while still utilizing the link fully provided there are enough users - = my point is, such gains dilute when a user enjoying a channel peak = doesn't have data waiting in his buffer at that time... It helps to keep = users' buffers non-empty from this perspective..." >=20 > As I pointed out to them, it may (or may not) be that things just work > out well; if the channel is busy, you'll have more time for > aggregation of packets to naturally occur. We don't need to run the > channel efficiently when the channel isn't saturated. Whenever the > air isn't busy, it doesn't matter if we don't bother to aggregate. So, what they're saying is that if I'm on a moving train (with varying = relationships between steel cages, 25kV pylons and granite rockfaces - = no exaggeration in Helsinki), there are times when my reception drops = out, and the tower will use those times to preferentially serve everyone = else, returning to serve me when my personal reception conditions = improve. I can grok that. What's not entirely clear is the timescale for this. It's most likely = to be seconds or milliseconds, though I'm not sure which. But it could = conceivably be sub-millisecond (which would look like random packet = loss), and the amount of buffering I've observed for 3G suggests that = provision for minutes of reduced connectivity is present - which is far = too much. It is of course worth remembering that a few seconds' worth of buffering = at the network's highest theoretical speed rating is most likely several = minutes' worth of solid GPRS traffic. If my train goes behind a rock = and there's only a 2G signal on the other side of it, that's a serious = problem. There is of course another use-case: people who use "wireless broadband" = while sitting still, whether that's in a cafe, a hotel room, or at home. = I have been known to use my tethered 3G phone as a primary Internet = connection, when for whatever reason a wired link was not available. In = that case I could put the phone up on the windowsill, well above street = level, and for the most part would expect a clean connection to the = tower. Under those circumstances I saw practically no random packet = loss, but until I tweaked my setup in some non-standard ways the = connection was often very difficult to use because the latency would = grow out of control. It is thus quite understandable why Apple disables updating or = downloading particularly large 'apps' over the air. For the benefit of the 3G folks, here are some helpful axioms to = discuss: 1) Buffering more than a couple of seconds of data (without employing = AQM) is unhelpful, and will actually increase network load without = increasing goodput. Unless there is a compelling reason, you should try = to buffer less than a second. This is because congestion and packet-loss information takes longer to = influence existing flows, and new flows are more difficult to start. = After about 3 seconds of no information, most TCPs will start = retransmission - regardless of whether the packets were physically lost, = or are simply languishing in a multi-megabyte buffer somewhere. 2) Buffering less than some threshold of data causes link = under-utilisation. The threshold depends on link data rate, the length = of pauses due to propagation conditions, and the round-trip delay, and = to a lesser extent on the congestion control algorithm employed by the = sending host. 2a) On a lightly loaded network link under-utilisation does not matter, = as the buffer will often become empty anyway, so you should aim to = minimise latency. On a heavily loaded one link utilisation does matter. 3) The number of packets that "a couple of seconds" represents will vary = according to the link speed - which in a wireless network is strongly = time-varying. So even if you know the network, you cannot set the buffer length to a = fixed value. This is what eBDP is designed to cope with. Because the = link bandwidth is also different on a per-user basis, you'll need to = vary the buffer size for each user. But see below... 4) AQM can let you use oversized buffers without destroying the user = experience. The specific features required are a) communication of congestion state = to the client and server, eg. via packet drop or (preferably) ECN; and = b) re-ordering of packets so that one flow does not starve another, eg. = DNS packets can overtake HTTP packets, and packets belonging to a light = user can bypass those belonging to a heavy user. RED is the traditional solution to requirement a), but SFB may be a = better solution. SFQ is a good way to implement b), and should dovetail = nicely with SFB. Axiom 4 is also particularly helpful to wired broadband providers, who = have been known to complain about a relatively small number of heavy = users who (allegedly) manage to starve lighter users of bandwidth. = Their existing solution seems to be to "charge and discourage" the heavy = users. The more intelligent solution is to make the network pay = attention to the lighter users, while allowing the heavy users to occupy = a fair share of the spare capacity. The intelligent solution makes for = better PR. - Jonathan