From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp86.iad3a.emailsrvr.com (smtp86.iad3a.emailsrvr.com [173.203.187.86]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4B9D93CB40; Mon, 12 Jul 2021 13:40:31 -0400 (EDT) Received: from app58.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C16B324AAC; Mon, 12 Jul 2021 13:40:30 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app58.wa-webapps.iad3a (Postfix) with ESMTP id AAD752012A; Mon, 12 Jul 2021 13:40:30 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Mon, 12 Jul 2021 13:40:30 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Mon, 12 Jul 2021 13:40:30 -0400 (EDT) From: "David P. Reed" To: "Livingood, Jason" Cc: "Luca Muscariello" , "Cake List" , "Make-Wifi-fast" , "Leonard Kleinrock" , "Bob McMahon" , "starlink@lists.bufferbloat.net" , "codel@lists.bufferbloat.net" , "cerowrt-devel" , "bloat" , "Ben Greear" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: <1625188609.32718319@apps.rackspace.com> <989de0c1-e06c-cda9-ebe6-1f33df8a4c24@candelatech.com> <1625773080.94974089@apps.rackspace.com> <1625859083.09751240@apps.rackspace.com> X-Client-IP: 209.6.168.128 Message-ID: <1626111630.69692379@apps.rackspace.com> X-Mailer: webmail/19.0.7-RC X-Classification-ID: d3677fe1-b9b4-405e-b39e-5e3c47309c67-1-1 Subject: Re: [Cerowrt-devel] [Bloat] Little's Law mea culpa, but not invalidating my main point X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 17:40:31 -0000 =C2=A0=0AOn Monday, July 12, 2021 9:46am, "Livingood, Jason" said:=0A=0A> I think latency/delay is becoming seen to be a= s important certainly, if not a more direct proxy for end user QoE. This is= all still evolving and I have to say is a super interesting & fun thing to= work on. :-)=0A=C2=A0=0AIf I could manage to sell one idea to the manageme= nt hierarchy of communications industry CEOs (operators, vendors, ...) it i= s this one:=0A=0A"It's the end-to-end latency, stupid!"=0A=0AAnd I mean, by= end-to-end, latency to complete a task at a relevant layer of abstraction.= =0A=0AAt the link level, it's packet send to packet receive completion.=0A= =0ABut at the transport level including retransmission buffers, it's datagr= am (or message) origination until the acknowledgement arrives for that mess= age being delivered after whatever number of retransmissions, freeing the r= etransmission buffer.=0A=0AAt the WWW level, it's mouse click to display up= date corresponding to completion of the request.=0A=0AWhat should be noted = is that lower level latencies don't directly predict the magnitude of highe= r-level latencies. But longer lower level latencies almost always amplfify = higher level latencies. Often non-linearly.=0A=0AThroughput is very, very w= eakly related to these latencies, in contrast.=0A=0AThe amplification proce= ss has to do with the presence of queueing. Queueing is ALWAYS bad for late= ncy, and throughput only helps if it is in exactly the right place (the so-= called input queue of the bottleneck process, which is often a link, but no= t always).=0A=0ACan we get that slogan into Harvard Business Review? Can we= get it taught in Managerial Accounting at HBS? (which does address logisti= cs/supply chain queueing).=0A=C2=A0=0A=C2=A0=0A=C2=A0=0A=C2=A0=0A=C2=A0