The best way to analyse MPTCPv1 performance? [QUESTION]

[vandit86]

I've been experimenting with MPTCPv0 (out-of-tree) and MPTCPv1 (upstream (RFC 8684)) for a while now.
However, I can't find a good application layer analysis tool for the upstream MPTCP protocol. All existing tools are not suitable for MPTCPv1, since the upstream version is not compatible with MPTCPv0. For now, I keep using the same set of standard tools to analyse MPTCPv1 performance, like Wireshark (version 3.4.8) and tcptrace.

Can someone advise me on the best way to examine MPTCPv1 protocol? For example, to see the data sequence number evolution through subflows, delays, re-injections, data mapping and so on. I note that wireshark works well with MPTCPv0, but it can't interpret (translate) perfectly the upstream version of the protocol. Please, correct me if I'm wrong.

Also, I can't find documentation other than RFC. Many aspects of the upstream protocol operation are not clear from the RFC (i.e., congestion control, scheduling mechanism, etc) and can only be identified by examining traffic. It would be nice to have a set of configuration/usage examples that will help one to understand better the operation of MPTCPv1.

Thank you!

[RuiCunhaM]

I note that wireshark works well with MPTCPv0, but it can't interpret (translate) perfectly the upstream version of the protocol.

Hi! Just for curiosity, why exactly do you find that Wireshark does not translate perfectly the upstream/v1 version of the protocol? I ask this because it is what I've been using also, and so far I haven't seem to have find anything wrong, I wonder if I missed something.

[matttbe]

Hello,

If you compile 'mptcp_v0.96' branch in the out-of-tree version, you can turn on a sysctl to use MPTCPv1.

Latest version of Wireshark should properly interpret MPTCPv1. If not, there is a bug :)

tcptrace has never been MPTCP aware.

Also, I can't find documentation other than RFC. Many aspects of the upstream protocol operation are not clear from the RFC (i.e., congestion control, scheduling mechanism, etc) and can only be identified by examining traffic. It would be nice to have a set of configuration/usage examples that will help one to understand better the operation of MPTCPv1.

Indeed but for the moment, the configuration is quite simple: there is one path-manager that can be modified with ip mptcp (there is a dedicated man page), one packet scheduler and no MPTCP-specific Congestion Control.

[vandit86]

@RuiCunhaM. Actually, I was confused by the Data Sequence Number(DSN), in the way it represented on Wireshark for upstream version. There are tree different fields: tcp.options.mptcp.rawdataseqno, mptcp.dsn, mptcp.dss.dsn. For out-of-tree protocol version, I looked only on mptcp.dsn (second DSN column on image) and it was "nice" increasing relative number.., but I guess for upstream version tcp.options.mptcp.rawdataseqno is makes more sense (first DSN column on image).

Other thing that I noted that Wireshark could not recognize data reinjection on MPTCP level, ( _mptcp.reinjectionof and _mptcp.reinjectedin ). Maybe this because of mapping for a range of data used in upstream MPTCPv1, rather than per‑packet signalling.

[vandit86]

@matttbe ,

If you compile 'mptcp_v0.96' branch in the out-of-tree version, you can turn on a sysctl to use MPTCPv1.

I've been experimenting with 5.15.0-rc7 kernel from the export branch from this (mptcp_net-next) repo.

Indeed but for the moment, the configuration is quite simple: there is one path-manager that can be modified with ip mptcp (there is a dedicated man page), one packet scheduler and no MPTCP-specific Congestion Control.

As I'm understand, MPTCPv1 implement BLEST-like packet scheduler and the coupled congestion control??

Thanks,

[matttbe]

@vandit86 I think we are talking about different things:

• MPTCPv1 is the protocol defined in RFC8684
• MPTCPv0: RFC6824 (deprecated by MPTCPv1)

There are two major implementations of MPTCP in the Linux kernel:

• an out-of-tree implementation (fork), aka mptcp.org: https://github.com/multipath-tcp/mptcp
• and an upstream version (this repo).

The out-of-tree supports MPTCPv0 from the beginning and MPTCPv1 since v0.96 (kernel 5.4). The upstream version only supports MPTCPv1.

As I'm understand, ~MPTCPv1~ MPTCP Upstream implement BLEST-like packet scheduler and the coupled congestion control??

The upstream implementations has for the moment only one packets scheduler inspired from BLEST model. No coupled congestion controls are supported (yet), regular ones per subflow are used..

[vandit86]

Ok, now everithing is much clearer to me then before. Thank you Matthieu @matttbe for explanation) I switch from the older kernel to upstreme version in order to make exepriments with MPTCPv1. Now i see that I could compile 'mptcp_v0.96' branch in the out-of-tree version (kernel 5.4) and switch to version 1 by sysctl instead. (I guess..).

Furthermore, as far as I understand, currently out-of-tree implementetion offers higher configuration flexebility. i.e., it is possible to select different alilable path-managers, congestion controls and schedulers.. In addition, ip mptcp tool should work as well if MPTCPv1 is enabled.. Am I right ??

Thank you !!!

[matttbe]

Great!

In addition, ip mptcp tool should work as well if MPTCPv1 is enabled..

No, ip mptcp is specific to the Upstream implementation.

I hope you don't mind if I close this ticket.

For what you saw with Wireshark, it looks like a bug on their side if it cannot properly track the DSN. Maybe best to open a bug report there. (But because it might be specific to MPTCPv1, maybe someone else has to look at that → maybe good to also open a new dedicated ticket in this project?)