From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 831A321F0BD for ; Mon, 31 Dec 2012 14:49:12 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id d41so6524722eek.0 for ; Mon, 31 Dec 2012 14:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=NuTOsi1+sibEjBSFrvZotK6s2T8L0qKEMW9Oka0NYd0=; b=feMxdlldrE8sGGvOm1K1Yeq8Ul+ssaMYsjr+BWfeVITndMy4ikaLlJJ0vfDt23ZYrr I1JD5J2luuPTj4lXiY18QcqHpy0yqHearLItDJVYSHY6sm9l7ph1WKsM7jQT2I7KhCEH Mmcttn8jCMfkLtYzBlrz94+9EmXa/EZSe6m8t/C7CKcdFAdIdGNT1EYapCWnUSdjKeYg 0o7OIIbZ2Fwvql5PE4LvZtuUnVPcdkXnMV7OjmKByqOnMlliQ33gA2Wx4s9f+wpIl1ki j0p319Uh3F+BHPi42m07y9kcrcBPLBxNk4NGoVO/qOcxDmcBYytzut4Y0zhqitU8Frwa snOg== X-Received: by 10.14.204.70 with SMTP id g46mr87770985eeo.15.1356994150216; Mon, 31 Dec 2012 14:49:10 -0800 (PST) Received: from bass.home.chromatix.fi (xdsl-83-150-84-172.nebulazone.fi. [83.150.84.172]) by mx.google.com with ESMTPS id 43sm87723080eed.10.2012.12.31.14.49.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Dec 2012 14:49:09 -0800 (PST) Subject: Re: FYI - tests on Verizon LTE show significant bufferbloat Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton X-Priority: 3 (Normal) In-Reply-To: <1356979451.184121766@apps.rackspace.com> Date: Tue, 1 Jan 2013 00:49:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D66BAD1-B12A-4D68-89D6-C0D7C781BC52@gmail.com> References: <1356979451.184121766@apps.rackspace.com> To: dpreed@reed.com X-Mailer: Apple Mail (2.1085) Cc: bloat-devel@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 22:49:12 -0000 On 31 Dec, 2012, at 8:44 pm, dpreed@reed.com wrote: > Here are the "network access link properties" I observed from the = client laptop: > =20 > current latency: 63 msec, 0% loss. > TCP setup latency: 94 msec. > Network bandwidth: uplink 2.3 Mb/sec, downlink 5.2 Mb/sec > Network buffer measurements: uplink 3000 msec, downlink 2400 msec. > =20 > Netalyzr doesn't tell me where the buffers are - they might be in the = phone itself (Android is based on Linux, but unfortunately it's quite = awkward to probe its internal network parameters/stats) or they might be = in the path to/from the phone to the public Internet. I would guess both, since it appears in both directions. You're not = hitting USB bandwidth limits there (USB 1.1 is 12Mbps less some = overhead, USB 2.0 is more like 480Mbps), so at least the downlink must = be bloated to the tune of a megabyte or so to make those numbers. The = upiink is probably due to Linux network stack defaults in Android. > This looks depressingly like the old ATT HSPA stats I measured with a = USB cable device. I can reliably reproduce downlink bloat using a tethered iPhone 3G in = Finland, producing tens of seconds of latency. In that case it's a = shaped connection, and the shaper evidently has a big dumb tail-drop = queue. > I realize that lots of people at IETF seem to still believe that = bufferbloat is totally unimportant, and unnecessary to fix. However, = the wireless companies are, unlike cable companies, not local = monopolies. So they might decide that competition forces them to = actually fix the problem, lest their competitors do so first. Here's hoping... - Jonathan Morton