3 ms·

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 i

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.

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.