From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 0DA4C3CB35; Fri, 2 Jul 2021 13:07:34 -0400 (EDT) Received: by mail-il1-x131.google.com with SMTP id t12so10333499ile.13; Fri, 02 Jul 2021 10:07:33 -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=kk7Bi0sx128IieGy40bUOM1xnxy2QNvOUfmIQe7PNe8=; b=dfb6n1aqtITP1C13Pe3T5pBa4f78xQtRanlRA0PaC+Sy8MumuTCVc+BhxHVF+tm9JG LIrRmFVGhkZh80wwjsa348unZ8Gwex9hnwoDk1wvWBr0HPeC1QdFlfpvE9EOyoy1Jtc4 I5sJPUgxPyZLd+WCawnpfoyqoC562QlFCVoLA9zCQSHLucGoQo/WSs7NjMoYb6dFw4e8 Lv/A7TFhOXEpeMSi9pZuq0kvZF6vu9m4t2SZwaTpphzk9AJhRovLomuo6Fuot5NX+opF uK+cEwHeesHMJjZZeeTCq0jO8jY+U3SsYiepONWmQk4rrti/yu9wy7vh6tYsjW4tN6uo b5WA== 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=kk7Bi0sx128IieGy40bUOM1xnxy2QNvOUfmIQe7PNe8=; b=syj6/z590zgiI8fR961gsAQC1wSF25TIrF9lF0fYs4jQDrn7PGqP+6RmhYCYLyqj0K ydoNCEiiQVy3dV7MrqQ9t/rqWYZKLVe2p7rLQajv71AleLXB3DAoBzulfd7n4ojxzJMg dbRR2rx9BB15/otggDvrRhc0bKuOUJ3tiyKq8/vRWdXY+hyEJc0FgjM7z8G9S5qsy7X+ wwn5uBGwQ0yxjTyzORIkDTpwcjsSJ2fXnLqp9/sdYQtjRx3oLEBB5iieoyCHOsx22Pno Z9vADnnTnc6fRSYHriEubFBgAOXcR0ebny/+N3s4n4Aq3BNyHYPmN/9QM5mM1nh7IcSk nDfg== X-Gm-Message-State: AOAM530Worx90AXHMYbVAsiYuNWIOo3VJK8fhvnhu/IqCTi8IRoU/lyx aOHnfGvonhQmQZOghyY/XVoVQsRomEzELKU906Q= X-Google-Smtp-Source: ABdhPJwJh5wqpny1fxEn2KyRKdCCAahAT9wlj78C3E9qTyCXZ6lOuc1kHX8tun0hcFAYfOx+e68B3U0YbcpL4YrOPj8= X-Received: by 2002:a92:d60c:: with SMTP id w12mr692777ilm.246.1625245653237; Fri, 02 Jul 2021 10:07:33 -0700 (PDT) MIME-Version: 1.0 References: <1625188609.32718319@apps.rackspace.com> In-Reply-To: <1625188609.32718319@apps.rackspace.com> From: Dave Taht Date: Fri, 2 Jul 2021 10:07:22 -0700 Message-ID: To: "David P. Reed" Cc: bloat , Make-Wifi-fast , cerowrt-devel , codel@lists.bufferbloat.net, starlink@lists.bufferbloat.net, Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Codel] [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: Fri, 02 Jul 2021 17:07:34 -0000 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 t= hat 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" sugge= sts that they REALLY, REALLY don't understand the Internet isn't the hardwa= re 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 im= aginary 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 pr= otocols - a desire to put *into the network* special tricks to optimize ASR= 33 logins to remote computers from terminal concentrators (aka remote login= ), bulk file transfers between file systems on different time-sharing syste= ms, and "sessions" (virtual circuits) that required logins. And then trying= to exploit underlying "multicast" by building it into the IP layer, becaus= e someone thought that TV broadcast would be the dominant application. > > > > Frankly, to think of "quality" as something that can be "provided" by "th= e 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 d= on't bother to include current and future users talking about what they mig= ht expect to experience that they don't experience. > > > > There was much fighting back in 1976 that basically involved "network exp= erts" saying that the network was the place to "solve" such issues as quali= ty, 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 is= sues. 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 wh= y 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 u= nderlying resources. That's it. Quality is a whole different thing. Quality= can be improved by end-to-end approaches, if the underlying network provid= es some kind of thing that actually creates a way for end-to-end applicatio= ns to affect queueing and routing decisions, and more importantly getting "= telemetry" from the network regarding what is actually going on with the ot= her 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" sai= d: > > > 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 Eart= h) > > 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=E2=80=99t 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 f= irewalls? > > 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=E2=80=99 experience most an= d 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:679101428493678592= 0/ > > > > Dave T=C3=A4ht 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=C3=A4ht CTO, TekLibre, LLC