Re: [webrtc-stats] End-to-end delay metrics (#537)

I would say the above is incorrect, because in creating local simulations & models I found the RTCP RTT corresponds to network packets, not frames of video. I found that it is possible for the video delay to be around 5,000% higher than the network packet delay, for example when network conditions change there is disproportionate amount of delay in the application layer vs the network layer

I first read this paper / research project, which made me realize the network RTT may not correlate with the video delay, specifically at times when the network conditions have changed recently:

- https://snr.stanford.edu/salsify/
- https://www.usenix.org/system/files/conference/nsdi18/nsdi18-fouladi.pdf 

In order to asses the delay on the audio & video, it should be done separately, in my opinion. Each frame of video or discrete chunk of audio packets should be assigned a monotonically increasing timestamp on the sender, and the RTT should be calculated against the same clock (not only are the clocks not synchronized, NTP time on a single clock isn't even guaranteed to give accurate durations when sampled over time due to clock slew & "adjust time" system calls)

> If we had synchronized clocks

In my opinion, this is not something that can be safe to assume or implemented easily. One option, yes, is to detect the clock drift using the 4 timestamps approach https://en.wikipedia.org/wiki/Network_Time_Protocol#Clock_synchronization_algorithm and try to detect when the clocks definitely are not in sync, but this is a slippery slope of re-inventing NTP which is a 20yr old system that doesn't need to be re-invented IMO.

IMO the easiest thing to do is to give a RTT, which gives an upper bound. Ideally it should be the delay of the media playout, not the delay of the network packets which would be rather useless IMO.

-- 
GitHub Notification of comment by joshribakoff
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/537#issuecomment-688956936 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 8 September 2020 15:31:33 UTC