From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 163023CB4C for ; Thu, 8 Jul 2021 18:51:37 -0400 (EDT) Received: by mail-ej1-x629.google.com with SMTP id gb6so12495642ejc.5 for ; Thu, 08 Jul 2021 15:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ml9N6nEt1kFg6QEGCNmjxM3B+81NmprEToW1dF3+BT0=; b=UR3ynbI3cWcW22kOmRcJhlkO5LqBA/zrD4+12ElOrEjdOIqXGm6/UyHa5xOaighsnb q8BmuAW+Gx7XxckUblipb3IMI9kWw2jKjTETMnq7SRu4yYL1Zt7YvOkf6ZbbYlHVEShq I1dpaMVYST9LUYng1GvCZ0yxoPufyoH+c8d4I= 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; bh=ml9N6nEt1kFg6QEGCNmjxM3B+81NmprEToW1dF3+BT0=; b=HGVg4f7syrcvNfl3LFLWNW/On1IGvlEMfa2nx3urpDW41pP978INyUOg/QqYTS/c77 MAYCTnjWE+eN4d/83RSwyYQtFOMb+HEL6vqPoOksZtAhtIlTqQ/mutnu0hEwk0554gx0 0D1/si+7mWZCa0JWEM8oOjKdOR+YlXXq8OEZDZwAtWhLNWqKLROy81R5HNSIAglLQQG3 ZEG0VO3ExrO5J5ez9xUrTIVrrteehSE7wYxYRda2L+WDDysFq0Dauv79JlohI5ZQqWxS /eOTLw9K9GoE0XNwrXOHzW74Xbvqk/EHEKsUwCcjNyQ++EWpLkl9BArkLmxntOEuuph0 r0cQ== X-Gm-Message-State: AOAM531Cxp4+PYZGErFJrJWqr/lg3yTZ/Fxiy2CbbQc8PT0N02Ck/jav kDrtQReDK3N9KilBNthbPQV/f92HofvZ7/Bz2LfhjFL6kv3q5334s4ibLiJwrXp2Bke4LTlX3cN ItkN5YqKJq71Gcpm0RuoByhAvKRxi3+agPmCFvo4T X-Google-Smtp-Source: ABdhPJy3lMMdQlaGVovHuqrT1bhes9KNmCjcyKi1qFMDyzbllEYVPFELyXwGf0I51ydVFpCRg0U43PYcY1HvjrK7uk8= X-Received: by 2002:a17:906:7950:: with SMTP id l16mr21969832ejo.400.1625784695323; Thu, 08 Jul 2021 15:51:35 -0700 (PDT) MIME-Version: 1.0 References: <1625188609.32718319@apps.rackspace.com> <989de0c1-e06c-cda9-ebe6-1f33df8a4c24@candelatech.com> <1625773080.94974089@apps.rackspace.com> In-Reply-To: <1625773080.94974089@apps.rackspace.com> From: Bob McMahon Date: Thu, 8 Jul 2021 15:51:24 -0700 Message-ID: Subject: Re: [Starlink] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board To: "David P. Reed" Cc: Ben Greear , Dave Taht , starlink@lists.bufferbloat.net, Make-Wifi-fast , Cake List , codel@lists.bufferbloat.net, cerowrt-devel , bloat Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000047481a05c6a47f40" X-List-Received-Date: Thu, 08 Jul 2021 22:51:37 -0000 --00000000000047481a05c6a47f40 Content-Type: multipart/alternative; boundary="000000000000401a4105c6a47f7b" --000000000000401a4105c6a47f7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks very much for this response. I need to dig in a bit more for sure. iperf 2 will give every UDP packet's OWD (if the clocks are sync'd) and will also provide TCP write to read latencies, both supported in histogram forms. So that's raw samples so to speak. I'm hooking up some units across geography including across the Pacific (sync'd to GPS atomic time) to see how "fractal" these distributions look, at least anecdotally. On top of all the "spherical cow queueing theory" (which made me laugh,) we've got bluetooth sometimes sharing the radio. So the transport latency of TCP writes can be all over the map so-to-speak. And bluetooth traffic is also highly correlated. Bob On Thu, Jul 8, 2021 at 12:38 PM David P. Reed wrote: > I will tell you flat out that the arrival time distribution assumption > made by Little's Lemma that allows "estimation of queue depth" is totally > unreasonable on ANY Internet in practice. > > > > The assumption is a Poisson Arrival 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. > > > > So, as I've tried to tell many, many net-heads (people who ignore > applications layer behavior, like the people that think latency doesn't > matter to end users, only throughput), end-to-end packet arrival times on= a > practical network are incredibly far from Poisson - and they are more lik= e > fractal probability distributions, very irregular at all scales of time. > > > > So, the idea that iperf can estimate queue depth by Little's Lemma by jus= t > measuring saturation of capacity of a path is bogus.The less Poisson, the > worse the estimate gets, by a huge factor. > > > > > > Where does the Poisson assumption come from? Well, like many theorems, i= t > is the simplest tractable closed form solution - it creates a simplified > view, by being a "single-parameter" distribution (the parameter is called > lambda for a Poisson distribution). And the analysis of a simple queue > with poisson arrival distribution and a static, fixed service time is the > first interesting Queueing Theory example in most textbooks. It is > suggestive of an interesting phenomenon, but it does NOT characterize any > real system. > > > > It's the queueing theory equivalent of "First, we assume a spherical > cow...". in doing an example in a freshman physics class. > > > > Unfortunately, most networking engineers understand neither queuing theor= y > nor application networking usage in interactive applications. Which makes > them arrogant. They assume all distributions are poisson! > > > > > > On Tuesday, July 6, 2021 9:46am, "Ben Greear" > said: > > > Hello, > > > > I am interested to hear wish lists for network testing features. We mak= e > 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 telemet= ry > > 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 t= o > > > 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 aimin= g > > > 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 need= s > > > (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 b= e > 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 t= o > > 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 "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 migh= t > 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=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 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=E2=80=99 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/ > > < > https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/= > > > > > > > > > > > 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/ > > < > https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/= > > > > > > > Dave T=C3=A4ht 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 fo= r > 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 intende= d > > 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 > > > --=20 This electronic communication and the information and any files transmitted= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --000000000000401a4105c6a47f7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks very much for this response. I need to dig in a bit= more for sure.

