dtaht

20 ms·

241.
by dtaht 5y ago
I note the 240/4 and 0/8 and especially zeroth ideas are the more viable of this bunch. What I mentally see as a possible use for 127/8 (with 127/16 still held in reserve) - is the really painfully untransparent string o
242.
by dtaht 5y ago
We've been having regular videoconferences to discuss this concept tuesdays 9:30 AM PDT over here: https://starwrt.v.taht.net:8443/group/bufferbloat/ (use any login, no password, chrome is best) There's
243.
How TCP works, using people as packets(blog.apnic.net)
2 points by dtaht 7y ago|0 comments
244.
by dtaht 7y ago
I think I've read everything she ever wrote about congestion control. I'd always wanted to meet her. :(
245.
by dtaht 7y ago
Do keep hoping everybody complaining here about their speed, also check their latency on dslreports.com. Bufferbloat makes slow internet a lot slower than it needs to be, and there's cures for it (sqm/fq_codel,sch_cake etc) - depl
246.
by dtaht 7y ago
As for private or public use, certainly there is demand for a larger CGNAT address space, somewhere, and allocation of a portion of 225-231 for that might drive adoption there. Still, the addresses need to become routable, and from there (a
247.
by dtaht 7y ago
We've had 225/8-231/8 up and running for 6+ months, with patches for various routing daemons. Running a gauntlet with 240/4 and 0/8 now working seemed best. In our exploration of converting these 120m addresses from
248.
by dtaht 7y ago
We have had many talks at many levels over the years. This is an attempt to break the logjam of finger pointing that ensued. We expect wide adoption of this and other ipv4 related patches over the next few years across the open source stack
249.
by dtaht 7y ago
Thx!
250.
by dtaht 7y ago
This work is a fallout of the conclusion of this report: https://www.internetgovernance.org/2019/02/20/report-on-ipv6... "legacy IPv4 will coexist with IPv6 indefinitely" which was referenced in the
251.
by dtaht 7y ago
225/8-231/8 were reserved for future multicast use and never allocated by iana. As near as we can tell by grepping the entire world's source they are entirely unused. 128m addresses....
252.
by dtaht 7y ago
Thx for the pointers to the work and talks!
253.
by dtaht 7y ago
This point was the overarching point of my talk at netdevconf. We are going to need more ipv4.
254.
by dtaht 7y ago
Drop myself and the other project members a line and see the unicast extensions project on github. It is a trivial number of patches to enable all the open source code in the world to work.
255.
by dtaht 7y ago
I am pleased to see no one coming at us with pitchforks and torches ablaze. 240/4 already works in many idea also. 127 and 225/8-232/8 can be reallocated as unicast also.
256.
by dtaht 8y ago
On the point to multipoint problem, I think we thoroughly licked that last year (and in openwrt 17.01) and later, with: https://www.usenix.org/system/files/conference/atc17/atc17-h... I look forward to
257.
by dtaht 10y ago
I would be very interested in trying to see the results of the firebind stuff, with our stuff (fq_codel and cake based "sqm") in place on the link. Could you drop by the bufferbloat mailing list and chat with us? Also: We use a to
258.
by dtaht 11y ago
It is everywhere... pretty thoroughly quantified now (example: http://www.dslreports.com/speedtest/results/bufferbloat?up=1 ) It is serious and remains so... but Fixes have emerged (fq_codel, pie, cake) that are w
259.
by dtaht 12y ago
And that we have fixed bufferbloat on many technologies, and thus a mandate for more packet loss, rather than less - or the deployment of ECN - would be WAY better than further political debate. example of the fix for cable modems. http:&#
260.
by dtaht 12y ago
I guess no one reads Vint Cerf anymore. Sigh.
261.
by dtaht 12y ago
I put up all I have to say on the subject at: https://lists.bufferbloat.net/pipermail/bloat/2014-August/00...
262.
by dtaht 12y ago
My problem with the new paper is that it computes for a baseline rtt of 100 or 150ms. Real world average rtts are in the range of 4 ms for Google fiber 18 ms for fios and 38 ms for cable, with the ethernet rtt in a Datacenter far lower than
263.
by dtaht 12y ago
I do look forward to the day where such complex congestion control protocols can be implemented in hardware... Until then... fq codel is the best thing going.
264.
by dtaht 12y ago
IMHO: EFF doesn't yet grok the importance of pushing out good routing protocols to the edge, and the need for mesh networking the edge together in the advent of emergency... or adversity. CeroWrt include every mesh networking protocol
265.
by dtaht 12y ago
I'd rather like better data on the problem you describe, as it does not seem to line up with the experimental data I have so far on the interaction of AQM and packet scheduling techniques with bittorrent. The first paper we did was: h
266.
by dtaht 12y ago
Thank you for the performance statistics. We have done a lot of work on other hardware platforms to get them up to being able to saturate gigE or higher, with tuning and things like "Byte Queue Limits" support. The problem with th
267.
by dtaht 12y ago
I don't regard cerowrt so much as "my" project. There's a couple hundred people on the mailing list - it's the "reference router project" for the bufferbloat-fighting community, And: cerowrt is much closer
268.
by dtaht 12y ago
I note that the bufferbloat.net project is looking for new hardware, and sponsors. The main foci of the project are apolitical in nature - just trying to build a faster, better internet. Most of cerowrt's original goals have been met,
269.
by dtaht 12y ago
Stuart Cheshire is the godfather of the bufferbloat project. With algorithms like fq_codel we've reduced induced network latencies by orders of magnitude... Two examples of fq_codel in action: 100Mbit: http://snapon.lab.buff
270.
by dtaht 12y ago
On Linux 3.13 and later it's easier to just add fq or fq_codel to /etc/sysctl.conf, which will enable it for all your devices, including those with hardware multi-queues. Or, at the command line: sysctl -w net.core.default_qd

More ›