I don't know which makes me sadder-- IPv4 only having a 32-bit address space or TCP using the source and destination IP addresses in the connection tuple. That's one of those "if I had a time machine" of things-- I'd go back and have Cert and Kahn change both of those items.
If TCP had a protocol specific identifier for connections (a couple of 32-bit values, for example-- a client nonce and server nonce) rather than using the source/destination IP addresses multi-homed hosts and seamless transition between different networks would become native features of the protocol. A client could roam between two different IP networks and TCP connections would "survive", for example. (I'm oversimplifying nearly to the point of hyperbole, to be sure...)
(Another fun future would have been one where SCTP got widespread adoption.)
a client nonce and server nonce) rather than using the source/destination IP addresses multi-homed hosts and seamless transition between different networks would become native features of the protocol. A client could roam between two different IP networks and TCP connections would "survive", for example.
This is mostly how Mosh [1] works and allows for IP roaming, changing IP's, etc... without losing ones SSH session. The connection can even be interrupted for a prolonged period of time and restore on its own on a new IP seamlessly.
How would routing be done without source/destination? When the device changes networks, how does the origin and all routers along the way know that this device is on a new network?
> How would routing be done without source/destination?
There is still a source/destination address. Routing still works. But those addresses are allowed to change without disrupting the connection because the connection isn't based on the values of these addresses.
> When the device changes networks, how does the origin and all routers along the way know
The routers don't need to "know" these things.
MPQUIC does this. To the network it's just UDP packets moving around. Connection state is dealt with at higher levels and doesn't rely on IP addresses.
> how does the origin and all routers along the way
It's just the origin that needs to know what address(es) it should be using as the destination at layer 3.
The big problems with this is that it depends upon things that weren't really feasible in the early 80's -- bigger packet headers, a bit more state on each side of the connection, potential need for cryptographic authentication.
* Where to send a frame to get to the other side of the connection
* Whose connection this is.
TCP combined the two, because we didn't have mobile clients or a lot of multihomed systems that would benefit from distinguishing them. Also, every octet in the header counted.
In practice, this means we have to keep building a lot of infrastructure on top of TCP (or parallel to it, in datagram protocols) to handle retries and splitting flows well. In turn, these things are completely opaque to the network and it's difficult to write rules about them.
Whereas if we had different packet fields for "where am I sending this packet right now" and "whose flow does this belong to"? we could write better firewall rules, have less infrastructure built on top of TCP, and have better typical application performance.
But the stuff that carries TCP is IP. That's why TCP can work seamlessly, because it uses identification from a previous layer. Consider I bind a server to an ID, and not IP:port, the operating system running it must know how to communicate that via IP, so there will be a corellation map somewhere and that map needs to be synchronized between all peers that wish to host the roaming server.
Otherwise you're just switching port (16-bit) value to arbitrary 32-bit identifier.
But... it doesn't? TCP has no notion of IP address in the protocol, only the port.
TCP with changing IPs can work e.g. on top of an ip-ip tunnel with applications not being aware at all.
> TCP has no notion of IP address in the protocol,
RFC793:
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. **Concatenated with the network
and host addresses from the internet communication layer,** this forms
a socket. A pair of sockets uniquely identifies each connection.
That is, a socket may be simultaneously used in multiple
connections.
TCP uses the combination of L3 source address, L3 destination address, L4 destination port, L4 source port to identify what connection a frame is on. We're discussing how using that L3 information isn't necessarily ideal for today's world.
> TCP with changing IPs can work e.g. on top of an ip-ip tunnel with applications not being aware at all.
That's just because the IPs have not changed from its point of view: it receives the same frame with the same destination/source IP addresses the entire time.
Part of the reason why we need things like IP-IP tunnels is because L4 connections can't "move" with TCP. In scenarios where we're using tunneling for this, we're accepting worse performance than if we could just directly send TCP to its true destination and have it processed.
So you want to implement persistent connections on L4 without implementing persistent addresses on L3 first?
This doesn't make much sense to me. The hardest problem here is not assigning uuids to pipes, it's the routing/mapping of the "true destination".
- If you manage to solve it on L3, ip-ip tunnels or not — you have it, TCP works unmodified and so does UDP and everything else including quic and http/3.
- If you didn't solve it, then support for persistent connections in TCP is useless.
In another words I don't see what a "transmission control protocol" has to do with it. It's very reasonable to assume that addreses are already figured out when designing transmission control and that's exactly what TCP did.
> - If you didn't solve it, then support for persistent connections in TCP is useless.
SCTP and multipath TCP (which is what we're talking about) already do pretty much this. Assuming that endpoints to a stream connection have single, unchanging network addresses isn't a reasonable assumption anymore. But we're stuck with the assumption that hosts won't move in one of our most common protocols.
In the OSI model, you got similar functionality up at layer 5, but TCP only handles the connection/disconnection aspect of the session layer. In the internet world, we have a bunch of haphazard sets of retries, session balancing, multihoming and reconnecting behavior that are protocol specific (and completely missing from many well-used protocols) kludged on top. (Actually arguably MP-TCP is a session layer on top of TCP).
The only way you solve this on layer 3 is to build some kind of messy overlay network, because addresses have no real relation to where things are anymore. And we know that overlay networks are suboptimal and inefficient. Solving it at layer 4 doesn't have to be (but it's too late for that now).
The protocol would have to handle binding the network to the transport. MPTCP and SCTP both handle that via registering and un-register network layer endpoints. This parallel universe TCP would be the same in that regard.
The problem is that the TCP/IP model stops at level 4, and if we consider TCP a protocol of transport, it shouldn't do that.
In the OSI model what you talk about is level 5, that is session, but in TCP/IP there is no such level, thus it must be handled by the application (e.g. trough a session cookie, in HTTP).
Slavish adherence to theoretical models is a recipe for failure. Even worse, the OSI model was developed in the 1970s before successful internetworks existed so it's not informed by experience; it's mostly made up.
