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

Multipath TCP patches from BZ 69292 #476

Closed
wants to merge 2 commits into from
Closed

Conversation

notroj
Copy link
Collaborator

@notroj notroj commented Aug 28, 2024

No description provided.

@@ -244,6 +244,9 @@ static int proxy_connect_handler(request_rec *r, proxy_worker *worker,
* For now we do nothing, ie we get DNS round robin.
* XXX FIXME
*/

/* set the socket protocol to use */
conf->sock_proto = worker->s->sock_proto;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not thread-safe, maybe ignoring MPTCP in mod_proxy_connect is acceptable for now because ap_proxy_connect_to_backend() has no worker configuration, and moving to ap_proxy_connect_backend() is more work..

Copy link

@Aperence Aperence Aug 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't mind dropping it in this case, from what I understood, this method is deprecated anyway so it should be replaced with ap_proxy_connect_backend in the future (which does support MPTCP) ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think dropping the changes in mod_proxy_connect and ap_proxy_connect_to_backend() is simpler for now, if one wants to use mod_proxy_connect with MPTCP we can look at how moving to ap_proxy_connect_backend() there.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dropped those in the latest version available on bugzilla

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.

Adding the possibility to create MPTCP sockets would thus
be a really fine addition to httpd, by allowing clients
to make use of their different interfaces.

This patch introduces the possibilty to connect to backend
servers using MPTCP. Note however that these changes are
only available on Linux, as IPPROTO_MPTCP is Linux specific
for the time being.

For proxies, we can connect using MPTCP by passing the
"multipathtcp" parameter:

ProxyPass "/example" "http://backend.example.com" multipathtcp=On

We then store this information in the worker and create sockets
appropriately according to this value.

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

Adding the possibility to create MPTCP sockets would thus
be a really fine addition to httpd, by allowing clients
to make use of their different interfaces.

This patch introduces the possibility to listen with MPTCP
sockets. Note however that these changes are only available
on Linux, as IPPROTO_MPTCP is Linux specific for the time being.

To do so, we extended the Listen directive to include
a "multipathtcp" option, allowing to create MPTCP sockets
instead of regular TCP ones:

Listen 80 options=multipathtcp

We then store this information in flags for the listen directive
and create sockets appropriately according to this value.

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]
@notroj
Copy link
Collaborator Author

notroj commented Aug 30, 2024

We normally bump MMN minor for changes additions to proxy_worker_shared right?

@ylavic
Copy link
Member

ylavic commented Sep 11, 2024

We normally bump MMN minor for changes additions to proxy_worker_shared right?

Yes correct.

@asfgit asfgit closed this in 4915c21 Sep 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants