5 ms·

Those aren't TCP downsides per se, just different design decisions based on different requirements back when TCP was standardised. QUIC eliminates the TLS hand

Those aren't TCP downsides per se, just different design decisions based on different requirements back when TCP was standardised. QUIC eliminates the TLS handshake time on top of TCP. You can't really improve on the TCP 3-way handshake - you need a minimum of 3 messages to ensure that both sides have agreed to a connection. You also have to question whether FEC should be implemented in layer 4, rather than implemented over the lower layers only as when needed. It seems to be terribly inefficient to implement FEC end-to-end when the packetloss is due to the last mile (or several meters for WiFi). To me, QUIC seems to be the wrong approach to the problem. If you want a connection-oriented protocol with the advantages above, it's much better just to push through a new version of TCP with the extensions. Sure, it's going to take longer than approving a new protocol over UDP, but the potential benefits are substantial. On the other hand, there is an argument that by pushing through QUIC, there is pressure to improve TCP in those ways. We'll have to see how this pans out.

ricardobeat 6y ago
There is no way to 'push a new version of TCP', I believe that's one of the strong motivations for these protocols. Billions of devices and the world's entire network infrastructure would need to be upgraded, you'd only start seeing decent support after a decade. So you have to work with what we have - TCP and UDP.
- clarry 6y ago
  Given how IPv6 went, a decade seems optimistic.
  - fiddlerwoaroof 6y ago
    IPv6 had a really bad case of second system effect, though.
- starfallg 6y ago
  >There is no way to 'push a new version of TCP' Yes there is. TCP has a variable options range of up to 320 bits starting at the 20th octet to handle exactly feature extensions (This is exactly how Multi-Path TCP is implemented). There are also 3 reserved bits set for future use (13th octet), which can also form the basis of even larger extended option ranges for stuff like TLS negotiation.
  - tialaramex 6y ago
    You're describing how it can be upgraded in theory but the parent was explaining that it can't be done in practice. One of the lessons of the last decade or so has been that only end-to-end encryption prevents ossification. To the extent that middleboxes can read stuff they will break forward compatibility. For example certificate compression. How are we only sending that to standardisation now in 2020? Well it was impossible to deploy this before TLS 1.3. Why? Because older versions of TLS didn't encrypt certificates, and so middleboxes could read them, and so middleboxes would freak out if the certificate wasn't as expected. That's all it took to make a useful optimisation impossible to deploy.
    - starfallg 6y ago
      Where you're talking about TCP, then the only state aware devices in the path are usually stateful firewalls close to the beginning and end of the path. I can't see this causing major issues as firewalls don't usually act on options unless specifically configured, seeing that they don't change the fundamentals of TCP flow (ie. flags, seqs and acks). The option but are usually just flags for signalling between the two endpoints.
    - folmar 6y ago
      > You're describing how it can be upgraded in theory but the parent was explaining that it can't be done in practice. Adding features to TCP was done many times successfully already. When my jurney started there was no ws-scaling, ECN, SACK... They are all widely adopted now.
      - tialaramex 6y ago
        Ten years after it was standardised, field reports showed ECN at 0.06% of all connections using ECN while almost 40% showed countermeasures preventing ECN or other failures (the remainder did not attempt ECN) So what did they do? Well they adjusted ECN so that it tolerates the broken middleboxes. That's what you have today. Your systems go "Oh, ECN is broken, oh well" and press on without it. You see this as a feature added "successfully" and I call it what it is: Failure.
Ericson2314 6y ago
Hmm I would say TCP does have downsides. The choice between TCP and UDP is all-or-nothing. Quic does some nice modularization/layering so that you can effectively control reliability and ordering separately. One way to think about it is negotiating a connection vs what that connection actually is are pretty separate. Sadly even the literature and education materials on TCP is pretty poor at explaining this. With the QUIC spec this just feels much clearer.
- Matthias247 6y ago
  I would actually say Quic is worse. In addition to mandatory ordering (like TCP) it also provides you mandatory encryption. You can not really have "flexible ordering" with default Quic, since Quic Streams are inherently ordered Streams. You could treat them as unordered on one end and deliver out-of-order data as soon as at arrives, but that won't allow the peer to send unordered data due to an overall limited flow control window. Future extensions on QUIC (like the proposed datagram one) might change this.
  - Ericson2314 6y ago
    You can create a new stream per datagram. Crazy, but it works.
mercer 6y ago
My apologies for just taking your comment as a jumping-off point, but could you or anyone else point me in the best (free) direction to properly learn about this whole stack of protocols? It's been very high on my list to finally figure out what sits below HTTP, and in a roundabout way my appetite has been whetted by reading a Claude Shannon biography and The Information (which I suppose aren't perhaps /that/ close to UDP and so on but more about information theory and error correction as a historical development), but those books made me really want to dive in and learn about the building blocks of 'the internet'. Any pointers to books, articles or courses would be very much appreciated!
- deleted 6y ago
  [deleted]
