I follow this pretty closely. The person you want to talk to is Sascha
Meinrath, about M-Lab - and if you have a good proposal, he has money to fund a
measurement project.
M-Lab has been a partial failure politically. The reason is this: the FCC does
not want to do anything that would annoy
I personally am happy that Henning Schulzrinne is pushing for this. However,
it should be remembered that the Commissioners rule the day at the FCC. I hope
he doesn't suffer what the Spectrum Policy Task Force at the FCC suffered when
I was one of the many people who was involved. Let's just
Doing good is not a good way to get rich, sadly. Mostly, I don't think they
focus on mesh routing anymore - they sell "enterprise systems".
-Original Message-
From: "Dave Taht"
Sent: Monday, November 19, 2012 4:48pm
To: cerowrt-de...@lists.bufferbloat.net, "bloat"
Subject: [Cerowrt-d
All the points below make sense. Ideally you want to measure the TCP FQ Codel
interaction in the "real world". Throughput benchmarks are irrelevant, the
equivalent of Hot Rod amateur dragstrip competitions among cars that cannot
even turn corners.
Beyond being hard, there is no "agreed up
I'm not sure why people are focused on iperf as a test of fqcodel.
iperf is a "hot rod" test. The UDP versions ignores congestion signals
entirely, and thus is completely irrelevant to bufferbloat.
The TCP tests are focused on throughput only, in an extreme case.
While it might be a nice
[This mail won't go to "end2end-interest" because I am blocked from posting
there, but I leave the address on so that I don't narrow the "reply-to" list
for those replying to me. I receive but can not send there.]
Looking at your graph, Ingemar, the problem is in the extreme cases, which are
Re: "the only thing that counts is peak throughput" - it's a pretty cynical
stance to say "I'm a professional engineer, but the marketing guys don't have a
clue, so I'm not going to build a usable system".
It's even worse when fellow engineers *disparage* or downplay the work of
engineers who
These observations are easily explained by a) excessive refusal to signal
congestion on each separate link (multiple seconds of buffering without drops
or ECN), plus b) a contended upstream bottleneck.
In other words, exactly the same phenomenon encountered in Comcast's "DOCSIS
plant".
I a
I have not investigated UDT in detail. My sense is that it is pretty much
like TCP but assumes that the bottleneck is actually a fixed rate link, rather
than one with significant variability in the capacity-per-flow available.
I don't think it uses the "biggest gun" that can improve things w
A small suggestion. Instead of working on *algorithms*, focus on getting
something actually *deployed* to fix the very real issues that we have today
(preserving the option to upgrade later if need be).
The folks who built the Internet (I was there, as you probably know) focused on
making st
+1
-Original Message-
From: "Wesley Eddy"
Sent: Friday, March 1, 2013 1:29pm
To: "Matt Mathis"
Cc: dpr...@reed.com, bloat-annou...@lists.bufferbloat.net, "bloat"
, cerowrt-de...@lists.bufferbloat.net
Subject: Re: [Bloat] [Cerowrt-devel] some good bloat related stuff on the ICCRG
agen
This is an excellent RFC. It should be issued immediately. It should also be
(along with fq_codel) cited as one alternative for managing queues properly in
a new version of a "best practices" RFC. There may be alternatives of similar
quality, but those alternatives should have quantitative e
Just curious... have you run RRUL-style testing of mosh over a congested link?
Not knowing in what way mosh is "UDP-based" I wonder what happens to it when
you run a program like, say, "top", over mosh when there is heavy file transfer
load.
-Original Message-
From: "Dave Taht"
Sen
Hi Ketan -
It is possible for good architects to simplify rather than to ramify. It takes
clear understanding of the system as a whole, a unifying perspective, and a
goal to make the system work extremely well and simply.
One of the key insights into how to do this was the choice of feature
Actually, using HTTP 1.1 GET that generates a single packet in each direction
for a ping is quite reasonable. In fact, it is "better" for measuring actual
path latencies, since ICMP pings *could* be discriminated against in a router
along the way (in the "old days" people in the routing co
End-to-end queueing delay (aggregate of delays in all queues except for the
queues in the endpoints themselves) should typically never (never means <99.9%
of any hour-long period) exceed 200 msec. in the worst case, and if at all
possible never exceed 100 msec. in networks capable of carryin
I'm afraid it's not *just* underfunded. I reviewed the details of the code
involved and the fixes, and my conclusion is that even programmers of security
software have not learned how to think about design, testing, etc. Especially
the continuing use of C in a large shared process address sp
All great points.
Regarding the Orange Book for distributed/network systems - the saddest part of
that effort was that it was declared "done" when the standards were published,
even though the challenges of decentralized networks of autonomously managed
computers was already upon us. The Ora
Why is the DNS PLR so high? 1% is pretty depressing.
Also, it seems odd to eliminate 19% of the content retrieval because the tail
is fat and long rather than short. Wouldn't it be better to have 1000 servers?
On Friday, April 18, 2014 2:15pm, "Greg White" said:
> Dave,
>
> We used
Well done. I'm optimistic for deployment everywhere, except CMTS's, the LTE
and HSPA+ access networks, and all corporate firewall and intranet gear.
The solution du jour is to leave bufferbloat in place, while using the real
fads: prioritization (diffserv once we have the "fast lanes" fully l
diffserv is not evil. However, there has never been a practical mechanism for
defining the meaning of the different "levels of service" across vendors and
Autonomous Systems.
The problem is that diffserv is framed as if there were a global "controller"
of the Internet who could impose a prec
I don't think that at all. I suspect you know that. But if I confused you, let
me assure you that my view of the proper operating point of the Internet as a
whole is that the expected buffer queue on any switch anywhere in the Internet
is < 1 datagram.
fq_codel is a good start, but it still r
I agree with you Jim about being careful with QoS. That's why Andrew Odlyzko
proposed the experiment with exactly two classes, and proposed it as an
*experiment*. So many researchers and IETF members seem to think we should just
turn on diffserv and everything will work great... I've seen very
Same concern I mentioned with Jim's message. I was not clear what I meant by
"pacing" in the context of optimization of latency while preserving throughput.
It is NOT just a matter of spreading packets out in time that I was talking
about. It is a matter of doing so without reducing throug
Good suggestions. Also, if you have 12V charging the relevant battery, you can
power 5V stuff with a cheap, off-the-shelf UBEC. In a system I built recently,
I powered a Wandboard, an SSD (SSD's typically only use their 5V supply) and an
8 port GigE desktop switch with one that puts out 5@5V:
[
http://www.habeyusa.com/products/fwmb-7950-rangeley-network-communication-board/
](
http://www.habeyusa.com/products/fwmb-7950-rangeley-network-communication-board/
) looks intriguing.
Probably a bit pricey, but has lots of advantages. There's another smaller one
that might do:
[ http:
I will sign. It would be better if we had an actual demonstration of how to
implement a speedtest improvement.
On Thursday, September 11, 2014 12:03pm, "Dave Taht" said:
> The theme of networks being "engineered for speedtest" has been a
> common thread in nearly every conversation I've
Among friends of mine, we can publicize this widely. But those friends
probably would like to see how the measurement would work.
On Thursday, September 11, 2014 8:13pm, "Rich Brown"
said:
> ___
> Cerowrt-devel mailing list
> cerowrt-de...@lists
The speedof.me API probably can be used directly as the measurement of download
and upload - you can create a competing download or upload in Javascript using
a WebWorker talking to another server that supports the websocket API to force
buffer overflow. (sort of poor man's RRUL).
The speedo
+1 for this idea. It really worked for Anand's and Tom's - their reviews
caught fire and got followed so much that they could become profitable
businesses from the ads.
Craigslist style business model, funding both reviewing and CeroWRT promotion
activities would be the logical thing. And I
bravo!
On Sunday, March 1, 2015 6:22pm, "Dave Taht" said:
> There's nothing new here, but it was a nice rant to get out of my system:
>
> http://permalink.gmane.org/gmane.org.operators.nanog/128201
>
> Of late, I have been taking a page from Linus Torvalds' playbook, in
> realizing that "on
On my own web server (running nginx) I provide an HTTP 1.1 accessible
statistics service. It returns a single JSON structure with the underlying
packet statistics for the server and the current connection. Since this packet
is inserted into the HTTP 1.1 stream upon request, it provides both the
It's a heavy burden to place on ICMP ping to say that it should tell you about
all aspects of its path through all the networks between source and destination.
On the other hand, I'll suggest that Fred's point - treat ICMP Ping like any
other IP datagram with the same header options is the essen
+1
On Wednesday, March 4, 2015 3:19pm, "Dave Taht" said:
> As you can see over the last month I have been laughing in despair
> about the futility we seem to face in getting solutions for
> bufferbloat "out there", ever since the streamboost and gogo-in-flight
> data came in.
>
> So it occurs
I do think engineers operating networks get it, and that Comcast's engineers
really get it, as I clarified in my followup note.
The issue is indeed prioritization of investment, engineering resources and
management attention. The teams at Comcast in the engineering side have been
the leaders in
DOn't want to get entangled in the political debate, but just a thought:
If you track what MAC addrs use what upstream capacity, you could have data on
which to judge who is pushing your usage over any caps you happen to have.
Having some data (not general fears or propaganda generated by those
Tools, tools, tools. Make it trivially easy to capture packets in the home
(don't require cerowrt, for obvious reasons). For example, an iPhone app that
does a tcpdump and sends it to us would be fantastic to diagnose "make wifi
fast" issues and also bufferbloat issues. Give feedback that is
What's your definition of 802.11 performing well? Just curious. Maximizing
throughput at all costs or maintaing minimal latency for multiple users sharing
an access point?
Of course, if all you are doing is trying to do point-to-point outdoor links
using 802.11 gear, the issue is different -
I'm curious as to why one would need low priority class if you were using
fq_codel? Are the LEDBAT flows indistinguishable? Is there no congestion
signalling (no drops, no ECN)? The main reason I ask is that end-to-end flows
should share capacity well enough without magical and rarely impleme
https://arxiv.org/abs/1701.02528
Interesting approach. Nice analysis.
Needs to be in OpenWRT?
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
I suggest we stop talking about throughput, which has been the mistaken idea
about networking for 30-40 years.
Almost all networking ends up being about end-to-end response time in a
multiplexed system.
Or put another way: "It's the Latency, Stupid".
I get (and have come to expect) 27 msec
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 (which is strictly true only for
Poisson arrival, but almost any
Just to be clear, I have built and operated a whole range of network platforms,
as well as diagnosing problems and planning deployments of systems that include
digital packet delivery in real contexts where cost and performance matter, for
nearly 40 years now. So this isn't only some kind of ra
43 matches
Mail list logo
