From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CCB5C3CB4C for ; Thu, 8 Jul 2021 15:38:01 -0400 (EDT) Received: from app57.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0825C4C79; Thu, 8 Jul 2021 15:38:01 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app57.wa-webapps.iad3a (Postfix) with ESMTP id E87F1E0073; Thu, 8 Jul 2021 15:38:00 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 8 Jul 2021 15:38:00 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Thu, 8 Jul 2021 15:38:00 -0400 (EDT) From: "David P. Reed" To: "Ben Greear" Cc: "Bob McMahon" , "Dave Taht" , starlink@lists.bufferbloat.net, "Make-Wifi-fast" , "Cake List" , codel@lists.bufferbloat.net, "cerowrt-devel" , "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20210708153800000000_10844" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <989de0c1-e06c-cda9-ebe6-1f33df8a4c24@candelatech.com> References: <1625188609.32718319@apps.rackspace.com> <989de0c1-e06c-cda9-ebe6-1f33df8a4c24@candelatech.com> X-Client-IP: 209.6.168.128 Message-ID: <1625773080.94974089@apps.rackspace.com> X-Mailer: webmail/19.0.7-RC X-Classification-ID: 1b1eeaf1-01b3-441b-a7ed-fd41f9ec24d4-1-1 Subject: Re: [Cerowrt-devel] [Starlink] [Make-wifi-fast] 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: Thu, 08 Jul 2021 19:38:02 -0000 ------=_20210708153800000000_10844 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI will tell you flat out that the arrival time distribution assumption m= ade by Little's Lemma that allows "estimation of queue depth" is totally un= reasonable on ANY Internet in practice.=0A =0AThe assumption is a Poisson A= rrival Process. In reality, traffic arrivals in real internet applications = are extremely far from Poisson, and, of course, using TCP windowing, become= highly intercorrelated with crossing traffic that shares the same queue.= =0A =0ASo, as I've tried to tell many, many net-heads (people who ignore ap= plications layer behavior, like the people that think latency doesn't matte= r to end users, only throughput), end-to-end packet arrival times on a prac= tical network are incredibly far from Poisson - and they are more like frac= tal probability distributions, very irregular at all scales of time.=0A =0A= So, the idea that iperf can estimate queue depth by Little's Lemma by just = measuring saturation of capacity of a path is bogus.The less Poisson, the w= orse the estimate gets, by a huge factor.=0A =0A =0AWhere does the Poisson = assumption come from? Well, like many theorems, it is the simplest tractab= le closed form solution - it creates a simplified view, by being a "single-= parameter" distribution (the parameter is called lambda for a Poisson distr= ibution). And the analysis of a simple queue with poisson arrival distribu= tion and a static, fixed service time is the first interesting Queueing The= ory example in most textbooks. It is suggestive of an interesting phenomeno= n, but it does NOT characterize any real system.=0A =0AIt's the queueing th= eory equivalent of "First, we assume a spherical cow...". in doing an examp= le in a freshman physics class.=0A =0AUnfortunately, most networking engine= ers understand neither queuing theory nor application networking usage in i= nteractive applications. Which makes them arrogant. They assume all distrib= utions are poisson!=0A =0A =0AOn Tuesday, July 6, 2021 9:46am, "Ben Greear"= said:=0A=0A=0A=0A> Hello,=0A> =0A> I am interest= ed to hear wish lists for network testing features. We make test=0A> equipm= ent, supporting lots=0A> of wifi stations and a distributed architecture, w= ith built-in udp, tcp, ipv6,=0A> http, ... protocols,=0A> and open to creat= ing/improving some of our automated tests.=0A> =0A> I know Dave has some te= st scripts already, so I'm not necessarily looking to=0A> reimplement that,= =0A> but more fishing for other/new ideas.=0A> =0A> Thanks,=0A> Ben=0A> =0A= > On 7/2/21 4:28 PM, Bob McMahon wrote:=0A> > I think we need the language = of math here. It seems like the network=0A> power metric, introduced by Kle= inrock and Jaffe in the late 70s, is something=0A> useful.=0A> > Effective = end/end queue depths per Little's law also seems useful. Both are=0A> avail= able in iperf 2 from a test perspective. Repurposing test techniques to=0A>= actual=0A> > traffic could be useful. Hence the question around what exact= telemetry=0A> is useful to apps making socket write() and read() calls.=0A= > >=0A> > Bob=0A> >=0A> > On Fri, Jul 2, 2021 at 10:07 AM Dave Taht > wrote:=0A> >=0A> > In terms= of trying to find "Quality" I have tried to encourage folk to=0A> > both r= ead "zen and the art of motorcycle maintenance"[0], and Deming's=0A> > work= on "total quality management".=0A> >=0A> > My own slice at this network, c= omputer and lifestyle "issue" is aiming=0A> > for "imperceptible latency" i= n all things. [1]. There's a lot of=0A> > fallout from that in terms of not= just addressing queuing delay, but=0A> > caching, prefetching, and learnin= g more about what a user really needs=0A> > (as opposed to wants) to know v= ia intelligent agents.=0A> >=0A> > [0] If you want to get depressed, read P= irsig's successor to "zen...",=0A> > lila, which is in part about what happ= ens when an engineer hits an=0A> > insoluble problem.=0A> > [1] https://www= .internetsociety.org/events/latency2013/=0A> =0A> >=0A> >=0A> >=0A> > On Thu, Jul 1, 2021 at 6:16= PM David P. Reed > wr= ote:=0A> > >=0A> > > Well, nice that the folks doing the conference are wi= lling to=0A> consider that quality of user experience has little to do with= signalling rate at=0A> the=0A> > physical layer or throughput of FTP trans= fers.=0A> > >=0A> > >=0A> > >=0A> > > But honestly, the fact that they call= the problem "network quality"=0A> suggests that they REALLY, REALLY don't = understand the Internet isn't the hardware=0A> or=0A> > the routers or even= the routing algorithms *to its users*.=0A> > >=0A> > >=0A> > >=0A> > > By = ignoring the diversity of applications now and in the future,=0A> and the f= act that we DON'T KNOW what will be coming up, this conference will=0A> lik= ely fall=0A> > into the usual trap that net-heads fall into - optimizing fo= r some=0A> imaginary reality that doesn't exist, and in fact will probably = never be what=0A> users=0A> > actually will do given the chance.=0A> > >=0A= > > >=0A> > >=0A> > > I saw this issue in 1976 in the group developing the = original=0A> Internet protocols - a desire to put *into the network* specia= l tricks to optimize=0A> ASR33=0A> > logins to remote computers from termin= al concentrators (aka remote=0A> login), bulk file transfers between file s= ystems on different time-sharing=0A> systems, and=0A> > "sessions" (virtual= circuits) that required logins. And then trying to=0A> exploit underlying = "multicast" by building it into the IP layer, because someone=0A> > thought= that TV broadcast would be the dominant application.=0A> > >=0A> > >=0A> >= >=0A> > > Frankly, to think of "quality" as something that can be "provide= d"=0A> by "the network" misses the entire point of "end-to-end argument in = system=0A> design".=0A> > Quality is not a property defined or created by T= he Network. If you want=0A> to talk about Quality, you need to talk about u= sers - all the users at all times,=0A> > now and into the future, and that'= s something you can't do if you don't=0A> bother to include current and fut= ure users talking about what they might expect=0A> to=0A> > experience that= they don't experience.=0A> > >=0A> > >=0A> > >=0A> > > There was much figh= ting back in 1976 that basically involved=0A> "network experts" saying that= the network was the place to "solve" such issues as=0A> quality,=0A> > so = applications could avoid having to solve such issues.=0A> > >=0A> > >=0A> >= >=0A> > > What some of us managed to do was to argue that you can't "solve= "=0A> such issues. All you can do is provide a framework that enables diffe= rent uses to=0A> > *cooperate* in some way.=0A> > >=0A> > >=0A> > >=0A> > >= Which is why the Internet drops packets rather than queueing them,=0A> and= why diffserv cannot work.=0A> > >=0A> > > (I know the latter is conftrover= sial, but at the moment, ALL of=0A> diffserv attempts to talk about end-to-= end applicaiton specific metrics, but=0A> never, ever=0A> > explains what t= he diffserv control points actually do w.r.t. what the IP=0A> layer can act= ually control. So it is meaningless - another violation of the=0A> > so-cal= led end-to-end principle).=0A> > >=0A> > >=0A> > >=0A> > > Networks are abo= ut getting packets from here to there, multiplexing=0A> the underlying reso= urces. That's it. Quality is a whole different thing. Quality=0A> can=0A> >= be improved by end-to-end approaches, if the underlying network provides= =0A> some kind of thing that actually creates a way for end-to-end applicat= ions to=0A> > affect queueing and routing decisions, and more importantly g= etting=0A> "telemetry" from the network regarding what is actually going on= with the other=0A> > end-to-end users sharing the infrastructure.=0A> > >= =0A> > >=0A> > >=0A> > > This conference won't talk about it this way. So d= on't waste your=0A> time.=0A> > >=0A> > >=0A> > >=0A> > >=0A> > >=0A> > >= =0A> > >=0A> > > On Wednesday, June 30, 2021 8:12pm, "Dave Taht"=0A> > said:=0A> > >=0A> > > > The pr= ogram committee members are *amazing*. Perhaps, finally,=0A> we can=0A> > >= > move the bar for the internet's quality metrics past endless,=0A> blind= =0A> > > > repetitions of speedtest.=0A> > > >=0A> > > > For complete detai= ls, please see:=0A> > > > https://www.iab.org/activities/workshops/network-= quality/=0A> =0A= > > > >=0A> > > > Submissions Due: Monday 2nd August 2021, midnight AOE=0A>= (Anywhere On Earth)=0A> > > > Invitations Issued by: Monday 16th August 20= 21=0A> > > >=0A> > > > Workshop Date: This will be a virtual workshop, spre= ad over=0A> three days:=0A> > > >=0A> > > > 1400-1800 UTC Tue 14th Septembe= r 2021=0A> > > > 1400-1800 UTC Wed 15th September 2021=0A> > > > 1400-1800 = UTC Thu 16th September 2021=0A> > > >=0A> > > > Workshop co-chairs: Wes Har= daker, Evgeny Khorov, Omer Shapira=0A> > > >=0A> > > > The Program Committe= e members:=0A> > > >=0A> > > > Jari Arkko, Olivier Bonaventure, Vint Cerf, = Stuart Cheshire,=0A> Sam=0A> > > > Crowford, Nick Feamster, Jim Gettys, Tok= e Hoiland-Jorgensen,=0A> Geoff=0A> > > > Huston, Cullen Jennings, Katarzyna= Kosek-Szott, Mirja=0A> Kuehlewind,=0A> > > > Jason Livingood, Matt Mathias= , Randall Meyer, Kathleen=0A> Nichols,=0A> > > > Christoph Paasch, Tommy Pa= uly, Greg White, Keith Winstein.=0A> > > >=0A> > > > Send Submissions to: n= etwork-quality-workshop-pc@iab.org=0A> .=0A> > > >=0A> > > > Position papers from academia, industry, the = open source=0A> community and=0A> > > > others that focus on measurements, = experiences, observations=0A> and=0A> > > > advice for the future are welco= me. Papers that reflect=0A> experience=0A> > > > based on deployed services= are especially welcome. The=0A> organizers=0A> > > > understand that speci= fic actions taken by operators are=0A> unlikely to be=0A> > > > discussed i= n detail, so papers discussing general categories=0A> of=0A> > > > actions = and issues without naming specific technologies,=0A> products, or=0A> > > >= other players in the ecosystem are expected. Papers should not=0A> focus= =0A> > > > on specific protocol solutions.=0A> > > >=0A> > > > The workshop= will be by invitation only. Those wishing to=0A> attend=0A> > > > should s= ubmit a position paper to the address above; it may=0A> take the=0A> > > > = form of an Internet-Draft.=0A> > > >=0A> > > > All inputs submitted and con= sidered relevant will be published=0A> on the=0A> > > > workshop website. T= he organisers will decide whom to invite=0A> based on=0A> > > > the submiss= ions received. Sessions will be organized according=0A> to=0A> > > > conten= t, and not every accepted submission or invited attendee=0A> will=0A> > > >= have an opportunity to present as the intent is to foster=0A> discussion= =0A> > > > and not simply to have a sequence of presentations.=0A> > > >=0A= > > > > Position papers from those not planning to attend the virtual=0A> s= essions=0A> > > > themselves are also encouraged. A workshop report will be= =0A> published=0A> > > > afterwards.=0A> > > >=0A> > > > Overview:=0A> > > = >=0A> > > > "We believe that one of the major factors behind this lack of= =0A> progress=0A> > > > is the popular perception that throughput is the of= ten sole=0A> measure of=0A> > > > the quality of Internet connectivity. Wit= h such narrow focus,=0A> people=0A> > > > don=E2=80=99t consider questions = such as:=0A> > > >=0A> > > > What is the latency under typical working cond= itions?=0A> > > > How reliable is the connectivity across longer time perio= ds?=0A> > > > Does the network allow the use of a broad range of protocols?= =0A> > > > What services can be run by clients of the network?=0A> > > > Wh= at kind of IPv4, NAT or IPv6 connectivity is offered, and=0A> are there fir= ewalls?=0A> > > > What security mechanisms are available for local services= ,=0A> such as DNS?=0A> > > > To what degree are the privacy, confidentialit= y, integrity=0A> and=0A> > > > authenticity of user communications guarded?= =0A> > > >=0A> > > > Improving these aspects of network quality will likely= depend=0A> on=0A> > > > measurement and exposing metrics to all involved p= arties,=0A> including to=0A> > > > end users in a meaningful way. Such meas= urements and exposure=0A> of the=0A> > > > right metrics will allow service= providers and network=0A> operators to=0A> > > > focus on the aspects that= impacts the users=E2=80=99 experience=0A> most and at=0A> > > > the same t= ime empowers users to choose the Internet service=0A> that will=0A> > > > g= ive them the best experience."=0A> > > >=0A> > > >=0A> > > > --=0A> > > > L= atest Podcast:=0A> > > >=0A> https://www.linkedin.com/feed/update/urn:li:ac= tivity:6791014284936785920/=0A> =0A> > > >=0A> > > > Dave T=C3=A4ht CTO, Te= kLibre, LLC=0A> > > > _______________________________________________=0A> >= > > Cerowrt-devel mailing list=0A> > > > Cerowrt-devel@lists.bufferbloat.n= et=0A> =0A> > > > https://lists= .bufferbloat.net/listinfo/cerowrt-devel=0A> =0A> > > >=0A> >=0A> >=0A> >=0A> > --=0A> > Latest P= odcast:=0A> > https://www.linkedin.com/feed/update/urn:li:activity:67910142= 84936785920/=0A> =0A> >=0A> > Dave T=C3=A4ht CTO, TekLibre, LLC=0A> > _____= __________________________________________=0A> > Make-wifi-fast mailing lis= t=0A> > Make-wifi-fast@lists.bufferbloat.net=0A> =0A> > https://lists.bufferbloat.net/listinfo/make-wifi-= fast=0A> =0A> >=0A> = >=0A> > This electronic communication and the information and any files tra= nsmitted=0A> with it, or attached to it, are confidential and are intended = solely for the use=0A> of=0A> > the individual or entity to whom it is addr= essed and may contain information=0A> that is confidential, legally privile= ged, protected by privacy laws, or otherwise=0A> > restricted from disclosu= re to anyone else. If you are not the intended=0A> recipient or the person = responsible for delivering the e-mail to the intended=0A> recipient,=0A> > = you are hereby notified that any use, copying, distributing, dissemination,= =0A> forwarding, printing, or copying of this e-mail is strictly prohibited= . If you=0A> > received this e-mail in error, please return the e-mail to t= he sender, delete=0A> it from your computer, and destroy any printed copy o= f it.=0A> >=0A> > _______________________________________________=0A> > Sta= rlink mailing list=0A> > Starlink@lists.bufferbloat.net=0A> > https://lists= .bufferbloat.net/listinfo/starlink=0A> >=0A> =0A> =0A> --=0A> Ben Greear =0A> Candela Technologies Inc http://www.candelatech= .com=0A> ------=_20210708153800000000_10844 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I will tell you flat o= ut that the arrival time distribution assumption made by Little's Lemma tha= t allows "estimation of queue depth" is totally unreasonable on ANY Interne= t in practice.

=0A

 

=0A

The assumption is a Poisson Arrival Process. In reality, traffic arrivals = in real internet applications are extremely far from Poisson, and, of cours= e, using TCP windowing, become highly intercorrelated with crossing traffic= that shares the same queue.

=0A

 

=0A

So, as I've tried to tell many, many net-heads (people who i= gnore applications layer behavior, like the people that think latency doesn= 't matter to end users, only throughput), end-to-end packet arrival times o= n a practical network are incredibly far from Poisson - and they are more l= ike fractal probability distributions, very irregular at all scales of time= .

