Live data from Hacker News

Multipath TCP for Linux (2022)

mptcp.dev

21–30 of 104 posts

Re: Multipath TCP for Linux (2022)

#21
post #7

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...

Whats the benefit of an openwrt router supporting mptcp? I'd think support on web servers and mobile devices would be most important...

Link aggregation and redundancy

Re: Multipath TCP for Linux (2022)

#22

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 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 the load balancer doesn't want to do it anyway.

Processing two streams together involves a lot of complexity in a high throughput code path. It's a lot of risk, and you've got to reboot for changes.

And then you do all that work and it only benefits iOS users, who tend to be on better networks anyway.

Re: Multipath TCP for Linux (2022)

#23
This can help in security/privacy setting.

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?

Re: Multipath TCP for Linux (2022)

#25
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.

Re: Multipath TCP for Linux (2022)

#26

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...

Re: Multipath TCP for Linux (2022)

#27
post #7

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...

Whats the benefit of an openwrt router supporting mptcp? I'd think support on web servers and mobile devices would be most important...

I got fiber run to my neighborhood, and for a while, had a 1gb coax connection and a 1gb fiber connection. I used openmptcprouter to aggregate my connections through a droplet and I effectively had a 2 gigabit internet connection. I would have stuck with it, but having a datacenter IP for your home network really doesn’t work.

Re: Multipath TCP for Linux (2022)

#28

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.

How would you change TCP?

Do you mean how we have to use 4 fields to track a connection - IP address and port for both ends?

Re: Multipath TCP for Linux (2022)

#29

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.

How would you change TCP? Do you mean how we have to use 4 fields to track a connection - IP address and port for both ends?

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.)

Re: Multipath TCP for Linux (2022)

#30

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 force one of both, cannot see a reason to prefer using both at the same time.

Maybe the latency thing? Never had that issue at home, but could understand that usage case "just use the network segment with less latency to reach $thing".

Post reply on HN