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

31–40 of 104 posts

Re: Multipath TCP for Linux (2022)

#31

Post by fragmede »

throw0101b wrote: post #18
quectophoton wrote: post #13

Earlier quoted context omitted.

> I've heard about MPTCP back in 2013. > 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. You might also be interested in SCTP[1] from the year 2000, which also hasn't gotten any traction so far. [1]: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...

> You might also be interested in SCTP[1] from the year 2000, which also hasn't gotten any traction so far. Probably partly because middleware boxes (e.g., firewalls) either didn't/don't support it and/or rules were written to only support "TCP" (as opposed to 'stream') or "UDP" (as opposed to 'dgram'; see also "DCCP").

The protocol is specified by a byte in the IP packet; how many middleware boxes block everything except for ICMP, TCP, and UDP? What is the probability that a packet with that byte set to something unexpected actually gets from source to destination?

Re: Multipath TCP for Linux (2022)

#32

Post by infogulch »

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" https://www.researchgate.net/publication/327122884_Multipath...

Now I'm curious about how these protocols compare in production operation. Anybody have experience with both?

Re: Multipath TCP for Linux (2022)

#33

Post by bbss »

toast0 wrote: post #22
ohnoesjmr wrote: post #6

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…

Apple also contributed[1] MPTCP support to Envoy Proxy.

[1]https://github.com/envoyproxy/envoy/pull/18780

Re: Multipath TCP for Linux (2022)

#34

Post by mauriciob »

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…

How would routing be done without source/destination? When the device changes networks, how does the origin and all routers along the way know that this device is on a new network?

Re: Multipath TCP for Linux (2022)

#35

Post by zare_st »

mauriciob wrote: post #34
EvanAnderson wrote: post #29

Earlier quoted context omitted.

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…

How would routing be done without source/destination? When the device changes networks, how does the origin and all routers along the way know that this device is on a new network?

Yeah it's a shortsighted plan. How would i set up rules on firewall if I don't know how to distingush the connections?

Re: Multipath TCP for Linux (2022)

#36

Post by zare_st »

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…

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 switching port (16-bit) value to arbitrary 32-bit identifier.

Re: Multipath TCP for Linux (2022)

#37

Post by mlyle »

zare_st wrote: post #35
mauriciob wrote: post #34

Earlier quoted context omitted.

How would routing be done without source/destination? When the device changes networks, how does the origin and all routers along the way know that this device is on a new network?

Yeah it's a shortsighted plan. How would i set up rules on firewall if I don't know how to distingush the connections?

There's two separate ideas here:

* Where to send a frame to get to the other side of the connection

* Whose connection this is.

TCP combined the two, because we didn't have mobile clients or a lot of multihomed systems that would benefit from distinguishing them. Also, every octet in the header counted.

In practice, this means we have to keep building a lot of infrastructure on top of TCP (or parallel to it, in datagram protocols) to handle retries and splitting flows well. In turn, these things are completely opaque to the network and it's difficult to write rules about them.

Whereas if we had different packet fields for "where am I sending this packet right now" and "whose flow does this belong to"? we could write better firewall rules, have less infrastructure built on top of TCP, and have better typical application performance.

Re: Multipath TCP for Linux (2022)

#38

Post by mlyle »

zare_st wrote: post #36
EvanAnderson wrote: post #29

Earlier quoted context omitted.

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…

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

Re: Multipath TCP for Linux (2022)

#39

Post by mlyle »

mauriciob wrote: post #34
EvanAnderson wrote: post #29

Earlier quoted context omitted.

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…

How would routing be done without source/destination? When the device changes networks, how does the origin and all routers along the way know that this device is on a new network?

> how does the origin and all routers along the way

It's just the origin that needs to know what address(es) it should be using as the destination at layer 3.

The big problems with this is that it depends upon things that weren't really feasible in the early 80's -- bigger packet headers, a bit more state on each side of the connection, potential need for cryptographic authentication.

Re: Multipath TCP for Linux (2022)

#40

Post by topspin »

mauriciob wrote: post #34
EvanAnderson wrote: post #29

Earlier quoted context omitted.

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…

How would routing be done without source/destination? When the device changes networks, how does the origin and all routers along the way know that this device is on a new network?

> How would routing be done without source/destination?

There is still a source/destination address. Routing still works. But those addresses are allowed to change without disrupting the connection because the connection isn't based on the values of these addresses.

> When the device changes networks, how does the origin and all routers along the way know

The routers don't need to "know" these things.

MPQUIC does this. To the network it's just UDP packets moving around. Connection state is dealt with at higher levels and doesn't rely on IP addresses.

Post reply on HN