3 ms·

In regards to the gains, these results are without 0-RTT, so I expect the gains with 0-RTT to be substantially larger. The numbers include total application la

In regards to the gains, these results are without 0-RTT, so I expect the gains with 0-RTT to be substantially larger. The numbers include total application latency, not just the latency introduced by the network, so the improvement to the network latency is larger. As such, applications that are more sensitive to network latency would show larger improvements. Thanks, Ian Disclosure: I authored the post

StefanKarpinski 6y ago
If I understand the benefits of HTTP/3 correctly, this post also doesn't address one of the major ones: seamless connection handoff during client mobility. Earlier HTTP versions are TCP-based, so if the IP address of a mobile client changes, e.g. because of moving from one cell tower to another or from wifi to/from cell, then the application layer has to notice the lost connection, create a new connection, and move whatever application-level context there is to the new connection. Not all applications do this, and even when they do, it's slow. If my understanding is correct, with HTTP/3 that's no longer necessary — the same HTTP/3 connection can migrate from one IP address to a different one. Another benefit that isn't measured in this post but has been mentioned elsewhere in the comments here is that the experience on flaky wireless connections (without changing IPs) should be much better. TCP was designed on the premise that packet loss almost never due to physical failure to transmit a packet, and almost always due to routers queues being full (i.e. network congestion). Wireless networks violate this assumption badly: physical-layer issues are the most likely cause of packet loss on a wireless connection. TCP reacts to wifi packet drops by backing off, assuming that some router is overloaded, but the routers are fine — it's just last hop signal that's bad. In those circumstances, the client should just try again instead of throttling the connection to nothing. Since HTTP/3 uses UDP, it can potentially handle dropped packets more appropriately.
- nh2 6y ago
  On your first point, why is it necessary to switch IPs when switching between cell tower? Doesn't the cell ISP manage the IP anyway, thus making it easy to keep it from one tower to the next? On your second point, it's configurable how TCP reacts to packet loss. For example, wasn't BBR congestion control made to address exactly that case?
  - judge2020 6y ago
    I think at least a few network already make an attempt to maintain IPs, at least when the new cell tower goes to the same backbone, but the problem isn't that your IP address changes - it's that the TCP connection itself is no longer there. Transferring an IP is easier than transferring a TCP connection and ensuring all packets are received and ordered correctly between the two towers.
    - jsnell 6y ago
      Every single mobile network will maintain IP addresses when migrating between cells. The IP address is not a property that the base stations care about at all, it's generally tied to the PDP context maintained by the GGSN/PGW, which will generally not be invalidated unless the connection is idle. Mobile operators will only have a handful of core networks even in large countries; having a subscriber move from the area covered by one core network to another would be quite rare. Switching between cells will cause a latency spike, and a lot of correlated packet loss if the subscriber has a large queue of undelivered data, but that's all. But handling packet loss and ordering are what TCP is supposed to do. I have no idea of what you mean by "the TCP connection is no longer there". The TCP connection is a distributed system living on the client and the server. It doesn't go away unless one of the endpoints decides so. (Modulo stateful middleboxes, like NATs. But nobody in their right mind would run a TCP state-aware middlebox on a cellular network base station). IP changes are relevant when switching networks entirely, like going from WiFi to mobile.
      - tialaramex 6y ago
        Yup. One type of roaming that does trigger for smartphones and similar devices is WiFi->4G/5G->WiFi. You're at home, obviously you don't want expensive mobile network data charges when you've got WiFi. So the connection is over WiFi. But as you walk out the door, currently your application software needs to spot that the WiFi is going away (not too hard), connect over the mobile network (unless your policies say to give up instead to save money) and keep going. QUIC would allow this to be done transparently at the transport layer, at least in some cases. When you reach a coffee shop/ friend's place/ work and there's WiFi again, the opposite transition saves you money and if you go indoors and signal is weaker may also be necessary to deliver a working network.

StefanKarpinski 6y ago

If I understand the benefits of HTTP/3 correctly, this post also doesn't address one of the major ones: seamless connection handoff during client mobility. Earlier HTTP versions are TCP-based, so if the IP address of a mobile client changes, e.g. because of moving from one cell tower to another or from wifi to/from cell, then the application layer has to notice the lost connection, create a new connection, and move whatever application-level context there is to the new connection. Not all applications do this, and even when they do, it's slow. If my understanding is correct, with HTTP/3 that's no longer necessary — the same HTTP/3 connection can migrate from one IP address to a different one. Another benefit that isn't measured in this post but has been mentioned elsewhere in the comments here is that the experience on flaky wireless connections (without changing IPs) should be much better. TCP was designed on the premise that packet loss almost never due to physical failure to transmit a packet, and almost always due to routers queues being full (i.e. network congestion). Wireless networks violate this assumption badly: physical-layer issues are the most likely cause of packet loss on a wireless connection. TCP reacts to wifi packet drops by backing off, assuming that some router is overloaded, but the routers are fine — it's just last hop signal that's bad. In those circumstances, the client should just try again instead of throttling the connection to nothing. Since HTTP/3 uses UDP, it can potentially handle dropped packets more appropriately.

nh2 6y ago
On your first point, why is it necessary to switch IPs when switching between cell tower? Doesn't the cell ISP manage the IP anyway, thus making it easy to keep it from one tower to the next? On your second point, it's configurable how TCP reacts to packet loss. For example, wasn't BBR congestion control made to address exactly that case?
- judge2020 6y ago
  I think at least a few network already make an attempt to maintain IPs, at least when the new cell tower goes to the same backbone, but the problem isn't that your IP address changes - it's that the TCP connection itself is no longer there. Transferring an IP is easier than transferring a TCP connection and ensuring all packets are received and ordered correctly between the two towers.
  - jsnell 6y ago
    Every single mobile network will maintain IP addresses when migrating between cells. The IP address is not a property that the base stations care about at all, it's generally tied to the PDP context maintained by the GGSN/PGW, which will generally not be invalidated unless the connection is idle. Mobile operators will only have a handful of core networks even in large countries; having a subscriber move from the area covered by one core network to another would be quite rare. Switching between cells will cause a latency spike, and a lot of correlated packet loss if the subscriber has a large queue of undelivered data, but that's all. But handling packet loss and ordering are what TCP is supposed to do. I have no idea of what you mean by "the TCP connection is no longer there". The TCP connection is a distributed system living on the client and the server. It doesn't go away unless one of the endpoints decides so. (Modulo stateful middleboxes, like NATs. But nobody in their right mind would run a TCP state-aware middlebox on a cellular network base station). IP changes are relevant when switching networks entirely, like going from WiFi to mobile.
    - tialaramex 6y ago
      Yup. One type of roaming that does trigger for smartphones and similar devices is WiFi->4G/5G->WiFi. You're at home, obviously you don't want expensive mobile network data charges when you've got WiFi. So the connection is over WiFi. But as you walk out the door, currently your application software needs to spot that the WiFi is going away (not too hard), connect over the mobile network (unless your policies say to give up instead to save money) and keep going. QUIC would allow this to be done transparently at the transport layer, at least in some cases. When you reach a coffee shop/ friend's place/ work and there's WiFi again, the opposite transition saves you money and if you go indoors and signal is weaker may also be necessary to deliver a working network.