From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.184]) (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 C1D9D3CB37; Mon, 12 Jul 2021 15:07:47 -0400 (EDT) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.110.51.28]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 9A1942A0067; Mon, 12 Jul 2021 19:07:46 +0000 (UTC) Received: from mail3.candelatech.com (mail2.candelatech.com [208.74.158.173]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id A6794380093; Mon, 12 Jul 2021 19:07:45 +0000 (UTC) Received: from [192.168.100.195] (50-251-239-81-static.hfc.comcastbusiness.net [50.251.239.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail3.candelatech.com (Postfix) with ESMTPSA id CEBB913C2B3; Mon, 12 Jul 2021 12:07:44 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail3.candelatech.com CEBB913C2B3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=candelatech.com; s=default; t=1626116865; bh=tK+xa+0M2zg6o1OpdHilsLzD4AlGkRpSBTX1yZEBw9o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qd9ebytVNeUsscXrdbnZ3i2SYZjE6SrxZiUiZmAES+hGJVgaJVPH7ZE3JpOESrVG2 Lw0Nv0GG6Rqi6OVhWk3kS1j9lG3Gunp1p35nMoC/WjJz5KGIObfKr0jrDKEWABpmxB NqY67Gb9kyLUX0Nz85Yy0nhJrSSsppsdGxf6ojuo= To: Bob McMahon , "David P. Reed" Cc: "Livingood, Jason" , Luca Muscariello , Cake List , Make-Wifi-fast , Leonard Kleinrock , "starlink@lists.bufferbloat.net" , "codel@lists.bufferbloat.net" , cerowrt-devel , bloat References: <1625188609.32718319@apps.rackspace.com> <989de0c1-e06c-cda9-ebe6-1f33df8a4c24@candelatech.com> <1625773080.94974089@apps.rackspace.com> <1625859083.09751240@apps.rackspace.com> <1626111630.69692379@apps.rackspace.com> From: Ben Greear Organization: Candela Technologies Message-ID: <9c3d61c1-7013-414e-964d-9e83f596e69d@candelatech.com> Date: Mon, 12 Jul 2021 12:07:44 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MDID: 1626116867-MD8a7H-ebIRx Subject: Re: [Bloat] Little's Law mea culpa, but not invalidating my main point 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: Mon, 12 Jul 2021 19:07:47 -0000 Measuring one or a few links provides a bit of data, but seems like if someone is trying to understand a large and real network, then the OWD between point A and B needs to just be input into something much more grand. Assuming real-time OWD data exists between 100 to 1000 endpoint pairs, has anyone found a way to visualize this in a useful manner? Also, considering something better than ntp may not really scale to 1000+ endpoints, maybe round-trip time is only viable way to get this type of data. In that case, maybe clever logic could use things like trace-route to get some idea of how long it takes to get 'onto' the internet proper, and so estimate the last-mile latency. My assumption is that the last-mile latency is where most of the pervasive assymetric network latencies would exist (or just ping 8.8.8.8 which is 20ms from everywhere due to $magic). Endpoints could also triangulate a bit if needed, using some anchor points in the network under test. Thanks, Ben On 7/12/21 11:21 AM, Bob McMahon wrote: > iperf 2 supports OWD and gives full histograms for TCP write to read, TCP connect times, latency of packets (with UDP), latency of "frames" with > simulated video traffic (TCP and UDP), xfer times of bursts with low duty cycle traffic, and TCP RTT (sampling based.) It also has support for sampling (per > interval reports) down to 100 usecs if configured with --enable-fastsampling, otherwise the fastest sampling is 5 ms. We've released all this as open source. > > OWD only works if the end realtime clocks are synchronized using a "machine level" protocol such as IEEE 1588 or PTP. Sadly, *most data centers don't provide > sufficient level of clock accuracy and the GPS pulse per second * to colo and vm customers. > > https://iperf2.sourceforge.io/iperf-manpage.html > > Bob > > On Mon, Jul 12, 2021 at 10:40 AM David P. Reed > wrote: > > > On Monday, July 12, 2021 9:46am, "Livingood, Jason" > said: > > > I think latency/delay is becoming seen to be as 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. :-) > > If I could manage to sell one idea to the management hierarchy of communications industry CEOs (operators, vendors, ...) it is this one: > > "It's the end-to-end latency, stupid!" > > And I mean, by end-to-end, latency to complete a task at a relevant layer of abstraction. > > At the link level, it's packet send to packet receive completion. > > But at the transport level including retransmission buffers, it's datagram (or message) origination until the acknowledgement arrives for that message being > delivered after whatever number of retransmissions, freeing the retransmission buffer. > > At the WWW level, it's mouse click to display update corresponding to completion of the request. > > What should be noted is that lower level latencies don't directly predict the magnitude of higher-level latencies. But longer lower level latencies almost > always amplfify higher level latencies. Often non-linearly. > > Throughput is very, very weakly related to these latencies, in contrast. > > The amplification process has to do with the presence of queueing. Queueing is ALWAYS bad for latency, 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 not always). > > Can we get that slogan into Harvard Business Review? Can we get it taught in Managerial Accounting at HBS? (which does address logistics/supply chain queueing). > > > > > > > > This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of > the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise > restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, > you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you > received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. -- Ben Greear Candela Technologies Inc http://www.candelatech.com