[Starlink] [Make-wifi-fast] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board
Bob McMahon
bob.mcmahon at broadcom.com
Wed Jul 7 15:19:43 EDT 2021
I can't speak for others. I've been successful in early prototyping using
one for simplistic off-diagonal h-matrix testing, i.e. varying the h-matrix
condition numbers. I see this as a small step in the right direction for
conductive, automated, and reproducible testing.
Developing a system that supports multiple RF channels to test against
seems hard. Then add to that causing the energy states per "peer RF
traffic" makes the challenge even more difficult.
Bob
On Wed, Jul 7, 2021 at 6:36 AM Ben Greear <greearb at candelatech.com> wrote:
> Thanks for the clarification. There are vendors that make these, but we
> have not tried
> integrating our software control with any of them. To date, not many of
> our customers
> have been interested in this, so it did not seem worth the effort.
>
> Do you see this as being useful for normal AP vendors/users, or mostly
> just radio manufacturers such
> as BCM?
>
> In case someone has one of these that has a sane API, I'd consider adding
> automation support
> to drive it while running throughput or RvR or whatever other types of
> tests seem interesting.
>
> Thanks,
> Ben
>
> On 7/6/21 3:05 PM, Bob McMahon wrote:
> > Sorry, I should have been more clear. Not a fixed butler matrix but a
> device with solid state, programmable, phase shifters, 0 - 360 degrees.
> It's a way to
> > create multiple phy channels and affect and vary the off diagonal
> elements of a MIMO H-matrix using conducted parts. Then automation software
> can have more
> > robust RF MIMO test scenarios that are reproducible.
> >
> >
> https://web.stanford.edu/~dntse/Chapters_PDF/Fundamentals_Wireless_Communication_chapter7.pdf
> > <
> https://web.stanford.edu/~dntse/Chapters_PDF/Fundamentals_Wireless_Communication_chapter7.pdf
> >
> >
> > Bob
> >
> > On Tue, Jul 6, 2021 at 2:24 PM Ben Greear <greearb at candelatech.com
> <mailto:greearb at candelatech.com>> wrote:
> >
> > We tried adding in an external butler matrix in the past, but could
> not notice any useful difference. Possibly
> > we didn't have the right use case.
> >
> > Typically we are competitive on price for full testing solutions,
> but you can get stand-alone attenuators
> > cheaper from specialized vendors. Happy to discuss pricing offlist
> if you wish.
> >
> > Thanks,
> > Ben
> >
> > On 7/6/21 1:43 PM, Bob McMahon wrote:
> > > The four part attenuator part would be more interesting to me if
> it also had a solid state phase shifters. This allows for testing 2x2 MIMO
> testing per
> > > affecting the spatial stream eigen vectors/values.
> > >
> > > Bob
> > >
> > > PS. The price per port isn't competitive. Probably a good idea to
> survey the market competition.
> > >
> > > On Tue, Jul 6, 2021 at 6:46 AM Ben Greear <
> greearb at candelatech.com <mailto:greearb at candelatech.com> <mailto:
> greearb at candelatech.com
> > <mailto:greearb at candelatech.com>>> wrote:
> > >
> > > Hello,
> > >
> > > I am interested to hear wish lists for network testing
> features. We 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 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 telemetry is useful to apps making socket write() and read() calls.
> > > >
> > > > Bob
> > > >
> > > > On Fri, Jul 2, 2021 at 10:07 AM Dave Taht <
> dave.taht at gmail.com <mailto:dave.taht at gmail.com> <mailto:
> dave.taht at gmail.com
> > <mailto:dave.taht at gmail.com>> <mailto:dave.taht at gmail.com <mailto:
> dave.taht at gmail.com> <mailto:dave.taht at gmail.com <mailto:
> dave.taht at gmail.com>>>> wrote:
> > > >
> > > > In terms of trying to find "Quality" I have tried to
> encourage folk to
> > > > both read "zen and the art of motorcycle
> maintenance"[0], and Deming's
> > > > work on "total quality management".
> > > >
> > > > My own slice at this network, computer and lifestyle
> "issue" is aiming
> > > > for "imperceptible latency" in all things. [1].
> There's a lot of
> > > > fallout from that in terms of not just addressing
> queuing delay, but
> > > > caching, prefetching, and learning more about what a
> user really needs
> > > > (as opposed to wants) to know via intelligent agents.
> > > >
> > > > [0] If you want to get depressed, read Pirsig's
> successor to "zen...",
> > > > lila, which is in part about what happens when an
> engineer hits an
> > > > insoluble problem.
> > > > [1]
> https://www.internetsociety.org/events/latency2013/ <
> https://www.internetsociety.org/events/latency2013/>
> > <https://www.internetsociety.org/events/latency2013/ <
> https://www.internetsociety.org/events/latency2013/>>
> > > >
> > > >
> > > >
> > > > On Thu, Jul 1, 2021 at 6:16 PM David P. Reed <
> dpreed at deepplum.com <mailto:dpreed at deepplum.com> <mailto:
> dpreed at deepplum.com
> > <mailto:dpreed at deepplum.com>> <mailto:dpreed at deepplum.com <mailto:
> dpreed at deepplum.com>
> > > <mailto:dpreed at deepplum.com <mailto:dpreed at deepplum.com>>>>
> 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 be
> > 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 to exploit underlying "multicast" by building it into the
> IP layer,
> > because 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 might
> > > 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" <
> dave.taht at gmail.com <mailto:dave.taht at gmail.com> <mailto:
> dave.taht at gmail.com
> > <mailto:dave.taht at gmail.com>> <mailto:dave.taht at gmail.com <mailto:
> dave.taht at gmail.com>
> > > <mailto:dave.taht at gmail.com <mailto:dave.taht at gmail.com>>>>
> 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/ <
> https://www.iab.org/activities/workshops/network-quality/>
> > <https://www.iab.org/activities/workshops/network-quality/ <
> 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 at iab.org <mailto:
> network-quality-workshop-pc at iab.org>
> > <mailto:network-quality-workshop-pc at iab.org <mailto:
> network-quality-workshop-pc at iab.org>>
> > > <mailto:network-quality-workshop-pc at iab.org <mailto:
> network-quality-workshop-pc at iab.org> <mailto:
> network-quality-workshop-pc at iab.org
> > <mailto:network-quality-workshop-pc at 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’t 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’
> 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/>
> > > <
> https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
> <https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
> >>
> > > > > >
> > > > > > Dave Täht CTO, TekLibre, LLC
> > > > > > _______________________________________________
> > > > > > Cerowrt-devel mailing list
> > > > > > Cerowrt-devel at lists.bufferbloat.net <mailto:
> Cerowrt-devel at lists.bufferbloat.net> <mailto:
> Cerowrt-devel at lists.bufferbloat.net
> > <mailto:Cerowrt-devel at lists.bufferbloat.net>> <mailto:
> Cerowrt-devel at lists.bufferbloat.net <mailto:
> Cerowrt-devel at lists.bufferbloat.net>
> > > <mailto:Cerowrt-devel at lists.bufferbloat.net <mailto:
> Cerowrt-devel at lists.bufferbloat.net>>>
> > > > > >
> https://lists.bufferbloat.net/listinfo/cerowrt-devel <
> https://lists.bufferbloat.net/listinfo/cerowrt-devel>
> > <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/
> > <
> https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/>
> <https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
> > <
> https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
> >>
> > > >
> > > > Dave Täht CTO, TekLibre, LLC
> > > > _______________________________________________
> > > > Make-wifi-fast mailing list
> > > > Make-wifi-fast at lists.bufferbloat.net <mailto:
> Make-wifi-fast at lists.bufferbloat.net> <mailto:
> Make-wifi-fast at lists.bufferbloat.net
> > <mailto:Make-wifi-fast at lists.bufferbloat.net>> <mailto:
> Make-wifi-fast at lists.bufferbloat.net <mailto:
> Make-wifi-fast at lists.bufferbloat.net>
> > > <mailto:Make-wifi-fast at lists.bufferbloat.net <mailto:
> Make-wifi-fast at lists.bufferbloat.net>>>
> > > > https://lists.bufferbloat.net/listinfo/make-wifi-fast <
> https://lists.bufferbloat.net/listinfo/make-wifi-fast>
> > <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 information that is confidential, legally privileged, protected by
> privacy laws, or
> > > otherwise
> > > > restricted from disclosure to anyone else. If you are not
> the intended 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 at lists.bufferbloat.net <mailto:
> Starlink at lists.bufferbloat.net> <mailto:Starlink at lists.bufferbloat.net
> <mailto:Starlink at lists.bufferbloat.net>>
> > > > https://lists.bufferbloat.net/listinfo/starlink <
> https://lists.bufferbloat.net/listinfo/starlink>
> > > >
> > >
> > >
> > > --
> > > Ben Greear <greearb at candelatech.com <mailto:
> greearb at candelatech.com> <mailto:greearb at candelatech.com <mailto:
> greearb at candelatech.com>>>
> > > Candela Technologies Inc http://www.candelatech.com <
> http://www.candelatech.com>
> > >
> > >
> > > 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
> information that is confidential, legally privileged, protected by privacy
> laws, or
> > otherwise
> > > restricted from disclosure to anyone else. If you are not the
> intended 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.
> >
> >
> > --
> > Ben Greear <greearb at candelatech.com <mailto:greearb at candelatech.com
> >>
> > Candela Technologies Inc http://www.candelatech.com <
> http://www.candelatech.com>
> >
> >
> > 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
> information that is confidential, legally privileged, protected by privacy
> laws, or otherwise
> > restricted from disclosure to anyone else. If you are not the intended
> 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.
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
--
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
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20210707/597cd46e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20210707/597cd46e/attachment-0001.bin>
More information about the Cerowrt-devel
mailing list