[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)