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

41–50 of 104 posts

Re: Multipath TCP for Linux (2022)

#41

Post by znpy »

fragmede wrote: post #31
throw0101b wrote: post #18

Earlier quoted context omitted.

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

The “funny” thing is that http3 really really looks like a transport protocol encapsulated into… uso. Exactly because many middle boxes block anything that’s not a very well known protocol

Re: Multipath TCP for Linux (2022)

#42

Post by londons_explore »

DarrisMackelroy wrote: post #27
londons_explore wrote: post #16

Earlier quoted context omitted.

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.

Except TCP is just a bad protocol to start with for tunnelling, because packetized data has to be delivered in-order, and head of line blocking messes up congestion control algorithms in the tunnelled data.

Re: Multipath TCP for Linux (2022)

#43

Post by alerighi »

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…

The problem is that the TCP/IP model stops at level 4, and if we consider TCP a protocol of transport, it shouldn't do that.

In the OSI model what you talk about is level 5, that is session, but in TCP/IP there is no such level, thus it must be handled by the application (e.g. trough a session cookie, in HTTP).

Re: Multipath TCP for Linux (2022)

#44

Post by EvanAnderson »

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…

The protocol would have to handle binding the network to the transport. MPTCP and SCTP both handle that via registering and un-register network layer endpoints. This parallel universe TCP would be the same in that regard.

(I did say I was oversimplifying...

Re: Multipath TCP for Linux (2022)

#45

Post by Hikikomori »

fragmede wrote: post #31
throw0101b wrote: post #18

Earlier quoted context omitted.

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

How does sctp work with NAT that your typical home box uses?

Re: Multipath TCP for Linux (2022)

#46

Post by eptcyka »

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 do you even firewall such a protocol?

Re: Multipath TCP for Linux (2022)

#47

Post by Hikikomori »

slt2021 wrote: post #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?

They just block or rate limit it severely when they dont know what it is.

Re: Multipath TCP for Linux (2022)

#48

Post by klysm »

alerighi wrote: post #43
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…

The problem is that the TCP/IP model stops at level 4, and if we consider TCP a protocol of transport, it shouldn't do that. In the OSI model what you talk about is level 5, that is session, but in TCP/IP there is no such level, thus it must be handled by the application (e.g. trough a session cookie, in HTTP).

I disagree. There’s no reason TCP couldn’t work like that. See QUIC for example

Re: Multipath TCP for Linux (2022)

#49

Post by mhandley »

vesinisa wrote: post #11

> If any middlebox in between does not support it, the returned SYN+ACK packet will not contain MPTCP options in the TCP option field. That sounds .. quite restrictive. Is the only requirement on a middlebox to just forward the MPTCP options as-is?

Before we finalized the specs we did a lot of testing to make sure that enabling MPTCP wouldn't break connectivity. Either it would be passed correctly, or it would fall back to single-path TCP safely. Generally, so long as a middlebox passes through unknown options unmodified, and does not try to enforce that the TCP sequence space it sees is contiguous, MPTCP should work through that middlebox.

If you're interested, we wrote a couple of papers on this:

[1] https://www.usenix.org/conference/nsdi12/technical-sessions/...

[2] https://www.researchgate.net/publication/229002024_Is_it_sti...

Re: Multipath TCP for Linux (2022)

#50

Post by dheera »

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

Post reply on HN