[HN Gopher] TCP's congestion control saved the internet ___________________________________________________________________ TCP's congestion control saved the internet Author : mikece Score : 68 points Date : 2023-09-24 14:58 UTC (8 hours ago) (HTM) web link (www.theregister.com) (TXT) w3m dump (www.theregister.com) | lxgr wrote: | The fact that such a simple endpoint-only control loop (mostly) | just works is one of the most amazing parts of the Internet to | me. | | Still, it has its limits - the most obvious one to me is | mentioned in the article: The optimal buffer size for each hop | that TCP (or similarly flow-controlled traffic) traverses depends | on the average delay and bandwidth, but these are per-flow | quantities which an intermediate router can't properly estimate | in principle. | | I've played around with Linux's excellent fq_codel a bit with | promising results in the past, but ultimately, that's not a | solution in the spirit of the Internet (dumb routers, smart | endpoints) since it depends on looking at individual flows, | something routers aren't really supposed to have to do. | | I really hope that something like Google's BBR will become the | de-facto TCP congestion control algorithm in the end. | Animats wrote: | > The fact that such a simple endpoint-only control loop | (mostly) just works is one of the most amazing parts of the | Internet to me. | | Me too. We really don't know what to do about congestion in the | middle of a pure datagram network. What saved the Internet was | cheap fiber backbones. If backbone bandwidth had remained | expensive, this would never have worked. | | When I was working on congestion in the early 1980s, our goal | was to run at about 70% long haul link utilization. We would | back off quite a bit if things got anywhere near saturation. | This was fine with the DoD people who funded us. They wanted | reliability under stress, not maximum performance at minimum | cost. Much of the work on congestion since then has involved | trying to squeeze out that last 30%, at the cost of much- | increased complexity. | | The "bufferbloat" mess is embarrassing. If you use FIFO queuing | into a bandwidth choke point, latency is going to go way up. | This is well known. It is still ignored in most cheap routers. | Every home router feeding limited bandwidth should have | outbound fair queuing. Looking at individual flows near the | network edges is a big win. | 0xDEF wrote: | The author of the original RFC 896 from 1984 and namesake of | Nagle's algorithm is John Nagle who is an active user here on | Hacker News: | | https://news.ycombinator.com/user?id=animats | | https://datatracker.ietf.org/doc/html/rfc896 | mannyv wrote: | The ATM part was amusing. | | It's still used in the telco space; xDSL runs over ATM, generally | speaking. | | It's not obvious that TCP/IP would win. I wonder how much of its | victory was because it was basically free; the specs were public, | and pretty much everyone build an implementation. | | Compare that to the other protocols, which tended to be stuck to | a vendor (DECnet, AppleTalk, IPX, token ring). That makes | interoperability difficult, since in general companies didn't | want to license their tech to someone else because it was a | competitive advantage. | | You can still find the free TCP/IP implementations out there | (like tinytcp, which is still floating around). | zdw wrote: | This is a syndicated from the upstream blog, which gets content | from Bruce and Larry earlier: | | https://systemsapproach.substack.com/p/how-congestion-contro... | suprjami wrote: | I looked into congestion control earlier in the year. | | It's hilarious to see the things which were hard coded in the | first BSD implementation, like a 4 KiB socket buffer size. | | Also, as far as I can see, Bill Joy DID actually have linear | backoff but it was hidden behind an always-false condition, so | his hand-written lesser float backoffs were chosen instead. This | seems like a fairly tragic coding error to me. ___________________________________________________________________ (page generated 2023-09-24 23:00 UTC)