Hacker News Reader

Comment by coddle-hark | Hacker News Reader

I’m not an expert but QUIC doesn’t seem like enough of an improvement over TCP to warrant replacing it, especially given that it’s even more complex.

- 0-RTT handshakes are great but there’s still the problem of slow start.

- QUIC’s congestion control mechanism is pretty much the same as TCP’s and doesn’t perform particularly well over e.g. mobile networks.

- Mandatory TLS means it’s going to be a huge PITA if you ever need to run a quic service locally (say, in a container).

- Having it in user space means there’a a good chance we’ll end up with 100s of implementations, all with their own quirks. It’s bad enough trying to optimise for the three big TCP stacks.

View on HN

As another user stated, the biggest advantage of QUIC is how much more sense it makes for wireless communications and mobile devices. Mobile networks break TCP connections all the time, it just violates too many useful assumptions of TCP.

HTTP/3's WebTransport (i.e. gRPC + sessions) defines a Session far more logically than a TCP Connection + your ad-hoc in-application Session does.

The predecessors of WebTransport already appear every everywhere in low-latency and realtime networked applications, like games, chat and video, on mobile devices. Typically that is achieved using UDP + an ad-hoc session management and authentication protocol. Or worse, undoing TCP connections and managing sessions on top of TCP connection breaks (as most dual web + native applications do).

Why reinvent that clumsy stuff over and over again instead of having it standardized? TCP is already dead on mobile, for many of the most popular applications people actually use.

My day job is providing internet connectivity to trains/busses/boats in remote areas over cellular modems. I couldn’t agree more that TCP over mobile networks is a non-starter, I just wish they’d done more than implement TCP over UDP. In terms of mobile performance, QUIC isn’t much better than TCP over a Wireguard VPN.

> QUIC isn’t much better than TCP over a Wireguard VPN.

Why? One of the main intends of QUIC is imho to be better in this scenarios. E.g. by handling retransmission and loss detection in a different fashion than TCP.

It handles congestion control slightly differently since it can estimate the Round Trip Time more accurately, but it’s essentially the same ACK based mechanism that TCP uses. The current draft [0] from the QUIC working group basically describes TCP NewReno (the authors say so themselves).

[0] https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html

Yes, congestion control is based on New Reno. But I think there are some higher level pieces where Quic is more flexible, and which can lead to higher performance on lossy links. E.g. has the ability to repackage data that was assumed lost in previous datagrams, and combine it with new data - leading to less total transmitted data in that cases. It doesn't have to retransmit every packet in exactly the same fashion. Some Quic implementation make use of this ability - while others don't.

