W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2020

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

From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
Date: Mon, 10 Feb 2020 09:31:04 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-584032187-1581327063-sysbot+gh@w3.org>
I see several issues with this stat (although as I said before, the more stats the better).

On congestion paths, rtt/2 is not a good proxy for one way delay, as you can have very asymmetric scenarios specially when competing against tcp based flows.

For the server case, I could implement the mapping of the RTP timestamp to the original sender NTP timestamp on my server, but I don't feel anyone will compensate the timestamps to account for the sender `rtt/2`, which will render this stat un-usable for relay server case.

How about removing the rtt of the stat and exposing the `playoutTimeInReceiverNtp` and `estimatedNtpDelta` ?

```
playoutTimeInReceiverNtp = current time according to local NTP clock
estimatedNtpDelta = reportReceivedInReceiverNtp - reportSentInSenderNtp;
estimatedPlayoutDelta = playoutTimeInReceiverNtp - estimatedPlayoutTimestamp  - 
                                         estimatedNtpDelta
```

If anyone wants to calculate the e2edelay by adding the `smoothedRtt/2`, it can be done in js with the already known values. 


-- 
GitHub Notification of comment by murillo128
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/537#issuecomment-584032187 using your GitHub account
Received on Monday, 10 February 2020 09:31:07 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:50 UTC