Posts by dtaht

250 million-plus reserved IPv4 addresses could be released – but the internet isn’t built to use them

Re: Cover them all

We did:

Probably the most important proposal was finally retiring fully the concept of 0 as broadcast: https://www.ietf.org/id/draft-schoen-intarea-unicast-lowest-address-05.html

That work is mostly done too, codewise.

So is 0/8. I´m really fond of that patch - deleted 5 lines of code and saved every computer on the planet a nanosecond or more on every packet.

Two MUCH more controversial proposals were limiting ipv4 multicast address space (which I do not feel like pursueing at this time), and shaving down 127 to something sane, and making it work with k8.

Re: Where's my share of the sale?

ARDC has funded some really great projects, and is always looking for more. I think they have used their share of the proceeds from their sale wisely and well.

https://www.ardc.net/apply/grants/

I wish they would sell off (or rent) even more of the still mostly unused 44 block and help more hams get onto ipv6, and keep working on getting more ham stuff back into the public consciousness, and also able to relax at least some of the amateur processes to make ham radio a viable BGP internet fallback in case of emergency. Investments into wifi would be nice too, but I think slightly out of scope.

IPv4 address rentals to mint millions of dollars for AWS

AWS is also squatting on 240/4

240m IPv4 addresses could have been moved from reserved to unicast status since 2008. Support is commonly available in every OS except windows, and multiple big companies are squatting on them.

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html

It's a shame.

How TCP's congestion control saved the internet

Re: WAN congestion is not DC congestion

I often wonder the same about incast. I am a big believer in the power of fair queuing to avoid starvation. The so-famed incast workload, had DCTCP arrive with a modification to ECN to provide multicast signalling, and the two memes have ridden together without much investigation, aside that letting dctcp loose outside the DC fills some with terror.

I, instead have stuck with conventional RFC3168, leveraging fq_codel, but with the target set to as low as can be achieved (50us) in software. It seems to scale properly down to a MTU in simulation, no matter how big the load. Someday perhaps, someone will reproduce the results we have been getting from that method in some popular publication. https://blog.cerowrt.org/post/juniper/

There is a lot of good work going in Linux on pushing tcp to unheard of single flow heights. Recently Eric Dumazet (who deserves fame!) cracked 120Gbit for a single flow.

Re: Another reason for Internet's success ...

It took 6 years to get fq_codel through the IETF process, which still stings. QUIC has been under development for 10.

VJ has made many more contributions

Van Jacobson and Kathie Nichols cracked the congestion control problem even further with the publication of https://queue.acm.org/detail.cfm?id=2209336 the codel AQM algorithm.

The fq_codel variant (RFC8290) is in many (but not enough) routers today, the default in linux, and the fq part at least, is part of all of Apple´s products.

VJ further was part of the BBR effort. Without him, what would the future have looked like?

Re: Hence HTTP 3...

I like to hope that libreqos, preseem, etc will make a difference, even in the face of QUIC, and without DPI.

Starlink's rocket speeds hit a 50 megabit wall for large downloads

bufferbloat on starlink breaks all known congestion controls

I have been trying to point out for 4+ years now that the scheduler and bufferbloat on starlink breaks all the congestion controls we have on the internet. I would hope, actually, that the rate cap actually implements something sane, but people have seemingly forgotten how to take a packet capture.

Some caps:

https://docs.google.com/document/d/1puRjUVxJ6cCv-rgQ_zn-jWZU9ae0jZbFATLf4PQKblM/edit#heading=h.fwv7fw3aeaz

Me ranting:

https://www.youtube.com/watch?v=c9gLo6Xrwgw

Cable internet won't need dose of fibre to stop feeling bloated

Re: tc qdisc red?

codel, fq_codel, and pie are the successors to RED, which was designed back in 1992 and never worked very well. These new AQM and Fair Queuing algorithms require a LOT less configuration, and "just work" at a wide range of bandwidths. Codel was developed by Kathie Nichols and Van Jacobson - Van was half responsible for RED, and tried really hard to come up with a viable replacement for 16 years... and he and Kathie hit it out of the park with codel and fq_codel.

So take a look at tc qdisc add dev whatever root {fq_codel,pie} on any modern linux distro.

or at the relevant manual pages, to see how far we've come.

My first attempt at posting this message was rejected, I'd pointed to this as a summary of where the buffer bloat effort stands today:

http://gettys.wordpress.com

Which also includes a funny story about why "red in a different light" couldn't get published.

And more specifically, I can point to the acm queue paper that kicked off the resurgence of interest in AQM technology: http://queue.acm.org/detail.cfm?id=2209336

And the relevant internet drafts for the docsis pie standard:

https://datatracker.ietf.org/doc/draft-white-aqm-docsis-pie/

The cable labs study that led to the adoption of docsis-pie was very interesting:

http://www.cablelabs.com/wp-content/uploads/2013/11/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf

and there are other algos pending standardization at the ietf:

https://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/

http://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00

I do this in the hope that more informed populace will lead to faster, wider adoption of this stuff, as it makes the internet SO much faster, under load.

Van's lecture on codel is a real treat, btw, explaining congestion via a new analogy to a water fountain, in ways that I hope more could grok:

http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos#Van-Jacobson-of-Google-introduces-the-codel-solution-and-the-packet-fountain-analogy-at-the-IETF84-conference-July-August-2012

For more information about how all this stuff works, please join the bloat email list, if you like.

Sincerely,

Dave Taht

Co-founder, Bufferbloat project

You don't have to wait for cable modems to be updated

Third party router firmwares such as openwrt barrier breaker, cerowrt, dd-wrt, ipfire, pfsense and others have had buffer bloat related fixes in their qos systems for over a year now.

Examples of the reduced latency and improved throughput you can get today, with an off the shelf router and these firmwares, on cable:

http://burntchrome.blogspot.gr/2014/05/fixing-bufferbloat-on-comcasts-blast.html

http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html

Some videos on the buffer bloat problem by Van Jacobson, Jim Gettys, myself and others:

http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos