Does MPTCP limit the total cwnd to 1.5MBytes?

[lwins-lights]

I and my colleagues conducted a lot of experiments to study the performance of MPTCP in HSR (High-Speed Railway) Scenario. We found something interesting that the sum of cwnds of all MPTCP subflows never exceeded 1.5MBytes. Does MPTCP explicitly limit the total cwnd to 1.5MBytes?

The cc we used is decoupled Cubic. And the scheduler is naive round-robin.

[cpaasch]

No, there is no such limitation. Your congestion window can stop increasing for several reasons. For example due to packet-loss, or because the connection is limited by the receive-window or the sender.

[lwins-lights]

@cpaasch I am quite sure that it is not due to packet-loss. Is it possible that the receive-window limits the TOTAL SUM of bytes-in-flights of all subflows? For another thing, this phenomenon (1.5MB BiF cap) disappeared when we change the kernel of the server from MPTCP to official Linux 4.10.

[cpaasch]

@lwins-lights - When you changed from MPTCP to "official Linux", you were no more using MPTCP. So then, did you had a single TCP-connection whose congestion-window was higher than 1.5MB ?

[lwins-lights]

@cpaasch Yes. That is what confused me the most. And I noted that when I changed the kernel of the server from MPTCP to "official Linux", the rwnd is set to 3MB from 1.5MB.

[cpaasch]

I see. Can you take a packet-trace on both client and server and share it with us?