iperf 2 will give every UDP packet's OWD (if the= clocks are sync'd) and will also provide TCP write to read latencies, = both supported in histogram forms. So that's raw samples so to speak. I= 'm hooking up some units across geography including across the Pacific = (sync'd to GPS atomic time) to see how "fractal" these distri= butions look, at least anecdotally.

On top of all the "spherica= l cow queueing theory" (which made me laugh,) we've got bluetooth = sometimes sharing the radio. So the transport latency of TCP=C2=A0writes ca= n be all over the map so-to-speak. And bluetooth traffic is also highly cor= related.

Bob




On Thu, Jul 8, 2021 at 12:38 PM David P.= Reed <dpreed@deepplum.com>= ; wrote:

I will tell you flat out that the arrival time distribut= ion assumption made by Little's Lemma that allows "estimation of q= ueue depth" is totally unreasonable on ANY Internet in practice.

=C2=A0=

The as= sumption is a Poisson Arrival Process. In reality, traffic arrivals in real= internet applications are extremely far from Poisson, and, of course, usin= g TCP windowing, become highly intercorrelated with crossing traffic that s= hares the same queue.

=C2=A0=

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

=C2=A0=

So, th= e idea that iperf can estimate queue depth by Little's Lemma by just me= asuring saturation of capacity of a path is bogus.The less Poisson, the wor= se the estimate gets, by a huge factor.

=C2=A0=

=C2=A0=

Where = does the Poisson assumption come from?=C2=A0 Well, like many theorems, it i= s the simplest tractable closed form solution - it creates a simplified vie= w, by being a "single-parameter" distribution (the parameter is c= alled lambda for a Poisson distribution).=C2=A0 And the analysis of a simpl= e queue with poisson arrival distribution and a static, fixed service time = is the first interesting Queueing Theory example in most textbooks. It is s= uggestive of an interesting phenomenon, but it does NOT characterize any re= al system.

=C2=A0=

It'= ;s the queueing theory equivalent of "First, we assume a spherical cow= ...". in doing an example in a freshman physics class.

=C2=A0=

Unfort= unately, most networking engineers understand neither queuing theory nor ap= plication networking usage in interactive applications. Which makes them ar= rogant. They assume all distributions are poisson!

=C2=A0=

=C2=A0=

On Tue= sday, July 6, 2021 9:46am, "Ben Greear" <greearb@candelatech.com> sai= d:

> H= ello,
>
> I am interested to hear wish lists for network testi= ng features. We make test
> equipment, supporting lots
> of wif= i stations and a distributed architecture, with built-in udp, tcp, ipv6,> http, ... protocols,
> and open to creating/improving some of o= ur automated tests.
>
> I know Dave has some test scripts alre= ady, so I'm not necessarily looking to
> reimplement that,
>= ; but more fishing for other/new ideas.
>
> Thanks,
> Be= n
>
> On 7/2/21 4:28 PM, Bob McMahon wrote:
> > I thi= nk we need the language=C2=A0of math here. It seems like the network
>= ; power metric, introduced by Kleinrock and=C2=A0Jaffe in the late 70s, is = something
> useful.
> > Effective end/end queue depths per L= ittle's law also seems useful. Both are
> available in iperf 2 fr= om a test perspective. Repurposing test techniques to
> actual
>= ; > traffic could be useful. Hence=C2=A0the question around what exact t= elemetry
> is useful to apps making socket write() and read() calls.<= br>> >
> > Bob
> >
> > On Fri, Jul 2, 2021= at 10:07 AM Dave Taht <dave.taht@gmail.com
> <mailto:dave.taht@gmail.com>> wrote:> >
> > In terms of trying to find "Quality" I ha= ve tried to encourage folk to
> > both read "zen and the art = of motorcycle maintenance"[0], and Deming's
> > work on &= quot;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 q= ueuing delay, but
> > caching, prefetching, and learning more abou= t what a user really needs
> > (as opposed to wants) to know via i= ntelligent agents.
> >
> > [0] If you want to get depress= ed, read Pirsig's successor to "zen...",
> > lila, w= hich is in part about what happens when an engineer hits an
> > in= soluble problem.
> > [1] https://www.internetsociety.org/ev= ents/latency2013/
> <https://www.internetsociety.org/ev= ents/latency2013/>
> >
> >
> >
> &g= t; On Thu, Jul 1, 2021 at 6:16 PM David P. Reed <dpreed@deepplum.com
> <mailt= o:dpreed@deepplum.= com>> wrote:
> > >
> > > Well, nice that = the folks doing the conference=C2=A0 are willing to
> consider that q= uality 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"
> sug= gests that they REALLY, REALLY don't understand the Internet isn't = the hardware
> or
> > the routers or even the routing algori= thms *to its users*.
> > >
> > >
> > ><= br>> > > 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 th= at 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 t= he group developing the original
> Internet protocols - a desire to p= ut *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 "m= ulticast" by building it into the IP layer, because someone
> &g= t; thought that TV broadcast would be the dominant application.
> >= ; >
> > >
> > >
> > > Frankly, to th= ink of "quality" as something that can be "provided"> by "the network" misses the entire point of "end-to-en= d argument in system
> design".
> > Quality is not a pr= operty 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 i= f you don't
> bother to include current and future users talking = about what they might expect
> to
> > experience that they d= on't experience.
> > >
> > >
> > ><= br>> > > There was much fighting back in 1976 that basically invol= ved
> "network experts" saying that the network was the pla= ce to "solve" such issues as
> quality,
> > so app= lications could avoid having to solve such issues.
> > >
>= ; > >
> > >
> > > What some of us managed to = do was to argue that you can't "solve"
> such issues. A= ll 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 spec= ific metrics, but
> never, ever
> > explains what the diffse= rv control points actually do w.r.t. what the IP
> layer can actually= control. So it is meaningless - another violation of the
> > so-c= alled end-to-end principle).
> > >
> > >
> &g= t; >
> > > Networks are about getting packets from here to t= here, multiplexing
> the underlying resources. That's it. Quality= is a whole different thing. Quality
> can
> > be improved b= y end-to-end approaches, if the underlying network provides
> some ki= nd of thing that actually creates a way for end-to-end applications to
&= gt; > 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 infrastr= ucture.
> > >
> > >
> > >
> > = > This conference won't talk about it this way. So don't waste y= our
> time.
> > >
> > >
> > >
= > > >
> > >
> > >
> > >
>= ; > > On Wednesday, June 30, 2021 8:12pm, "Dave Taht"
&g= t; <dave.taht@g= mail.com <mailto:dave.taht@gmail.com>> said:
> > >
> > = > > The program committee members are *amazing*. Perhaps, finally,> we can
> > > > move the bar for the internet's qua= lity metrics past endless,
> blind
> > > > repetitions= of speedtest.
> > > >
> > > > For complete d= etails, please see:
> > > > https://www.iab.org= /activities/workshops/network-quality/
> <https:/= /www.iab.org/activities/workshops/network-quality/>
> > >= ; >
> > > > Submissions Due: Monday 2nd August 2021, midn= ight AOE
> (Anywhere On Earth)
> > > > Invitations Iss= ued by: Monday 16th August 2021
> > > >
> > > &g= t; Workshop Date: This will be a virtual workshop, spread over
> thre= e days:
> > > >
> > > > 1400-1800 UTC Tue 14t= h September 2021
> > > > 1400-1800 UTC Wed 15th September 20= 21
> > > > 1400-1800 UTC Thu 16th September 2021
> >= ; > >
> > > > Workshop co-chairs: Wes Hardaker, Evgeny= Khorov, Omer Shapira
> > > >
> > > > The Pro= gram Committee members:
> > > >
> > > > Jari = Arkko, Olivier Bonaventure, Vint Cerf, Stuart Cheshire,
> Sam
>= > > > Crowford, Nick Feamster, Jim Gettys, Toke Hoiland-Jorgensen= ,
> Geoff
> > > > Huston, Cullen Jennings, Katarzyna K= osek-Szott, Mirja
> Kuehlewind,
> > > > Jason Livingoo= d, Matt Mathias, Randall Meyer, Kathleen
> Nichols,
> > >= > Christoph Paasch, Tommy Pauly, Greg White, Keith Winstein.
> &g= t; > >
> > > > Send Submissions to: network-quality-work= shop-pc@iab.org
> <mailto:network-quality-workshop-pc@iab.org>.
> > > >
> > > > Position papers from a= cademia, industry, the open source
> community and
> > > = > others that focus on measurements, experiences, observations
> a= nd
> > > > advice for the future are welcome. Papers that re= flect
> experience
> > > > based on deployed services = are especially welcome. The
> organizers
> > > > under= stand that specific actions taken by operators are
> unlikely to be> > > > discussed in detail, so papers discussing general cat= egories
> of
> > > > actions and issues without naming= specific technologies,
> products, or
> > > > other p= layers in the ecosystem are expected. Papers should not
> focus
&g= t; > > > 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
&g= t; discussion
> > > > and not simply to have a sequence of p= resentations.
> > > >
> > > > Position papers= from those not planning to attend the virtual
> sessions
> >= ; > > themselves are also encouraged. A workshop report will be
&g= t; published
> > > > afterwards.
> > > >
&= gt; > > > Overview:
> > > >
> > > > = "We believe that one of the major factors behind this lack of
> = progress
> > > > is the popular perception that throughput i= s the often sole
> measure of
> > > > the quality of I= nternet connectivity. With such narrow focus,
> people
> > &= gt; > 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 clie= nts of the network?
> > > > What kind of IPv4, NAT or IPv6 c= onnectivity is offered, and
> are there firewalls?
> > > = > What security mechanisms are available for local services,
> suc= h as DNS?
> > > > To what degree are the privacy, confidenti= ality, integrity
> and
> > > > authenticity of user co= mmunications guarded?
> > > >
> > > > Improvi= ng these aspects of network quality will likely depend
> on
> &= gt; > > measurement and exposing metrics to all involved parties,
= > including to
> > > > end users in a meaningful way. Suc= h measurements and exposure
> of the
> > > > right met= rics will allow service providers and network
> operators to
> = > > > focus on the aspects that impacts the users=E2=80=99 experie= nce
> most and at
> > > > the same time empowers users= to choose the Internet service
> that will
> > > > gi= ve them the best experience."
> > > >
> > >= >
> > > > --
> > > > Latest Podcast:
&= gt; > > >
> https://www.linkedi= n.com/feed/update/urn:li:activity:6791014284936785920/
> <https://www.linkedin.com/feed/update/urn:li:activi= ty:6791014284936785920/>
> > > >
> > > &g= t; Dave T=C3=A4ht CTO, TekLibre, LLC
> > > > _______________= ________________________________
> > > > Cerowrt-devel maili= ng list
> > > > Cerowrt-devel@lists.bufferbloat.net
>= ; <mailto:Cerowrt-devel@lists.bufferbloat.net>
> > > &= gt; https://lists.bufferbloat.net/listinfo/cerowrt-devel
>= ; <https://lists.bufferbloat.net/listinfo/cerowrt-devel><= br>> > > >
> >
> >
> >
> > = --
> > Latest Podcast:
> > h= ttps://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
> <https://www.linkedin.com/feed/up= date/urn:li:activity:6791014284936785920/>
> >
> >= Dave T=C3=A4ht CTO, TekLibre, LLC
> > ___________________________= ____________________
> > Make-wifi-fast mailing list
> > = M= ake-wifi-fast@lists.bufferbloat.net
> <mailto:Make-wifi-fast@li= sts.bufferbloat.net>
> > https://lists.bufferbloat= .net/listinfo/make-wifi-fast
> <https://lists.bufferb= loat.net/listinfo/make-wifi-fast>
> >
> >
> = > This electronic communication and the information and any files transm= itted
> with it, or attached to it, are confidential and are intended= solely for the use
> of
> > the individual or entity to who= m it is addressed and may contain information
> that is confidential,= legally privileged, protected by privacy laws, or otherwise
> > r= estricted from disclosure to anyone else. If you are not the intended
&g= t; recipient or the person responsible for delivering the e-mail to the int= ended
> recipient,
> > you are hereby notified that any use,= copying, distributing, dissemination,
> forwarding, printing, or cop= ying of this e-mail is strictly prohibited. If you
> > received th= is e-mail in error, please return the e-mail to the sender, delete
> = it from your computer, and destroy any printed copy of it.
> >
= > > _______________________________________________
> > Star= link mailing list
> > Starlink@lists.bufferbloat.net
> > = https://lists.bufferbloat.net/listinfo/starlink
> >
> >
> --
> Ben Greear <greearb@candelatech.com>
> Candela= Technologies Inc = http://www.candelatech.com
>


