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

From: Qin Wu <[email-masked]>
Date: Fri, 3 Aug 2012 07:30:42 +0000

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

---

From: Qin Wu <[email-masked]>
Date: Fri, 3 Aug 2012 16:55:03 +0000

Hi, Mario:
I think reporting one way network delay or one way delay including decoding delay and playout delay is more straightforward and simple way comparing reporting media synchronization metadata information using IDMS XR block.
But maybe both reporting can coexist and be used to support IDMS. 
Please see my replies inline below.

Regards!
-Qin
-----邮件原件-----
发件人: Mario Montagud Climent [mailto:[email-masked]] 
发送时间: 2012年8月3日 22:59
收件人: Qin Wu
抄送: [email-masked]
主题: Re: [AVTCORE] Is IDMS XR BLOCK in IDMS draft the only way to calculate one way delay?

Hi Qin, all,

See our comments inline.

Qin Wu <[email-masked]> escribió:

> 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 :
> 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
> ?
> ?
> 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
> 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.
>

[F & M] We don?t think the XR block for IDMS, or IDMS report, attempts  
to cover a ?full coverage? of relevant metrics of concern to ?a  
specific application?. It reports on reception times (mandatory)  
and/or presentation times (optional), which in our opinion are two  
relevant metrics for those applications requiring IDMS (not for a  
dedicated application), both referred to the RTP timestamp of a  
specific RTP packet.

[Qin]: my point is those metrics are only dedicated by IDMS application.

Reporting on RTP packet reception times is mandatory. It can be used  
to infer the one-way network delay which can be easily calculated by  
the target side (e.g. MSAS). 

[Qin]: Why not report one way network delay metric directly?
It is more straightforward and simple and save more bytes to be sent.

Presentation times give information of  
the end-to-end one-way delay (from generation at the sender side to  
presentation at the client side) for the RTP packet the XR block  
reports on, and they are optional since not all the applications would  
be able to track RTP packets until their presentation time (this can  
be seen as a layer-violation in some RTP implementations, as it was  
already discussed in the AVTCORE mailing list in previous versions of  
the IDMS draft).

[Qin]: Right presented timestamp is optional metric not mandatory metric.
If some SCs support reporting presented timestamp while some SCs don't,
the sever must ignore this presented timestamp even some SCs send
their own presented timestamp.

From this perspective, it is equivalent to report received timestamp or one way network delay.
Why we choose to report received timestampe.

On the other hand, we can take the sum of decoding delay and playout delay at the client side into account when
We choose to report one way delay directly. That is to say, SC can send only one way network delay to the server,
Only SC report the sum of one way network delay in the network side and decoding delay, playout delay at the client side which we call it
"one way delay", then we can use one flag bit in the Block header to indicate which to report.
In this sense, it is equivalent to report received timestamp and presented timestamp or "one way delay".

By including both metrics, the MSAS can know if an increase/decrease  
of the end-to-end delay for a specific SC is due to the  
increase/decrease of the network delay (e.g. congestion in the  
network), since it is given by the time difference between the  
reception and generation time of that RTP packet, or it is due to the  
increase/decrease of the delay at the end-system side (e.g. buffering,  
decoding, de-packetization, processing, rendering, etc., delays),  
since it is given by the time difference between the presentation and  
reception time for that RTP timestamp.

We think both metrics are needed since they indicate useful  
information for IDMS.

[Qin]: You can not guarantee reporting both metrics since in some cases, SCs
are not intelligent to report presented timestamp.
>
> 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.
>

[F & M] If presentation times are included in the XR block for IDMS,  
the SCs SHOULD report on the last presented RTP Timestamp, not on the  
last received RTP Timestamp, as it is indicated in the last version of  
the IDMS draft. This solves the situation you mention.

[Qin]: That still not addresses my comments above since in some cases, 
SC may be not able to report presented timestamp even they can report
Received timestamp.
>
> 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
>

[F & M] Despite of the one-way delay can be variable during an RTCP  
report interval due to network jitter, the end-to-end delay should be  
kept in a smooth way if a proper playout buffering (intra-stream sync)  
is adopted at the client side (i.e. the temporal dependencies of the  
incoming media stream are re-stablished at the jitter/playout buffer  
side).

[Qin]: It doesn't matter, since suppose end to end delay is kept in a smooth way,
That means maximum one way delay doesn't do frequent change.

Another issue is that reporting on last received/presented RTP  
timestamps gives information on the last updated statistics for IDMS.  
Reporting on the maximum one-way delay may not be as accurate if e.g.  
a sporadic peak of delay occurs during the RTCP report interval.

[Qin]: I disagree, how do you guarantee the sporadic peak of delay is not applied
to last received/presented RTP timestamp. In other words,
Report last received/presented timestamp is you only measure once in one reporting
Interval, how do you guarantee the received/presented timestamp can reflect the real one way delay and
Not affect by sporadic peak of delay.

On the hand, based on RFC2679, one way delay 
for IPPM, such peak value can be sorted out.
Also you can choose to report average value of one way delay you received in each reporting interval.

Thank you for your comments!

Regards, Fernando Boronat & Mario Montagud