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

Mptcp: Moving laptop from GBit to wireless without applications noticing?

redhat.com

Post reply on HN
Print view View original

11–20 of 43 posts

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#11

Post by fulafel »

mister_goo wrote: post #10
fulafel wrote: post #8

The net community gave up on the TCP->SCTP upgrade because of NAT (and other middle-) boxes breaking IP. It would have fixed many other things too (eg head-of-line blocking). The good side was that we kept the simplicity of TCP. I wonder what's the middlebox story of MPTCP.

Newer protocols like QUIC are encapsulated by UDP instead of adding new protocol numbers. NAT box breaks because NAT must be implemented for each protocol (port number not at IP level).

SCTP is over 20 years old. I think the explanation for today's situation is slightly more complex than NAT boxes not having enough advance notice. NAT isn't allowed by the TCP/IP specs, for the exact reason that it breaks IP and new internet applications. Everyone was supposed to move to IPv6 with enough addresses so the temptation to use NAT would go away. Instead we ignored the stewardship of IETF and ISOC, and just adapted to the laissez faire world of middleboxes and broken IPv4.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#12

Post by dr_hooo »

fulafel wrote: post #8

The net community gave up on the TCP->SCTP upgrade because of NAT (and other middle-) boxes breaking IP. It would have fixed many other things too (eg head-of-line blocking). The good side was that we kept the simplicity of TCP. I wonder what's the middlebox story of MPTCP.

In MPTCP each connection from the bundle appears/behaves just like a single "traditional" TCP connection. Therefore - at least in theory - there should be no issues with NAT/middleboxes. In fact this has been a major design goal from the start.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#13

Post by ale42 »

justsomehnguy wrote: post #6
thrtythreeforty wrote: post #5

Earlier quoted context omitted.

Re: bonding, what a good idea! I may have to set this up on my laptop. Are there any downsides? (Besides being unable to connect to different networks of course)

You need to be in the same L2/L3 domain. Not always the case for the corporate networks.

Definitely not the case in our network... IP ranges are totally different on wired and wireless here.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#14

Post by mister_goo »

fulafel wrote: post #11
mister_goo wrote: post #10

Earlier quoted context omitted.

Newer protocols like QUIC are encapsulated by UDP instead of adding new protocol numbers. NAT box breaks because NAT must be implemented for each protocol (port number not at IP level).

SCTP is over 20 years old. I think the explanation for today's situation is slightly more complex than NAT boxes not having enough advance notice. NAT isn't allowed by the TCP/IP specs, for the exact reason that it breaks IP and new internet applications. Everyone was supposed to move to IPv6 with enough addresses so the temptation to use NAT would go away. Instead we ignored the stewardship of IETF and ISOC, and jus…

So there is a difference between what people are supposed to do and what people actually do. What I am wondering now is why IPv6 didn't adapt NAT as a first class feature, if IPv6 added something like port number in IPv6 header, NAT could not break protocols. It seems IPv6 strongly resists NAT, but in reality, people still use NAT on IPv6.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#15

Post by fulafel »

mister_goo wrote: post #14
fulafel wrote: post #11

Earlier quoted context omitted.

SCTP is over 20 years old. I think the explanation for today's situation is slightly more complex than NAT boxes not having enough advance notice. NAT isn't allowed by the TCP/IP specs, for the exact reason that it breaks IP and new internet applications. Everyone was supposed to move to IPv6 with enough addresses so the temptation to use NAT would go away. Instead we ignored the stewardship of IETF and ISOC, and jus…

So there is a difference between what people are supposed to do and what people actually do. What I am wondering now is why IPv6 didn't adapt NAT as a first class feature, if IPv6 added something like port number in IPv6 header, NAT could not break protocols. It seems IPv6 strongly resists NAT, but in reality, people still use NAT on IPv6.

Using NAT with IPv6 sounds tragic, hopefully this isn't common.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#16

Post by jeroenhd »

dr_hooo wrote: post #12
fulafel wrote: post #8

The net community gave up on the TCP->SCTP upgrade because of NAT (and other middle-) boxes breaking IP. It would have fixed many other things too (eg head-of-line blocking). The good side was that we kept the simplicity of TCP. I wonder what's the middlebox story of MPTCP.

In MPTCP each connection from the bundle appears/behaves just like a single "traditional" TCP connection. Therefore - at least in theory - there should be no issues with NAT/middleboxes. In fact this has been a major design goal from the start.

