I've heard about MPTCP back in 2013.<p>It made so much sense back then, when mobile apps were not that robust to networks changing, I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day.<p>It's incredibly depressing that this gained barely any traction in the last 10 years, and kernel options are appearing just recently, after everyone has wrapped they http calls in multiple retry handlers, and mobile operating systems have abstracted network connectivity to the point where it feels more like you are using zeromq rather than tcp.
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.
Too bad there is no link to projects using mptcp, such as Openwrt derivatives.<p>PS: I mentored a student for 2 years at GSOC to patch Openwrt with mptcp:<p><a href="https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-support-ledeopenwrt-trunk/" rel="nofollow">https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...</a>
Why does this require explicit opt in by applications if there’s transparent fallback? Wouldn’t it make most sense for the kernel to do it transparently for every TCP connection so that it can make more global decisions about path aggregation / link preference?
The only practical use of MPTCP for me is to use mobile and Wi-Fi network together to boost the speed. iOS and WeChat both support this. However, I always turn them off because my mobile network is metered. So in the end, MPTCP is useless for me *personally*.
I work supporting, debugging, fixing the Linux network stack and drivers. I am amazed how little adoption this has seen.<p>Like everything which came along and tried to supplant regular TCP, such as SCTP, it seems MPTCP has also been confined to a niche of application developers who will use it forever while the rest of the world forgets about it.
I found [1] which describes the architectural difference between MPTCP and QUIC, and also introduces the authors' proposed MPQUIC protocol:<p>> QUIC multiplexes application streams on a single UDP flow, whereas MPTCP splits a single stream on multiple TCP subflows. MPQUIC combines both features by multiplex-
ing application streams on multiple UDP subflows.<p>[1]: "Multipath QUIC: A Deployable Multipath Transport Protocol" <a href="https://www.researchgate.net/publication/327122884_Multipath_QUIC_A_Deployable_Multipath_Transport_Protocol" rel="nofollow">https://www.researchgate.net/publication/327122884_Multipath...</a><p>Now I'm curious about how these protocols compare in production operation. Anybody have experience with both?
Apple supports it too and uses it for Siri <a href="https://developer.apple.com/documentation/foundation/urlsessionconfiguration/improving_network_reliability_using_multipath_tcp" rel="nofollow">https://developer.apple.com/documentation/foundation/urlsess...</a>
> If any middlebox in between does not support it, the returned SYN+ACK packet will not contain MPTCP options in the TCP option field.<p>That sounds .. quite restrictive. Is the only requirement on a middlebox to just forward the MPTCP options as-is?
This can help in security/privacy setting.<p>for example Great Chinese firewall: if you can split your traffic across multiple uplink channels, the firewall will have a hard time to put them together for enforcement?
The examples given on the page seem to focus on multipath to get to a device over the internet, but I can see this being more likely to work properly without needing to fallback on home networks.