(intended in the most lighthearted way possible!)
I'm not one to defer to authority too easily, but it's my experience that, when someone with enough experience says something that sounds out of this world, it's a good idea to think about it for a bit.
* https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
I think a lot of the effort put into QUIC, HTTP/2,3,4,whatever, etc, could have been avoided if SCTP was more broadly adopted.
Do note that SCTP is heavily used in telecom. Every network element in that world needs to be redundant, along with the multiple routes to get to each of those redundant elements. SCTP helps hide some of that from the application layers.
It's actually the quadruple (local ip, port, rem ip, port) in the steady state.
Example: layer 3 knows nothing about ports?
correct
Just like a phone number isn't the same thing as an SMS thread.
Just to provide my 2 cents on the issue:
There are a lot of things at play... Rekhter's law ("Addressing can follow topology or topology can follow addressing. Choose one.") doesn't combine well with the fact that it's not desirable to have end-hosts participate in routing updates. When these two are taken together, they have implications on scalability of any routing solution, especially in the cases of end-host mobility and multihoming.
When the "topology follows addressing" (like TCP/IP), the constraint of not wanting to advertise the end-host address (as someone mentioned, no ISP will accept your /32 on BGP) assigning the end-host a different address per attached network is the simplest solution. This indeed boils down to the assigning L3 addresses to the interface. The TCP connection problem can be handled by tunnels (as is the case in Mobile IP or LISP) but tunnels are rather expensive since the tunnel endpoint in the network has to maintain al lot of state.
In the case of "addressing follows topology", changes in topology, when taking the constraint of not advertising end-hosts via routing, requires address renumbering of the network elements.
So, when taken as a pure L3 problem, it boils down to choosing which problem to solve: constantly tracking the end-hosts, or constantly renumbering the network. The latter, when used in combination with recursive network layering, shows quite some promise. It requires less addresses, but I know from experience that it's not the easiest idea to sell.
MPTCP provides a pragmatic workaround on top of L4 that doesn't require tunnels. It's a shame that it's not completely transparent to the applications (it requires explicit code changes to enable).I agree with a lot of the concerns of getting this upstream in the kernel. I tried to play around with it a couple of times, but the distribution as a full kernel was a bit of a roadblock. Would be easier if it was distributed as a kernel patch. And it seems perfectly doable to implement it in user space, that might further speed up adoption.
Anyway, take care :)
In my mind, L2 addresses are not for routing across organizations, and L3 addresses are. So the L2 address identifies an interface, and a L3 address identifies a routable entity. The weird thing is that there is an almost one-to-one mapping between these.
It might make sense for the same host on e.g. a WiFi and Ethernet interface off the same organization to have the same L3 address. After all, the organization responsible for routing to that host can know those interfaces belong to the same host.
However, once you get into multiple interfaces at disparate organizations things change. Take for example, a phone with LTE from some provider and WiFi from some how ISP. There are two separate organizations who are responsible for routing to those interfaces. Hence, the decisions needed to route to those interfaces differ. This makes routing based on the same address a lot harder.
I think my argument boils down to "topology follows addressing" being highly beneficial in our federated world of routing on the internet. It allows every autonomous network to handle internal routing however they want.
Biggest thing is to deal with really easy hijacks where you tell a server that your victim 's data should instead be sent to you. This is harder with the current TCP.
The mistake instead is that TCP is not fully layer 4. They are entangled with layer 3. Specifically, a TCP socket is defined by an (IP, port) pair. Where the IP is layer 3. As such, it is fundamentally impossible to persist a TCP connection accross multiple IPs.
There is no reason for this. If instead a socket were identified as (uuid, port) then after I change my ip address, I can continue receiving packets sent to (uuid, port). And the other side will still recognize packets from me, because only my IP changed, not the connection uuid.
You'd maybe need to add some spoofing defenses, but we need those in current TCP too.