5 ms·

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

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.

coddle-hark 6y ago
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.
- Matthias247 6y ago
  > 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.
  - coddle-hark 6y ago
    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 https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html
    - Matthias247 6y ago
      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).
- withinboredom 6y ago
  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.
  - coddle-hark 6y ago
    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.

coddle-hark 6y ago

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.

Matthias247 6y ago
> 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.
- coddle-hark 6y ago
  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 https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html
  - Matthias247 6y ago
    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).
withinboredom 6y ago
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.
- coddle-hark 6y ago
  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.