Netdev 0x16 - Keynote: It's Time to Replace TCP in the Datacenter
netdevconf2 HN recommenders · recommended in 2 months, 2023-2023
5K views · 3 years ago · talk · evergreen
John Ousterhout's Netdev 0x16 keynote arguing that nearly every aspect of TCP is wrong for the datacenter, from connections and streams to reliable delivery and congestion control. He presents the case for a replacement protocol.
Recommended as the thorough case for replacing TCP in datacenters and for Ousterhout's Homa protocol.
1:21:16A New Way to look at Networking
Google
52K views • 19 years ago
47:18OpenFlow @ Google - Urs Hoelzle, Google
Open Networking Summit
47K views • 14 years ago
59:388 Frames in 16ms: Rollback Networking in Mortal Kombat and Injustice 2
GDC Festival of Gaming
94K views • 7 years ago
1:21:20A New Way to look at Networking
Google TechTalks
30K views • 19 years ago
28:31Velocity 2010: James Hamilton, "Datacenter Infrastructure Innovation"
O'Reilly
9K views • 16 years ago
9:59Moving online webserver using public transport
Sascha P
164K views • 16 years ago
42:20"Stop Rate Limiting! Capacity Management Done Right" by Jon Moore
Strange Loop Conference
41K views • 9 years ago
58:17Raft lecture (Raft user study)
Diego Ongaro
87K views • 13 years ago
51:27Google I/O 2012 - Go Concurrency Patterns
Google for Developers
894K views • 14 years ago
48:45Matrix 2.0 — How we're making Matrix go voom!
Matrixdotorg
16K views • 3 years ago
1:19:35Lecture 1: Introduction
MIT 6.824: Distributed Systems
921K views • 6 years ago
46:23High Volume, Bandwidth Heavy Infrastructure On The Cheap - Kyle Drake
PDX Node
1K views • 9 years ago
40:04ONS 2015: Wednesday Keynote - Amin Vahdat
Open Networking Summit
32K views • 11 years ago
1:21:16A New Way to look at Networking
GoogleTalksArchive
26K views • 14 years ago
34:52Liberating Distributed Consensus - Heidi Howard
Reactive Summit
7K views • 7 years ago
45:27Avoiding Microservice Megadisasters - Jimmy Bogard
NDC Conferences
439K views • 9 years ago
1:26:02Stanford Seminar - The Soul of a New Machine: Rethinking the Computer
Stanford Online
76K views • 6 years ago
1:10:23"Systems that run forever self-heal and scale" by Joe Armstrong (2013)
Strange Loop Conference
85K views • 5 years ago
42:26AWS re:Invent 2015 | (NET403) Another Day, Another Billion Packets
Amazon Web Services
55K views • 11 years ago
56:57IPv6 Summit 2014: Wells Fargo adopting IPv6
Rocky Mountain IPv6 Taskforce
237 views • 11 years ago
4 comments from Hacker News
I think there are a few misunderstandings there (the video is funny, btw). The kind of async IO I'm referring to exists one layer below whatever Apache and node are using. Both are event-driven, actually. They both use some flavor of epoll (see link ). Historically, buffered IO was sufficient to circumvent slow threads. Simply because buffered IO operations usually don't block (you merely memcpy, and the kernel flushes asynchronously in the background). That can only take you so far, however, and it's apparent today that hardware can go much further and that the gap is widening. It's a valid point, though, to question whether that additional performance is even needed. John Ousterhout ( ▶ this video ) is currently working on a new network protocol to alleviate some of the problems TCP creates in software wrt performance, and he also questions whether there is even a need for very fast networking for real-world applications. IMO, the mere existence of stuff like DPDK is proof enough. Many folks use it and would rather use the kernel if it could provide comparable performance.
You can obviously build an RPC protocol on top of TCP, people have been doing it for decades. However there are things that are difficult to efficiently implement on top of TCP (multiplexing different logical streams over the same connection, message priorities) in the TCP model, and some things that are impossible to implement over TCP (for example, you don't really have any ability to influence what happens during congestion control scenarios). There are also a bunch of things about TCP that are fundamentally inefficient on modern hardware. Do these things matter if you're running some RPC service over the internet with a Python backend? Almost certainly not. But if you read John Ousterhout's paper or watch his Netdev talk^[1] it's also pretty clear that this isn't the use case he's been talking about. He's talking about RPC in the datacenter, where in theory modern hardware is capable of delivering RPC messages with microsecond scale latency but in practice no RPC systems built on TCP come anywhere close to that. The Netdev talk I've linked below is really good and John makes a really thorough presentation of his ideas and what he's actually trying to optimize for. [1]: ▶ this video
If you'd like to watch Ousterhoust explain Homa and his vision of replacing TCP: ▶ this video Spoiler: Ousterhout is right, and the data shows he is right. Maybe not everyone knows it yet, or it's the kind of "right" that not everyone will ever get to (and we'll settle for "good enough" for much longer), but he is almost certainly right. Not to disparage the poster of this article of course -- I always love a good hot take or contrarian piece.
If you want to watch Outsterhout in talk form: Netdev 0x16 - Keynote: It's time to replace TCP in the datacenter: ▶ this video Netdev is an amazing conference btw, it is insane that we get access to the trailblazing being shown off at conferences for free on places like YT.