Closed dweb32 closed 5 years ago
cpaasch
commented
5 years ago Hello,
I don't understand your question. Because, if you use tcpdump to measure the time, the data-sequence number is in the TCP option-space. So you see it there.
Cheers, Christoph
dweb32
commented
5 years ago Hi Christoph,
if you use tcpdump to measure the time, the data-sequence number is in the TCP option-space. So you see it there.
Unfortunately, not all received packets carry a data-sequence number (DSN) in the data-sequence signal (DSS) option. The RFC 6824 describes it as follows:
A data sequence mapping does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver. This can be used to reduce overhead in cases where the mapping is known in advance; one such case is when there is a single subflow between the hosts, another is when segments of data are scheduled in larger than packet-sized chunks.
Therefore, we try to calculate the individual DSN(P) of such packet P manually by taking the data-sequence number of the last received mapping DSN(P_last) and add the difference of the mapped subflow-sequence number SSN(P_last) and TCP-sequence number TCP_SEQ(P):
DSN(P) = DSN(P_last) + [TCP_SEQ(P) - SSN(P_last)]
The question now is whether this calculation applies without loss of generality or if we have missed a special case in which some nasty middleboxes break this equation?
Regards, Daniel
cpaasch
commented
5 years ago if you use tcpdump to measure the time, the data-sequence number is in the TCP option-space. So you see it there.
Unfortunately, not all received packets carry a data-sequence number (DSN) in the data-sequence signal (DSS) option. The RFC 6824 describes it as follows:
You should just track the packets that do have a DSS-option. Because, MPTCP will always only acknowledge the full mapping. So, when you receive on the input-path a DSS-option, store DSN + DLEN = expected_data_ack with the timestamp. Once you see an outgoing DATA_ACK >= expected_data_ack, your mapping has been ack'd and you have the time spent in the receive/out-of-order queue.
A data sequence mapping does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver. This can be used to reduce overhead in cases where the mapping is known in advance; one such case is when there is a single subflow between the hosts, another is when segments of data are scheduled in larger than packet-sized chunks. Therefore, we try to calculate the individual DSN(P) of such packet P manually by taking the data-sequence number of the last received mapping DSN(P_last) and add the difference of the mapped subflow-sequence number SSN(P_last) and TCP-sequence number TCP_SEQ(P):
DSN(P) = DSN(P_last) + [TCP_SEQ(P) - SSN(P_last)]
The question now is whether this calculation applies without loss of generality or if we have missed a special case in which some nasty middleboxes break this equation?
As mentioned above - mappings are always acknowledged in one big batch. The receiver never splits up a mapping. So, you just need to track the packets that actually do have a DSS-option.
Does this clarifies it? :)
dweb32
commented
5 years ago You should just track the packets that do have a DSS-option. Because, MPTCP will always only acknowledge the full mapping. So, when you receive on the input-path a DSS-option, store DSN + DLEN = expected_data_ack with the timestamp. Once you see an outgoing DATA_ACK >= expected_data_ack, your mapping has been ack'd and you have the time spent in the receive/out-of-order queue.
Ok, this totally clarifies my question. I will close this issue now.
Initially, my thinking about a per-packet DSN was inspired by this part of the code: https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.95/net/mptcp/mptcp_input.c#L435-L441 But as you mentioned that only full mappings get ack'd, it's actually easier than I thought.
Thank you Christoph! :)
maybe you could give us a hint on the following question:
We would like to compute a metric denoting the time that received data spends in the MPTCP-level reordering queue. As you have already proposed on github #204 we want to take the packet-trace at the receiver and compute the difference of the timestamps between when a packet arrives and when the MPTCP DATA_ACK acknowlegdes it.
In order to map a received packet to the data sequence number in the DATA_ACK we need to compute the data-level sequence number of the received packet. We have tried to reconstruct how this is computed on the basis of the description of section 3.3.1 of the MPTCP-RFC as well as by looking into the mptcp source code. Unfortunately, we are still unclear on the correct interpretation of this calculation.
Could you maybe give us an example for the calculation of the data-level sequence number of a received packet using the data sequence and subflow sequence numbers of the last data sequence mapping received and the TCP sequence number of the received packet?
We would really be thankful, if you could help us out here.