Re: [Bloat] infinite queue

There was an idea (I think from the 1970’s) that is refinement of this - isometric flow control. I would say that the key notion (expressed here) is that the ‘work in progress’ is finite - the isometric concept is a refinement on that, in that it says “there is some number”. Also, subtly

Re: [Bloat] [EXTERNAL] Re: Terminology for Laypeople

Matt This is such a great idea that the Broadband Forum has been working on it for a couple of years now - see TR452.1 https://www.broadband-forum.org/download/TR-452.1.pdf - it is being actively worked on, it can exploit existing

Re: [Bloat] Terminology for Laypeople

The Broadband forum in the QED initiative (https://www.broadband-forum.org/download/TR-452.1.pdf) us “structural” to capture the “impairment” from technological / topologyissues. Neil > On 5 May 2021, at 01:02, Livingood, Jason via Bloat > wrote: > > Like many of you I have been

Re: [Bloat] Questions for Bufferbloat Wikipedia article

It should be noted that a) and b) are related by the “service rate” - if you want to look at how to measure “unhappiness” in networking you might want to look at the Broadband Forum’s work on “Quality Attenuation” discussed in TR452.1[1] where there is a formal definition and calculus for it…

Re: [Bloat] splitting the ping

There is some interesting work from the Broadband Forum on this sort of “spatially aware” measurement… https://www.broadband-forum.org/open-broadband/broadband-experience . Including a webinar this week..

Re: [Bloat] [Cerowrt-devel] DC behaviors today

; On Wednesday, December 13, 2017 11:41am, "Jonathan Morton" > <chromati...@gmail.com> said: > > > Have you considered what this means for the economics of the operation of > > networks? What other industry that “moves things around” (i.e logistical or > > si

Re: [Bloat] [Cerowrt-devel] DC behaviors today

> On 12 Dec 2017, at 22:53, dpr...@reed.com wrote: > > Luca's point tends to be correct - variable latency destroys the stability of > flow control loops, which destroys throughput, even when there is sufficient > capacity to handle the load. > > This is an indirect result of Little's Lemma

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] Steam In Home Streaming on ath9k wifi

> On 24 Nov 2017, at 09:20, Hal Murray wrote: > > > neil.dav...@pnsol.com said: >> There are a few more issues - the relative drift between the two clocks >> can be as high as 200ppm, though typically 50-75ppm is what we observe, but >> this drift is monotonic. > >

Re: [Bloat] Steam In Home Streaming on ath9k wifi

Hal We use this approach to automatically manage measurements. There are a few more issues - the relative drift between the two clocks can be as high as 200ppm, though typically 50-75ppm is what we observe, but this drift is monotonic. Also NTP can make changes at one (or both) ends - they show

Re: [Bloat] Detecting bufferbloat from outside a node

On 4 May 2015, at 11:28, Jonathan Morton chromati...@gmail.com wrote: Generally, the minimum observed delay will correspond to the case when both inbound and outbound queues are empty throughout the path. This delay should correspond to basic propagation and forwarding delays, which can't

Re: [Bloat] Detecting bufferbloat from outside a node

On 4 May 2015, at 11:41, Paolo Valente paolo.vale...@unimore.it wrote: Thanks for this extra information and suggestions. Just to be certain that I am not missing anything: I am assuming that also the observed delay you mention is the delay observed from outside endpoints, and not the total

Re: [Bloat] Detecting bufferbloat from outside a node

not accreting into longer and longer periods of non-idleness). However that is a pattern as well as a load dependent phenomena. Neil On 4 May 2015, at 13:17, Jonathan Morton chromati...@gmail.com wrote: On 4 May, 2015, at 14:39, Neil Davies neil.dav...@pnsol.com wrote: Noting that, delay

Re: [Bloat] Detecting bufferbloat from outside a node

know - by observation) Neil On 28 Apr 2015, at 00:11, Jonathan Morton chromati...@gmail.com wrote: On 27 Apr 2015 23:31, Neil Davies neil.dav...@pnsol.com wrote: Hi Jonathan On 27 Apr 2015, at 16:25, Jonathan Morton chromati...@gmail.com wrote: One thing that might help you here

Re: [Bloat] Detecting bufferbloat from outside a node

On 27 Apr 2015, at 22:37, Toke Høiland-Jørgensen t...@toke.dk wrote: Neil Davies neil.dav...@pnsol.com writes: ... One of my adages is that network quality doesn' t exist - just like you can't buy a box of dark and make a room dark by opening the box, you can't buy a box of network

Re: [Bloat] Detecting bufferbloat from outside a node

On 28 Apr 2015, at 10:58, Sebastian Moeller moell...@gmx.de wrote: Hi Neil, On Apr 28, 2015, at 09:17 , Neil Davies neil.dav...@pnsol.com wrote: Jonathan The timestamps don't change very quickly - dozens (or more) of packets can have the same timestamp, so it doesn't give you

Re: [Bloat] Detecting bufferbloat from outside a node

On 27 Apr 2015, at 11:45, Toke Høiland-Jørgensen t...@toke.dk wrote: Neil Davies neil.dav...@pnsol.com writes: Take a look at http://www.pnsol.com/publications.html, you may find http://www.pnsol.com/public/PP-PNS-2009-02.pdf as a good starting point. I've seen this referred on the list

