Linux Kernel MultiPath TCP Project
multipath-tcp.org
multipath-tcp.org
Theoretically it would also be useful for corporate laptops that get unplugged from a docking station every time someone needs to go to a meeting. Any long-running downloads wouldn't have to be interrupted, SSH sessions could remain connected, etc...
It's good tech. I hope more people implement.
When I go into an elevator, the WIFI / 4G connection can drop for half minute for example, then it reconnects later.
Or for example switching from one wifi network where the connection is slow to another one (my fast tethered mobile network).
Remember, your identity in a TCP connection is your IP address. If you connect from another IP and want your session to continue, identity must be handled higher in the stack.
TCP connection technically live forever by default. It’s up to either party to complete the handshake. Without that mechanism, your box would run out of ports.
The essential tuple of a stateful IP session, the "5-tuple," is the source IP address, source port number, destination IP address, destination port number and the IP protocol number, in this case TCP. None of those elements can change during the lifetime of the connection. Or rather, changing any element constitutes a different connection.
Not that you needed to be told that; you probably know this already. It's just an interesting factoid that I imagine others might find interesting or useful when thinking about networking. In the guts of every device that handles TCP state (clients, servers, middle boxes, whatever) there is a table of all in-flight 5-tuples that marries every incoming packet with some state.
MPTCP sender -> [link1 | link2] -> shared link -> MPTCP receiver
There might be a TCP flow using the shared link, in which case fairness means that the MPTCP sender should only send the same total traffic as would a single TCP flow. Or there might be a TCP flow using link1, and a second TCP flow using link2, and the shared link might be uncongested, in which case MPTCP could reasonably behave like two TCP flows. Or maybe there's a single path TCP flow using (link1 -> shared), or one using (link1 -> link2), or ...
The MPTCP congestion controller was designed so that in all of these cases it's no greedier than if it were a single TCP flow. And it has to do this without knowing the network topology, nor what other flows are using the network.
Reference: 2011 paper, https://www.usenix.org/conference/nsdi11/design-implementati...
So, if MPTCP is a drop-in replacement for TCP, why do programs need to opt into it?
Without being enabled by default, this project will go nowhere.
There are different ways to enable it on unmodified applications, e.g. via a wrapper or using eBPF.
The maintainers of Linux distributions will enable it, if they see doesn't cause trouble with regular network traffic.
After all, there are instructions for the "old" implementation: <https://multipath-tcp.org/pmwiki.php/Users/ConfigureMPTCP>, <https://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting> and the "new" implementation: <https://github.com/multipath-tcp/mptcp_net-next/wiki/#how-to...>.
Suppose for example there's a packet-sniffing security appliance along the path, and it only sees packets on one path of the MPTCP flow, and it says "This stream of packets doesn't look like a legitimate TCP flow, so it's probably an attack, so I'll block it."
The same happened with Max Segment Size detection - and that mostly works now.
Most users remain unaware that ISPs track and monitor traffic, or that services like Google and Cloudflare can fingerprint and statistically aggregate connection meta-data (packet size and timing) to build data sets even where privacy preserving technologies are deployed by the user.
Many domestic users could take advantage of this TCP kernel update because of the ubiquity of available connections. In dense urban settings people might have access to one or more wired connections, perhaps a couple of 4G /5G modems lying around, a phone to tether, and perhaps some free-open wifi connections from nearby coffee shops etc.
Multi-homing not only offers greater reliability, it can allow connections to evade spying much like "spread spectrum" cryptography, by multiplexing connections - as TCP was designed/intended to accommodate - spreading them randomly over multiple links.
Of course there are ways that multi-con TCP could lessen privacy in the hands of a naive user, perhaps by unexpectedly routing through a less secure link, but this comes down to digital literacy and good craft in the end.
If you have access to wired, wifi and 4G/5G the correct use of that is to always in every single case to use wired, until it breaks. Your ISP will get the exact same traffic as it does without multipath TCP (which probably is encrypted anyway). The only difference and advantage is that your connection doesn't break when you switch between them. You'd do the exact same switch without multipath TCP only you'd have to reconnect.
On the other hand, you do give google and everyone else you talk to your complete list of endpoints. So your movement can be trivially followed and you have another insanely valuable tracking data that does not necessarily change when you change network.
I am flabbergasted that anyone can argue that this is a positive from a privacy point of view. I hope I've missed something obvious.
Look at how for decades, people cited Facebook privacy concerns, about their tracking, and data collection policies. People were discussing this, railing against it, for 15 years before it caused election interference(Cambridge), and deaths world wide(civil wars).
Most people, including those in the industry, just did not care. Facebook is fun! We make money using it! Who cares!
This is quite typical human behaviour.
As an example, I note how people who have been worried about Facebook for decades, think using cash is weird.
Meanwhile, banks collect immense data about people, share that data with others, including associative data. Banks know more about you than Facebook, and even use their power to restrict cash usage.
One day, if this decades long, slow trend continues, two human beings will be unable to exchange money, without a third party being involved.
Considering that the US government already tracks many forms of payment in the US, post 9/11, and secondly, purchases tracking info from private corps, anyone who worries about privacy?
Well. Such people should be using cash as exclusively as possible.
But what do you see from tech inclined privacy advocates?
Paying with NFC or RDIF on their phones. Using credit cards. Complaining about cash. Not carrying cash.
Not using cash.
The battle to retain anonymous fiscal transactions is more important than online tracking, for there is little "out".
EG, you can leave your phone at home, but you still must pay for things somehow...
So do not be surprised. People only care about privacy after death, destruction, and political destabilization.
They only care, after, not before.
Convenience first, after all!
Er, maybe in the EU? Since I've had an ISP mail me a notice that they were planning to monetize my traffic, I can assure you there are jurisdictions where it clearly isn't.
That's not necessarily the case, unless you define 'it breaks' tautologically.
If you're connecting to a LAN server where your server has 2x1G, but your client has 1x1G, you can transfer data faster if you use wired and wifi.
Same thing if your wired internet connection is bandwidth limited; augmenting with 4G/5G would help transfer data faster. Having access to multiple routes may help in case of congestion or faulty links anywhere on the path (although, of course, there's nothing preventing paths being shared by ISPs on multiple last-mile mediums).
On the other hand, MPTCP is difficult to optimize; high performance tcp stacks arrange for all the packets for a given connection to be received on the same cpu to reduce contention; it's hard to arrange that for the two (or more) underlying connections of MPTCP. It's probably better to do MPTCP to protect reachability rather than to improve bulk transfer rates, IMHO.
Augmenting with 4G/5G could really help but before daring to do that you'd really have to make sure that it doesn't incur extra costs or drain the data-plan.
And mixing in wifi also begs the question, is this latency bound or not? And do we really want to pollute the spectrum with this high-throughput transfer for a minor speed increase? Potential ruining it for everyone else.
To make it sensible the server would also need 2x1G which is already very very niche and if it was a considered usecase you'd probably opt for 10G anyway.
In the vast majority of cases and probably the only sensible defaults would be wired > wifi > 4G/5G.
Bonding can give you higher thoruhput, assuming you have multiple tcp sessions.
On top of that MPTCP also offers advantages when it comes to handover in mobile networks: if your IP address changes for some reason (e.g., switching from Wifi to mobile), existing connections won't be interrupted.
I don't know enough about bonded interfaces, but I don't see how they'd help in this scenario. This scenario is natural with mobile devices, which is probably why Apple uses MPTCP.