Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multipath TCP for Linux (2022)

mptcp.dev

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Multipath TCP for Linux (2022)

#81

Post by wil421 »

DEADMINCE wrote: post #68
toast0 wrote: post #22

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.

> A U.S. analysis of Wi-Fi and mobile Internet usage across unique smartphones on the iOS and Android platforms reveals that 71 percent of all unique iPhones used both mobile and Wi-Fi networks to connect to the Internet, while only 32 percent of unique Android mobile phones used both types of connections. A further analysis of this pattern of behavior in the U.K. shows consistent results, as 87 percent of unique iPhones used both mobile and Wi-Fi networks for web access compared to a lower 57 percent of Android phones.

https://www.comscore.com/lat/Prensa-y-Eventos/Infographics/i...

Re: Multipath TCP for Linux (2022)

#82

Post by DEADMINCE »

wil421 wrote: post #81
DEADMINCE wrote: post #68

Earlier quoted context omitted.

> iOS users, who tend to be on better networks anyway. I don't think there is any basis to claim that.

> A U.S. analysis of Wi-Fi and mobile Internet usage across unique smartphones on the iOS and Android platforms reveals that 71 percent of all unique iPhones used both mobile and Wi-Fi networks to connect to the Internet, while only 32 percent of unique Android mobile phones used both types of connections. A further analysis of this pattern of behavior in the U.K. shows consistent results, as 87 percent of unique iPh…

Since wi-fi networks tend to be higher quality than cell networks, what you provided works against the point I responded to.

Re: Multipath TCP for Linux (2022)

#83

Post by LinuxBender »

EvanAnderson wrote: post #29
bobmcnamara wrote: post #28

Earlier quoted context omitted.

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 oversimpl…

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.

This is mostly how Mosh [1] works and allows for IP roaming, changing IP's, etc... without losing ones SSH session. The connection can even be interrupted for a prolonged period of time and restore on its own on a new IP seamlessly.

[1] - https://mosh.org/

Re: Multipath TCP for Linux (2022)

#84

Post by ajb »

karma_pharmer wrote: post #79
ajb wrote: post #26

Earlier quoted context omitted.

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

QUIC is a step backwards here; it has no multipath support: https://lwn.net/Articles/964377/ 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…

The draft multipath extension is here: https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/

It's on the standards track, rather than experimental, so likely to be supported once finished. There seem to be some implementations, including Apple:

https://github.com/quicwg/multipath/wiki/QUIC-Implementation...

Re: Multipath TCP for Linux (2022)

#85

Post by lo0dot0 »

txutxu wrote: post #30
extraduder_ire wrote: post #14

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…

For a long time enterprise firewalls (and more recently SD-WAN) allowed load balancing between different links, but unlike MPTCP the traffic of a single TCP connection is not split up. This is in line with the established network admin wisdom saying that reordering packets of a TCP connection hurts performance.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Ho...

Re: Multipath TCP for Linux (2022)

#86

Post by andrewmackrodt »

zoobab wrote: 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...

I've been looking at this project for a while which may be interesting to you: https://github.com/Ysurac/openmptcprouter.

I recently bought a property where I cannot get a full fibre connection, but I can get 150-400 Mbps using 5G. I've been thinking about using dual 5G connections and tunneling my traffic via mptcp to a VPS to aggregate the connections.

Re: Multipath TCP for Linux (2022)

#87

Post by remram »

EvanAnderson wrote: post #29
bobmcnamara wrote: post #28

Earlier quoted context omitted.

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 oversimpl…

Like the IPv6 flow label?

Re: Multipath TCP for Linux (2022)

#88

Post by dheera »

kariemf wrote: post #67
dheera wrote: post #50

Earlier quoted context omitted.

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 created something like what you're describing with the addition of P2P communication using NAT traversal ( https://www.hyperpath.ie ) It will connect your devices in a P2P Mesh VPN and allow them to send and receive data using multiple links (e.g. multiple 5G or 5G + Satellite). It is significantly cheaper than Peplink's license, less latency and no bandwidth / data limits. You need to bring your own hardware thoug…

what about something like this? two minipcie slots which i suppose you could put two cellular modems into. not sure what OS it runs though but presumably some flavor of linux.

https://mikrotik.com/product/rbm33g#fndtn-specifications

maybe someone could make one that uses an RPi compute module instead.

Re: Multipath TCP for Linux (2022)

#89

Post by semi »

txutxu wrote: post #30
extraduder_ire wrote: post #14

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…

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

I don't understand why you would want to be able to use them with a single path. the gain would be being able to aggregate them and have individual tcp streams faster than any one IP connection could handle.

Though personally I think the resilience is more appealing. Not having to have a hard cutover when wifi degrades as I walk away would be nice

Re: Multipath TCP for Linux (2022)

#90

Post by DEADMINCE »

Longhanks wrote: post #77
DEADMINCE wrote: post #68

Earlier quoted context omitted.

> iOS users, who tend to be on better networks anyway. I don't think there is any basis to claim that.

Someone paying for a premium phone is probably also inclined to pay for a premium mobile network.

Not all iPhones are 'premium' phones, and there are not really 'premium' cell phone networks in the US. Or anywhere.
Post reply on HN