But plenty has changed since then. It seems all my complains about the API are now addressed. Maybe it's a good time to actually run with MPTCP again :)
In my private affairs, I realised I need MPTCP less, since I started using tailscale. My SSH sessions tend to last longer when going over it.
My biggest disappointment with MPTCP was that seemingly, you need both the old and new address to be available when doing handover. So you cannot suspend your laptop, go to a different place, and resume the TCP sessions on the new Wi-Fi.
Seems like a fool's errand. The cited RFC8684 starts from the wrong premise:
> TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers.
In reality, IP modules of all the hosts and routers can load-balance over a set of all available interfaces, as long as global routing information is available.
Sort of related, I'm curious why SCTP did not take off more in this space? It might have had more telecom origins maybe but seemed to fill some of the same needs back in the day.
Windows doesn't have kernel mode SCTP so it was slow for most consumer devices for a long time. Even now, Linux SCTP is slow in comparison to other protocols. Plus, it's complicated enough already to get UDP and TCP traffic to make it's way through middleboxes. Also, not a lot of consumer routers support things like port forwards and combining SCTP with NAT doesn't seem to be widely tested. Things just didn't work out when SCTP stood to gain adoption.
It's an interesting protocol, but these days I think the internet has ossified so far that you're probably better off relying on hacks like QUIC and MPTCP to get the protocol features that SCTP stood to introduce.
Coming from the telecoms space, I was slightly amazed to see how little well known SCTP actually is in the networking world.
My old company/offices had site internet provided by one of the top 50 UK Managed Service Providers. They swapped out the on-site router not many years ago as the fibre to site was being upgraded from 100mbit to gigabit and so a new Juniper firewall with GBE ports was required.
Turns out the newer, faster, shinier, though albeit lower model numbered'd Juniper SRX fundamentally didn't support passing SCTP data and suddenly we lost access to all our remote stuff that used it. Ended up on a call with the MSPs Head of Networks (who was not a stupid person), but their opening gambit was "Are you sure you mean SCTP? Oh. What is that then?"
There was also numerous weird kernel bugs with implementations on CentOS 5, 6 and 7 which all would manage to get themselves into weird states where only a reboot would clear - not really what you want from a multi-endpoint, 'copes and recovers well from network weirdness' tunnelling protocol.
It did see a lot of use. I forgot to say, but the majority of 3G UMTS and 4G LTE radios (operator level and even down to tiny things like femtocells) required it to connect back to the $(core network) and encapsulated a mix of control and user data through it (though often also encapsulating SCTP in a VPN). That is to say, there were a lot of devices out there that used it in anger. If you made a call or used a cellular data session for over a decade, your traffic was likely getting encapsulated through it.
Great to see the continued work on MPTCP integration for Linux. Having this as a mature, native option for better session resilience and bandwidth aggregation is a huge win for network performance.
Hey! MPTCP again!
Back in Jan I wrote a piece about how to actually use MPTCP
https://blog.cloudflare.com/multi-path-tcp-revolutionizing-c...
But plenty has changed since then. It seems all my complains about the API are now addressed. Maybe it's a good time to actually run with MPTCP again :)
In my private affairs, I realised I need MPTCP less, since I started using tailscale. My SSH sessions tend to last longer when going over it.
My biggest disappointment with MPTCP was that seemingly, you need both the old and new address to be available when doing handover. So you cannot suspend your laptop, go to a different place, and resume the TCP sessions on the new Wi-Fi.
Seems like a fool's errand. The cited RFC8684 starts from the wrong premise:
> TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers.
In reality, IP modules of all the hosts and routers can load-balance over a set of all available interfaces, as long as global routing information is available.
Check out http://www.openmptcprouter.com which works excellent!
Sort of related, I'm curious why SCTP did not take off more in this space? It might have had more telecom origins maybe but seemed to fill some of the same needs back in the day.
https://docs.kernel.org/networking/sctp.html
PS the kernel work goes back to 2003!
Windows doesn't have kernel mode SCTP so it was slow for most consumer devices for a long time. Even now, Linux SCTP is slow in comparison to other protocols. Plus, it's complicated enough already to get UDP and TCP traffic to make it's way through middleboxes. Also, not a lot of consumer routers support things like port forwards and combining SCTP with NAT doesn't seem to be widely tested. Things just didn't work out when SCTP stood to gain adoption.
It's an interesting protocol, but these days I think the internet has ossified so far that you're probably better off relying on hacks like QUIC and MPTCP to get the protocol features that SCTP stood to introduce.
I believe it's because of firewalls. You need to be either UDP or TCP to work in the Internet at large.
Though SCTP did find its place as a layer in WebRTC.
Coming from the telecoms space, I was slightly amazed to see how little well known SCTP actually is in the networking world.
My old company/offices had site internet provided by one of the top 50 UK Managed Service Providers. They swapped out the on-site router not many years ago as the fibre to site was being upgraded from 100mbit to gigabit and so a new Juniper firewall with GBE ports was required.
Turns out the newer, faster, shinier, though albeit lower model numbered'd Juniper SRX fundamentally didn't support passing SCTP data and suddenly we lost access to all our remote stuff that used it. Ended up on a call with the MSPs Head of Networks (who was not a stupid person), but their opening gambit was "Are you sure you mean SCTP? Oh. What is that then?"
There was also numerous weird kernel bugs with implementations on CentOS 5, 6 and 7 which all would manage to get themselves into weird states where only a reboot would clear - not really what you want from a multi-endpoint, 'copes and recovers well from network weirdness' tunnelling protocol.
Funny enough, the first and last time I heard of sctp was in “Unix network programming”. It seemed so promising according to Stevens.
It did see a lot of use. I forgot to say, but the majority of 3G UMTS and 4G LTE radios (operator level and even down to tiny things like femtocells) required it to connect back to the $(core network) and encapsulated a mix of control and user data through it (though often also encapsulating SCTP in a VPN). That is to say, there were a lot of devices out there that used it in anger. If you made a call or used a cellular data session for over a decade, your traffic was likely getting encapsulated through it.
Great to see the continued work on MPTCP integration for Linux. Having this as a mature, native option for better session resilience and bandwidth aggregation is a huge win for network performance.