12 ms·

TCP has some downsides which can not be fixed. And QUIC solves them by going below TCP. It just uses UDP because all other protocols are usually blocked and thu

TCP has some downsides which can not be fixed. And QUIC solves them by going below TCP. It just uses UDP because all other protocols are usually blocked and thus unusable. Transparent handover (when changing IP addresses) Multipath Multiplexing: No head-of-line blocking Faster handshake Enforce authentication and encryption (also of some metadata) Forward Error Correction and other improvements for wire less networks So the improvements are mostly noticeable for for mobile devices.

the8472 6y ago
There are some mistakes here. MPTCP definitely exists and has been deployed, which also encompasses handover. Faster handshake is covered by TFO in principle. FEC was only a proposal and has been dropped.
- JoshTriplett 6y ago
  > MPTCP definitely exists and has been deployed, which also encompasses handover. I wouldn't be surprised if many stacks and networks are able to deploy QUIC more easily than MPTCP.
baybal2 6y ago
> UDP because all other protocols are usually blocked and thus unusable. Well, UDP does not fare better on a lot of ISPs.
- the8472 6y ago
  If your ISP is blocking UDP and not just your router (which you can reconfigure if you want to use some other IP protocols) then you're arguably not on an Internet Service Provider at all, you're on some sort of WWW Service Provider.
  - manquer 6y ago
    Well that applies to any protocol , ISPs don’t block anything , your company usually do though . UDP is very commonly blocked in almost every corporate environment I have seen, it is a pain get it enabled for applications like video streaming which benefits from UDP
    - the8472 6y ago
      Well, then you don't have internet access in your company. Only some fossilized subset of internet. They have intentionally excluded themselves from any kind of progress, so arguing against any new kind of standard because some people deliberately exclude themselves from new standards is a non-argument in my opinion. It's like arguing against a developing new TLS version because people configure their firewalls to block any flavor of TLS they don't know.
      - dheera 6y ago
        4G LTE is a godsend when companies or schools block stuff.
      - iso947 6y ago
        There is a whole generation that have grown up woth ubiquitous “internet” access, but no concept that anything other than http(s) exists.
      - manquer 6y ago
        Even today I am forced to deploy TCP fallback pretty much everywhere, even with corporations "whitelist" us, mainly because they have many/many PoPs all over the world. There is no guarantee their system-wide policies is actually applied at a particular access point/ device for any number of reasons. It is particularly worse in consulting industry, This is usually because their customer actually controls the network/infra for the teams working with them, usually that means a lot of fragmented IT managment. This is from my experience deploying Flash / WebRTC stack video tools in Fortune 500/2000 type orgs in last 8-9 years. One of the main reasons we moved to WebRTC from Flash early on is because the heavy friction for deploying RTMP/RTMPS(E). I can count in one hand how many of them had sensible network polices. You may had a good experience with network policies, many many large organizations still insist on IE11 and restricted networks world around, that is the sad reality .
- vbezhenar 6y ago
  I don't think that's true. A lot of commonly used applications utilize UDP.
virattara 6y ago
> TCP has some downsides which can not be fixed. I guess the problem is more with getting to adopt the fixes on a large scale even if the downsides of TCP are fixed. > It just uses UDP because all other protocols are usually blocked UDP is also blocked on several firewalls because of the fear of UDP flood attacks, QUIC fallbacks to TCP in such cases.
starfallg 6y ago
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.
dehrmann 6y ago
I'm not sure if forward error correction works with UDP. UDP has a checksum field that's optional in IPv4, mandatory in IPv6 (why IPvAnything dictates anything in the transport layer is beyond me). Assuming you treat the checksum as absent and set it to zeros, it could still get added at any hop, and if that gets corrupted, the packet would be dropped. If routers either ignore the checksum or never add it in, it could work.
- p1mrx 6y ago
  UDP's checksum depends on information from the IP header, for both IPv4 and IPv6: https://en.wikipedia.org/wiki/User_Datagram_Protocol#Checksum_computation https://en.wikipedia.org/wiki/User_Datagram_Protocol#Checksu... Omitting the UDP/IPv4 checksum is permitted because the IPv4 header has its own redundant checksum, but omitting the UDP/IPv6 checksum would leave the IPv6 header with no checksum at all, which is why that's not permitted. https://en.wikipedia.org/wiki/UDP-Lite https://en.wikipedia.org/wiki/UDP-Lite lets you checksum the UDP/IP header plus an arbitrary (possibly zero-length) prefix of the payload, but I'm not sure if people actually use that.
- comex 6y ago
  I believe the "errors" in this context are generally not actual corrupted packets, which are rare, but dropped packets seen in the context of a larger data transmission.
nyanpasu64 6y ago
Is transparent handover in use in QUIC or HTTP/3 today? Can you start a large download or SSH session on Wi-Fi, switch to mobile data, and not break the connection?
- Matthias247 6y ago
  It's supported by the protocol. But I'm not sure if it's actually supported by anyone who deployed the protocol. It requires to actually support connection ID migration in the library (which not all of them do), as well as to support it on infrastructure (e.g. L4 load balancers): If those receive a packet belonging to the same connection, but having a new source IP address (due to client having migrated), they still need to route things to the same server which has all the state about the connection. Therefore the whole thing is rather hard to implement.

