The publication of a new, definitive specification for TCP (RFC 9293) is enough of a big deal in our world that we couldn’t resist a second post on the topic. In particular, we were intrigued by the discussion that compared QUIC to TCP, which inspired this week’s newsletter.
The narrow waist of the Internet is indeed, something that lives in a magic shrink machine. I'd argue that Internet applications which need to work ubiquitously must be designed using port 80 or 443. I remember trying really hard to convince the 3GPP folks of this when they were deliberating whether femtocells should use IPsec or an SSL based encrypted connection back to their gateways. They chose IPsec, and that protocol has also been hit by the narrowing waist. So good luck planting your femtocell behind a corporate firewall. RTP --> WebRTC is another example of the shrinking waist. This seems to be following a pattern where web browsers are becoming *the* Internet access client where a human UI is expected - and firewall admins are setting the knobs to allow nothing else to pass. So to Chris, I'd say that the function is still needed, buy yeah, RIP SCTP.
I also think that your RPC observation is spot-on. Datagrams and Byte Streams (UDP and TCP) are Transport layer functions, but not Application layer functions. The Application layer has a number of *CASEs* that have been cobbled together in most Internet applications: typically variants of ACSE and ROSE. QUIC offers an interesting way to create the CASE "layer" functions and then re-use it across applications. (Not trying to push OSI here - they have too many layers. But IMHO the IETF stack has too few. My only assertion is that the functions need to be supported in some way and the OSI terms give me words to talk about them.)
Like QUIC itself, I also think that application communication behaviors (CASE) are being thrust into browsers, and over port 443 as that slides into place as the real small waist of the encrypted Internet. Clearly QUIC can support various behaviors and functions, and I like to think of it as grabbing some of the transport layer and also providing scaffolding to develop the functions of an ill-defined upper layer of the Internet - like the application identifier from the last comment. So I think that QUIC obviates the need for TCP in browsers going forward. If that means "replaces" - given the small waist - then OK, I think it does. Another way to say it is that expect to see much less work on TCP going forward.
I also had to laugh out loud reading your RPC observation, and I applaud you both for writing about it very early on. It lines up very well with the observations that computer scientist, John Day, made in his book, "Patterns in Network Architecture." His fundamental claim is that networking is *all* just distributed Inter-process communication. He and his insights have strongly influenced my own thinking about networking. I think he does a great job of describing the functions needed in networking, and also in describing how well they are or are not supported by existing protocols. I especially like how he describes the strange protocols and architecture we have had to invent to compensate for their absence in the places they ought to be.
Great article on the always interesting transport protocol space. Couple of thoughts:
1. SCTP RIP. Stating the obvious, heh?
2. Wonder about QUIC implementations. User space or kernel? I am thinking the former for faster development/testing/deployment as well as kernel bypass advantages. For the latter, do we think some sort of eBPF, offload NICs and boxes, or even L4 connection-splicing middle boxes? Or am I off base because it runs over UDP? QUIC has been rolled out It and I presume web server platforms can handle this at scale.
3. Interested in seeing how streaming over QUIC can improve the live event viewing apps (such as NFL Sunday Ticket) that use HTTP live streaming (HLS). I was looking at the media-over-quic (moq) docs.
This was a great read! I wanted to ask as someone who’s still getting familiar with networking and RPCs specifically - is one of the benefits of using QUIC to make it less painful when dealing with RPCs? I’m not sure if I misunderstood, but that’s kind of where it seemed like it was going?
Just a QUIC comment or two... 8-)
The narrow waist of the Internet is indeed, something that lives in a magic shrink machine. I'd argue that Internet applications which need to work ubiquitously must be designed using port 80 or 443. I remember trying really hard to convince the 3GPP folks of this when they were deliberating whether femtocells should use IPsec or an SSL based encrypted connection back to their gateways. They chose IPsec, and that protocol has also been hit by the narrowing waist. So good luck planting your femtocell behind a corporate firewall. RTP --> WebRTC is another example of the shrinking waist. This seems to be following a pattern where web browsers are becoming *the* Internet access client where a human UI is expected - and firewall admins are setting the knobs to allow nothing else to pass. So to Chris, I'd say that the function is still needed, buy yeah, RIP SCTP.
I also think that your RPC observation is spot-on. Datagrams and Byte Streams (UDP and TCP) are Transport layer functions, but not Application layer functions. The Application layer has a number of *CASEs* that have been cobbled together in most Internet applications: typically variants of ACSE and ROSE. QUIC offers an interesting way to create the CASE "layer" functions and then re-use it across applications. (Not trying to push OSI here - they have too many layers. But IMHO the IETF stack has too few. My only assertion is that the functions need to be supported in some way and the OSI terms give me words to talk about them.)
Like QUIC itself, I also think that application communication behaviors (CASE) are being thrust into browsers, and over port 443 as that slides into place as the real small waist of the encrypted Internet. Clearly QUIC can support various behaviors and functions, and I like to think of it as grabbing some of the transport layer and also providing scaffolding to develop the functions of an ill-defined upper layer of the Internet - like the application identifier from the last comment. So I think that QUIC obviates the need for TCP in browsers going forward. If that means "replaces" - given the small waist - then OK, I think it does. Another way to say it is that expect to see much less work on TCP going forward.
I also had to laugh out loud reading your RPC observation, and I applaud you both for writing about it very early on. It lines up very well with the observations that computer scientist, John Day, made in his book, "Patterns in Network Architecture." His fundamental claim is that networking is *all* just distributed Inter-process communication. He and his insights have strongly influenced my own thinking about networking. I think he does a great job of describing the functions needed in networking, and also in describing how well they are or are not supported by existing protocols. I especially like how he describes the strange protocols and architecture we have had to invent to compensate for their absence in the places they ought to be.
Thanks for the article and Best Regards,
Tom
Great article on the always interesting transport protocol space. Couple of thoughts:
1. SCTP RIP. Stating the obvious, heh?
2. Wonder about QUIC implementations. User space or kernel? I am thinking the former for faster development/testing/deployment as well as kernel bypass advantages. For the latter, do we think some sort of eBPF, offload NICs and boxes, or even L4 connection-splicing middle boxes? Or am I off base because it runs over UDP? QUIC has been rolled out It and I presume web server platforms can handle this at scale.
3. Interested in seeing how streaming over QUIC can improve the live event viewing apps (such as NFL Sunday Ticket) that use HTTP live streaming (HLS). I was looking at the media-over-quic (moq) docs.
-chrisMetz
This was a great read! I wanted to ask as someone who’s still getting familiar with networking and RPCs specifically - is one of the benefits of using QUIC to make it less painful when dealing with RPCs? I’m not sure if I misunderstood, but that’s kind of where it seemed like it was going?