- convolvatron 6y ago
  the RFCs themselves are pretty accessible -ymmv. rfc 791 - internet protocol rfc 793 - transmission control protocol
- starfallg 6y ago
  TCP/IP Illustated Volume 1: The Protocols by W. R. Stevens is the classic textbook and a great place to start off. You can then read the IETF RFCs, which are usually well written and completely readable to anybody with a computing background.
  - mercer 6y ago
    awesome, thanks for the recommendation!

ricardobeat 6y ago

There is no way to 'push a new version of TCP', I believe that's one of the strong motivations for these protocols. Billions of devices and the world's entire network infrastructure would need to be upgraded, you'd only start seeing decent support after a decade. So you have to work with what we have - TCP and UDP.

clarry 6y ago
Given how IPv6 went, a decade seems optimistic.
- fiddlerwoaroof 6y ago
  IPv6 had a really bad case of second system effect, though.
starfallg 6y ago
>There is no way to 'push a new version of TCP' Yes there is. TCP has a variable options range of up to 320 bits starting at the 20th octet to handle exactly feature extensions (This is exactly how Multi-Path TCP is implemented). There are also 3 reserved bits set for future use (13th octet), which can also form the basis of even larger extended option ranges for stuff like TLS negotiation.
- tialaramex 6y ago
  You're describing how it can be upgraded in theory but the parent was explaining that it can't be done in practice. One of the lessons of the last decade or so has been that only end-to-end encryption prevents ossification. To the extent that middleboxes can read stuff they will break forward compatibility. For example certificate compression. How are we only sending that to standardisation now in 2020? Well it was impossible to deploy this before TLS 1.3. Why? Because older versions of TLS didn't encrypt certificates, and so middleboxes could read them, and so middleboxes would freak out if the certificate wasn't as expected. That's all it took to make a useful optimisation impossible to deploy.
  - starfallg 6y ago
    Where you're talking about TCP, then the only state aware devices in the path are usually stateful firewalls close to the beginning and end of the path. I can't see this causing major issues as firewalls don't usually act on options unless specifically configured, seeing that they don't change the fundamentals of TCP flow (ie. flags, seqs and acks). The option but are usually just flags for signalling between the two endpoints.
  - folmar 6y ago
    > You're describing how it can be upgraded in theory but the parent was explaining that it can't be done in practice. Adding features to TCP was done many times successfully already. When my jurney started there was no ws-scaling, ECN, SACK... They are all widely adopted now.
    - tialaramex 6y ago
      Ten years after it was standardised, field reports showed ECN at 0.06% of all connections using ECN while almost 40% showed countermeasures preventing ECN or other failures (the remainder did not attempt ECN) So what did they do? Well they adjusted ECN so that it tolerates the broken middleboxes. That's what you have today. Your systems go "Oh, ECN is broken, oh well" and press on without it. You see this as a feature added "successfully" and I call it what it is: Failure.

Ericson2314 6y ago

Hmm I would say TCP does have downsides. The choice between TCP and UDP is all-or-nothing. Quic does some nice modularization/layering so that you can effectively control reliability and ordering separately. One way to think about it is negotiating a connection vs what that connection actually is are pretty separate. Sadly even the literature and education materials on TCP is pretty poor at explaining this. With the QUIC spec this just feels much clearer.

Matthias247 6y ago
I would actually say Quic is worse. In addition to mandatory ordering (like TCP) it also provides you mandatory encryption. You can not really have "flexible ordering" with default Quic, since Quic Streams are inherently ordered Streams. You could treat them as unordered on one end and deliver out-of-order data as soon as at arrives, but that won't allow the peer to send unordered data due to an overall limited flow control window. Future extensions on QUIC (like the proposed datagram one) might change this.
- Ericson2314 6y ago
  You can create a new stream per datagram. Crazy, but it works.

mercer 6y ago

My apologies for just taking your comment as a jumping-off point, but could you or anyone else point me in the best (free) direction to properly learn about this whole stack of protocols? It's been very high on my list to finally figure out what sits below HTTP, and in a roundabout way my appetite has been whetted by reading a Claude Shannon biography and The Information (which I suppose aren't perhaps /that/ close to UDP and so on but more about information theory and error correction as a historical development), but those books made me really want to dive in and learn about the building blocks of 'the internet'. Any pointers to books, articles or courses would be very much appreciated!

deleted 6y ago
[deleted]
convolvatron 6y ago
the RFCs themselves are pretty accessible -ymmv. rfc 791 - internet protocol rfc 793 - transmission control protocol
starfallg 6y ago
TCP/IP Illustated Volume 1: The Protocols by W. R. Stevens is the classic textbook and a great place to start off. You can then read the IETF RFCs, which are usually well written and completely readable to anybody with a computing background.
- mercer 6y ago
  awesome, thanks for the recommendation!