I think that's great until those middleboxes start trying to parse TLS headers. TLS 1.3 looks like TLS 1.2 because of the same protocol ossification problem.

There will be issues with middleboxes, but in my opinion middleboxes have been given more than enough time to stop freaking out about network interception after the problem with TLS 1.3 was discovered.

The Red Hat people primarily seem to focus on this as a backend/server-to-server communication method which means that MPTCP (or SCTP) can be rolled out without too much trouble. A big problem SCTP has is that there is no good implementation outside Linux, and even on Linux performance is suboptimal. MPTCP can be linked into the application at runtime (https://github.com/ngi-mptcp/curl/wiki/Multipath-TCP-on-Wind...) so that's not necessarily an issue here, which helps.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#17

Post by ignoramous »

fulafel wrote: post #8

The net community gave up on the TCP->SCTP upgrade because of NAT (and other middle-) boxes breaking IP. It would have fixed many other things too (eg head-of-line blocking). The good side was that we kept the simplicity of TCP. I wonder what's the middlebox story of MPTCP.

Popular IPv4 to IPv6 transition mechanisms broke anything that wasn't TCP/UDP/ICMP, just as well.

And: Speak nothing of BigCloud load balancers...

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#18

Post by jeroenhd »

fulafel wrote: post #15
mister_goo wrote: post #14

Earlier quoted context omitted.

So there is a difference between what people are supposed to do and what people actually do. What I am wondering now is why IPv6 didn't adapt NAT as a first class feature, if IPv6 added something like port number in IPv6 header, NAT could not break protocols. It seems IPv6 strongly resists NAT, but in reality, people still use NAT on IPv6.

Using NAT with IPv6 sounds tragic, hopefully this isn't common.

There are reasons to do some kind of NAT across IPv6. For example, switching ISPs may throw your internal network addressing in disarray which can be either a pain or a massive problem; NPTv6 will prevent that from being too much of an issue inside the premises, which should cover 95% of the issues. The best thing is that you keep most of the advantages of IPv6 (all addresses and all ports publicly reachable, foregoing the need for dangerous stuff like ALG) despite the address translation.

Alternatively you could register an IPv6 address of your own but you'd need to find an ISP that will let you use that, which can be harder than you'd hope, or you could tunnel your entire connection through the cloud in a semi-NAT system.

This isn't a problem for 99.9% of people and I'd wager it's not a problem for over 80% of businesses either. However, for companies with zealous network administrators and IP-based access control this is a real problem that needs solutions like NAT.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#19

Post by jeroenhd »

fulafel wrote: post #8

The net community gave up on the TCP->SCTP upgrade because of NAT (and other middle-) boxes breaking IP. It would have fixed many other things too (eg head-of-line blocking). The good side was that we kept the simplicity of TCP. I wonder what's the middlebox story of MPTCP.

Aside from terrible middleboxes, SCTP also suffered from a lack of kernel implementations on non-Linux platforms and performance issues in the existing implementation.

It's still there but there hasn't been a need for a protocol to really use it. Protocols like HTTP(S) could really use the SCTP benefits but those need solid client implementations; server protocols like DNS or FTP are restricted more by their own limitations than by TCP, really. Of course you'll find niche use cases where SCTP would've been a godsend, but without proper Windows support _and_ broken middleboxes ruining everybody's internet experience, SCTP was sort of doomed from the start.

MPTCP has some compatibility advantages and TCP-inside-TCP allows for solid client side implementations that can be linked to the userland code itself (https://github.com/ngi-mptcp/curl/wiki/Multipath-TCP-on-Wind...) without elevating credentials; sadly, SCTP didn't have that luxury, as Windows (rightfully) restricted access to raw sockets not long after SCTP began to gain popularity among its fringe group of supporters.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#20

Post by iforgotpassword »

jeroenhd wrote: post #4
globalc wrote: post #3

Earlier quoted context omitted.

Nice, was not sure how stable such a setup would be. The applications will not need further modification and just need to be sent over the bond. For MPTCP, as of today the applications over the mptcp-stream (which has subflows over the 2 media) need to be modified to use MPTCP, or an additional layer like with shadowsocks needs to be used to transparently encapsulate traffic over the link.

The article mentions the tool `mptcpize` which converts TCP into MPTCP by hooking calls to the networking API. With the tooling already there, I think this makes for an excellent use case for MPTCP.

As you need to do it on both ends it is limited to your own stuff. The bonding trick works for everything automagically.
Post reply on HN