tsvwg / ietf-multipath-dccp

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-multipath-dccp/
8 stars 13 forks source link

Specify OWD measurement #12

Closed markusa closed 2 years ago

markusa commented 3 years ago

MP_RTT is mainly specified for the purpose of reassembling the data stream, split by the sender, on the receiver side. MP_RTT exposes therefore the per path RTT information from the sender to the receiver to allow the building of inter-path latency differences considered in the re-assembly process to predict lost packets.

Under some circumstances that is not ideal since RTT information sent from sender to receiver are per definition old (at least 1.5 RTTs in practice more due to ACK ratio, smoothing etc) or loose accuracy due to assymetric latency ratio in down- and uplink.

More accurate might be One Way Delay measurements transmitting the send timestamp along with packets and compare across paths.

To estimate One way Delay (OWD) DIFFERENCE for two paths, the method is the following. Sender adds to each packet its sending timestamp, call it Sx (x is packet number). Receiver logs for each packet when it was received (say Tx) Now receiver receives two packets. Say packet 1 is sent over path 1 and packet 2 over path 2. The latency difference of the two different paths can be estimated by minussing of S2-S1 (that tells you how much later packet 2 was sent. Then you minus off R2-R1 (S1 and S2 have same clock, R1 and R2 have same clock although can be different) so no need to synch clocks. Say S2-S1 is 10 millisec, we know that paths with equal delays should also have R2-R1 = 10 ms. If that is not the case then either path 1 is faster or path2 and you can easily calculate this difference.

That has to be reflected into the draft document by either defining this as part of the MP_RTT definition or define a a new MP option. The first would probably require a renaming to MP_SNDTIME or something similar.

NathalieRM commented 2 years ago

DCCP has the timestamp option: https://datatracker.ietf.org/doc/html/rfc4340#page-99 , which corresponds precisely to the sending timestamp of the packet, and it is permitted in any DCCP packet. In the Linux kernel implementation the option is only sent in the REQUEST and RESPONSE packets, but the function could be called from the MP-DCCP stack to be sent with any data packet. In summary no additional option (MP_SNDTIME) neither additional information in the MP_RTT option are necessary to implement the OWD difference estimation.

markusa commented 2 years ago

Agree with @NathalieRM and #43 will describe the usage of the DCCP Timestamp Option as a mean for advanced re-ordering capabilities. No further action needed here.