From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 A7A553B29D for ; Fri, 9 Jul 2021 06:05:23 -0400 (EDT) Received: by mail-wr1-x42b.google.com with SMTP id l7so10458742wrv.7 for ; Fri, 09 Jul 2021 03:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1lEyrO8+stXZYUSXvFHkbPEVqqhQ6kUVgLdoM7QTsEY=; b=coKlhwCeqUTi3de19mJ48bCnnyWmby+Pt1TEE1QZFFy3KTNkS+0/yRtxpEu65NrqYp pP/uYDCHKQyaLL0OutEDLQW6LNYVp+Lqi9T5mez3XpQjJJQWcUwP5wL5aEEemweRpbvo RhrCFCkx4+yoMSbrtDxnWzIGY5WGAmyXIHKE0= 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=1lEyrO8+stXZYUSXvFHkbPEVqqhQ6kUVgLdoM7QTsEY=; b=R7bMQU+X3YNcDTXXCuzoZUAtNu+gmZZwB6hdb1XtQkfAr4FQ9LlD9qkw7rYV3pzZDc Qm4n3Zq1989PrMBwPraDrQNpKyxEnQrQJuBOvR2aez/JAmXq1iSTRhjkoRau7Ps9D7rn w0mo61mEaFrNrV/In/qMswJE0YbB41a0yaBPfF9PYV2Ohv4EWnnrYbGl5zpObolHkdw7 BrtSWTuL5tF5XA0yexWtj/9vlEXGQRwBP5WXnJ7O05kk1Bd4oQb30kzCleo/Farzp4zJ IjCYB3SVAJ6BGMomvp+zw9FHZ/6EEO5FeLR4le+WSZOEIZePCmhWvVHZgdzBwX+9Hsgl kdcg== X-Gm-Message-State: AOAM531ePIGjxexbZ+y06mi6MI0WIg5iCP8EFlc6ncXWU3qm/XwzGrkC 1FcFhGYlDfiqnt1WZCOHGfv9YnR0O6yDCJ9KP6rlMw== X-Google-Smtp-Source: ABdhPJwEYofd+qLZVPEGZQX8pxu1wLljHpEJW9SNc4dTWUSg5nZAPkJ4LMSTDBKYAQB9e2z/rDdS1t/+Svcbi6LhFG8= X-Received: by 2002:a5d:400c:: with SMTP id n12mr953525wrp.257.1625825122475; Fri, 09 Jul 2021 03:05:22 -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: From: Luca Muscariello Date: Fri, 9 Jul 2021 12:05:11 +0200 Message-ID: To: Leonard Kleinrock Cc: "David P. Reed" , starlink@lists.bufferbloat.net, Make-Wifi-fast , Bob McMahon , Cake List , codel@lists.bufferbloat.net, cerowrt-devel , bloat , Ben Greear Content-Type: multipart/alternative; boundary="000000000000e4cd8505c6ade81b" X-Mailman-Approved-At: Fri, 09 Jul 2021 06:25:19 -0400 Subject: Re: [Cerowrt-devel] [Make-wifi-fast] [Starlink] 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, 09 Jul 2021 10:05:24 -0000 --000000000000e4cd8505c6ade81b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For those who might be interested in Little's law there is a nice paper by John Little on the occasion of the 50th anniversary of the result. https://www.informs.org/Blogs/Operations-Research-Forum/Little-s-Law-as-Vie= wed-on-its-50th-Anniversary https://www.informs.org/content/download/255808/2414681/file/little_paper.p= df Nice read. Luca P.S. Who has not a copy of L. Kleinrock's books? I do have and am not ready to lend them! On Fri, Jul 9, 2021 at 11:01 AM Leonard Kleinrock wrote: > David, > > I totally appreciate your attention to when and when not analytical > modeling works. Let me clarify a few things from your note. > > First, Little's law (also known as Little=E2=80=99s lemma or, as I use in= my book, > Little=E2=80=99s result) does not assume Poisson arrivals - it is good f= or *any* > arrival process and any service process and is an equality between time > averages. It states that the time average of the number in a system (for= a > sample path *w)* is equal to the average arrival rate to the system > multiplied by the time-averaged time in the system for that sample path. > This is often written as NTimeAvg =3D=CE=BB=C2=B7TTimeAvg . Moreover, = if the > system is also ergodic, then the time average equals the ensemble average > and we often write it as N =CC=84 =3D =CE=BB T =CC=84 . In any case, thi= s requires > neither Poisson arrivals nor exponential service times. > > Queueing theorists often do study the case of Poisson arrivals. True, it > makes the analysis easier, yet there is a better reason it is often used, > and that is because the sum of a large number of independent stationary > renewal processes approaches a Poisson process. So nature often gives us > Poisson arrivals. > > Best, > Len > > > > On 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 > > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --000000000000e4cd8505c6ade81b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For those who might b= e interested in Little's law
there is a nice paper by John Little on the occasio= n=C2=A0
o= f the 50th anniversary=C2=A0 of the result.

