flags: add 'luminar' endpoints support #326
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some new defines related to MPTCP_INFO and EV flags, and switch to _BITUL(). Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Currently, upon the reception of an ADD_ADDR (and when the fullmesh flag is not used), the in-kernel PM will create new subflows using the local address the routing configuration will pick. It would be easier to pick local addresses from a selected list of endpoints, and use it only once, than relying on routing rules. Use case: both the client (C) and the server (S) have two addresses (a and b). The client establishes the connection between C(a) and S(a). Once established, the server announces its additional address S(b). Once received, the client connects to it using its second address C(b). Compared to a situation without the 'laminar' endpoint for C(b), the client didn't use this address C(b) to establish a subflow to the server's primary address S(a). So at the end, we have: C S C(a) --- S(a) C(b) --- S(b) In case of a 3rd address on each side (C(c) and S(c)), upon the reception of an ADD_ADDR with S(c), the client should not pick C(b) because it has already been used. C(c) should then be used. Note that this situation is currently possible if C doesn't add any endpoint, but configure the routing in order to pick C(b) for the route to S(b), and pick C(c) for the route to S(c). That doesn't sound very practical because it means knowing in advance the IP addresses that will be used and announced by the server. 'laminar', like the idea of laminar flows: the different subflows don't mix with each other on an endpoint, unlike the "turbulent" way traffic is mixed by 'fullmesh'. This new flag is then added to mptcpd as well. Link: multipath-tcp/mptcp_net-next#503 Link: https://git.kernel.org/netdev/net-next/c/539f6b9de39e Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Pull Request Test Coverage Report for Build 18382362772Details
💛 - Coveralls |
Endpoints are usually added with a flag: validate that. Set a random one (the new 'subflow' one) instead of 0. Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
matttbe
force-pushed
the
pm-kern-endp-add_addr-new
branch
from
c7dc293 to
fc6e388
Compare
This parameter was not validated before. Use all possible flags (even if they are not individually checked). Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
matttbe
commented
Oct 15, 2025
| # | ||
| # See the ip-mptcp(8) man page for details. | ||
| # | ||
| # addr-flags=subflow |
There was a problem hiding this comment.
I wonder if we should not set subflow,laminar by default. Older kernel versions will accept that.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, upon the reception of an
ADD_ADDR(and when thefullmeshflag is not used), the in-kernel PM will create new subflows using the local address the routing configuration will pick.It would be easier to pick local addresses from a selected list of endpoints, and use it only once, than relying on routing rules.
Use case: both the client (C) and the server (S) have two addresses (a and b). The client establishes the connection between C(a) and S(a). Once established, the server announces its additional address S(b). Once received, the client connects to it using its second address C(b). Compared to a situation without the 'laminar' endpoint for C(b), the client didn't use this address C(b) to establish a subflow to the server's primary address S(a). So at the end, we have:
In case of a 3rd address on each side (C(c) and S(c)), upon the reception of an ADD_ADDR with S(c), the client should not pick C(b) because it has already been used. C(c) should then be used.
Note that this situation is currently possible if C doesn't add any endpoint, but configure the routing in order to pick C(b) for the route to S(b), and pick C(c) for the route to S(c). That doesn't sound very practical because it means knowing in advance the IP addresses that will be used and announced by the server.
laminar, like the idea of laminar flows: the different subflows don't mix with each other on an endpoint, unlike the "turbulent" way traffic is mixed byfullmesh.This new flag is then added to mptcpd as well.
Link: multipath-tcp/mptcp_net-next#503
Link: https://git.kernel.org/netdev/net-next/c/539f6b9de39e