This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly 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. --000000000000401a4105c6a47f7b-- --00000000000047481a05c6a47f40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQagYJKoZIhvcNAQcCoIIQWzCCEFcCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg3BMIIFDTCCA/WgAwIBAgIQeEqpED+lv77edQixNJMdADANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yODA5MTYwMDAwMDBaMFsxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhHbG9iYWxTaWduIEdDQyBS MyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vbCmXCcsbZ/a0fRIQMBxp4gJnnyeneFYpEtNydrZZ+GeKSMdHiDgXD1UnRSIudKo+moQ6YlCOu4t rVWO/EiXfYnK7zeop26ry1RpKtogB7/O115zultAz64ydQYLe+a1e/czkALg3sgTcOOcFZTXk38e aqsXsipoX1vsNurqPtnC27TWsA7pk4uKXscFjkeUE8JZu9BDKaswZygxBOPBQBwrA5+20Wxlk6k1 e6EKaaNaNZUy30q3ArEf30ZDpXyfCtiXnupjSK8WU2cK4qsEtj09JS4+mhi0CTCrCnXAzum3tgcH cHRg0prcSzzEUDQWoFxyuqwiwhHu3sPQNmFOMwIDAQABo4IB2jCCAdYwDgYDVR0PAQH/BAQDAgGG MGAGA1UdJQRZMFcGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAgYKKwYBBAGCNwoDBAYJ KwYBBAGCNxUGBgorBgEEAYI3CgMMBggrBgEFBQcDBwYIKwYBBQUHAxEwEgYDVR0TAQH/BAgwBgEB /wIBADAdBgNVHQ4EFgQUljPR5lgXWzR1ioFWZNW+SN6hj88wHwYDVR0jBBgwFoAUj/BLf6guRSSu TVD6Y5qL3uLdG7wwegYIKwYBBQUHAQEEbjBsMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9i YWxzaWduLmNvbS9yb290cjMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5j b20vY2FjZXJ0L3Jvb3QtcjMuY3J0MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFs c2lnbi5jb20vcm9vdC1yMy5jcmwwWgYDVR0gBFMwUTALBgkrBgEEAaAyASgwQgYKKwYBBAGgMgEo CjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAN BgkqhkiG9w0BAQsFAAOCAQEAdAXk/XCnDeAOd9nNEUvWPxblOQ/5o/q6OIeTYvoEvUUi2qHUOtbf jBGdTptFsXXe4RgjVF9b6DuizgYfy+cILmvi5hfk3Iq8MAZsgtW+A/otQsJvK2wRatLE61RbzkX8 9/OXEZ1zT7t/q2RiJqzpvV8NChxIj+P7WTtepPm9AIj0Keue+gS2qvzAZAY34ZZeRHgA7g5O4TPJ /oTd+4rgiU++wLDlcZYd/slFkaT3xg4qWDepEMjT4T1qFOQIL+ijUArYS4owpPg9NISTKa1qqKWJ jFoyms0d0GwOniIIbBvhI2MJ7BSY9MYtWVT5jJO3tsVHwj4cp92CSFuGwunFMzCCA18wggJHoAMC AQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9v dCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5 MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENB IC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0E XyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+J J5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8u nPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTv riBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGj QjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5N UPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigH M8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmU Y/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V 14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcy a5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/ XzCCBUkwggQxoAMCAQICDBhL7k9eiTHfluW70TANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMg UGVyc29uYWxTaWduIDIgQ0EgMjAyMDAeFw0yMTAyMjIwNDQyMDRaFw0yMjA5MDEwODA5NDlaMIGM MQswCQYDVQQGEwJJTjESMBAGA1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxFjAU BgNVBAoTDUJyb2FkY29tIEluYy4xFDASBgNVBAMTC0JvYiBNY01haG9uMScwJQYJKoZIhvcNAQkB Fhhib2IubWNtYWhvbkBicm9hZGNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDyY95HWFm48WhKUyFbAS9JxiDqBHBdAbgjx4iF46lkqZdVkIJ8pGfcXoGd10Vp9yL5VQevDAt/ A/Jh22uhSgKR9Almeux9xWGhG8cyZwcCwYrsMt84FqCgEQidT+7YGNdd9oKrjU7mFC7pAnnw+cGI d3NFryurgnNPwfEK0X7HwRsga5pM+Zelr/ZM8MkphE1hCvTuPGakNylOFhP+wKL8Bmhsq5tNIInw DrPV5EPUikwiGMDmkX8o6roGiUwyqAp8dMZKJZ/vS/aWEELV+gm21Btr7eqdAWyqm09McVpkM4th v/FOYcj8DeJr8MXmHW53gN2fv0BzQjqAdrdCBPNRAgMBAAGjggHZMIIB1TAOBgNVHQ8BAf8EBAMC BaAwgaMGCCsGAQUFBwEBBIGWMIGTME4GCCsGAQUFBzAChkJodHRwOi8vc2VjdXJlLmdsb2JhbHNp Z24uY29tL2NhY2VydC9nc2djY3IzcGVyc29uYWxzaWduMmNhMjAyMC5jcnQwQQYIKwYBBQUHMAGG NWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2dzZ2NjcjNwZXJzb25hbHNpZ24yY2EyMDIwME0G A1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxz aWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1UdHwRCMEAwPqA8oDqGOGh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2NyM3BlcnNvbmFsc2lnbjJjYTIwMjAuY3JsMCMGA1UdEQQc MBqBGGJvYi5tY21haG9uQGJyb2FkY29tLmNvbTATBgNVHSUEDDAKBggrBgEFBQcDBDAfBgNVHSME GDAWgBSWM9HmWBdbNHWKgVZk1b5I3qGPzzAdBgNVHQ4EFgQUpyXYr5rh8cZzkns+zXmMG1YkBk4w DQYJKoZIhvcNAQELBQADggEBACfauRPak93nzbpn8UXqRZqg6iUZch/UfGj9flerMl4TlK5jWulz Y+rRg+iWkjiLk3O+kKu6GI8TLXB2rsoTnrHYij96Uad5/Ut3Q5F4S0ILgOWVU38l0VZIGGG0CzG1 eLUgN2zjLg++xJuzqijuKQCJb/3+il2MTJ8dcDaXuYcjg7Vt6+EtCBS1SGMVhOTH4Fp50yGWj8ZA bPF1uuJM+dGLJLheUizCr5J/OBEdENg+DSmrqoZ+kZd76iRaF2CkhboR2394Ft8lFlKQiU0q8lnR 9/kdZ0F0iCcUfhaLaGYWujW7N0LZ+rQuTfuPGLx9zZNeNMWSZi/Pc8vdCO7EnlIxggJtMIICaQIB ATBrMFsxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwAgwYS+5PXokx35blu9EwDQYJ YIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIEoCLFqz1wUYdezpKRsU6wCHlvjLjFojQtK9 BHQUHJjFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwODIy NTEzNVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFlAwQCATAN BgkqhkiG9w0BAQEFAASCAQCx9gakX6DPVcwEZShtmL5MQOmaLXWrNQz4BtVv1zLDOGRKr/yQmt6c 4foQlIsoYzWUAT1TBTWlsPcFPcXBWML7LQaLIcQKTfCkzDYfm2Kahf7aJbU4rXWLNTL4aRXhlEYt HHa1fYEVUOFo4HIiTYoEF7+ZZo89MeXD+hZztb02ZONZ5TQz2Xc1HIIrt/YpAUw8JK1WAsplwGlO 6nF61aZqSpTa2ZGQoHyORGyEZICzMWySDZoC1BCe7mmqmnpLtUgiZAye/ioDIjf4NETQtftn97gY JYICX1yJDu8bdIvEdoGGDzpDhZkTOleYjTQFHkUBJdGZPmWjxWIcNFABI7Tr --00000000000047481a05c6a47f40--