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

If so, that's a step in the right direction. I know of a few "old guard" protocols which typically use appropriate DSCPs too. But YouTube doesn't, and neither do any of the major BitTorrent implementations (despite us asking nicely), nor typical VoIP clients, nor multiplayer games. Those are

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

I thought that some browsers already use various DSCPs when running WebRTC? > On Nov 30, 2017, at 9:09 PM, Jonathan Morton wrote: > > Cake already supports treating CS1 as less-than-besteffort by default. > Adding more codepoints to that list is easy. > > The trick is

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

Cake already supports treating CS1 as less-than-besteffort by default. Adding more codepoints to that list is easy. The trick is getting applications to actually use them. That's a chicken-egg problem. - Jonathan Morton ___ Bloat mailing list

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

On Thu, 30 Nov 2017, Jonathan Morton wrote: I submit that to provide *deployable* QoS schemes, you must either solve the classification problem elegantly (which is a Hard Problem), or else show that your scheme works adequately in the absence of classification. I'm taking the latter approach

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

A central assumption in all of your references so far is that the relevant traffic classes can be distinguished reliably in realtime and sent to appropriate queues. There is no fallback mechanism given for any cases where this assumption is false - the queue within each class is a FIFO, which as

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

The key design goal was to create assured bounds on loss and delay for designated classes during extended periods of load saturation. The mechanisms, to some extent, are not the issue - the ability configure it and know a-prori (to a given error bound) what would happen to the traffic flows

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

Martin Geddes writes: > In the meantime, I can give you a trial version to play with. How > about you give it a spin and share your feedback here of what you > learned? You mean the measurement tool, right? I won't promise I have time to do an extensive evaluation, but I

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

Hi Toke, I'd really like to get it to be open source, and that's probably going to take a collaborative industry funding effort to achieve as a reference measurement implementation of a universal interoperable quality standard (i.e. ∆Q-based metrics). There's a mathematical inevitability to the

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

I read the paper just now, and skimmed through the thesis to determine that it was talking about the same thing using an order of magnitude more space. It boils down to a Diffserv implementation using a classifier (details handwaved as usual), policers, shapers, and a strict-priority

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

Martin Geddes writes: > The two critical references are this paper > and this PhD thesis > . The former describes > "cherish-urgency" multiplexing. The "cherish" is what is

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

For the graphs, it would be great for f they were using a normalize output that allows for easy comparisons between runs. Especially the y axis for the “all” graph. On Mon, Nov 27, 2017 at 15:55 Dave Taht wrote: > On Mon, Nov 27, 2017 at 3:16 PM, Martin Geddes

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

On Mon, Nov 27, 2017 at 3:16 PM, Martin Geddes wrote: > Hi Toke, > > The two critical references are this paper and this PhD thesis. The former > describes "cherish-urgency" multiplexing. The "cherish" is what is different > to today's scheduling. It is used to create a new

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

Martin Geddes writes: > 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

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

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

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

Sorry for the late reply. Martin Geddes 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

[Bloat] Bufferbloat in high resolution + non-stationarity

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. See slide 18 of this deck: https://www.slideshare.net/mgeddes/stationarity-is-the-new-speed. The classic