the8472 6y ago

There are some mistakes here. MPTCP definitely exists and has been deployed, which also encompasses handover. Faster handshake is covered by TFO in principle. FEC was only a proposal and has been dropped.

JoshTriplett 6y ago
> MPTCP definitely exists and has been deployed, which also encompasses handover. I wouldn't be surprised if many stacks and networks are able to deploy QUIC more easily than MPTCP.

baybal2 6y ago

> UDP because all other protocols are usually blocked and thus unusable. Well, UDP does not fare better on a lot of ISPs.

the8472 6y ago
If your ISP is blocking UDP and not just your router (which you can reconfigure if you want to use some other IP protocols) then you're arguably not on an Internet Service Provider at all, you're on some sort of WWW Service Provider.
- manquer 6y ago
  Well that applies to any protocol , ISPs don’t block anything , your company usually do though . UDP is very commonly blocked in almost every corporate environment I have seen, it is a pain get it enabled for applications like video streaming which benefits from UDP
  - the8472 6y ago
    Well, then you don't have internet access in your company. Only some fossilized subset of internet. They have intentionally excluded themselves from any kind of progress, so arguing against any new kind of standard because some people deliberately exclude themselves from new standards is a non-argument in my opinion. It's like arguing against a developing new TLS version because people configure their firewalls to block any flavor of TLS they don't know.
    - dheera 6y ago
      4G LTE is a godsend when companies or schools block stuff.
    - iso947 6y ago
      There is a whole generation that have grown up woth ubiquitous “internet” access, but no concept that anything other than http(s) exists.
    - manquer 6y ago
      Even today I am forced to deploy TCP fallback pretty much everywhere, even with corporations "whitelist" us, mainly because they have many/many PoPs all over the world. There is no guarantee their system-wide policies is actually applied at a particular access point/ device for any number of reasons. It is particularly worse in consulting industry, This is usually because their customer actually controls the network/infra for the teams working with them, usually that means a lot of fragmented IT managment. This is from my experience deploying Flash / WebRTC stack video tools in Fortune 500/2000 type orgs in last 8-9 years. One of the main reasons we moved to WebRTC from Flash early on is because the heavy friction for deploying RTMP/RTMPS(E). I can count in one hand how many of them had sensible network polices. You may had a good experience with network policies, many many large organizations still insist on IE11 and restricted networks world around, that is the sad reality .
vbezhenar 6y ago
I don't think that's true. A lot of commonly used applications utilize UDP.

virattara 6y ago

> TCP has some downsides which can not be fixed. I guess the problem is more with getting to adopt the fixes on a large scale even if the downsides of TCP are fixed. > It just uses UDP because all other protocols are usually blocked UDP is also blocked on several firewalls because of the fear of UDP flood attacks, QUIC fallbacks to TCP in such cases.

starfallg 6y ago

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.

dehrmann 6y ago

I'm not sure if forward error correction works with UDP. UDP has a checksum field that's optional in IPv4, mandatory in IPv6 (why IPvAnything dictates anything in the transport layer is beyond me). Assuming you treat the checksum as absent and set it to zeros, it could still get added at any hop, and if that gets corrupted, the packet would be dropped. If routers either ignore the checksum or never add it in, it could work.

p1mrx 6y ago
UDP's checksum depends on information from the IP header, for both IPv4 and IPv6: https://en.wikipedia.org/wiki/User_Datagram_Protocol#Checksum_computation https://en.wikipedia.org/wiki/User_Datagram_Protocol#Checksu... Omitting the UDP/IPv4 checksum is permitted because the IPv4 header has its own redundant checksum, but omitting the UDP/IPv6 checksum would leave the IPv6 header with no checksum at all, which is why that's not permitted. https://en.wikipedia.org/wiki/UDP-Lite https://en.wikipedia.org/wiki/UDP-Lite lets you checksum the UDP/IP header plus an arbitrary (possibly zero-length) prefix of the payload, but I'm not sure if people actually use that.
comex 6y ago
I believe the "errors" in this context are generally not actual corrupted packets, which are rare, but dropped packets seen in the context of a larger data transmission.

nyanpasu64 6y ago

Is transparent handover in use in QUIC or HTTP/3 today? Can you start a large download or SSH session on Wi-Fi, switch to mobile data, and not break the connection?

Matthias247 6y ago
It's supported by the protocol. But I'm not sure if it's actually supported by anyone who deployed the protocol. It requires to actually support connection ID migration in the library (which not all of them do), as well as to support it on infrastructure (e.g. L4 load balancers): If those receive a packet belonging to the same connection, but having a new source IP address (due to client having migrated), they still need to route things to the same server which has all the state about the connection. Therefore the whole thing is rather hard to implement.