You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Currently, upon the reception of an
ADD_ADDR
(and when thefullmesh
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
andb
). The client establishes the connection betweenC(a)
andS(a)
. Once established, the server announces its additional addressS(b)
. Once received, the client connects to it using its second addressC(b)
. The client didn't use this addressC(b)
to establish a subflow with the server's primary addressS(a)
.In case of a 3rd address on each side (
C(c)
andS(c)
), upon the reception of anADD_ADDR
withS(c)
, the client should not pickC(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 pickC(b)
for the route toS(b)
, and pickC(c)
for the route toS(c)
. That doesn't sound very practical.About the configuration, such endpoints could be marked with a new flag (not compatible with
fullmesh
(andsubflow
?)), 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 toIPADDRANY
, and let the routing table finding a new local address: if the goal is to limit only to endpoints with such flag, thenip mptcp limits set add_addr_accepted X
could be used, withX
being the number of endpoints with such flag.The text was updated successfully, but these errors were encountered: