Re: [Bloat] Bufferbloat in high resolution + non-stationarity

[Martin Geddes <mail@martingeddes.com>]

[-- Attachment #1: Type: text/plain, Size: 3358 bytes --]

Hi Dave,

The data was being taken from general network traffic from multiple opcos
for a tier 1 global network operator. The task wasn't to fix or improve
anything, but to merely establish the baseline quality of the network as-is.

What is different about these metrics is the ability to extract the
underlying causality, and to be able to (de)compose complete supply chains
in a scientific manner (that would stand up in court). If you can capture
timing data of the same packet passing multiple probing points, then you
can use preexisting measurement capture systems. What matters if getting
multi-point distributions, rather than single-point averages.

The inherent limitation of AQM is its goal: constructing exemplars of
"success modes" for differential flow treatment, without considering what
the "failure mode" risks are (which are significant and serious). That
said, it prolongs the life of the current infrastructure, buying time to
address the underlying science and engineering issues (like work
conservation, emergent performance outcomes, and loss/delay trading that
conflates degrees of freedom).

It doesn't matter what scheduling algorithm you build if it creates
arbitrage or denial-of-service attacks that can arm a systemic collapse
hazard. The good news is we have a new class of scheduling technology (that
works on a different paradigm) that can fully address all of the
requirements. We are currently deploying it to enable the world's first
commercial quality-assured broadband service.

Martin

On 16 October 2017 at 21:26, Dave Taht <dave@taht.net> wrote:

>
> Sorry for the late reply.
>
> Martin Geddes <mail@martingeddes.com> writes:
>
> > Folks,
> >
> > I have uploaded a presentation of high-fidelity network performance
> measures
> > which includes an example of bufferbloat in high resolution, as possibly
> you
> > have never seen it before.
>
> Well, flent can generate a similar level of detail under a generated
> load. Some of kathie's work can now do it against tcp on pcaps.
>
> Was yours against general traffic?
>
> >
> > See slide 18 of this deck:
> > https://www.slideshare.net/mgeddes/stationarity-is-the-new-speed. The
> classic
> > "bloat" is a sudden formation of the queue, and a very slow (and steady)
> > draining. Bufferbloat is just one form of statistical variability
> > ("non-stationarity") in packet networks.
>
> Good set of slides. Analysis is picking up...
>
> Where you and I always tend to fall off a cliff is on your conclusions
> as to what to do about it, e.g. slide 19. I'd rather love it if you
> repeated your tests and graphs against pie, and fq_codel, and/or cake.
>
> For that matter BBR might be interesting against your tool.
>
> And then say what you'd do differently. In some way I can repeat.
>
> > For a world record winner, see this one where packets take over a minute
> (Huawei
> > WiFi hotspot roaming in Ireland with UK SIM)! Or for a pretty picture of
> buffers
> > draining, try this one.
>
> Well, at the moment gogo-in-flight holds the interplanetary record
> (680sec as I recall), but yea, 60+ seconds is up there. Contact
> Guinness!
>
> >
> > Happy to answer any questions.
> >
> > Martin Geddes
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 4466 bytes --]