http= s://www.informs.org/Blogs/Operations-Research-Forum/Little-s-Law-as-Viewed-= on-its-50th-Anniversary

https://www.informs.org/content/download/255808/= 2414681/file/little_paper.pdf

= Nice read.=C2=A0
Luca=C2=A0

P.S.=C2=A0
Who has not a copy of L. Kleinrock's b= ooks? I do have and am not ready to lend them!

On Fri, Jul 9, 2021 at 11:01 AM Leonard Kleinrock <lk@cs.ucla.edu> wrote:
David,

I totally appreciate =C2=A0your atte= ntion to when and when not analytical modeling works. Let me clarify a few = things from your note.

First, Little's law (al= so known as Little=E2=80=99s lemma or, as I use in my book, Little=E2=80=99= s result) does not assume Poisson arrivals - =C2=A0it is good for any arrival process and any service process and is an equality between time a= verages.=C2=A0 It states that the time average of the number in a system (f= or a sample path w)=C2=A0is equal to th= e average arrival rate to the system multiplied by the time-averaged time i= n the system for that sample path.=C2=A0 This is often written as =C2=A0=C2= =A0N<= /span>TimeAvg =3D=CE=BB<= /span>=C2=B7TTimeAvg . = =C2=A0Moreover, if the system is also ergodic, then the time average= equals the ensemble average and we often write it as=C2=A0N =CC=84 =3D =CE= =BB T =CC=84 . =C2=A0In any case, th= is requires neither Poisson arrivals nor exponential service times. =C2=A0<= /span>

Q= ueueing theorists often do study the case of Poisson arrivals.=C2=A0 True, = it makes the analysis easier, yet there is a better reason it is often used= , and that is because the sum of a large number of independent stationary r= enewal processes approaches a Poisson process.=C2=A0 So nature often gives = us Poisson arrivals. =C2=A0

Best,
Len



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

I will tell you flat out that= the arrival time distribution assumption made by Little's Lemma that a= llows "estimation of queue depth" is totally unreasonable on ANY = Internet in practice.

=C2=A0

The assumption is a Poisson Arrival Process. In = reality, traffic arrivals in real internet applications are extremely far f= rom Poisson, and, of course, using TCP windowing, become highly intercorrel= ated with crossing traffic that shares the same queue.

=C2=A0

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

=C2=A0

So, the idea t= hat iperf can estimate queue depth by Little's Lemma by just measuring = saturation of capacity of a path is bogus.The less Poisson, the worse the e= stimate gets, by a huge factor.

=C2=A0

=C2=A0

Where does the Poisson assumption = come from?=C2=A0 Well, like many theorems, it is the simplest tractable clo= sed form solution - it creates a simplified view, by being a "single-p= arameter" distribution (the parameter is called lambda for a Poisson d= istribution).=C2=A0 And the analysis of a simple queue with poisson arrival= distribution and a static, fixed service time is the first interesting Que= ueing Theory example in most textbooks. It is suggestive of an interesting = phenomenon, but it does NOT characterize any real system.

=C2=A0

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

=C2=A0

Unfortunately,= most networking engineers understand neither queuing theory nor applicatio= n networking usage in interactive applications. Which makes them arrogant. = They assume all distributions are poisson!

=C2=A0

=C2=A0

On Tuesday, July 6, 202= 1 9:46am, "Ben Greear" <greearb@candelatech.com> said:

> Hello,
> =
> I am interested to hear wish lists for network testing features. W= e make test
> equipment, supporting lots
> of wifi stations and= a distributed architecture, with built-in udp, tcp, ipv6,
> http, ..= . protocols,
> and open to creating/improving some of our automated t= ests.
>
> I know Dave has some test scripts already, so I'= m not necessarily looking to
> reimplement that,
> but more fis= hing for other/new ideas.
>
> Thanks,
> Ben
>
= > On 7/2/21 4:28 PM, Bob McMahon wrote:
> > I think 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
&= gt; useful.
> > Effective end/end queue depths per Little's la= w also seems useful. Both are
> available in iperf 2 from a test pers= pective. Repurposing test techniques to
> actual
> > traffic= could be useful. Hence=C2=A0the 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 D= ave Taht <dave.= taht@gmail.com
> <mailto:dave.taht@gmail.com>> wrote:
> >
= > > In terms of trying to find "Quality" I have tried to en= courage folk to
> > both read "zen and the art of motorcycle = maintenance"[0], and Deming's
> > work on "total qua= lity management".
> >
> > My own slice at this netwo= rk, computer and lifestyle "issue" is aiming
> > for &qu= ot;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 age= nts.
> >
> > [0] If you want to get depressed, read Pirsi= g's successor to "zen...",
> > lila, which is in par= t about what happens when an engineer hits an
> > insoluble proble= m.
> > [1] https://www.internetsociety.org/events/latency20= 13/
> <https://www.internetsociety.org/events/latency20= 13/>
> >
> >
> >
> > On Thu, Jul= 1, 2021 at 6:16 PM David P. Reed <dpreed@deepplum.com
> <mailto:dpreed@deepplum.com>>= ; wrote:
> > >
> > > Well, nice that the folks doin= g the conference=C2=A0 are willing to
> consider that quality of user= experience has little to do with signalling rate at
> the
> &g= t; physical layer or throughput of FTP transfers.
> > >
>= > >
> > >
> > > But honestly, the fact that = they call the problem "network quality"
> suggests that the= y REALLY, REALLY don't understand the Internet isn't the hardware> or
> > the routers or even the routing algorithms *to its u= sers*.
> > >
> > >
> > >
> > &= gt; 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 conferen= ce will
> likely fall
> > into the usual trap that net-heads= fall into - optimizing for some
> imaginary reality that doesn't= exist, and in fact will probably never be what
> users
> > = actually will do given the chance.
> > >
> > >
&= gt; > >
> > > I saw this issue in 1976 in the group devel= oping the original
> Internet protocols - a desire to put *into the n= etwork* special tricks to optimize
> ASR33
> > logins to rem= ote 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, because someone
> > thought tha= t TV broadcast would be the dominant application.
> > >
>= > >
> > >
> > > Frankly, to think of "q= uality" 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 the= y might expect
> to
> > experience that they don't exper= ience.
> > >
> > >
> > >
> > &= gt; There was much fighting back in 1976 that basically involved
> &q= uot;network experts" saying that the network was the place to "so= lve" such issues as
> quality,
> > so applications coul= d avoid having to solve such issues.
> > >
> > >> > >
> > > What some of us managed to do was to argu= e that you can't "solve"
> such issues. All you can do = is provide a framework that enables different uses to
> > *coopera= te* in some way.
> > >
> > >
> > >
&= gt; > > 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 poi= nts actually do w.r.t. what the IP
> layer can actually control. So i= t is meaningless - another violation of the
> > so-called end-to-e= nd principle).
> > >
> > >
> > >
>= ; > > Networks are about getting packets from here to there, multiple= xing
> the underlying resources. That's it. Quality is a whole di= fferent thing. Quality
> can
> > be improved by end-to-end a= pproaches, if the underlying network provides
> some kind of thing th= at actually creates a way for end-to-end applications to
> > affec= t queueing and routing decisions, and more importantly getting
> &quo= t;telemetry" from the network regarding what is actually going on with= the other
> > end-to-end users sharing the infrastructure.
>= ; > >
> > >
> > >
> > > This conf= erence won't talk about it this way. So don't waste your
> ti= me.
> > >
> > >
> > >
> > >=
> > >
> > >
> > >
> > > On= Wednesday, June 30, 2021 8:12pm, "Dave Taht"
> <dave.taht@gmail.com &= lt;mailto:dave.tah= t@gmail.com>> said:
> > >
> > > > The = program committee members are *amazing*. Perhaps, finally,
> we can> > > > move the bar for the internet's quality metrics p= ast endless,
> blind
> > > > repetitions of speedtest.=
> > > >
> > > > For complete details, please= see:
> > > > https://www.iab.org/activities/wo= rkshops/network-quality/
> <https://www.iab.org/a= ctivities/workshops/network-quality/>
> > > >
>= > > > Submissions Due: Monday 2nd August 2021, midnight AOE
&g= t; (Anywhere On Earth)
> > > > Invitations Issued by: Monday= 16th August 2021
> > > >
> > > > Workshop Da= te: This will be a virtual workshop, spread over
> three days:
>= ; > > >
> > > > 1400-1800 UTC Tue 14th September 20= 21
> > > > 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,
> Geof= f
> > > > Huston, Cullen Jennings, Katarzyna Kosek-Szott, Mi= rja
> Kuehlewind,
> > > > Jason Livingood, Matt Mathia= s, Randall Meyer, Kathleen
> Nichols,
> > > > Christop= h Paasch, Tommy Pauly, Greg White, Keith Winstein.
> > > >> > > > Send Submissions to: network-quality-workshop-pc@iab.or= g
> <mailto:network-quality-workshop-pc@iab.org>.
>= > > >
> > > > Position papers from academia, indus= try, the open source
> community and
> > > > others th= at 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 spe= cific actions taken by operators are
> unlikely to be
> > &g= t; > discussed in detail, so papers discussing general categories
>= ; of
> > > > actions and issues without naming specific tech= nologies,
> products, or
> > > > other players in the = ecosystem are expected. Papers should not
> focus
> > > &= gt; on specific protocol solutions.
> > > >
> > >= ; > The workshop will be by invitation only. Those wishing to
> at= tend
> > > > should submit a position paper to the address a= bove; it may
> take the
> > > > form of an Internet-Dr= aft.
> > > >
> > > > 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 organ= ized according
> to
> > > > content, and not every acc= epted submission or invited attendee
> will
> > > > ha= ve an opportunity to present as the intent is to foster
> discussion<= br>> > > > and not simply to have a sequence of presentations.<= br>> > > >
> > > > Position papers from those no= t planning to attend the virtual
> sessions
> > > > th= emselves are also encouraged. A workshop report will be
> published> > > > afterwards.
> > > >
> > > = > Overview:
> > > >
> > > > "We belie= ve that one of the major factors behind this lack of
> progress
&g= t; > > > is the popular perception that throughput is the often so= le
> measure of
> > > > the quality of Internet connec= tivity. 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 pro= tocols?
> > > > What services can be run by clients of the n= etwork?
> > > > What kind of IPv4, NAT or IPv6 connectivity = is offered, and
> are there firewalls?
> > > > What se= curity mechanisms are available for local services,
> such as DNS?> > > > To what degree are the privacy, confidentiality, integ= rity
> and
> > > > authenticity of user communications= guarded?
> > > >
> > > > Improving these asp= ects of network quality will likely depend
> on
> > > >= ; measurement and exposing metrics to all involved parties,
> includi= ng to
> > > > end users in a meaningful way. Such measuremen= ts and exposure
> of the
> > > > right metrics will al= low service providers and network
> operators to
> > > &g= t; focus on the aspects that impacts the users=E2=80=99 experience
> = most and at
> > > > the same time empowers users to choose t= he Internet service
> that will
> > > > give them the = best experience."
> > > >
> > > >
>= ; > > > --
> > > > Latest Podcast:
> > >= ; >
> https://www.linkedin.com/feed/u= pdate/urn:li:activity:6791014284936785920/
> <https://www.linkedin.com/feed/update/urn:li:activity:679101428= 4936785920/>
> > > >
> > > > Dave T=C3= =A4ht CTO, TekLibre, LLC
> > > > ___________________________= ____________________
> > > > Cerowrt-devel mailing list
&= gt; > > > Cerowrt-devel@lists.bufferbloat.net
> <mailto:C= erowrt-devel@lists.bufferbloat.net>
> > > > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> <https://lists.bufferbloat.net/listinfo/cerowrt-devel>
> >= ; > >
> >
> >
> >
> > --
> = > Latest Podcast:
> > https://www.= linkedin.com/feed/update/urn:li:activity:6791014284936785920/
> &= lt;https://www.linkedin.com/feed/update/urn:li= :activity:6791014284936785920/>
> >
> > Dave T=C3= =A4ht CTO, TekLibre, LLC
> > _____________________________________= __________
> > Make-wifi-fast mailing list
> > Make-wifi-f= ast@lists.bufferbloat.net
> <mailto:Make-wifi-fast@lists.buffer= bloat.net>
> > https://lists.bufferbloat.net/listi= nfo/make-wifi-fast
> <https://lists.bufferbloat.net/l= istinfo/make-wifi-fast>
> >
> >
> > This = electronic communication and the information and any files transmitted
&= gt; 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 ad= dressed and may contain information
> that is confidential, legally p= rivileged, protected by privacy laws, or otherwise
> > restricted = from disclosure to anyone else. If you are not the intended
> recipie= nt or the person responsible for delivering the e-mail to the intended
&= gt; recipient,
> > you are hereby notified that any use, copying, = distributing, dissemination,
> forwarding, printing, or copying of th= is e-mail is strictly prohibited. If you
> > received this e-mail = in error, please return the e-mail to the sender, delete
> it from yo= ur computer, and destroy any printed copy of it.
> >
> > = _______________________________________________
> > Starlink maili= ng list
> > Starlink@lists.bufferbloat.net
> > https://li= sts.bufferbloat.net/listinfo/starlink
> >
>
> > --
> Ben Greear <greearb@candelatech.com>
> Candela Technolog= ies Inc http://www= .candelatech.com
>
_______________________________________________
Starlink ma= iling list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.n= et/listinfo/starlink

______= _________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast
--000000000000e4cd8505c6ade81b--