Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add TCP_MAXSEG socket option support #515

Open
matttbe opened this issue Aug 23, 2024 · 0 comments
Open

Add TCP_MAXSEG socket option support #515

matttbe opened this issue Aug 23, 2024 · 0 comments

Comments

@matttbe
Copy link
Member

matttbe commented Aug 23, 2024

The TCP_MAXSEG socket option is currently not supported by MPTCP, mainly because it has never been requested before. But there are still valid use-cases, e.g. with HAProxy:

It's not that common anymore but 15 years ago when ADSL over PPPoE was
everywhere, it was super frequent to see users not able to upload large
POST data over TCP because their PC connected with a 1500 MTU to their
PPPoE modem/router was seeing its packets rejected due to the extra 8
bytes of PPPoE encapsulation. Many people had by then implemented the
set-mss rule in iptables on the server infrastructure to deal with this,
but high-bandwidth hosting providers couldn't even just place a firewall
in front of haproxy just to deal with that, so in this case it was very
convenient to permit haproxy to simply configure the socket to negotiate
a lower MSS compatible with everyone's setup.

Nowadays with everyone having a triple-play box provided by the ISP,
all this stuff is transparent to the user (when needed at all). However
I've been aware of users doing that as well to fixup trouble caused by
inter-company VPN links. You know, the type of places where everyone
says "it's right on my side, it must be the other side"...

So I guess that nowadays the mss setting mostly serves to fixup VPN
environments, and it's not much likely that we'll see that with MPTCP
soon I think (but I could of course be wrong).

https://www.mail-archive.com/haproxy@formilux.org/msg45227.html

It should not be difficult to add its support in MPTCP by propagating the value to all subflows. If someone wants a different behaviour, BPF can be used to set different values per subflows (or change the MSS value per path with Netfilter).

haproxy-mirror pushed a commit to haproxy/haproxy that referenced this issue Aug 30, 2024
Multipath TCP (MPTCP), standardized in RFC8684 [1], is a TCP extension
that enables a TCP connection to use different paths.

Multipath TCP has been used for several use cases. On smartphones, MPTCP
enables seamless handovers between cellular and Wi-Fi networks while
preserving established connections. This use-case is what pushed Apple
to use MPTCP since 2013 in multiple applications [2]. On dual-stack
hosts, Multipath TCP enables the TCP connection to automatically use the
best performing path, either IPv4 or IPv6. If one path fails, MPTCP
automatically uses the other path.

To benefit from MPTCP, both the client and the server have to support
it. Multipath TCP is a backward-compatible TCP extension that is enabled
by default on recent Linux distributions (Debian, Ubuntu, Redhat, ...).
Multipath TCP is included in the Linux kernel since version 5.6 [3]. To
use it on Linux, an application must explicitly enable it when creating
the socket. No need to change anything else in the application.

This attached patch adds MPTCP per address support, to be used with:

  mptcp{,4,6}@<address>[:port1[-port2]]

MPTCP v4 and v6 protocols have been added: they are mainly a copy of the
TCP ones, with small differences: names, proto, and receivers lists.

These protocols are stored in __protocol_by_family, as an alternative to
TCP, similar to what has been done with QUIC. By doing that, the size of
__protocol_by_family has not been increased, and it behaves like TCP.

MPTCP is both supported for the frontend and backend sides.

Also added an example of configuration using mptcp along with a backend
allowing to experiment with it.

Note that this is a re-implementation of Björn's work from 3 years ago
[4], when haproxy's internals were probably less ready to deal with
this, causing his work to be left pending for a while.

Currently, the TCP_MAXSEG socket option doesn't seem to be supported
with MPTCP [5]. This results in a warning when trying to set the MSS of
sockets in proto_tcp:tcp_bind_listener.

This can be resolved by adding two new variables:
sock_inet(6)_mptcp_maxseg_default that will hold the default
value of the TCP_MAXSEG option. Note that for the moment, this
will always be -1 as the option isn't supported. However, in the
future, when the support for this option will be added, it should
contain the correct value for the MSS, allowing to correctly
set the TCP_MAXSEG option.

Link: https://www.rfc-editor.org/rfc/rfc8684.html [1]
Link: https://www.tessares.net/apples-mptcp-story-so-far/ [2]
Link: https://www.mptcp.dev [3]
Link: #1028 [4]
Link: multipath-tcp/mptcp_net-next#515 [5]

Co-authored-by: Dorian Craps <dorian.craps@student.vinci.be>
Co-authored-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Needs triage
Development

No branches or pull requests

1 participant