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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4