From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E0E253B2A4 for ; Thu, 6 May 2021 09:41:00 -0400 (EDT) Received: from dlang-laptop (unknown [10.2.0.162]) by mail.lang.hm (Postfix) with ESMTP id D4B2AF6CF5; Thu, 6 May 2021 06:40:59 -0700 (PDT) Date: Thu, 6 May 2021 06:40:59 -0700 (PDT) From: David Lang X-X-Sender: dlang@dlang-laptop To: Jason Iannone cc: "Livingood, Jason" , bloat In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="===============5809395306191834000==" Subject: Re: [Bloat] Terminology for Laypeople 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: Thu, 06 May 2021 13:41:01 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============5809395306191834000== Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT it's sometimesworth reminding technical folks that if you look at a small enough time slice, a network is either 0% or 100% utilized, so if the output is 100% utilized the instant a packet arrives, the device ither dropps the data or buffers it. David Lang On Thu, 6 May 2021, Jason Iannone wrote: > It's not a short discussion but I start with a comparison of circuit and > packet switching, usually with an accompanying drawing. There's a physicist > joke in here about assuming a frictionless environment but for the intent > of this explanation, a circuit switched path is bufferless because circuit > switched networks are point to point and bits are transmitted at the same > rate that they are received. Packet switching introduces a mechanism for > nodes supporting multiple ingress, single egress transmission. In order to > support transient bursts, network nodes hold onto bits for a time while the > egress interface processes the node's ingress traffic. That hold time > equates to additional latency. Every node in a path may subject a flow's > traffic to buffering, increasing latency in transit based on its individual > load. > > Jason > > On Tue, May 4, 2021 at 8:02 PM Livingood, Jason via Bloat < > bloat@lists.bufferbloat.net> wrote: > >> Like many of you I have been immersed in buffer bloat discussions for many >> years, almost entirely within the technical community. Now that I am >> starting to explain latency & latency under load to internal non-technical >> folks, I have noticed some people don’t really understand “traditional” >> latency vs. latency under load (LUL). >> >> >> >> As a result, I am planning to experiment in some upcoming briefings and >> call traditional latency “idle latency” – a measure of latency conducted on >> an otherwise idle connection. And then try calling LUL either “active >> latency” or perhaps “working latency” (suggested by an external colleague – >> can’t take credit for that one) – to try to communicate it is latency when >> the connection is experiencing normal usage. >> >> >> >> Have any of you here faced similar challenges explaining this to >> non-technical audiences? Have you had any success with alternative terms? >> What do you think of these? >> >> >> >> Thanks for any input, >> >> Jason >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> > --===============5809395306191834000== Content-Type: text/plain; CHARSET=utf-8 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: INLINE X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQmxvYXQgbWFp bGluZyBsaXN0CkJsb2F0QGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldApodHRwczovL2xpc3RzLmJ1ZmZl cmJsb2F0Lm5ldC9saXN0aW5mby9ibG9hdAo= --===============5809395306191834000==--