From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.48]) (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 46B123CB37; Tue, 6 Jul 2021 09:46:42 -0400 (EDT) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.7.67.119]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 685861C006C; Tue, 6 Jul 2021 13:46:40 +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 B8DCF7C0075; Tue, 6 Jul 2021 13:46:39 +0000 (UTC) Received: from [192.168.254.6] (unknown [50.34.183.227]) (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 A466F13C2B1; Tue, 6 Jul 2021 06:46:38 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail3.candelatech.com A466F13C2B1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=candelatech.com; s=default; t=1625579199; bh=KhX4By2bUyTKPRt0U+oVUwpQKn/dRtzXmsu3dWsa6Ng=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=N9Ox7M57oUhJvznnSVT9Si8QNi7yqMQGSC8KGLNuPLhxH9bM0K+DH3RaUIt+Oh6Pb UWl3I2+gCpWydmpflMOoeFTuqYa/EsoFR+llgVwWGoIoqnIkgNSEaGssboIcX+Trg9 OCa9lQFuDIj//52aYhckDBE6OkiUoswmLGMBqIBQ= To: Bob McMahon , Dave Taht Cc: starlink@lists.bufferbloat.net, Make-Wifi-fast , "David P. Reed" , Cake List , codel@lists.bufferbloat.net, cerowrt-devel , bloat References: <1625188609.32718319@apps.rackspace.com> From: Ben Greear Organization: Candela Technologies Message-ID: <989de0c1-e06c-cda9-ebe6-1f33df8a4c24@candelatech.com> Date: Tue, 6 Jul 2021 06:46:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-MW Content-Transfer-Encoding: 8bit X-MDID: 1625579200-7yLXwK7TMDS4 Subject: Re: [Codel] [Starlink] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 13:46:42 -0000 Hello, I am interested to hear wish lists for network testing features. We make test equipment, supporting lots of wifi stations and a distributed architecture, with built-in udp, tcp, ipv6, http, ... protocols, and open to creating/improving some of our automated tests. I know Dave has some test scripts already, so I'm not necessarily looking to reimplement that, but more fishing for other/new ideas. Thanks, Ben On 7/2/21 4:28 PM, Bob McMahon wrote: > I think we need the language of math here. It seems like the network power metric, introduced by Kleinrock and Jaffe in the late 70s, is something useful. > Effective end/end queue depths per Little's law also seems useful. Both are available in iperf 2 from a test perspective. Repurposing test techniques to actual > traffic could be useful. Hence the question around what exact telemetry is useful to apps making socket write() and read() calls. > > Bob > > On Fri, Jul 2, 2021 at 10:07 AM Dave Taht > wrote: > > In terms of trying to find "Quality" I have tried to encourage folk to > both read "zen and the art of motorcycle maintenance"[0], and Deming's > work on "total quality management". > > My own slice at this network, computer and lifestyle "issue" is aiming > for "imperceptible latency" in all things. [1]. There's a lot of > fallout from that in terms of not just addressing queuing delay, but > caching, prefetching, and learning more about what a user really needs > (as opposed to wants) to know via intelligent agents. > > [0] If you want to get depressed, read Pirsig's successor to "zen...", > lila, which is in part about what happens when an engineer hits an > insoluble problem. > [1] https://www.internetsociety.org/events/latency2013/ > > > > On Thu, Jul 1, 2021 at 6:16 PM David P. Reed > wrote: > > > > Well, nice that the folks doing the conference  are willing to consider that quality of user experience has little to do with signalling rate at the > physical layer or throughput of FTP transfers. > > > > > > > > But honestly, the fact that they call the problem "network quality" suggests that they REALLY, REALLY don't understand the Internet isn't the hardware or > the routers or even the routing algorithms *to its users*. > > > > > > > > By ignoring the diversity of applications now and in the future, and the fact that we DON'T KNOW what will be coming up, this conference will likely fall > into the usual trap that net-heads fall into - optimizing for some imaginary reality that doesn't exist, and in fact will probably never be what users > actually will do given the chance. > > > > > > > > I saw this issue in 1976 in the group developing the original Internet protocols - a desire to put *into the network* special tricks to optimize ASR33 > logins to remote computers from terminal concentrators (aka remote login), bulk file transfers between file systems on different time-sharing systems, and > "sessions" (virtual circuits) that required logins. And then trying to exploit underlying "multicast" by building it into the IP layer, because someone > thought that TV broadcast would be the dominant application. > > > > > > > > Frankly, to think of "quality" as something that can be "provided" by "the network" misses the entire point of "end-to-end argument in system design". > Quality is not a property defined or created by The Network. If you want to talk about Quality, you need to talk about users - all the users at all times, > now and into the future, and that's something you can't do if you don't bother to include current and future users talking about what they might expect to > experience that they don't experience. > > > > > > > > There was much fighting back in 1976 that basically involved "network experts" saying that the network was the place to "solve" such issues as quality, > so applications could avoid having to solve such issues. > > > > > > > > What some of us managed to do was to argue that you can't "solve" such issues. All you can do is provide a framework that enables different uses to > *cooperate* in some way. > > > > > > > > Which is why the Internet drops packets rather than queueing them, and why diffserv cannot work. > > > > (I know the latter is conftroversial, but at the moment, ALL of diffserv attempts to talk about end-to-end applicaiton specific metrics, but never, ever > explains what the diffserv control points actually do w.r.t. what the IP layer can actually control. So it is meaningless - another violation of the > so-called end-to-end principle). > > > > > > > > Networks are about getting packets from here to there, multiplexing the underlying resources. That's it. Quality is a whole different thing. Quality can > be improved by end-to-end approaches, if the underlying network provides some kind of thing that actually creates a way for end-to-end applications to > affect queueing and routing decisions, and more importantly getting "telemetry" from the network regarding what is actually going on with the other > end-to-end users sharing the infrastructure. > > > > > > > > This conference won't talk about it this way. So don't waste your time. > > > > > > > > > > > > > > > > On Wednesday, June 30, 2021 8:12pm, "Dave Taht" > said: > > > > > The program committee members are *amazing*. Perhaps, finally, we can > > > move the bar for the internet's quality metrics past endless, blind > > > repetitions of speedtest. > > > > > > For complete details, please see: > > > https://www.iab.org/activities/workshops/network-quality/ > > > > > > Submissions Due: Monday 2nd August 2021, midnight AOE (Anywhere On Earth) > > > Invitations Issued by: Monday 16th August 2021 > > > > > > Workshop Date: This will be a virtual workshop, spread over three days: > > > > > > 1400-1800 UTC Tue 14th September 2021 > > > 1400-1800 UTC Wed 15th September 2021 > > > 1400-1800 UTC Thu 16th September 2021 > > > > > > Workshop co-chairs: Wes Hardaker, Evgeny Khorov, Omer Shapira > > > > > > The Program Committee members: > > > > > > Jari Arkko, Olivier Bonaventure, Vint Cerf, Stuart Cheshire, Sam > > > Crowford, Nick Feamster, Jim Gettys, Toke Hoiland-Jorgensen, Geoff > > > Huston, Cullen Jennings, Katarzyna Kosek-Szott, Mirja Kuehlewind, > > > Jason Livingood, Matt Mathias, Randall Meyer, Kathleen Nichols, > > > Christoph Paasch, Tommy Pauly, Greg White, Keith Winstein. > > > > > > Send Submissions to: network-quality-workshop-pc@iab.org . > > > > > > Position papers from academia, industry, the open source community and > > > others that focus on measurements, experiences, observations and > > > advice for the future are welcome. Papers that reflect experience > > > based on deployed services are especially welcome. The organizers > > > understand that specific actions taken by operators are unlikely to be > > > discussed in detail, so papers discussing general categories of > > > actions and issues without naming specific technologies, products, or > > > other players in the ecosystem are expected. Papers should not focus > > > on specific protocol solutions. > > > > > > The workshop will be by invitation only. Those wishing to attend > > > should submit a position paper to the address above; it may take the > > > form of an Internet-Draft. > > > > > > All inputs submitted and considered relevant will be published on the > > > workshop website. The organisers will decide whom to invite based on > > > the submissions received. Sessions will be organized according to > > > content, and not every accepted submission or invited attendee will > > > have an opportunity to present as the intent is to foster discussion > > > and not simply to have a sequence of presentations. > > > > > > Position papers from those not planning to attend the virtual sessions > > > themselves are also encouraged. A workshop report will be published > > > afterwards. > > > > > > Overview: > > > > > > "We believe that one of the major factors behind this lack of progress > > > is the popular perception that throughput is the often sole measure of > > > the quality of Internet connectivity. With such narrow focus, people > > > don’t consider questions such as: > > > > > > What is the latency under typical working conditions? > > > How reliable is the connectivity across longer time periods? > > > Does the network allow the use of a broad range of protocols? > > > What services can be run by clients of the network? > > > What kind of IPv4, NAT or IPv6 connectivity is offered, and are there firewalls? > > > What security mechanisms are available for local services, such as DNS? > > > To what degree are the privacy, confidentiality, integrity and > > > authenticity of user communications guarded? > > > > > > Improving these aspects of network quality will likely depend on > > > measurement and exposing metrics to all involved parties, including to > > > end users in a meaningful way. Such measurements and exposure of the > > > right metrics will allow service providers and network operators to > > > focus on the aspects that impacts the users’ experience most and at > > > the same time empowers users to choose the Internet service that will > > > give them the best experience." > > > > > > > > > -- > > > Latest Podcast: > > > https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ > > > > > > Dave Täht CTO, TekLibre, LLC > > > _______________________________________________ > > > Cerowrt-devel mailing list > > > Cerowrt-devel@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > > > > -- > Latest Podcast: > https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ > > Dave Täht CTO, TekLibre, LLC > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast > > > 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. > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > -- Ben Greear Candela Technologies Inc http://www.candelatech.com