A big issue is that "average queue length" was and is a terrible
indicator of congestion. But I think the first "bug" Van was referring
to was the original RED "control law" - I asked him why he thought it
would work as it really ends up looking like a step function which your
first control t
Can I give an email "thumbs up" to Bill Woodcock's email?
That information is certainly there in TCP. I don't know how much of
QUIC is in the clear.
On 12/6/23 6:22 PM, Bill Woodcock via Bloat wrote:
On Dec 6, 2023, at 22:46, Sauli Kiviranta via Nnagain
wrote: What would be a
comprehensi
On 10/31/22 7:46 PM, Dave Taht via Bloat wrote:
I remember when I thought videoconferencing quality like this, was good.
VJ, on Kathie's codel, and a ton of queue theory that seems to have
sunk in around the world, with a talk that still seems fresh.
https://archive.org/details/video1_20191129
a ping by any other name...
Has anyone ever done a rigorous study to see how well ping delays
correspond to the delay that information-carrying packets experience?
On 5/12/22 10:15 AM, Christoph Paasch via Bloat wrote:
Ookla's measure of "loaded latency":
https://www.ookla.com/articles/intro
In coming up with metrics, I would really encourage you to think about
making use of tdigest to gather statistics in some of your on-line
measurement. I'm not sure users see "average" behavior. I mean if
someone is getting great latency numbers most of the time, with a small
percentage of unaccept
On 2/26/21 4:56 AM, Jason Iannone wrote:
...
> passively monitor production flows to get a novel sense of end to end
> performance per flow. I don't know of any other passive monitoring
> technique, beyond a port mirror + a whole gang of systems, that can
> provide this level of detail. Please enli
On 1/15/19 12:02 AM, Dave Taht wrote:
> https://www.cablelabs.com/enabling-the-cable-networks-for-mobile-backhaul/
>
>
Hmm. From the linked article:
> Additionally, in building the PoC, we have accumulated expertise on
> how to perfect the BWR algorithm to optimally predict the amount of
> data
On 11/27/18 3:17 PM, Dave Taht wrote:
...
>
> but now that we all have bedtime reading, I'm going to go back to
> hacking on libcuckoo. :)
>
>
Geez, louise. As if everyone doesn't have enough to do! I apologize. I
did not mean for anyone to completely read the links I sent, just look
at the rel
I have been kind of blown away by this discussion. Jim Gettys kind of
kicked off the current wave of dealing with full queues, dubbing it
"bufferbloat". He wanted to write up how it happened so that people
could start on a solution and I was enlisted to get an article written.
We tried to draw on
Yes, Dave, thanks for being the guy with the lantern keeping this work
in front of people and organizing work and measurements. As a "shiny
object" person who likes to move on to the next "interesting" problem, I
really appreciate that you stuck it out and worked to make solutions a
reality, not j
If you do not find a tool, you might try building your own. Using
libtins http://libtins.github.io/ makes it much easier to build C++
programs that operate on sniffed packets than it used to be. I used it
in pping https://github.com/pollere/pping and connmon for TCP flows and
in some non-public st
On 6/19/18 11:56 PM, Sebastian Moeller wrote:
>
> Addendum: when running speedtests on cable for the purpose of estimating the
> "true" docsis shaper goodput one needs to take care to not be fooled by
> transient bandwidth allowances like powerboost but rather one needs to find
> the sustainab
On 6/21/18 12:17 PM, Dave Taht wrote:
> On Thu, Jun 21, 2018 at 9:43 AM, Kathleen Nichols wrote:
>> On 6/21/18 8:18 AM, Dave Taht wrote:
>>
>>> This is a case where inserting a teeny bit more latency to fill up the
>>> queue (ugh!), or a driver having some way to
On 6/21/18 8:18 AM, Dave Taht wrote:
> This is a case where inserting a teeny bit more latency to fill up the
> queue (ugh!), or a driver having some way to ask the probability of
> seeing more data in the
> next 10us, or... something like that, could help.
>
Well, if the driver sees the arriving
On 6/19/18 11:56 PM, Sebastian Moeller wrote:
> Addendum: when running speedtests on cable for the purpose of
> estimating the "true" docsis shaper goodput one needs to take care to
> not be fooled by transient bandwidth allowances like powerboost but
> rather one needs to find the sustainable st
On 11/2/17 1:25 AM, Sebastian Moeller wrote:
> Hi Y.
>
>
>> On Nov 2, 2017, at 07:42, Y wrote:
>>
>> hi.
>>
>> My connection is 810kbps( <= 1Mbps).
>>
>> This is my setting For Fq_codel,
>> quantum=300
>>
>> target=20ms
>> interval=400ms
>>
>> MTU=1478 (for PPPoA)
>> I cannot compare well. But A
due to
> footprint issues; but many current home routers would have space for it.
>
> - Jim
>
>
>
>
> On Sun, Apr 30, 2017 at 8:41 PM, Kathleen Nichols <mailto:nich...@pollere.com>> wrote:
>
>
> Hi,
>
app, which makes it big for a
>> home router, so it can't be used on old small home routers due to
>> footprint issues; but many current home routers would have space for
>> it.
>>
>>
>> - Jim
>>
>>
Hi,
I've just made one of the tools I use to measure network delay
available with a GPLv2 license. Perhaps it will be of intererst.
https://github.com/pollere/pping
Kathie
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferb
That's a good idea in general, but what are you measuring for your
"actual performance"?
Raw throughput? Goodput (which requires a bit of processing)? Then what
about delay?
On 11/28/16 9:41 AM, David Collier-Brown wrote:
> Put the speed-test /into the router/, with a big red button to turn
> fq
Well, it would be good to know where the congestion is coming from, i.e.
saying that "the network is congested" doesn't say which network. Since
our downlink got upgraded, there is rarely an issue there but from time
to time the comcast network just "goes down" in that it seems that
nothing gets o
I never have any problem hearing you, Dave.
Random stuff in-line.
On 11/27/16 1:24 PM, Dave Taht wrote:
> There *are* 430+ other minds on this mailing list, and probably a few
> AIs.
>
> Sometimes I worry that most of our postings go into spamboxes now,
> or that we've somehow completely burned
My measurements are showing those kinds of delays are in the client
network but I don't know enough about this set up to know what's
going on.
If anyone is interested, I'm talking about some recent measurements at
the IRTG MAPRG meeting that is Thursday morning Korea time. I'm
guessing there's no
Hi, Justin,
Thanks for the explanations. So the grade is for the user not the ISP?
I just have to point out that the below jumped out at me a bit. A user
can fully use the link bandwidth capacity and not have an unacceptable
latency. After all, that's the goal of AQM. But, yes, there are those
pe
't be one of
> the headlines their ISP advertises. Saying "100ms" would confuse
> people. And the tests they're used to / compare with, show idle latency
> instead.)
>
> On 27/08/16 16:19, Kathleen Nichols wrote:
>> Yeah.
>>
>> I admit to muddy
Yeah.
I admit to muddying the waters because I think of the size of a buffer as
being in megabytes and the size of a queue (latency) as being in
milliseconds. I think the tests attempt to measure the worst possible
latency/queue that can occur on a path.
On 8/27/16 4:46 AM, Rich Brown wrote:
> I
in-line
On 8/26/16 4:20 PM, David Lang wrote:
> On Fri, 26 Aug 2016, Kathleen Nichols wrote:
>
>> I think it might be useful to say these tests measure the maximum
>> *potential* for
>> bufferbloat. That is, they plumb the depths of the buffers in the path.
>>
I think it might be useful to say these tests measure the maximum
*potential* for
bufferbloat. That is, they plumb the depths of the buffers in the path.
I tried running
dslreports while I was running a video and though dslreports ramps
delays up to 700ms,
before and after that peak delay is more
PM, David Lang wrote:
> On Thu, 4 Aug 2016, grenville armitage wrote:
>
>> Kathy, Dave,
>>
>> Thanks for the +ve comments!
>>
>> On 08/04/2016 03:03, Kathleen Nichols wrote:
>>> Nicely laid out and reported, but I have a question for the authors.
Nicely laid out and reported, but I have a question for the authors. At the
top of section II. D. it says:
"Instantaneous’ throughput is an approximation derived
from the actual bytes transferred during constant windows
of time."
Is the "actual bytes transferred" the sum of the packet sizes throu
Pollere has been working on passive monitoring methods, in particular on
monitoring
delay. This has something of a slog, but whenever there is data, it's
pretty fun. I've
been running our prototype in my home network and wrote up the delay
results in a note:
http://pollere.net/Pdfdocs/FunWithTSDE
Are these tools all active probes? It looks that way to me.
Kathie
On 6/2/16 1:05 PM, Colin Dearborn wrote:
> Plenty of easy ways to do v4 and v6.
> DNS can be built to only have hosts for v4 or v6, and you run two tests, one
> to each set of hosts.
> Comcast has been doing it forever.
It sounds like you are defining congestion as packets experiencing 5ms of
delay over a period of 5ms.
When you evaluate this, what metrics do you use to evaluate the effect on
the applications using this buffer?
Kathie
On 5/21/15 8:26 AM, Jonathan Morton wrote:
> When Codel is applied o
On 5/21/15 9:21 AM, Jonathan Morton wrote:
>
>> On 19 May, 2015, at 22:17, Dave Taht wrote:
>>
>> So I finished writing up my thoughts on bobbie,
>> http://www.bufferbloat.net/projects/codel/wiki/Bobbie
>>
>> which might work better than anything on the table in the face of
>> huge bursts like
omg
On 5/4/15 1:41 PM, Dave Taht wrote:
> http://www.c-span.org/video/?325750-1/google-vice-president-vint-cerf-future-internet
>
> see 7:30 in...
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just to clarify...I wrote the sfqcodel code in ns using existing sfq
code so I
could put something together quickly to show the benefits, most
specifically,
of binning acks and other short packets separately from longer data
transfer packets.
At the t
Somewhat apropos of this discussion, Pollere has been working on passive
techniques to measure latency under a DoE SBIR grant. Although these
can be used on an end-host, the goal is to deploy anywhere. But part of the
goal with SBIR grants is to figure out a revenue stream. As Dave has noted,
this
Good, point. I like to think of the original RED as more 1) noting that all
those full buffers weren't doing anyone any good and 2) noting that one
could perhaps be aware of creeping congestion and "gently" prevent it.
Those two items are still important it's just that making 2) work has more
"ah
In general, it's not a good idea to start out with a preconceived idea about
what you want to prove in an experiment, except perhaps as a hypothesis.
Athough I think CoDel is better than other AQMs I generally make my
experiments tell me that.
There really aren't any shortcuts to understanding, u
"If you just look at the efficiency measures, the bigger satellites" are
going to make it easier to for an "unfriendly" to disrupt global
communications.
I think, on the whole, given a scrappy communications protocol, I'd
prefer the lemonade.
Kathie
__
Gosh, that's high praise. And what's really neat is that this was such a
team effort
where we don't even necessarily know each other! What's perhaps bad is that
this was a "volunteer" effort, though that also is a strength. I'm not
sure the
answer is for everyone to work for Google.
On 5/15/14 6:
Thanks, Rich.
And to show you what an amazing bit of work that first fq_codel was, I have
on my calendar that I first "exposed" CoDel to a small group in a
meeting room
and on the phone at ISC on April 24. It was really amazing to me to watch
something Van and I had been discussing (okay, arguing
I've added a new note on CoDel. This is about CoDel with "bursty"
MACs where packets don't leave the queue at a steady rate. If you
are interested, see:
http://www.pollere.net/CoDelnotes.html
Kathie
___
Bloat mailing list
Bloat@lists.bufferbloa
It would be me that tries to say "stochastic flow queuing with CoDel"
as I like to be accurate. But I think FQ-Codel is Flow queuing with CoDel.
JimG suggests "smart flow queuing" because he is ever mindful of the
big audience.
On 11/27/12 4:27 PM, Paul E. McKenney wrote:
> On Tue, Nov 27, 2012 a
44 matches
Mail list logo