Re: [Bloat] Detecting bufferbloat from outside a node

Toke On 27 Apr 2015, at 15:22, Toke Høiland-Jørgensen t...@toke.dk wrote: Neil Davies neil.dav...@pnsol.com writes: You'll find the way that ∆Q can be decomposed into basis set of ∆Q|G, ∆Q|S and ∆Q|V - helps work out which parts of the budget get eaten up by different elements

Re: [Bloat] Detecting bufferbloat from outside a node

that we can't get away from. On 27 Apr 2015, at 16:51, Toke Høiland-Jørgensen t...@toke.dk wrote: Neil Davies neil.dav...@pnsol.com writes: Depends on your starting point: Right, having looked a bit more at this: - if it is how does this relate to the end user - look at the properties

Re: [Bloat] Detecting bufferbloat from outside a node

as you need to isloate the effect of the network transport from the processing (which also has an influence on the performance) On which documents should I concentrate more to better understand this point? Thanks, Paolo Il giorno 27/apr/2015, alle ore 11:54, Neil Davies neil.dav

Re: [Bloat] Detecting bufferbloat from outside a node

Toke On 27 Apr 2015, at 13:03, Toke Høiland-Jørgensen t...@toke.dk wrote: Neil Davies neil.dav...@pnsol.com writes: I don't think that the E2E principle can manage the emerging performance hazards that are arising. Well, probably not entirely (smart queueing certainly has a place). My

Re: [Bloat] Measuring Latency

Gents, This is not actually true - you can measure one-way delays without completely accurately synchronised clocks (they have to be reasonably precise, not accurate) - see CERN thesis at http://goo.gl/ss6EBq It is possible, with appropriate measurements, to construct arguments that make

Re: [Bloat] Check out www.speedof.me - no Flash

:10 AM, Neil Davies neil.dav...@pnsol.com wrote: Rich You may want to check how accurate they are to start. I just ran a “speed test” on my line (which I have complete control and visibility over the various network elements) and it reports an average “speed” (in the up direction

Re: [Bloat] Check out www.speedof.me - no Flash

Sebastian On 25 Jul 2014, at 15:17, Sebastian Moeller moell...@gmx.de wrote: But how do you propose to measure the (bottleneck) link capacity then? It turns out for current CPE and CMTS/DSLAM equipment one typically can not relay on good QoE out of the box, since typically these

Re: [Bloat] ipspace.net: QUEUING MECHANISMS IN MODERN SWITCHES, (Jonathan Morton)

On 28 May 2014, at 18:29, David Collier-Brown dave...@rogers.com wrote: On 05/28/2014 11:33 AM, Jonathan Morton chromati...@gmail.com wrote It's a mathematical truth for any topology that you can reduce to a black box with one or more inputs and one output, which you call a queue and which

Re: [Bloat] ipspace.net: QUEUING MECHANISMS IN MODERN SWITCHES

case (be it fiscal or safety of life) it does create new performance related attack vectors. We know this, because we've been asked this and we've done the analysis. - Jonathan Morton --- Neil Davies, PhD, CEng, CITP, MBCS Chief Scientist

Re: [Bloat] ipspace.net: QUEUING MECHANISMS IN MODERN SWITCHES

Of course it misses out the first principle. in non discarding scheduling total delay is conserved, irrespective of the scheduling discipline (there is a similar statement when discarding is taking place). Neil On 27 May 2014, at 09:21, Hagen Paul Pfeifer ha...@jauu.net wrote:

Re: [Bloat] ADSL2+ interleaving (Re: CFP: Workshop on Reducing Internet Latency)

in that frequency band On 10 Dec 2013, at 08:04, Mikael Abrahamsson swm...@swm.pp.se wrote: On Tue, 10 Dec 2013, Neil Davies wrote: We've seen this even when we've played with the settings through the customer portal (I'm' in the UK - the provisioning portal allows many such changes). Are you

Re: [Bloat] curious.....

On 8 Dec 2013, at 10:40, Sebastian Moeller moell...@gmx.de wrote: ... Is that really true? given enough concurrent flows, critical flows might be delayed purely be the round robin scheduling of equally worthy packets in fq_codel, so some residual priory system might still make sense…

Re: [Bloat] Bufferbloat at LUG talk - Meeting Report

Oliver Every TCP transfer (which may be collection of web page accesses) that reaches an instantaneous packet rate in-excess of the capacity of the most constrained network element on the path causes such problems. This is a measurable phenomena, it is equipment/configuration dependant - but

Re: [Bloat] Not all the world's a WAN

Stephen I disagree with you - Patrick has solved his problem. As for papering over the cracks - that is just pure provocation - if more than *one* packet in the buffer? Any finite queueing system has two degrees of freedom - there are three variables in play: loading factor (ratio of arrival

[Bloat] Burst Loss

On the issue of loss - we did a study of the UK's ADSL access network back in 2006 over several weeks, looking at the loss and delay that was introduced into the bi-directional traffic. We found that the delay variability (that bit left over after you've taken the effects of geography and line