“MultiPath TCP (MPTCP) is an effort towards enabling the simultaneous use of several IP-addresses/interfaces by a modification of TCP that presents a regular TCP interface to applications, while in fact spreading data across several subflows.”
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.
The work on MPTCP started before QUIC. One big difference is that MPTCP puts a lot of effort to look like TCP to avoid being affected by middleboxes (firewall, NAT, proxies, ...). QUIC uses UDP which is more often blocked or throttled, though that will quickly change as it gets more widely deployed!
> Programs that were built to use TCP will still use the TCP connections when running on an MPTCP-enabled kernel unless the programmer/user/admin opts-in to using Multipath TCP.
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.
MPTCP is an extension of TCP and is "drop-in". But AFAIK making it opt-in was a concession to get it upstreamed in Linux, understandably as this is a risky change.
There are different ways to enable it on unmodified applications, e.g. via a wrapper or using eBPF.
MPTCP is a drop-in replacement -- but its original designers were paranoid about e.g. packet-sniffing middleboxes, so they made it opt-in.
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."
I think the real answer is to test a lot of middleboxes, come up with some fallback behaviour that will at least work with 99% of them, and then just break the last 1%.
The same happened with Max Segment Size detection - and that mostly works now.
Bonded interfaces have the same IP (iirc), MPTCP can send traffic over multiple IPs, eg over both wifi and 4g, for better roaming. Especially useful when moving around and entering/leaving different wifi networks, all without dropping the TCP connection.
A bonded/teamed interface usually load balanced based on a flow. Thus, over a single TCP flow you will only use one of the interfaces.
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.
Suppose the sender has a single interface, and it's the receiver that has multiple interfaces. With MPTCP, the sender will learn that there are multiple paths available, and it'll balance its load adaptively over those paths.
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.
For anyone wondering what the point of this is -- MPTCP is being pushed primarily by Apple. It is intended to make mobile devices like phones or tablets be able to switch between WiFi and 4G/5G seamlessly.
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...
"Pushed" is a bit objectifying. Apple implemented and owning both sides of client (iphone) and server (iOS distribution service) have made it work for them. And iMessage. It's works, it gives persisting end to end connection (I would say session in isolation 7 layer model terms) state, it allows services to continue unabated between wifi and mobile.
I don't know what Android uses for the same purpose, but it got a lot better about 2-3 years ago. I see it every day, when I leave the house in my car, and it's been seamless for a while now, even for live phone calls. I suppose YMMV, since everyone seems to be on a different release of Android, different hardware, etc.
This isn’t a gab at you. But this question doesn’t make sense. I think the things you don’t know you don’t know about TCP and distributed system design make this difficult to pick apart.
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.
> Remember, your identity in a TCP connection is your IP address
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.
Indeed! I always appreciate help explaining. I've been deep in networking for so long that I struggle threading the needle between not enough and too much information.
TCP can survive those interruptions on its own, unless the application sets short timeouts or the IP address changes. MPTCP keeps working when either side of the connection changes addresses.
I had such high expectations for mptcp when I first heard about it, it just makes lot of sense. But after a decade of work I see no wider interest in it, nevermind mptcp becoming the default option.
What about the obvious privacy concerns that arise from the use of this technology, particularly if it becomes widespread? I see nothing on this website that addresses those.
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.
ISP monitoring is illegal in many cases and is the easiest to prevent completely whereas multipath TCP doesn't help much at all in this case. And if you can assume digital literacy and good craft it is a non-issue anyway.
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.
People only see privacy issues, after they have been used against them, and further, after they have had detrimental impact.
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.
You might like my Digital Vegan [1] Though I suspect you really don't
need to read it. Maybe suggest or review it for others stuck in the
same trap of "convenience uber alles". Regards.
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.
> 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.
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.
Sure, but these are really niche edgecases where you really have to optimize it on a case by case.
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.
In theory yes, but good luck finding a firewall or consumer router that passes SCTP. Support for it across random internet paths is atrocious, this stuff is so stuck that if you don't look like TCP or UDP it's not generally usable. MP-TCP specifically does what it can to look like normal TCP connections so it doesn't get messed up by middle boxes and degrades gracefully.
54 comments
[ 4.1 ms ] story [ 118 ms ] threadMPTCP 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.
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.
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.
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!
[1] https://digitalvegan.net
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.