And it might also have a bit more flexibility when to retransmit (but I'm not an expert).

It’s not hard to make a transparent proxy talk over udp to a POP and avoid TCP issues altogether. I did this for a satellite based internet service I ran back in 09, mostly for fun and profit. Never thought it could be something worth selling because it was so simple.

Nope, that’s the easy part! You don’t avoid TCP issues altogether though, all the usual behaviours of TCP are still there with respect to packet loss, latency, jitter etc.

To be fair the real problem is not mandatory TLS, it’s mandatory WebPKI certs: self-signed certs are not a problem in a local docker container, and is not worse than unencrypted.

Isn't there a performance burden?

Supposedly not (vs TCP/TLS), at least not in the Google implementation (haven't read anything about the IETF version). And with 0-RTT, when it comes out, you gain some performance back anyway by not having to re-handshake on drops.

The comparison would be against TCP with no TLS, since the issue was mandatory encryption.

Some, but maybe less than you think if you're using OpenSSL and a computer less than ten years old (AES-NI and maybe PCLMULQDQ for GCM). Often something else (NIC, network) will be the bottleneck.

You still need to add those certs to a bunch of different places (browsers use their own certificate stores).

More importantly, I don’t think it’s a good idea to teach people to add self signed certs to their certificate stores willy-nilly. Seems like a good way to get pwned.

Well, there are other problems (even requiring encryption at all means some low-power clients can't use it because they lack the processing power), but X.509/WebPKI is the main one, followed by ciphersuite proliferation requiring dozens of times as much audited cryptographic code.

No head-of-line blocking is a pretty significant improvement.

Yes, but in reality you don’t want your page to load until all above the fold assets are loaded anyway. We went through this a couple of years ago with increasingly complicated techniques to avoid the dreaded “flash of unstyled content”.

Head-of-line blocking is only a problem if you’re multiplexing connections. Just open one TCP socket per request and you’ll never have head of line blocking. There are issues with opening multiple TCP sockets of course (mainly Slow Start) but these aren’t insurmountable.

You do want to download multiple assets like images in parallel over the same connection since you can’t open that many connections per domain.

That’s not a fundamental limitation of TCP though. You can theoretically open 4294967296 sockets between two machines (with one IP address per machine) and a beefy machine can handle >1M concurrent connections.

They’ve already proposed adding HTTPS and SVCB DNS records for performance, it would be easy enough to implement a ICANTAKEIT record that lets the browser know it’s OK to open as many sockets as it needs.

It's a bigger lift than just switching from TCP to QUIC though.

And there's other reasons you wouldn't want to use as many connections as you have assets to download; each connection has startup overhead.

N connections have the same startup overhead as a single connection though, since they’re made in parallel.

A single (TCP) connection has a single SYN and SYN-ACK packet of startup overhead. N connections have N SYN packets and N SYN-ACKs. That might still not be very much overhead, but it is more.

You’re right, of course, there’s a (teeny tiny) cost for the handshakes but what I meant was that the performance overhead will be zero.

The performance overhead will not be zero. You're spending more computational power and memory opening up and maintaining a larger number of connections, and you're sending more packets and bits over the network in total because each additional connection has non-zero overhead.

> (teeny tiny) cost for the handshakes

What happens when your ping time is >500ms?

> was that the performance overhead will be zero

I think QUIC is motivated by Google's expansion into developing markets (China, India, etc). These areas are primarily mobile markets that would like to consume the same content we do. What might sound like small overhead (SYN->SYN-ACK) actually takes half a second. If your performance is measured in this way than N connections times half a second is a long time. And, on mobile networks, sometimes your TCP connection will drop even if there's still data being sent back and forth (some times you can see latency spikes up to 3sec on really bad networks which causes most software to timeout since it thinks no data came in because of head-of-line blocking).

It's a truely miserable experience that QUIC or HTTP/3 can easily solve. Imagine how slow an `apt update && apt upgrade` is and how much of that overhead can be dropped by connecting to 1 mirror a single time and bulk requesting 10 to 100 file transfers. This allows you to maximize your network throughput. Think instead of how slow this would be if you opened 10 to 100 connections each of which might take 500ms per startup. In the worst case that's a 500ms penalty versus a 5 second penalty.

> What happens when your ping time is >500ms?

Actually, that's not a problem with one reused connection versus N simultaneous connections (as coddle-hark said, the connections are made in parallel). It's a problem with how many round trips it takes to set up each connection.

When you open and depend on N connections, your total time is now linked to the worst performing of those N connections. As N increases, so does the latency, because it’s a long tail.

The same holds for N QUIC streams though.

You need much fewer QUIC streams to move the same amount of total files than you need TCP connections, because each stream handles multiple files.

There are many things that use HTTP that are not web browsers. Things like S3, for example, can make use of no head of line blocking by allowing multiple file transfers, multiple pagination requests, etc. Even APIs can benefit from this by using bidirectional streaming.

Games can now also be built over a REST-like API using separate channels for different priority messages: movement, world state, chat, etc. Since you don't need to worry about blocking you get way better performance. Almost every game engine networking component essentially implements TCP-over-UDP just to get application level control over these functions.

You can do all of that, except for the application level control, by just opening multiple TCP sockets. QUIC is just basically TCP over UDP in that it shares the same semantics (guaranteed, in order delivery of a bidirectional data stream with congestion control). Sure, game engines don’t always want all those attributes - guaranteed delivery, for example - and will implement their own thing over UDP that makes more sense for them. QUIC is just as bad as TCP for those use cases though!

The benefit is that you can open up as many channels within a connection as you want so you obtain the same abilities as you'd normally implement in a game engine.

No, you wouldn’t. You can’t turn off retransmissions in QUIC, for instance.

Or we'll have new tooling which makes it simple to enable SSL locally.

Dev and prod should be as similar as possible anyway.

Sure, I can create a self-signed certificate and copy it to my docker container and update the app’s config to use it and add it to the system’s certificate store and then add it to every browser’s certificate store every time I need to run something over QUIC locally. And sure, maybe one day there will be a tool that can do a that automatically.

But like... why?

A lot of browsers already expect tls to enable specific features. I've had things break between dev and prod because of a lack of tls on the backend as well.

It's also one of those things that once you sort it out it's no longer a problem. Like "why do I need to setup all this complex stuff to manage a dependancy? Just give me your source code and let me `gcc -o binary a.c b.c ....`"

In reality once you solve a problem with an ergonomic solution and the solution improves your alignment with production and comes at no real cost it's a win/win/win.

Mostly browsers require Secure Context rather than TLS, so http://127.0.0.1/ which is a secure context is fine.

Browsers have for some time behaveD quite differently when using HTTPS vs HTTP, particularly if you’re not navigating to precisely http://localhost (e.g. if your dev environment needs multiple domains). In particular a lot of newer browser features will refuse to work, and you won’t be able to see any HTTP/2 specific issues (e.g. header case) either.

I started using mkcert for this. It's trivially easy to use and fixes all the weird quirks of http vs https:

https://blog.filippo.io/mkcert-valid-https-certificates-for-...

https://github.com/FiloSottile/mkcert

This should be the user's choice, not Google's.

And its not, its the IETF since whats being discussed here is the IETF version not Google's. Is was their choice to adopt QUIC for HTTP/3 and standardized it. If you don't like the IETF then its another matter. Just point you pitchfork the right way.

"The Internet Engineering Task Force is an open standards organization, which develops and promotes voluntary (my emphasis) Internet standards, in particular the standards that comprise the Internet protocol suite." No one is twisting the arms of Google or browser/tooling implementers. Did I miss a flag where this can be disabled on the browser? If so, that's my fault! But if not, that's my point.

> - Having it in user space means there’a a good chance we’ll end up with 100s of implementations, all with their own quirks. It’s bad enough trying to optimise for the three big TCP stacks.

Big QUIC implementors have all used the interop runner, intended to prevent exactly that:

https://interop.seemann.io/

And it’s open source: https://github.com/marten-seemann/quic-interop-runner

Isn't there an exception explicitly for localhost?

Not that I know of.

What does QUIC solve then?

Removes the overhead and blocking of TCP while providing redundancy for the packet loss of UDP.

That’s not quite right. It greatly reduces the handshake time for new connections, but it adds more network overhead (more bytes sent) than TCP. TCP doesn’t “block” any more than QUIC.

It also allows for multiple concurrent encrypted streams while just doing one handshake.

HTTP/2 also allowed this, but suffered from head-of-line blocking between those multiplexed connections. Quic streams are independent. One Stream can still make progress if datagrams which contained data for another stream got lost.

Multiple concurrent encrypted streams with a single handshake isn’t much of a win though. N concurrent TLS connections won’t be any slower than a single TLS connection since the requests can be done in parallel.

In a world with variable ping times and packet loss that is a bold lie.

How so? Surely the variable ping times and packet loss affect both scenarios equally?

How can that remotely be true? It's easy to forget in a world where the internet has defacto concentrated into the hands of a select few CDNs, but behind each of those CDNs are origin servers, serving the content to those CDNs. Servers can be housed in different data centres, different countries, etc. Specific servers can have hardware issues or be congested, while others remain unaffected, etc.

But with QUIC you run the risk of all streams going to a server with hardware issues, congestion etc. It’s not clear to me that that’s any better?

Even if you can achieve comparable performance on N concurrent TLS connections (which I actually think you can), you have a high additional cost of establishing those N connections.

For a lot of systems the TLS handshake is the most expensive part of an operation. Reducing the amount of TLS handshakes by N can literally reduce cost by up to N in those systems.

> Mandatory TLS means it’s going to be a huge PITA

Let's Encrypt!

Let’s Encrypt can’t generate certificates for localhost, much less containers accessed via a local network.

Sure, you can get anything to work, but it WILL be a huge PITA.

Let's Encrypt can generate certificates for your.domain. your.domain can in turn resolve to localhost. I've been using Let's Encrypt for websites behind a VPN for several years.

Yes, of course, and that might make sense in a production setting. Those certificates expire after 90 days though, do you really want to have to edit your dns records every 90 days? To run something locally?

Why would I have to edit dns records manually? I have a cron job that tries to renew the certificate once a day. There is no manual work involved.

In that case you’re using either HTTP or TLS verification, which only works if you have a public static ip/port that LE can access. You can’t do that from behind a NAT without port forwarding and you generally don’t want your local docker machines to be accessible to the internet.

Unless your cron script is doing some funky DNS altering, that is.

All of the DNS altering is performed automatically by lego [1] which has support for a large number of DNS providers.

[1] https://github.com/go-acme/lego [2] https://go-acme.github.io/lego/dns/

Oh, that’s cool, I hadn’t heard of lego before! But still, you shouldn’t need to buy a domain to do stuff locally on your own device and it adds quite a bit of complexity.

The only thing we care about is that there's just one authoritative name hierarchy, if somebody in the name hierarchy wants to give you a name without selling it, that would be totally fine.

I would totally be down with say, the US government issuing citizens with a DNS name under their ccTLD somewhere. Done your tax paperwork in reasonable time? Your name is guaranteed by law to keep working for another year. Maybe 1480219643.ny.citizen-names.us is ugly but it'd satisfy this problem for individuals. Maybe they could bolt on a checkbox, $50 extra to the IRS and you get to pick any as-yet unreserved legal name, or they have rules like for license plates.

> it'd satisfy this problem for individuals.

No, it wouldn't, because that involves interacting with the public DNS hierarchy.

> you shouldn't need to buy a domain to do stuff locally on your own device [emphasis added]

Put the emphasis on the word "buy" instead, because they were describing a situation where you don't need to buy.

There are also free dynamic dns providers that let you set txt records and get certificates. But of course you can't depend on one of those to last forever.

I do the following:

1. have the domain in question resolve to a server with a public IP

2. have that server generate the certs with any ACME client with HTTP challenge

3. have that server ship the certs to the actual server hosting the service via intranet

4. in the intranet, have the domain resolve to the actual server via /etc/hosts override

All of that is not that hard to set up even at scale with proper config management tools. Having said that, I don't actually use it for that many services myself. The most significant one is LDAPS.

I'm also doing this.

I have a wildcard certificate for *.local.example.com (and local.example.com), and a local DNS server which resolves all the subdomains of local.example.com.

All local servers share the same certificate and it gets refreshed automatically every 2 months. local.example.com has a public NS entry to a custom nameserver which only exists so that letsencrypt can perform the DNS validation for that domain (and its subdomains).

This way I can use server-1.local.example.com, server-2.local.example.com, workstation-1.local.example.com internally with TLS.

And we should be thankful that workflow is supported by LE. I just don’t think it’s a reasonable expectation that people will buy a domain and host a public nameserver so they can run QUIC on localhost.

ACME supports multiple challenge types. The most popular is the HTTP-01 challenge, but there is also the DNS-01 challenge (via TXT record) which allows validation without exposing your webserver to the internet.

You can point a CNAME somewhere, where you have e.g. https://github.com/joohoi/acme-dns which is meant just for this. There are even providers (listed later in the README linked), that you can use this with, without managing another software.

Reply on news.ycombinator.com