[AVTCORE] Is IDMS XR BLOCK in IDMS draft the only way to calculate one way delay?

[Qin Wu <[e-mail]>]

Hi：
I read recent version of IDMS draft, it seems some of my comments to version (-05) wrote on Jun 28 hasn’t been taken in the version (-06)
Please see :
http://www.ietf.org/mail-archive/web/avt/current/msg15434.html

One more issue I like to raise is to IDMS XR BLOCK defined in section 7:
It seems to me IDMS XR BLOCK defined in IDMS draft is only used for the dedicated IDMS application to report one way delay metric, which fails to follow guideline we defined in draft-ietf-avtcore-monarch
“
a new XR block should contain a single metric or a small number of metrics relevant
   to a single parameter of interest or concern, rather than containing
   a number of metrics which attempt to provide full coverage of all
   those parameters of concern to a specific application.

”
In other words, IDMS XR BLOCK seems to be defined in current version too much specific and is difficult to re-used by other RTP applications.

One alternative way is just to report maximum one way delay metric from each SC is more than enough. The one way delay can be calculated
Based on the sum of one way network delay and receiver-side end system delay(include decoding delay and playout delay) and can replace 64bit NTP timestamp + 32 bit RTP timestamp +32bit
presented timestamp and save at least 12 bytes.

Suppose 3 SCs report 3 different one way delay from each SC, the server could choose the maximum one way delay and send to each SC, SC
Can compare the difference between received one way delay from the server and the one way delay sent by itself and see how to synchronize media stream.


Another thing is it seems IDMS XR BLOCK is used to report on specific RTP packet (i.e.,the 1st RTP packet containing start of I-frame or last received packet).

If IDMS XR BLOCK reports on the 1st packet containing decodable frame, IDMS XR BLOCK can report both received timestamp and presented timestamp.



However if IDMS XR BLOCK reports on the last received packet during reporting interval, IDMS XR BLOCK can not report presented timestamp.

That means you ignore sum of decoding delay and playout delay(i.e., receiver-side end system delay) in each SC, when each SC has different end system delay,

That may cause one way delay calculated not precisely and impact synchronization metadata of media stream sent to different SCs.



Also comparing reporting only maximum one way delay metric, report on the last received packet may be not close or precise to maximum one way delay metric

Since maximum one way delay should keep track of each received RTP packet in each report Interval and get the maximum one way delay in the whole reporting

interval.

Regards!
-Qin