From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 D751D21F311 for ; Mon, 30 Mar 2015 21:14:37 -0700 (PDT) Received: by lajy8 with SMTP id y8so3647131laj.0 for ; Mon, 30 Mar 2015 21:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rF3r/D7tTrQUhQElrbeFNrQkWAlnxjtfZjt7UJtRr3g=; b=CPxF6A/XroVJy2rzvC5nEjjojleN7PAwTWHsMFsx3N59/op0JR2Sw0uQJKFzbibAff YKUpQIBuSpAELHDVUlqHrexUCibncPpwCSY2T92/J06WpMdMQfoSkYd5o6W2OnMhyreg 9Wx05AKgNr/B9qBwwWIoM8PqrsoVph6JoTDvtKxVKs9o0R/E+3LJdfTYqn/ohooysHAH UctDxLkeTk6NMSz+w957AKjTCDFJu9Y/aVVgcIHla/ecKd9U8unAU2iKMsUS/dwSEDuR z2510STLaF2D0yOBf6rijRxvpDZ06qvP+SHwOCwJlKeVXBd3Ni5jvZ8atP6iGZLMIYA+ hqVw== X-Received: by 10.112.173.133 with SMTP id bk5mr29085374lbc.94.1427775275169; Mon, 30 Mar 2015 21:14:35 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-15-150.bb.dnainternet.fi. [188.67.15.150]) by mx.google.com with ESMTPSA id ju14sm2382019lab.8.2015.03.30.21.14.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Mar 2015 21:14:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jonathan Morton In-Reply-To: Date: Tue, 31 Mar 2015 07:14:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <34E8AB1B-D179-402B-94A9-AD8CF18B08F7@gmail.com> References: <20150316203532.05BD21E2@taggart.lackof.org> <123130.1426635142@turing-police.cc.vt.edu> <15A0911A-E3B7-440A-A26B-C5E1489EA98B@viagenie.ca> <1426773234.362612992@apps.rackspace.com> <1426796961.194223197@apps.rackspace.com> <5FD20B4A-A7E8-48C0-89F9-E2EB86DED8A6@gmail.com> <755FC1BE-141C-42FD-B3E3-564488982665@gmail.com> <95B0F8DA-7650-4064-BEE6-F0CDF936D33A@gmail.com> To: Pedro Tumusok X-Mailer: Apple Mail (2.2070.6) Cc: "dpreed@reed.com" , bloat Subject: Re: [Bloat] Latency Measurements in Speed Test suites (was: DOCSIS 3+ recommendation?) 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: Tue, 31 Mar 2015 04:15:06 -0000 > Currently the 'saturation' meter is pinging away at an unrelated = server (dslreports.com) > probably it should ping away, and with higher frequency, at one of the = servers streaming data in? because then there are more likely to be = filled buffers en-route? > or are the bloated buffers mainly at the customer end of the = experience. Mostly at the customer end (see below). The core is generally built = with sufficient capacity and small buffers (compared to the link = capacity). I recommend pinging a topologically-nearby server rather than = a central one. > I can make the saturation meter display RTT directly, and continue = during the test as an preference. I don't really want to have it pinging = away during the test because it probably slows the result down. Actually = I'll have to check that. Definitely on slow lines it would (like GPRS = and 3G). A simple ping, without artificially added payload, is about 64 bytes. A = small UDP packet (whose payload is just a unique cookie) can be used for = the same purpose, and is less likely to experience artificial = prioritisation. Four of those a second makes a quarter of a kilobyte = per second each way. That=E2=80=99ll be noticeable on GPRS and analogue = modems, but not to anyone else. I say that as someone who regularly = uses 3G. A concept I=E2=80=99d like to introduce you to is =E2=80=9Cnetwork = responsiveness=E2=80=9D, which is measured in Hz rather than ms, and = thus goes down when latency goes up. A responsiveness of 10.0Hz = corresponds to a 100ms latency, and that=E2=80=99s a useful, = rule-of-thumb baseline for acceptable VoIP and gaming performance. It = can be compared fairly directly to the framerate of a video or a = graphics card. > tcptrace on the server side of one stream would immediately reveal = average and peak RTT and more. I wonder if that is the goal to be = shooting for rather than these more indirect measurements. >=20 > What is the buffer bloat opinion on the ESNet page? >=20 > =C2=BBfasterdata.es.net/network-tuning =C2=B7=C2=B7=C2=B7 r-bloat/ >=20 > they say more not less buffers are needed for 10gig, and its only a = problem with residential.=20 Datacentres and the public Internet are very different places. You = can=E2=80=99t generalise from one to the other. The RTTs are very = different, for a start - LAN vs WAN scales. At 10Gbps, a megabyte of buffer will drain in about a millisecond. = What=E2=80=99s more, a megabyte might be enough, because chances are = such a fat link is being used by lots of TCP sessions in parallel, so = you only need to worry about one or two of those bursting at a given = instant. Since buffers (after the first couple of packets) are used to = absorb bursts, that=E2=80=99s all you might need. Frankly, one of our present problems is getting consumer-grade router = hardware to work reliably at 100Mbps or so, which is just starting to = become widely available. There=E2=80=99s only so much you can do with a = wimpy, single-core, cost-optimised MIPS, even if it=E2=80=99s attached = to lots of GigE and 802.11ac hardware; I=E2=80=99m using an ancient = Pentium-MMX as a surprisingly accurate model for these things. = Sufficient buffering isn=E2=80=99t the problem here - it just can=E2=80=99= t turn packets around fast enough. On a more typical rural consumer connection, at 1Mbps, a megabyte of = buffer will take about 10 seconds to drain, and is therefore obviously = oversized. Even at 10Mbps, it=E2=80=99ll take a whole second to drain, = which is painful. The AQM systems we=E2=80=99re working on are an = answer to that problem - they will automatically act to keep the buffers = at a more sensible fill level. They also isolate flows from each other, = so that one bursting or otherwise misbehaving flow won=E2=80=99t = interfere (adding that draining latency) with a sparse, = latency-sensitive one like VoIP or gaming. It is that last scenario, which the great majority of consumers = experience in practice, which we=E2=80=99d like you to address by = measuring latency under load. - Jonathan Morton