=0A

 

=0A

So, the idea= that iperf can estimate queue depth by Little's Lemma by just measuring sa= turation of capacity of a path is bogus.The less Poisson, the worse the est= imate gets, by a huge factor.

=0A

 

=0A

 

=0A

Where does the Poisson as= sumption come from?  Well, like many theorems, it is the simplest trac= table closed form solution - it creates a simplified view, by being a "sing= le-parameter" distribution (the parameter is called lambda for a Poisson di= stribution).  And the analysis of a simple queue with poisson arrival = distribution and a static, fixed service time is the first interesting Queu= eing Theory example in most textbooks. It is suggestive of an interesting p= henomenon, but it does NOT characterize any real system.

=0A

 

=0A

It's the queueing theory equival= ent of "First, we assume a spherical cow...". in doing an example in a fres= hman physics class.

=0A

 

=0A

Unfortunately, most networking engineers understand neither queuing t= heory nor application networking usage in interactive applications. Which m= akes them arrogant. They assume all distributions are poisson!

=0A

 

=0A

 

=0A

On Tuesday, July 6, 2021 9:46am, "Ben Greear" <greearb@candelate= ch.com> said:

=0A
=0A

> Hello,
>
> I am interested to hear w= ish lists for network testing features. We make test
> equipment, s= upporting lots
> of wifi stations and a distributed architecture, w= ith built-in udp, tcp, ipv6,
> http, ... protocols,
> and o= pen 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 ide= as.
>
> Thanks,
> Ben
>
> On 7/2/= 21 4:28 PM, Bob McMahon wrote:
> > I think we need the language&= nbsp;of math here. It seems like the network
> power metric, introd= uced by Kleinrock and Jaffe in the late 70s, is something
> us= eful.
> > Effective end/end queue depths per Little's law also s= eems useful. Both are
> available in iperf 2 from a test perspectiv= e. Repurposing test techniques to
> actual
> > traffic c= ould be useful. Hence the question around what exact telemetry
&g= t; is useful to apps making socket write() and read() calls.
> >=
> > Bob
> >
> > On Fri, Jul 2, 2021 at 10= :07 AM Dave Taht <dave.taht@gmail.com
> <mailto:dave.taht@gma= il.com>> wrote:
> >
> > In terms of trying to f= ind "Quality" I have tried to encourage folk to
> > both read "z= en and the art of motorcycle maintenance"[0], and Deming's
> > w= ork on "total quality management".
> >
> > My own sli= ce 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<= br />> > caching, prefetching, and learning more about what a user re= ally needs
> > (as opposed to wants) to know via intelligent age= nts.
> >
> > [0] If you want to get depressed, read P= irsig'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/
&g= t; <https://www.internetsociety.org/events/latency2013/>
> &g= t;
> >
> >
> > On Thu, Jul 1, 2021 at 6:16= PM David P. Reed <dpreed@deepplum.com
> <mailto:dpreed@deepp= lum.com>> wrote:
> > >
> > > Well, nice t= hat 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.> > >
> > >
> > >
> > &= gt; 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 n= ow and in the future,
> and the fact that we DON'T KNOW what will b= e 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 s= aw this issue in 1976 in the group developing the original
> Intern= et protocols - a desire to put *into the network* special tricks to optimiz= e
> ASR33
> > logins to remote computers from terminal c= oncentrators (aka remote
> login), bulk file transfers between file= systems on different time-sharing
> systems, and
> > "s= essions" (virtual circuits) that required logins. And then trying to
&= gt; exploit underlying "multicast" by building it into the IP layer, becaus= e someone
> > thought that TV broadcast would be the dominant ap= plication.
> > >
> > >
> > >
> > > Frankly, to think of "quality" as something that can be "pr= ovided"
> by "the network" misses the entire point of "end-to-end a= rgument in system
> design".
> > Quality is not a proper= ty defined or created by The Network. If you want
> to talk about Q= uality, 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 do= n't
> bother to include current and future users talking about what= they might expect
> to
> > experience that they don't e= xperience.
> > >
> > >
> > >
> > > There was much fighting back in 1976 that basically involve= d
> "network experts" saying that the network was the place to "sol= ve" such issues as
> quality,
> > so applications could = avoid having to solve such issues.
> > >
> > ><= br />> > >
> > > What some of us managed to do was t= o argue that you can't "solve"
> such issues. All you can do is pro= vide a framework that enables different uses to
> > *cooperate* = in some way.
> > >
> > >
> > >> > > Which is why the Internet drops packets rather than queue= ing 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 specif= ic metrics, but
> never, ever
> > explains what the diff= serv control points actually do w.r.t. what the IP
> layer can actu= ally control. So it is meaningless - another violation of the
> >= ; so-called end-to-end principle).
> > >
> > ><= br />> > >
> > > Networks are about getting packets = from here to there, multiplexing
> the underlying resources. That's= it. Quality is a whole different thing. Quality
> can
> &g= t; 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 ap= plications to
> > affect queueing and routing decisions, and mor= e importantly getting
> "telemetry" from the network regarding what= is actually going on with the other
> > end-to-end users sharin= g the infrastructure.
> > >
> > >
> >= ; >
> > > This conference won't talk about it this way. So= don't waste your
> time.
> > >
> > >> > >
> > >
> > >
> > &= gt;
> > >
> > > On Wednesday, June 30, 2021 8:1= 2pm, "Dave Taht"
> <dave.taht@gmail.com <mailto:dave.taht@gma= il.com>> said:
> > >
> > > > The progr= am committee members are *amazing*. Perhaps, finally,
> we can
> > > > move the bar for the internet's quality metrics past e= ndless,
> blind
> > > > repetitions of speedtest.<= br />> > > >
> > > > For complete details, ple= ase see:
> > > > https://www.iab.org/activities/workshops/= network-quality/
> <https://www.iab.org/activities/workshops/net= work-quality/>
> > > >
> > > > Submiss= ions Due: Monday 2nd August 2021, midnight AOE
> (Anywhere On Earth= )
> > > > Invitations Issued by: Monday 16th August 2021> > > >
> > > > Workshop Date: This will b= e a virtual workshop, spread over
> three days:
> > >= >
> > > > 1400-1800 UTC Tue 14th September 2021
&= gt; > > > 1400-1800 UTC Wed 15th September 2021
> > >= ; > 1400-1800 UTC Thu 16th September 2021
> > > >
= > > > > Workshop co-chairs: Wes Hardaker, Evgeny Khorov, Omer S= hapira
> > > >
> > > > The Program Commit= tee members:
> > > >
> > > > Jari Arkko, = Olivier Bonaventure, Vint Cerf, Stuart Cheshire,
> Sam
> &g= t; > > Crowford, Nick Feamster, Jim Gettys, Toke Hoiland-Jorgensen,> Geoff
> > > > Huston, Cullen Jennings, Katarzyna = Kosek-Szott, Mirja
> Kuehlewind,
> > > > Jason Liv= ingood, Matt Mathias, Randall Meyer, Kathleen
> Nichols,
> = > > > Christoph Paasch, Tommy Pauly, Greg White, Keith Winstein.> > > >
> > > > Send Submissions to: netwo= rk-quality-workshop-pc@iab.org
> <mailto:network-quality-worksho= p-pc@iab.org>.
> > > >
> > > > Positio= n papers from academia, industry, the open source
> community and> > > > others that focus on measurements, experiences, obs= ervations
> 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 operato= rs are
> unlikely to be
> > > > discussed in detai= l, so papers discussing general categories
> of
> > >= > actions and issues without naming specific technologies,
> pr= oducts, or
> > > > other players in the ecosystem are expe= cted. Papers should not
> focus
> > > > on specifi= c 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-Draf= t.
> > > >
> > > > All inputs submitted a= nd considered relevant will be published
> on the
> > &g= t; > workshop website. The organisers will decide whom to invite
&g= t; based on
> > > > the submissions received. Sessions wil= l 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 seque= nce of presentations.
> > > >
> > > > Pos= ition papers from those not planning to attend the virtual
> sessio= ns
> > > > themselves are also encouraged. A workshop repo= rt will be
> published
> > > > afterwards.
&g= t; > > >
> > > > Overview:
> > > &g= t;
> > > > "We believe that one of the major factors behin= d this lack of
> progress
> > > > is the popular p= erception that throughput is the often sole
> measure of
> = > > > the quality of Internet connectivity. With such narrow focus= ,
> people
> > > > don=E2=80=99t consider question= s such as:
> > > >
> > > > What is the la= tency under typical working conditions?
> > > > How reliab= le is the connectivity across longer time periods?
> > > >= Does the network allow the use of a broad range of protocols?
> &g= t; > > What services can be run by clients of the network?
> = > > > What kind of IPv4, NAT or IPv6 connectivity is offered, and<= br />> are there firewalls?
> > > > What security mecha= nisms are available for local services,
> such as DNS?
> &g= t; > > To what degree are the privacy, confidentiality, integrity
> and
> > > > authenticity of user communications gua= rded?
> > > >
> > > > Improving these asp= ects of network quality will likely depend
> on
> > >= > measurement and exposing metrics to all involved parties,
> i= ncluding to
> > > > end users in a meaningful way. Such me= asurements and exposure
> of the
> > > > right met= rics will allow service providers and network
> operators to
&= gt; > > > focus on the aspects that impacts the users=E2=80=99 exp= erience
> most and at
> > > > the same time empowe= rs users to choose the Internet service
> that will
> > = > > give them the best experience."
> > > >
>= ; > > >
> > > > --
> > > > Lates= t Podcast:
> > > >
> https://www.linkedin.com/feed= /update/urn:li:activity:6791014284936785920/
> <https://www.link= edin.com/feed/update/urn:li:activity:6791014284936785920/>
> >= ; > >
> > > > Dave T=C3=A4ht CTO, TekLibre, LLC
> > > > _______________________________________________
&= gt; > > > Cerowrt-devel mailing list
> > > > Cero= wrt-devel@lists.bufferbloat.net
> <mailto:Cerowrt-devel@lists.bu= fferbloat.net>
> > > > https://lists.bufferbloat.net/li= stinfo/cerowrt-devel
> <https://lists.bufferbloat.net/listinfo/c= erowrt-devel>
> > > >
> >
> >
> >
> > --
> > Latest Podcast:
> >= https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/<= br />> <https://www.linkedin.com/feed/update/urn:li:activity:67910142= 84936785920/>
> >
> > Dave T=C3=A4ht CTO, TekLibre= , LLC
> > _______________________________________________
&= gt; > Make-wifi-fast mailing list
> > Make-wifi-fast@lists.bu= fferbloat.net
> <mailto:Make-wifi-fast@lists.bufferbloat.net>=
> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
= > <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 inf= ormation
> that is confidential, legally privileged, protected by p= rivacy laws, or otherwise
> > restricted from disclosure to anyo= ne else. If you are not the intended
> recipient or the person resp= onsible for delivering the e-mail to the intended
> recipient,
> > you are hereby notified that any use, copying, distributing, dis= semination,
> forwarding, printing, or copying of this e-mail is st= rictly prohibited. If you
> > received this e-mail in error, ple= ase return the e-mail to the sender, delete
> it from your computer= , and destroy any printed copy of it.
> >
> > _______= ________________________________________
> > Starlink mailing li= st
> > Starlink@lists.bufferbloat.net
> > https://lis= ts.bufferbloat.net/listinfo/starlink
> >
>
> > --
> Ben Greear <greearb@candelatech.com>
> = Candela Technologies Inc http://www.candelatech.com
>

=0A
= ------=_20210708153800000000_10844--