Hacker News Reader

Comment by posix86 | Hacker News Reader

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.

View on HN

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

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.

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.

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.

Yeah that's sad. My take was just that the problem is not caused by the transport protocol.

Bad example. Browsers have had per-site caches since between 2013 (Safari) and 2020 (Chrome, Firefox).

TLS has session resumption with exactly the same issues, it is just more efficient in QUIC.

CurveCP, also UDP-based, predates QUIC and can do this as well.

https://curvecp.org/addressing.html

"A CurveCP connection remains fully functional even if the client changes IP address."

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

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)

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

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

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.

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....

Reply on news.ycombinator.com