3 Aug 2012 18:55
[AVTCORE] 答复: Is IDMS XR BLOCK in IDMS draft the only way to calculate one way delay?
Qin Wu <bill.wu <at> huawei.com>
2012-08-03 16:55:03 GMT
2012-08-03 16:55:03 GMT
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:mamontor <at> posgrado.upv.es] 发送时间: 2012年8月3日 22:59 收件人: Qin Wu 抄送: avt <at> ietf.org 主题: 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 <bill.wu <at> huawei.com> 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 : > 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. > [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 _______________________________________________ Audio/Video Transport Core Maintenance avt <at> ietf.org https://www.ietf.org/mailman/listinfo/avt