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

in-kernel PM: use endpoints only to create subflows with received ADD_ADDR #503

Open
matttbe opened this issue Jun 18, 2024 · 0 comments
Open
Labels
enhancement pm path-manager

Comments

@matttbe
Copy link
Member

matttbe commented Jun 18, 2024

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 sounds interesting to pick local addresses from a selected list of endpoint, and use it only once.

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). The client didn't use this address C(b) to establish a subflow with the server's primary address S(a).

 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.

About the configuration, such endpoints could be marked with a new flag (not compatible with fullmesh (and subflow?)), using a good explicit name (TBD).

If at least one endpoint with such flag is used, and they have all been used to create subflows, what should we do in case of a reception of a new ADD_ADDR? Maybe good to fallback to IPADDRANY, and let the routing table finding a new local address: if the goal is to limit only to endpoints with such flag, then ip mptcp limits set add_addr_accepted X could be used, with X being the number of endpoints with such flag.

@matttbe matttbe added the pm path-manager label Jun 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement pm path-manager
Projects
Status: Needs triage
Development

No branches or pull requests

1 participant