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: store received ADD_ADDR #496

Open
matttbe opened this issue Jun 6, 2024 · 1 comment
Open

in-kernel PM: store received ADD_ADDR #496

matttbe opened this issue Jun 6, 2024 · 1 comment
Labels
enhancement pm path-manager

Comments

@matttbe
Copy link
Member

matttbe commented Jun 6, 2024

Currently, upon the reception of an ADD_ADDR, new subflows are potentially created (depending on the limits), and accepted ADD_ADDR are somehow stored in the 'conn_list'. If we want to browse the list of accepted ADD_ADDR, the PM can iterate over the list of subflows, and compare addresses.

There are some limits:

  • if subflows are removed from the list from different reasons (error, closed by the other peer, etc.), we potentially lose the linked address
  • if the subflow is no longer in the conn_list, some events might no longer trigger the expected action, e.g. the add_addr_accepted counter will not be decremented upon the reception of an RM_ADDR → it might be needed to do a series of actions also when subflows are removed from the conn_list.
  • if also means the PM will not be able to create future subflows using the linked address

(Also note that in the conn_list, we could have more than one subflow using the same remote address, adding a bit more complexity.)

Idea: storing received ADD_ADDR (in a list?) instead of relying on the conn_list:

  • It would ease remote addresses managements: we store what we received, we can mark the ones being accepted, we can remote an item from the list when a RM_ADDR is removed (fixing the issue with the add_addr_accepted counter), etc.
  • This should simplify the code in pm_netlink. Iterating over this list instead of the conn_list.

Linked to mptcp: update add_addr_accepted and accept_add after subflow added patch.

@matttbe
Copy link
Member Author

matttbe commented Jun 6, 2024

@pabeni : from what I understood, when you designed the in-kernel PM, you didn't want to create a list of received ADD_ADDR, probably because it was enough to rely on the conn_list.

Now that new(?) limits have been listed, do you think adding a new list would be OK?

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