4 ms·

I'm surprised that a major feature of QUIC isn't mentioned at all: Identification of session solely through connection IDs, unrelated to IP addresses. When you

I'm surprised that a major feature of QUIC isn't mentioned at all: Identification of session solely through connection IDs, unrelated to IP addresses. When you travel & change network, from WIFI to cellular, from one cellular tower to another, your phone / laptop often changes IP address, causing the TCP sessions to be directed into the void. Meaning, they wait until they timeout, then restart with new handshake. QUIC uses connection IDs to identify sessions independent of IP addresses, so a single packet from the new IP is enough to make the server switch to sending to the new IP without having to establish a new session at all. This is again mainly an issue for unstable connections when browsing (and fast travels in old cellular networks), and even then not a major problem, but still, it's pretty cool.

nikita2206 5y ago
I think it’s because it’s a network level session which isn’t very useful for the app level. Those connections are still ephemeral enough that you wouldn’t be able to treat their IDs as application’s session ID, you’d simply get randomly interrupted sessions otherwise.
- posix86 5y ago
  Agreed on the last point but isn't that the case for all improvements? From an application layer, all you see is a set of datastreams that are now less interrupted/delayed than before....
1vuio0pswjnm7 5y ago
CurveCP, also UDP-based, predates QUIC and can do this as well. https://curvecp.org/addressing.html https://curvecp.org/addressing.html "A CurveCP connection remains fully functional even if the client changes IP address."
- posix86 5y ago
  As it should be, in my opinion. A connection should be between hosts, and anything path related on a different abstraction layer.
p_l 5y ago
Funnily enough, technically ISO TP4 did the same (as you could in theory change the NSAPs - ISO network addresses - and keep the same reference numbers (which are used for matching connections)
frmdstryr 5y ago
This "feature" is also a major downside... protocol level user tracking. See https://svs.informatik.uni-hamburg.de/publications/2019/2019-07-17-Sy-A_QUIC_Look_at_Web_Tracking_PETS_2019.pdf https://svs.informatik.uni-hamburg.de/publications/2019/2019...
- mgrund 5y ago
  Absolutely not a coincident that Google is proposing a protocol that allows protocol level user tracking. By making the session ticket server-initiated and not client-controlled all control is also stripped from the user.
  - ithkuil 5y ago
    The clients are free to make another "connection" and get a new session id every time they want. It's similar to http connection reuse: the src ip-port + dst-port also acts as a "session identifier", as long as multiple requests flow throug the same TCP connection.
    - josefx 5y ago
      Browsers are also free to use per site caches instead of a global one and sadly we ended up with just that because it turns out you cannot trust the internet with user privacy in any way.
      - ithkuil 5y ago
        Yeah that's sad. My take was just that the problem is not caused by the transport protocol.
      - majewsky 5y ago
        Bad example. Browsers have had per-site caches since between 2013 (Safari) and 2020 (Chrome, Firefox).
- ilove196884 5y ago
bogomipz 5y ago
Would this be the equivalent of MPTC(multi-path TCP) in QUIC then? Can it be used for bandwidth aggregation as well?
- NavinF 5y ago
  Hopefully some day. I’m not aware of any HTTP3 implementations that do multipath today.

nikita2206 5y ago

I think it’s because it’s a network level session which isn’t very useful for the app level. Those connections are still ephemeral enough that you wouldn’t be able to treat their IDs as application’s session ID, you’d simply get randomly interrupted sessions otherwise.

posix86 5y ago
Agreed on the last point but isn't that the case for all improvements? From an application layer, all you see is a set of datastreams that are now less interrupted/delayed than before....

1vuio0pswjnm7 5y ago

CurveCP, also UDP-based, predates QUIC and can do this as well. https://curvecp.org/addressing.html https://curvecp.org/addressing.html "A CurveCP connection remains fully functional even if the client changes IP address."

posix86 5y ago
As it should be, in my opinion. A connection should be between hosts, and anything path related on a different abstraction layer.

p_l 5y ago

Funnily enough, technically ISO TP4 did the same (as you could in theory change the NSAPs - ISO network addresses - and keep the same reference numbers (which are used for matching connections)

frmdstryr 5y ago

This "feature" is also a major downside... protocol level user tracking. See https://svs.informatik.uni-hamburg.de/publications/2019/2019-07-17-Sy-A_QUIC_Look_at_Web_Tracking_PETS_2019.pdf https://svs.informatik.uni-hamburg.de/publications/2019/2019...

mgrund 5y ago
Absolutely not a coincident that Google is proposing a protocol that allows protocol level user tracking. By making the session ticket server-initiated and not client-controlled all control is also stripped from the user.
- ithkuil 5y ago
  The clients are free to make another "connection" and get a new session id every time they want. It's similar to http connection reuse: the src ip-port + dst-port also acts as a "session identifier", as long as multiple requests flow throug the same TCP connection.
  - josefx 5y ago
    Browsers are also free to use per site caches instead of a global one and sadly we ended up with just that because it turns out you cannot trust the internet with user privacy in any way.
    - ithkuil 5y ago
      Yeah that's sad. My take was just that the problem is not caused by the transport protocol.
    - majewsky 5y ago
      Bad example. Browsers have had per-site caches since between 2013 (Safari) and 2020 (Chrome, Firefox).
ilove196884 5y ago

bogomipz 5y ago

Would this be the equivalent of MPTC(multi-path TCP) in QUIC then? Can it be used for bandwidth aggregation as well?

NavinF 5y ago
Hopefully some day. I’m not aware of any HTTP3 implementations that do multipath today.