MPTCP_INFO: get metrics about sent/received bytes, etc. for the MPTCP connections

[ggreenway]

Issue: MPTCP_TCPINFO provide info about the data being sent, received, retransmit, etc. per subflow. It is possible to aggregate info from the different subflows except that if a subflow is closed in the middle of a connection, the info from this subflow is lost (the subflow has been closed by the kernel without asking the userspace).

Goal: Add metrics about the MPTCP connection to MPTCP_INFO sockopt, e.g. data octets sent/received, retransmits, etc. Info from the MPTCP level, not from the subflows.

---

(Original description)

I can get TCP_INFO metrics for all open subflows, but there's no way to retrieve metrics for subflows that have already closed.

I'd like either a way to get the totals of various metrics (data octets sent/received, retransmits, etc) for the entire mptcp connection.

[matttbe]

Hi Greg,

Thank you for having created this new ticket.

I can get TCP_INFO metrics for all open subflows, but there's no way to retrieve metrics for subflows that have already closed.

At the end, it is similar to TCP. Except that here, the subflows are closed by the kernel and the userspace cannot fetch data just before the end.

I'd like either a way to get the totals of various metrics (data octets sent/received, retransmits, etc) for the entire mptcp connection.

It would be good indeed.

I think such info could be added to MPTCP_INFO (or a new one if we need to fetch them from different subflows but I don't think we want to do that).
I don't think we currently store such metrics (sent/received data, reinjection, etc.) at MPTCP level.

Would it be OK for you to get such metrics from MPTCP level instead of per subflows?

(So here, we don't talk about TCP specific metrics, e.g. latency, packets, etc. but what happened between the userspace app and the data sent to or received from the different subflows.)

[ggreenway]

At the end, it is similar to TCP. Except that here, the subflows are closed by the kernel and the userspace cannot fetch data just before the end.

I'm considering the case where a subflow is closed much earlier than the MPTCP connection being closed, as in when the peer sends a REMOVE_ADDRESS.

Would it be OK for you to get such metrics from MPTCP level instead of per subflows?

Yes, I think that would be sufficient.

Another piece of information that may be useful on MPTCP_TCPINFO is a way to identify each entry in the array or tcp_info so that for a subflow, I can periodically poll MPTCP_TCPINFO and compute deltas for some metrics.

For instance, if I had two subflows, and then sometime during the MPTCP connection the 0'th subflow is closed and a new one is created (so the array of tcp_info has two elements in both cases) being able to tell that they are not referring to the same two subflows between two calls to MPTCP_TCPINFO.

[matttbe]

At the end, it is similar to TCP. Except that here, the subflows are closed by the kernel and the userspace cannot fetch data just before the end.

I'm considering the case where a subflow is closed much earlier than the MPTCP connection being closed

Yes indeed, that's what I was thinking about. If a subflow is closed before the end of the MPTCP connection, the userspace app will not be asked to close the subflow so it is not possible to retrieve the last info.

Would it be OK for you to get such metrics from MPTCP level instead of per subflows?

Yes, I think that would be sufficient.

Good, I will update the description of the ticket to take this direction.
We will discuss about that at our next weekly meeting.

Another piece of information that may be useful on MPTCP_TCPINFO is a way to identify each entry in the array or tcp_info so that for a subflow, I can periodically poll MPTCP_TCPINFO and compute deltas for some metrics.

For instance, if I had two subflows, and then sometime during the MPTCP connection the 0'th subflow is closed and a new one is created (so the array of tcp_info has two elements in both cases) being able to tell that they are not referring to the same two subflows between two calls to MPTCP_TCPINFO.

Good point, we didn't think about this case.
Modifying MPTCP_TCPINFO is a bit more complex. To avoid confusions, do you mind creating a separated ticket for that please?

For the moment and as a workaround, just having retrieved info from MPTCP_TCPINFO, you might want to retrieve the addresses (IPs and ports) via MPTCP_SUBFLOW_ADDRS sockopt: the different subflows will be iterated the same way. But you need to take into account that the subflows might change between the two getsockopt(). If it happens, it will likely be that the number of subflows has changed, I guess it is quite unlikely to have one subflow removed and one added at the same time (worst case, that's just for the stats, could be detected with the number of packets/bytes sent that is lower than before).