Doc and guidance for users

[matttbe]

We don't have a clear documentation and guidance for users. It is missing and we can see that by looking at the recent tickets we got from users.

It might be good to update https://mptcp.dev with:

• What to do to have MPTCP working:
  • app using IPPROTO_MPTCP or mptcpize (+ go)
  • configure routing (+ why) on both the client and the server for each additional address (if not LAN)
  • add MPTCP endpoints (+ why) for each additional address on both the client and the server
  • how to check MPTCP is being used?
• What to look at in case of problems (another page?)
  • ss -Menita → subflows > 0 == additional subflows
  • ip mptcp endpoint
  • ip mptcp limits
  • ip rule
  • nstat
  • tcpdump
• Explanations about path manager vs packet scheduler:
  • concept: we can re-use schema from slides, e.g. page 20 and 21 from https://fosdem.org/2023/schedule/event/mptcp_upstream/attachments/slides/5786/export/events/attachments/mptcp_upstream/slides/5786/FOSDEM_23_MPTCP_Upstream.pdf
  • how it is controlled:
    • in-kernel PM vs userspace PM
    • default vs WIP BPF packet scheduler

Also, regarding the issues on GitHub, it might be good to add templates with some hints / pointers: not to much of text, commands that can be helpful, etc.

Anybody interested by looking at that? :)

[matttbe]

We can also add some tools as part of mptcpd, e.g. something to check if the routes are OK, something to dump all useful info.

[matttbe]

From the last meeting: we can also modify mptcpize to check the paths, etc.:

• check the different endpoints and check if the routes are OK: ip route get <ip> from <iface>
• check if we get an ADD_ADDR by just opening a new connection (to have more subflows established, we need to get data)

[pabeni]

check if we get an ADD_ADDR by just opening a new connection (to have more subflows established, we need to get data)

... and then check if the local host valid route to reach such address, additionally check if local endpoint with full-mesh flag have valid route to reach such address.

In both case reports the expected number of created subflows and the eventual problematic endpoints.

Note that the above will not catch firewall or NAT related issues

[matttbe]

(and we don't have to code that in C ;-) )

[matttbe]

I think we can close this ticket:

• mptcp.dev has been updated with more content
• a doc is available on the kernel side
• a script is available in mptcpd to help to collect info