4 ms·

> especially with changing networks like mobile In particular QUIC contains everything necessary to continue connections after the client's IP address (any one

> especially with changing networks like mobile In particular QUIC contains everything necessary to continue connections after the client's IP address (any one side really, but the other side has to find it) changes, which is helpful when devices change between networks without needing a Mobile IP-style bouncer.

mholt 8y ago
Except no mobile devices use this yet :(
- dweekly 8y ago
  Plenty of mobile devices use QUIC. The OS only needs to support UDP (which I believe all do) and applications that use QUIC will work.
- zlynx 8y ago
  My Pixel 2 running the Hangouts app transparently switches between home WiFi, LTE and xfinity WiFi (Comcast's attempt to make every one of their customers into a WiFi hotspot). The Hangout connection doesn't drop. It may go fuzzy/staticy before the WiFi drops in favor of LTE but that's all.
deleted 8y ago
[deleted]
eridius 8y ago
Doesn't Multipath TCP already exist as a solution for this?
- ianlevesque 8y ago
  Indeed. I’m not sure why adoption is so poor on that.
  - toast0 8y ago
    It's only available on apple iOS and maybe Mac OS out of the box. Android is probably not going to support it; if Android does support it, it will be a long time before there's critical mass and early versions may claim to support it, but not work well, and it may be hard to selectively enable it, and we know many devices won't get the updates to fix it. It's expensive to support on servers because (to my knowledge) there's not a good way to ensure related sub flows arrive at the same nic rx queue on the same server in real world load balancing situations, which is critical for performance. Nobody else is doing it (other than Apple for Siri), so it's not clear what the benefits are.
    - ianlevesque 8y ago
      It's weird that Android wouldn't support it, it was developed for linux first.
- manigandham 8y ago
  That's very inefficient as it is essentially creating backup TCP connections to get around the fact that TCP might not behave well in certain situations. On mobile, it is meant to use an entirely separate network backbone (wifi vs LTE) so doesn't offer much benefits when you're limited to a single type.
yardstick 8y ago
In practice I’ve seen poor handling in Chrome on desktop when the router changes WAN IP. Chrome reports ERR_NETWORK_CHANGED rather than do something sensible — this problem doesn’t exist in HTTP/1.x. I assume it should just be reconnecting — or the server should be using the connection ID field properly.

mholt 8y ago

Except no mobile devices use this yet :(

dweekly 8y ago
Plenty of mobile devices use QUIC. The OS only needs to support UDP (which I believe all do) and applications that use QUIC will work.
zlynx 8y ago
My Pixel 2 running the Hangouts app transparently switches between home WiFi, LTE and xfinity WiFi (Comcast's attempt to make every one of their customers into a WiFi hotspot). The Hangout connection doesn't drop. It may go fuzzy/staticy before the WiFi drops in favor of LTE but that's all.

deleted 8y ago

[deleted]

eridius 8y ago

Doesn't Multipath TCP already exist as a solution for this?

ianlevesque 8y ago
Indeed. I’m not sure why adoption is so poor on that.
- toast0 8y ago
  It's only available on apple iOS and maybe Mac OS out of the box. Android is probably not going to support it; if Android does support it, it will be a long time before there's critical mass and early versions may claim to support it, but not work well, and it may be hard to selectively enable it, and we know many devices won't get the updates to fix it. It's expensive to support on servers because (to my knowledge) there's not a good way to ensure related sub flows arrive at the same nic rx queue on the same server in real world load balancing situations, which is critical for performance. Nobody else is doing it (other than Apple for Siri), so it's not clear what the benefits are.
  - ianlevesque 8y ago
    It's weird that Android wouldn't support it, it was developed for linux first.
manigandham 8y ago
That's very inefficient as it is essentially creating backup TCP connections to get around the fact that TCP might not behave well in certain situations. On mobile, it is meant to use an entirely separate network backbone (wifi vs LTE) so doesn't offer much benefits when you're limited to a single type.

yardstick 8y ago

In practice I’ve seen poor handling in Chrome on desktop when the router changes WAN IP. Chrome reports ERR_NETWORK_CHANGED rather than do something sensible — this problem doesn’t exist in HTTP/1.x. I assume it should just be reconnecting — or the server should be using the connection ID field properly.