From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4FFE13B29E for ; Wed, 29 Aug 2018 11:38:06 -0400 (EDT) Received: by mail-qk0-x22e.google.com with SMTP id b19-v6so3633018qkc.6 for ; Wed, 29 Aug 2018 08:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=q1sMRY/qaXYDww/JCHbSBeSc72ai/HtZYqHNq+qyRx0=; b=miioavBTAr8yXkjES9b+uU+VlqvmMkNPckZEtUd4aYffKZnQJQHFD/gCG3y3QbXAMg YAZVHQOaPqtDPqHAiX3po9QnG10Hnhsjac63EQwxfg+eODiVuuNpJLjcI7qNd+M+EOl7 EV8k2ppmy9pdbxY3iR0ltQH80MwyoVGYjv/4S81IQKx+eP5F1MZfqbK4+XRnTr1T3H1h hbhkrShJC9uui0GEz/JXM3vEObzxTD6xLltZQH4IqIISgBq0cUaZRW2kwRGwuJIej7s8 7qPiI7YdX2S6S3PwsTLubZAl7iQmn+fPE4xUX6RvTTVJ2mHqvHDeX4a4jlCvWe9Vdeh8 s87Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=q1sMRY/qaXYDww/JCHbSBeSc72ai/HtZYqHNq+qyRx0=; b=CM45VeqiCppMd2zzH4tOIuMNWwIEMMvTZdbTgdT7u9gwSCAgmVStFRLDHRjmO3+C8+ J8XKU9CCL7La1D7FKYmVlDpU9oV7O9L/GA6HOrTb0jRgVRtrUfCpEFDGhTkBTQX4QUZW kGYdCl8tb5d+em3tyzjnY7LN4ciSbDidkgCS6/KoCIHzBN9jpg/yCwI4PRmGAngWaURq DrOOIlWdhUk4Xa52Gk3r/ipaAKZkrKkKQ/KVSPRoEsFK8d+s4OeKCqB977AHlOQ+n+fA Al8TrfF+Ot2jzIBKu69M7aTuSG9T0ZJfFE+a1UzzkRCdghEzTnCRNrZc5tecHllNzM+P 08nw== X-Gm-Message-State: APzg51Dg6WNbRdQP0l9ufnxRwHl0KTQXVgXh/M+5qYH1bz2c34/yXtRR tZFiUBlS84ZSBQffJe/SoT8uflr2WtHBzSPSUGo= X-Google-Smtp-Source: ANB0VdYaPh/UA8i3bfoziQSGMw6fRCvEAW78mS+kfxMz4nagwJ52I9KCpwXQYDt8sGVke7apVpaU21NUJz1B3UUK90w= X-Received: by 2002:a37:6e82:: with SMTP id j124-v6mr6735844qkc.179.1535557085765; Wed, 29 Aug 2018 08:38:05 -0700 (PDT) MIME-Version: 1.0 References: <2385fcbb-d460-ce57-e4e3-e3cbb94ebc3d@rogers.com> In-Reply-To: From: Dave Taht Date: Wed, 29 Aug 2018 08:37:50 -0700 Message-ID: To: =?UTF-8?Q?Jonas_M=C3=A5rtensson?= Cc: Jonathan Morton , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] an observation from the field X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 15:38:06 -0000 On Wed, Aug 29, 2018 at 1:20 AM Jonas M=C3=A5rtensson wrote: > > Hi Jonathan, > > On Wed, Aug 29, 2018 at 2:16 AM Jonathan Morton w= rote: >> >> > On 29 Aug, 2018, at 2:53 am, David Collier-Brown = wrote: >> > >> > Humans experience delays directly, and so perceive systems with high l= atency as "slow". The proverbial "man on the Clapham omnibus" therefor resp= onds to high-latency systems with disgust. >> > >> > A trained scientist, however, runs the risk of choosing something that= requires complicated measurement schemes, and might well choose to optimiz= e for throughput, as that sounds like a desirable measure, one matching the= ir intuitions of what "fast" means. >> >> The correct approach, for scientists, is to observe that for many applic= ations, response time (a form of latency) is the *only* relevant metric. I= n some cases, higher bandwidth correlates with reduced response time, such = as for software updates. In other cases, bandwidth is essentially irreleva= nt, except as it pertains to serialisation delay of single packets. > > > Yes, exactly, thank you for bringing some actual scientific reasoning int= o the discussion. It would actually be nice to have a tool for measuring "r= esponse time" for different applications We used to use the chrome web page benchmarker a lot, but it broke. In flent, we use VOIP MOS scores. We use the rrul test as a quick diagnostic of a dozen things that can be wrong on a link. There's a PLT test as well but it takes work to setup. We're discussing over here: https://github.com/tohojo/flent/issues/148 ways to improve and revise our existing tests, if you have any suggestions? Scientist: This new compression algorithm can fit 10% more angels on the head of a pin! Engineer: Great! Let's go get some angels and a couple pins and try it out. Does it work on devils, too? Jim's also always pointed to a lot of human factors research. I'm always saying that the 20ms interval for voip is massively inferior to old switched networks and we should at the very least be aiming for 2ms now. 20ms was an engineering compromise based on how much stress users could handle... We learned RTT is what dominates page load time above 40mbit several years = back. I'm an itinerant engineer that is really bugged by the lack of rigorous experimentation and repeatable results that plague "science" today. I read paper after paper and want some sort of web based red rubber stamp to mark up all the dubious things I've had to read so that perhaps others would poke holes in them, that there'd be some forward and backward trail in time that could sort out the good ideas from the bad. I gave a talk once on this: https://conferences.sigcomm.org/sigcomm/2014/doc/slides/137.pdf Sigcomm's not invited me back. Instead of the vigor of public debate, we get researchgate, a "safe space", for science as usual. I want my little red rubber stamps. A scientist worries about what can go wrong every 2^32 times in an algorithm, and uses saturating math. The engineer looks at the lost 6 ns * 2^32-1 and says "f**k, I can't live with that", and goes to ask the scientist if the universe will explode if he makes that optimization. In starting this thread, I should have perhaps said: Of the .00001% of humanity aware of bufferbloat, perhaps .000002% are completely willing to sacrifice bandwidth for latency because they are unwilling or unable to spend 300 bucks on a router. A follow up experiment is: does this hold for the rest of humanity? At what price point or level of inconvenience or other variable tips the scales for 25% of humanity? I'd love a psychology experiment: What happens to people when locked up in a room with a deadline with lousy internet? Measure stress hormone levels afterwards. There's lots of anecdotal evidence about good and bad wifi out there... The other day i sat in a coffeeshop next to a lady that took a videocall at the table I was at. Seeing her nod, shake her head no or yes, and emit all sorts of body language that is utterly impossible to use on a phone call was *really fascinating*... good videoconferencing totally changes the internet interaction, I gleaned she was working for facebook... And I couldn't help myself. I fired up a rrul test in the middle of her con-call. It disrupted her conversation almost immediately, and to watch her dismay, disorientation and frustration was painful to watch. ~25 seconds in, I had to abort the test. It took her, oh, 8 seconds to regain her footing. I introduced myself to her after the call, told her that her glitch was probably bufferbloat, but didn't tell her it was my fault. >> >> >> Conversely, there are some applications for which sufficient bandwidth i= s not a matter of response time, but a threshold prerequisite for correct o= peration. We can refer to these as isochronous applications, or choose ano= ther term if you prefer. Video streaming is an example of this; given an a= -priori chosen video codec setting, if the data it produces cannot be trans= ferred as fast as it is produced, the receiver will not be able to play it = back in synchrony. >> >> YouTube can reliably stream Full-HD (1080p60) video down a 10Mbps debloa= ted pipe. The broadband standard in the US claims that 25Mbps is necessary= for this precise application. > > > No, it doesn't. It claims the opposite, i.e. that 10Mbps is sufficient fo= r streaming one HD video but with 25Mbps you can stream two HD videos or on= e 4K video, see Table 1 in the FCC report: > > https://docs.fcc.gov/public/attachments/FCC-15-10A1.pdf Good to know. > /Jonas > >> >> Draw your own conclusions. >> >> - Jonathan Morton >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619