71–80 of 104 posts
Too bad there is no link to projects using mptcp, such as Openwrt derivatives. PS: I mentored a student for 2 years at GSOC to patch Openwrt with mptcp: https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...
It was recently enabled in the Home Assistant ‘HAOS’ kernel. https://github.com/home-assistant/operating-system/pull/3248
Earlier quoted context omitted.
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 switc…
If TCP didn't use L3 source and destination addresses to distinguish connections, it could be more easily taught to deal with: * Clients roaming between L3 addresses * Clients/servers with multiple L3 addresses
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?
My understanding is that it was basically a condition enforced by the maintainers of the Linux TCP / networking subsystems. If you look at the initial upstreaming discussions[1], this was setup as a ground rule. If you look at the older multipath TCP implementation, prior to the upstreaming, it was intended to be fully transparent to the application, which I think makes more sense for the intent of the protocol. Sure…
But apps can use it by default. For the server case, it really makes sense: https://www.mptcp.dev/faq.html#why--when-should-mptcp-be-ena...
GNU/Linux distributions could even switch MPTCP on by default (via eBPF).
I've heard about MPTCP back in 2013. 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. 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…
I was excited about it because we were working on delivery robots and I wanted a good solution for instant failover given 2 cellular modems. We ended up going with PepLink's SpeedFusion to save engineering time. But the license was costly. I really hope for a free solution in the future for 2 cellular networks and Multipath UDP + OpenVPN would also probably be a viable solution.
I found [1] which describes the architectural difference between MPTCP and QUIC, and also introduces the authors' proposed MPQUIC protocol: > 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. [1]: "Multipath QUIC: A Deployable Multipath Transport Protocol"…
But both tries to achieve the same goal. Technically, you can have a very similar behaviour. MPTCP is implemented in the Linux kernel, while QUIC is on the userspace side.
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.
At home/lan we use LACP, VRRP... I mean link aggregation and HA needs are solved time ago. With multiple ISPs, or on a complex enough LAN, we can use multiple routing tables + weights too. Also, if the ISP at home can do 10Gbps, 1Gbps, 300 Mbps whatever... I want to be able to use them with a single path, so there is no gain using multiple paths. Eventually, when I have cable+wifi connected at the same time, I use to…
Earlier quoted context omitted.
I wanted to like it, and Apple included it in iOS, but supporting it on real servers was going to be too hard... When I was deployed on FreeBSD with no load balancers, there weren't recent patches. And even if there were, I'd need to do some serious work to avoid advertising the private network ips as alternates... When I was on Linux behind a load balancer, it's too complex to get the streams to the right place. And…
> iOS users, who tend to be on better networks anyway. I don't think there is any basis to claim that.
I work supporting, debugging, fixing the Linux network stack and drivers. I am amazed how little adoption this has seen. 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've heard about MPTCP back in 2013. 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. 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…
I suspect that a lot of innovation energy moved to QUIC, because with TCP your nice new variant can be randomly nobbled by middleboxes. For example, see https://blog.apnic.net/2021/12/08/efficient-multipath-transp...
Multipath: There are several areas where TCP still has an advantage over QUIC. One of those is multipath support. Multipath TCP connections can send data on different network paths simultaneously — for example, sending via both WiFi and cellular data — to provide better throughput than either path permits individually.
Server connection migration is explicitly forbidden by QUIC:
I've heard about MPTCP back in 2013. 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. 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…