[ATsch]

There's something else, performance aside, that's really exciting about HTTP/3: Fixing a decades old layering violation that has made truly mobile internet impossible.

In TCP, a connection is uniquely identified by the following tuple:

    (src ip, src port, dst ip, dst port)

The issue is that we depend not only on layer 4 details (port numbers) but also on layer 3 information (IP addresses). This means we can not ever keep a connection alive when moving from one network and hence IP address into another.

We can do some trickery to let people keep their addresses while inside of a network, but switch from mobile data to wifi and every TCP connection drops.

This is easy enough to solve, in theory. Give every connection an unique ID, and then remember the last address you received a packet for that connection from, ideally in the kernel. This makes IP addresses completely transparent to applications, just like MAC addresses are. However, the tuple is assumed almost everywhere and NAT makes new layer 4 protocols impossible. Unless you layer them over UDP. And this is exactly what Wireguard, QUIC, mosh and others do. Once it's ubiquitous, you'll be able to start an upload or download at home, hop on your bike, ride to the office, and finish it without the connection dropping once.

[rixed]

Part of me consider HTTP/3 as an application protocol and disagree with this. This is not a problem for HTTP to solve but a problem for the routing protocol to solve. Is it desirable to reinvent a routing protocol at the application layer, so that we can use it as another transport protocol and so on? Shouldn't we be using a single, unique 128bit address for every device regardless of which physical network it is attached to, by now? This is not a technological limitation: If the same operator would administer both local wifi and long distance GSM then of course you would not loose your IP, as you do not lose it when you hop from one GSM antenna to the next.

...and part of me think HTTP/3 could be that universal transport protocol that could eventually solve this problem, and then I agree.

[labawi]

I agree it would be appropriate to solve roaming on a lower layer, so any application can roam.

However, the solution should not and cannot be a global routing table. Aside from privacy issues, routing tables are very expensive. It needs to be decentralized, done on or at least near the endpoints, similar to programs like mosh, wireguard etc. Though there are certain security and privacy trade-offs in mentioned protocols that may not be appropriate.

[ATsch]

Yes, this shouldn't be done at the application layer. This is why it's done in QUIC, which is layer 4.5-ish. HTTP/3 runs on top of that.

The "flat address space" idea however is completely ridiculous. That would mean every node on the internet keeping track of the path to every singe other node. This is what ethernet does and it barely scales to ten or so thousand nodes. Routers are already struggling hard with the 700k table entries we have for the IPv4 internet. To the point where providers actually wrap IP packets inside of simpler protocols once they enter the network.

We need some kind of hierarchical addressing that expresses the location of a node in the network. We know this works. We just need the layers above not to rely on those addresses staying constant.

[DarkWiiPlayer]

> The "flat address space" idea however is completely ridiculous. That would mean every node on the internet keeping track of the path to every singe other node. This is what ethernet does and it barely scales to ten or so thousand nodes. Routers are already struggling hard with the 700k table entries we have for the IPv4 internet. To the point where providers actually wrap IP packets inside of simpler protocols once they enter the network.

If anything, we need a more hierarchical structure, with stricter separations by, e.g. Continent/Country/Province and possibly down to street or even house level, so routers can more easily just throw the data in the right general direction. Note the obvious privacy problem there.

[mcguire]

Each Ethernet interface has a unique address; using them is widely regarded as a privacy violation.

[ATsch]

That can be solved, but more importantly, Ethernet can not scale beyond 10k or so nodes because the addresses are meaningless and there's no way to tell what the next hop for an address you've never seen before should be beyond just sending it everywhere and hoping for the best. There's also no way to prevent spoofing, which would be a huge nuisance.

[rasz]

>you'll be able to start a download at home, hop on your bike, ride to the office, and finish your download without the connection dropping once.

you could do this for over 20 years as long as server supports HTTP/1.1 https://en.wikipedia.org/wiki/Byte_serving

[ATsch]

The connection does drop though. Range requests just allow you to resume it.

[gopalv]

> This means we can not ever keep a connection alive when moving from one network and hence IP address into another.

One of the things I was looking forward to from IPv6 was the mobility of IPs [1].

[1] - https://en.wikipedia.org/wiki/Mobile_IP#Changes_in_IPv6_for_...

[ATsch]

I think the idea of mobile IP is fundamentally flawed and I'm not surprised it didn't catch on. The whole point of IP addresses is to be a hierarchical address describing a location in the network. Once you can move IPs, they become completely meaningless. Mobile IP proposals just hack around this by running everything through a glorified VPN.

[underdeserver]

How would the server know that the destination IP changed?

[BenjiWiebe]

When the acknowledgement packet suddenly comes from a new IP address, referencing an existing connection ID.

[mcguire]

There's security implications...

[Matthias247]

Those are addressed by the QUIC specification, by having lots of encryption. The whole content of QUIC packets is encrypted. You can't really do a lot with connection IDs. And for most of the packets you can't even observe the full connection ID, since an abbreviated version is sent.

Acknowledgements are encrypted.

[labawi]

Can the transport path be hijacked from a single captured packet? As in capture a single packet, scribble an address and the connection now goes via Pentagon or China.

I know it's possible for wireguard, maybe mosh.

[keithwinstein]

No -- Mosh is careful to make sure that a transient network attack can only result in a transient application-layer consequence. So a single misrouted IP datagram can't permanently affect the connection. Mosh does this at the cost of having client-only mobility; the client keeps sending to the same server address for the life of the connection.

[salmaanp]

this sounds similar to SSL resumption

[m_eiman]

There’s also Multipath TCP that intends to solve that problem.

[ATsch]

Multipath is different in purpose though, although it does also break up the tuple. It's designed to allow load balancing across multiple addresses/interfaces. You need to explicitly tell the other side "I am also available under the following address". There is definitely some overlap and there are proposals for multipath QUIC which gives you both.

[dehrmann]

SCTP gets closer to it with multi-homing.

[ATsch]

Still incredibly disappointed this didn't catch on widely before NAT prevented any new protocols. There'd be so many problems we wouldn't have today.

[dehrmann]

I tend to say the OSI model got it wrong because TCP should live on top of TCP and use its mechanism for ports. That also would have made it easier to launch new protocols with connection and reliability semantics.