From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp64.iad3a.emailsrvr.com (smtp64.iad3a.emailsrvr.com [173.203.187.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DE3B33CB41; Thu, 1 Jul 2021 21:16:49 -0400 (EDT) Received: from app45.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp33.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 65261198C; Thu, 1 Jul 2021 21:16:49 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app45.wa-webapps.iad3a (Postfix) with ESMTP id 5095C61802; Thu, 1 Jul 2021 21:16:49 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 1 Jul 2021 21:16:49 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Thu, 1 Jul 2021 21:16:49 -0400 (EDT) From: "David P. Reed" To: "Dave Taht" Cc: "bloat" , "Make-Wifi-fast" , "cerowrt-devel" , codel@lists.bufferbloat.net, starlink@lists.bufferbloat.net, "Cake List" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20210701211649000000_37808" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1625188609.32718319@apps.rackspace.com> X-Mailer: webmail/19.0.7-RC X-Classification-ID: 251a4995-5ad9-434f-b6bc-b8bbcc897d52-1-1 Subject: Re: [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board 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: Fri, 02 Jul 2021 01:16:50 -0000 ------=_20210701211649000000_37808 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AWell, nice that the folks doing the conference are willing to consider = that quality of user experience has little to do with signalling rate at th= e physical layer or throughput of FTP transfers.=0A =0ABut honestly, the fa= ct 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 e= ven the routing algorithms *to its users*.=0A =0ABy 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 th= at 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 give= n the chance.=0A =0AI saw this issue in 1976 in the group developing the or= iginal Internet protocols - a desire to put *into the network* special tric= ks 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 login= s. And then trying to exploit underlying "multicast" by building it into th= e IP layer, because someone thought that TV broadcast would be the dominant= application.=0A =0AFrankly, to think of "quality" as something that can be= "provided" by "the network" misses the entire point of "end-to-end argumen= t in system design". Quality is not a property defined or created by The Ne= twork. If you want to talk about Quality, you need to talk about users - al= l 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 a= bout what they might expect to experience that they don't experience.=0A = =0AThere was much fighting back in 1976 that basically involved "network ex= perts" saying that the network was the place to "solve" such issues as qual= ity, so applications could avoid having to solve such issues.=0A =0AWhat so= me 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 *cooperat= e* in some way.=0A =0AWhich is why the Internet drops packets rather than q= ueueing them, and why diffserv cannot work.=0A(I know the latter is conftro= versial, but at the moment, ALL of diffserv attempts to talk about end-to-e= nd 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 princi= ple).=0A =0ANetworks are about getting packets from here to there, multiple= xing the underlying resources. That's it. Quality is a whole different thin= g. Quality can be improved by end-to-end approaches, if the underlying netw= ork 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 w= ith the other end-to-end users sharing the infrastructure.=0A =0AThis confe= rence won't talk about it this way. So don't waste your time.=0A =0A =0A = =0AOn Wednesday, June 30, 2021 8:12pm, "Dave Taht" sa= id:=0A=0A=0A=0A> The program committee members are *amazing*. Perhaps, fina= lly, we can=0A> move the bar for the internet's quality metrics past endles= s, blind=0A> repetitions of speedtest.=0A> =0A> For complete details, pleas= e see:=0A> https://www.iab.org/activities/workshops/network-quality/=0A> = =0A> Submissions Due: Monday 2nd August 2021, midnight AOE (Anywhere On Ear= th)=0A> Invitations Issued by: Monday 16th August 2021=0A> =0A> Workshop Da= te: This will be a virtual workshop, spread over three days:=0A> =0A> 1400-= 1800 UTC Tue 14th September 2021=0A> 1400-1800 UTC Wed 15th September 2021= =0A> 1400-1800 UTC Thu 16th September 2021=0A> =0A> Workshop co-chairs: Wes= Hardaker, Evgeny Khorov, Omer Shapira=0A> =0A> The Program Committee membe= rs:=0A> =0A> Jari Arkko, Olivier Bonaventure, Vint Cerf, Stuart Cheshire, S= am=0A> Crowford, Nick Feamster, Jim Gettys, Toke Hoiland-Jorgensen, Geoff= =0A> Huston, Cullen Jennings, Katarzyna Kosek-Szott, Mirja Kuehlewind,=0A> = Jason Livingood, Matt Mathias, Randall Meyer, Kathleen Nichols,=0A> Christo= ph Paasch, Tommy Pauly, Greg White, Keith Winstein.=0A> =0A> Send Submissio= ns to: network-quality-workshop-pc@iab.org.=0A> =0A> Position papers from a= cademia, industry, the open source community and=0A> others that focus on m= easurements, experiences, observations and=0A> advice for the future are we= lcome. Papers that reflect experience=0A> based on deployed services are es= pecially welcome. The organizers=0A> understand that specific actions taken= by operators are unlikely to be=0A> discussed in detail, so papers discuss= ing general categories of=0A> actions and issues without naming specific te= chnologies, products, or=0A> other players in the ecosystem are expected. P= apers should not focus=0A> on specific protocol solutions.=0A> =0A> The wor= kshop will be by invitation only. Those wishing to attend=0A> should submit= a position paper to the address above; it may take the=0A> form of an Inte= rnet-Draft.=0A> =0A> All inputs submitted and considered relevant will be p= ublished on the=0A> workshop website. The organisers will decide whom to in= vite based on=0A> the submissions received. Sessions will be organized acco= rding to=0A> content, and not every accepted submission or invited attendee= will=0A> have an opportunity to present as the intent is to foster discuss= ion=0A> and not simply to have a sequence of presentations.=0A> =0A> Positi= on papers from those not planning to attend the virtual sessions=0A> themse= lves are also encouraged. A workshop report will be published=0A> afterward= s.=0A> =0A> Overview:=0A> =0A> "We believe that one of the major factors be= hind this lack of progress=0A> is the popular perception that throughput is= the often sole measure of=0A> the quality of Internet connectivity. With s= uch narrow focus, people=0A> don=E2=80=99t consider questions such as:=0A> = =0A> What is the latency under typical working conditions?=0A> How reliable= is the connectivity across longer time periods?=0A> Does the network allow= the use of a broad range of protocols?=0A> What services can be run by cli= ents of the network?=0A> What kind of IPv4, NAT or IPv6 connectivity is off= ered, and are there firewalls?=0A> What security mechanisms are available f= or local services, such as DNS?=0A> To what degree are the privacy, confide= ntiality, integrity and=0A> authenticity of user communications guarded?=0A= > =0A> Improving these aspects of network quality will likely depend on=0A>= measurement and exposing metrics to all involved parties, including to=0A>= end users in a meaningful way. Such measurements and exposure of the=0A> r= ight metrics will allow service providers and network operators to=0A> focu= s on the aspects that impacts the users=E2=80=99 experience most and at=0A>= the same time empowers users to choose the Internet service that will=0A> = give them the best experience."=0A> =0A> =0A> --=0A> Latest Podcast:=0A> ht= tps://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/=0A>= =0A> Dave T=C3=A4ht CTO, TekLibre, LLC=0A> _______________________________= ________________=0A> Cerowrt-devel mailing list=0A> Cerowrt-devel@lists.buf= ferbloat.net=0A> https://lists.bufferbloat.net/listinfo/cerowrt-devel=0A> ------=_20210701211649000000_37808 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Well, nice that the fo= lks 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.

=0A

 

=0A

But honestly, the fact that they call the problem "network q= uality" 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= *.

=0A

 

=0A

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 th= e usual trap that net-heads fall into - optimizing for some imaginary reali= ty that doesn't exist, and in fact will probably never be what users actual= ly will do given the chance.

=0A

 

=0A

I saw this issue in 1976 in the group developing the origina= l 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. An= d then trying to exploit underlying "multicast" by building it into the IP = layer, because someone thought that TV broadcast would be the dominant appl= ication.

=0A

 

=0A

Frank= ly, to think of "quality" as something that can be "provided" by "the netwo= rk" misses the entire point of "end-to-end argument in system design". Qual= ity is not a property defined or created by The Network. If you want to tal= k 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 bo= ther to include current and future users talking about what they might expe= ct to experience that they don't experience.

=0A

&nb= sp;

=0A

There was much fighting back in 1976 that ba= sically involved "network experts" saying that the network was the place to= "solve" such issues as quality, so applications could avoid having to solv= e such issues.

=0A

 

=0A

What some of us managed to do was to argue that you can't "solve" such iss= ues. All you can do is provide a framework that enables different uses to *= cooperate* in some way.

=0A

 

=0A

Which is why the Internet drops packets rather than queueing them= , and why diffserv cannot work.

=0A

(I know the latt= er is conftroversial, but at the moment, ALL of diffserv attempts to talk a= bout 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 actua= lly control. So it is meaningless - another violation of the so-called end-= to-end principle).

=0A

 

=0A

Networks are about getting packets from here to there, multiplexing th= e underlying resources. That's it. Quality is a whole different thing. Qual= ity can be improved by end-to-end approaches, if the underlying network pro= vides some kind of thing that actually creates a way for end-to-end applica= tions to affect queueing and routing decisions, and more importantly gettin= g "telemetry" from the network regarding what is actually going on with the= other end-to-end users sharing the infrastructure.

=0A

 

=0A

This conference won't talk about it t= his way. So don't waste your time.

=0A

 

=0A=

 

=0A

 

=0A

On Wednesday, June 30, 2021 8:12pm, "Dave Taht" <dave.taht= @gmail.com> said:

=0A
=0A=

> The program committee members are *amazing*. Perh= aps, finally, we can
> move the bar for the internet's quality metr= ics past endless, blind
> repetitions of speedtest.
>
> For complete details, please see:
> https://www.iab.org/activ= ities/workshops/network-quality/
>
> Submissions Due: Mond= ay 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:
>
> 1= 400-1800 UTC Tue 14th September 2021
> 1400-1800 UTC Wed 15th Septe= mber 2021
> 1400-1800 UTC Thu 16th September 2021
>
&= gt; Workshop co-chairs: Wes Hardaker, Evgeny Khorov, Omer Shapira
>=
> The Program Committee members:
>
> Jari Arkko,= Olivier Bonaventure, Vint Cerf, Stuart Cheshire, Sam
> Crowford, N= ick Feamster, Jim Gettys, Toke Hoiland-Jorgensen, Geoff
> Huston, C= ullen Jennings, Katarzyna Kosek-Szott, Mirja Kuehlewind,
> Jason Li= vingood, 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, produ= cts, or
> other players in the ecosystem are expected. Papers shoul= d 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
&= gt; form of an Internet-Draft.
>
> All inputs submitted an= d considered relevant will be published on the
> workshop website. = The organisers will decide whom to invite based on
> the submission= s received. Sessions will be organized according to
> content, and = not every accepted submission or invited attendee will
> have an op= portunity to present as the intent is to foster discussion
> and no= t simply to have a sequence of presentations.
>
> Position= papers from those not planning to attend the virtual sessions
> th= emselves are also encouraged. A workshop report will be published
>= afterwards.
>
> Overview:
>
> "We believ= e that one of the major factors behind this lack of progress
> is t= he 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 i= s the latency under typical working conditions?
> How reliable is t= he connectivity across longer time periods?
> Does the network allo= w 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 connec= tivity is offered, and are there firewalls?
> What security mechani= sms 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 o= f network quality will likely depend on
> measurement and exposing = metrics to all involved parties, including to
> end users in a mean= ingful way. Such measurements and exposure of the
> right metrics w= ill allow service providers and network operators to
> focus on the= aspects that impacts the users=E2=80=99 experience most and at
> t= he same time empowers users to choose the Internet service that will
&= gt; give them the best experience."
>
>
> --
> Latest Podcast:
> https://www.linkedin.com/feed/update/urn:li= :activity:6791014284936785920/
>
> Dave T=C3=A4ht CTO, Tek= Libre, LLC
> _______________________________________________
&= gt; Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.ne= t
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> =

=0A
 ------=_20210701211649000000_37808--