Mptcp: An overlooked new feature in Go 1.21 | Hacker News Reader

Mptcp: An overlooked new feature in Go 1.21

sobyte.net

52 pointssigna1126 comments

I've come across sobyte.net a few times now. Who's behind it? It's frequently updated with content that, at least to me, is very interesting. If it's just one person, I'd like to know how they approach it. Very impressive.

As I've previously commented (https://news.ycombinator.com/item?id=37236699), this website consists of content copied and translated from other Chinese websites, without permission (I've asked one author). The homepage is pumping out articles much faster than I would expect a person to be able to write them, and I found multiple articles with text stolen and translated from other people's writing, and code stolen verbatim. Flag and move on.

If this article is typical of their content, then they approach it by copy-pasting someone else's entire article into Google Translate and then publishing the output.

Seems like a straight translation of the referenced https://colobu.com/2023/07/03/mptcp-a-go-1-21-new-feature/

The link at the end did not make me think the entire post was a direct translation. Good catch.

Edit: It's nice this person translated it. But normally you note at the top when something is a translation. Or note it at all.

Yeah, that's not even a real link either as it can't be clicked.

Seems pretty disingenuous of the translator. :(

> By default, mptcp is disabled

By default, all TCP connections should be MPTCP. There is just upside and no real downside. It falls back to TCP when the network doesn't support it, and the vast majority of the internet supports that since iPhones use MPTCP by default.

Please reconsider the decision not to just use MPTCP by default. People using Go software for decades to come will have a buggy experience whenever they move networks from wifi to cell otherwise.

I haven't looked into mptcp much, but my understanding is that there's nothing the network needs to add to support it, right? I'm not sure why the system would ever need to fall back to standard TCP if the kernels on both ends support mptcp.

My understanding is also that MPTCP will send data over the backup link, which can incur data charges. Those charges shouldn't be very big, but I've seen carriers who round data up to the next megabyte, and a single background handshake at night can eat through your data cap surprisingly fast.

I would hope whatever data savings systems are built into mobile operating systems take care of this automatically, but I can see why one could want to disable this by default on mobile operating systems.

The fear is probably shitty corporate networks. So not a real issue.

Fair enough, there's always a shitty corporate network that'll mess with your well-designed protocol.

If I understand correctly, the protocol stack is built on TCP, but they use different IP protocol numbers, so a router or firewall may easily pass TCP, but not MPTCP(either by configuration or age).

As far as I understand, MPTCP works via a TCP option rather than a separate IP protocol number. To any normal firewall, the unknown option field shouldn't be cause for concern.

I had assumed that since IPPROTO_MPTCP(262)!=IPPROTO_TCP(6), they were using another protocol number for everything, but you're right that there's a TCP option involved too.

But also, plenty of stateful firewalls will strip unknown options. Here's how to enable Ciscos to forward it: https://www.cisco.com/c/en/us/support/docs/ip/transmission-c....

Edit: here's checkpoint: https://support.checkpoint.com/results/sk/sk114666

IPPROTO_MPTCP (262) is too big to fit into the byte that's reserved for the protocol number. I'm not sure what the reason is Linux has this protocol number, I'm guessing it's so that user mode sockets can easily request MPTCP sockets?

I'm not too surprised about Cisco and Checkpoint. I suppose corporate networks are intentionally always a pain when it comes to new protocols and features.

I think you're right that it serves only as a way to communicate to the kernel that userspace wants MTCP socket.

This does appear to be the plan: https://github.com/golang/go/issues/56539#issuecomment-13325...

   It would be up to the implementation whether the default result from MultipathTCP is on or off, and then programs could override that with SetMultipathTCP. In Go 1.21, we would default it off everywhere, and then in Go 1.22 or later, we would turn it on by default for systems that support it. Support might mean that it's an operating system that we have code for, or it might mean a more precise result, that we've sniffed the current kernel to see if it's available. That detail is up to the implementation and can change over time.

Posts with text like this really grinds my gears:

> chatGPT says that MPTCP has been included in the mainline kernel since Linux kernel version 3.6 and that users can configure and use MPTCP features, but the MPTCP community website says that MPTCP v1 is only supported since 5.6.

Why is it interesting what a GPT has to say about it, if you've fact-checked it and found contradictory information?

To remind people how unreliable GPT "facts" are?

I'm all in favor of anything that socializes the idea that believing what a GPT tells you is like believing the guy who hangs out at the corner gas station.

Demonstrating that the tool that many developers may consult first may not be telling the full truth, and that they might need to do more research?

This isn't even that egregious of a reference to a GPT, in my opinion.

At least, it mentions GPT usage. The amount of GPT verbiage passed as human output dwarves those punctilious occurrences.

Who actually uses multipath?

Anyone who uses SIRI is probably a great example.

It's quite popular actually, even there's an market for openwrt based mptcp routers, sometime also called SDN routers.

Say have eth, wifi(2.4+5Ghz+6Ghz) and cellular network, you may want to use them fully all together, there's a way for mptcp to shine;

or you have multiple proxies, and wants to improve reliability, you can also use mptcp.

And even commercial broadband services.... In full disclosure I worked as a supplier to implement MPTCP on the CPE for BT at the launch of their service (time marker 1:48 starting point) : https://youtu.be/eMKAFWy6940

MPTCP has been in use at massive scale on iOS for years now for core Apple services and any iOS application that uses Network.framework can leverage it too.

Apple

Reply on news.ycombinator.com