Hacker News Reader

Comment by Lichtso | Hacker News Reader

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.

View on HN

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.

> 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.

> 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.

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.

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.

Given how IPv6 went, a decade seems optimistic.

IPv6 had a really bad case of second system effect, though.

>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.

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.

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.

> 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.

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.

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.

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.

You can create a new stream per datagram. Crazy, but it works.

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!

the RFCs themselves are pretty accessible -ymmv.

rfc 791 - internet protocol

rfc 793 - transmission control protocol

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.

awesome, thanks for the recommendation!

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?

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.

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.

UDP's checksum depends on information from the IP header, for both IPv4 and IPv6: 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 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.

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.

> UDP because all other protocols are usually blocked and thus unusable.

Well, UDP does not fare better on a lot of ISPs.

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.

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

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.

4G LTE is a godsend when companies or schools block stuff.

There is a whole generation that have grown up woth ubiquitous “internet” access, but no concept that anything other than http(s) exists.

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 .

Do you know of any non-TCP, non-UDP, non-ICMP, etc services I can try out?

IPsec?

Expect it is not just configuration. It is hardware too. I am member in a internet provider by students. We couldn't allow an UDP since we have an agreement with our uplink that we will make it impossible to host outwards facing services. To guarantee that for UDP we would need a stateful firewall, which we didn't have. Due to agreements without uplink they want to have full access to our firewall and since they only use Cisco, we are required to do so too. This means we had to shell out €€€€€ to get a firewall from Cisco and we had to put aside money to do that for years. Then our (old) core router had 90%+ load during testing of the firewall since the hardware UDP support it supposedly had was not up for the task. So we had to buy a second core router where we lucky weren't bound to Cisco due to outside obligations another €€€€ investment. It's not just stupid configuration, sometimes it is just means and it takes long strategic planning we can do as a non-profit to afford such things.

> We couldn't allow an UDP since we have an agreement with our uplink that we will make it impossible to host outwards facing services.

Again, that agreement already means you're not providing internet service, even if you provided outgoing UDP you still would be violating the end to end principle. The hardware is just a consequence of wanting to be more (rather: less) than a dumb pipe.

So what are we then? I think we are better internet provider than any commercial one could be in the dorms we supply. Being an internet provider is being more than a dumb pipe. There are regulations too. We have to do customer service, keep up times, ... But according to you we are not an internet service provider.

I don't think that's true. A lot of commonly used applications utilize UDP.

Reply on news.ycombinator.com