Closed markusa closed 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.
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.
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.
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 toMP_SNDTIME
or something similar.