5 ms·

QUIC: let's build an application-specific protocol on top of UDP and call it a day. So really, is it faster? Does it reduce the amount of load on network devic

by mannyv 3y ago

QUIC: let's build an application-specific protocol on top of UDP and call it a day. So really, is it faster? Does it reduce the amount of load on network devices? Does it allow a server to serve more connections more quickly than the equivalent HTTP/2.0 stack? Does it make my web app faster? I mean, for 99% of Wordpress sites the problem is Wordpress, not the transport protocol. For a lot of the web the problem is client-side rendering issues. QUIC may solve a problem, but is it a problem in real life or a thought experiment that got folded into a standard?

miohtama 3y ago
Most of the web traffic is BigTech and big 5 and they see significant cost and energy reductions using QUIC. Nobody cares about Wordpress sites, as it does not make a dent.
- jeffbee 3y ago
  And most of the flows on this planet are inside hyperscaler datacenters. QUIC demonstrably solves problems that TCP causes inside datacenters.
- lxgr 3y ago
  If your Wordpress site is hosted by one of the big hosting providers and/or behind Cloudflare, it's quite likely to already use QUIC.
lxgr 3y ago
> Does it reduce the amount of load on network devices? This is not a goal of QUIC: Ideally, network devices between two TCP hosts don't do anything to TCP segments that they wouldn't also do to UDP datagrams, so there shouldn't be much difference. > I mean, for 99% of Wordpress sites the problem is Wordpress, not the transport protocol. Addressing Wordpress problems or rendering issues is also not really a stated goal of QUIC. It does solve some real TCP inefficiencies though, especially when used on older OS/kernel versions that'll probably never be updated to make use of some of the newer developments there (Bufferbloat avoidance is a big one, for example). These might not be very high on your list, but they absolutely are on someone's. And as long as you don't host your own webserver, you don't need to do anything to benefit from the results, since your hoster/CDN/proxy will just transparently provide them for you.
winstonprivacy 3y ago
I don't have benchmarks but I built a protocol that QUIC later turned out to be eerily similar to. It was a direct replacement for TCP and we used it to provide an additional layer of encryption for all traffic on a given network between two points. Latency was exceptionally improved. Web pages felt like the loaded faster and at the very least, users could not tell that they were using an encrypted connection. The protocol essentially worked using a fast-ACK protocol that would preemptively request retransmits (and was occasionally wrong). This enabled it to use connectionless UDP protocol as the underlying transport mechanism. There is, of course, a cost for reduced latency. That cost was slightly higher bandwidth utilization on the network. This was suboptimal for long-lived streams (media and other downloads) so we tried to fault over to ordinary TCP in these instances.
contravariant 3y ago
From the diagram they draw QUIC is supposed to solve transport layer problems (reliability, congestion, security). Perhaps some session layer issues slip in as well, but it looks like you don't have to put HTTP on top of it. I have no clue why it's built on UDP though, do we just accept that the time has passed for truly new network protocols?
- adgjlsfhk1 3y ago
  It's built on UDP because UDP is simple enough to basically be perfect. It's header is 8 bytes, of which the first 6 are obviously necessary and the last 2 are pretty nice. If you were re-doing the protocol, how would you change it to be more efficient?
  - contravariant 3y ago
    You say they are obvious but it seems to me that the source port and destination port of UDP are going to be fixed for QUIC, so I'm not too sure those are necessary. Especially since QUIC has connection IDs instead. I don't know QUIC on a deep enough level to figure out if the length and checksum are still needed. I mean I get why you'd tunnel it through a UDP connection, since replacing every single router on the planet no longer seems feasible, but if you want to call it a transport level protocol that's kind of what you'd have to do.
- doublepg23 3y ago
  > I have no clue why it's built on UDP though, do we just accept that the time has passed for truly new network protocols? Yes. According to my research, the Internets middleboxes are ossified and if they see a packet that’s not UDP or TCP they will silently drop it. SCTP was an past attempt to introduce a new protocol AFAIK https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
standardly 3y ago
Combining the TLS and TCP handshakes into a single request amounts to probably less than 50ms latency. For a major web hosting provider, this might add up. For most just cases, it's trivial.
- adgjlsfhk1 3y ago
  50ms in the good case, but for people halfway across the world or on a slow connection (e.g. geostationary satellite or bad 4g) each round trip can pretty easily be ~100-500ms. It's not about reducing server load, but improving user experience.
  - standardly 3y ago
    True. But, the application data is still going to be many more packets than the few you save during TCP/TLS setup. I imagine the user in that scenario would not see a significant difference, but I'd be curious to know for sure. Retransmits being smaller/less frequent is an improvement, but I'm not sure how much - latency due to geographic distance is pretty much built in. I just might google if there's any data on this. Since major providers are adoping it, I have to assume there is an improvement.

by mannyv 3y ago

miohtama 3y ago

Most of the web traffic is BigTech and big 5 and they see significant cost and energy reductions using QUIC. Nobody cares about Wordpress sites, as it does not make a dent.

jeffbee 3y ago
And most of the flows on this planet are inside hyperscaler datacenters. QUIC demonstrably solves problems that TCP causes inside datacenters.
lxgr 3y ago
If your Wordpress site is hosted by one of the big hosting providers and/or behind Cloudflare, it's quite likely to already use QUIC.

lxgr 3y ago

> Does it reduce the amount of load on network devices? This is not a goal of QUIC: Ideally, network devices between two TCP hosts don't do anything to TCP segments that they wouldn't also do to UDP datagrams, so there shouldn't be much difference. > I mean, for 99% of Wordpress sites the problem is Wordpress, not the transport protocol. Addressing Wordpress problems or rendering issues is also not really a stated goal of QUIC. It does solve some real TCP inefficiencies though, especially when used on older OS/kernel versions that'll probably never be updated to make use of some of the newer developments there (Bufferbloat avoidance is a big one, for example). These might not be very high on your list, but they absolutely are on someone's. And as long as you don't host your own webserver, you don't need to do anything to benefit from the results, since your hoster/CDN/proxy will just transparently provide them for you.

winstonprivacy 3y ago

I don't have benchmarks but I built a protocol that QUIC later turned out to be eerily similar to. It was a direct replacement for TCP and we used it to provide an additional layer of encryption for all traffic on a given network between two points. Latency was exceptionally improved. Web pages felt like the loaded faster and at the very least, users could not tell that they were using an encrypted connection. The protocol essentially worked using a fast-ACK protocol that would preemptively request retransmits (and was occasionally wrong). This enabled it to use connectionless UDP protocol as the underlying transport mechanism. There is, of course, a cost for reduced latency. That cost was slightly higher bandwidth utilization on the network. This was suboptimal for long-lived streams (media and other downloads) so we tried to fault over to ordinary TCP in these instances.

contravariant 3y ago

From the diagram they draw QUIC is supposed to solve transport layer problems (reliability, congestion, security). Perhaps some session layer issues slip in as well, but it looks like you don't have to put HTTP on top of it. I have no clue why it's built on UDP though, do we just accept that the time has passed for truly new network protocols?

adgjlsfhk1 3y ago
It's built on UDP because UDP is simple enough to basically be perfect. It's header is 8 bytes, of which the first 6 are obviously necessary and the last 2 are pretty nice. If you were re-doing the protocol, how would you change it to be more efficient?
- contravariant 3y ago
  You say they are obvious but it seems to me that the source port and destination port of UDP are going to be fixed for QUIC, so I'm not too sure those are necessary. Especially since QUIC has connection IDs instead. I don't know QUIC on a deep enough level to figure out if the length and checksum are still needed. I mean I get why you'd tunnel it through a UDP connection, since replacing every single router on the planet no longer seems feasible, but if you want to call it a transport level protocol that's kind of what you'd have to do.
doublepg23 3y ago
> I have no clue why it's built on UDP though, do we just accept that the time has passed for truly new network protocols? Yes. According to my research, the Internets middleboxes are ossified and if they see a packet that’s not UDP or TCP they will silently drop it. SCTP was an past attempt to introduce a new protocol AFAIK https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...

standardly 3y ago

Combining the TLS and TCP handshakes into a single request amounts to probably less than 50ms latency. For a major web hosting provider, this might add up. For most just cases, it's trivial.

adgjlsfhk1 3y ago
50ms in the good case, but for people halfway across the world or on a slow connection (e.g. geostationary satellite or bad 4g) each round trip can pretty easily be ~100-500ms. It's not about reducing server load, but improving user experience.
- standardly 3y ago
  True. But, the application data is still going to be many more packets than the few you save during TCP/TLS setup. I imagine the user in that scenario would not see a significant difference, but I'd be curious to know for sure. Retransmits being smaller/less frequent is an improvement, but I'm not sure how much - latency due to geographic distance is pretty much built in. I just might google if there's any data on this. Since major providers are adoping it, I have to assume there is an improvement.