Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms

[Fernando Boronat Seguí <[e-mail]>]

Dear Qin,

Thank You very much for your comments. I try to answer them below.
>
>     ----- Original Message -----
>     *From:* Fernando Boronat Seguí <mailto:[e-mail]>
>     *To:* [e-mail] <mailto:[e-mail]> ;
>     [e-mail] <mailto:[e-mail]>
>     *Sent:* Tuesday, October 11, 2011 5:54 PM
>     *Subject:* [AVTCORE] Possible Additional functionalities
>     fordraft-brandenburg-avt-rtcp-for-idms
>
>     Dear Group members,
>
>     As this is our first mail to the list, we introduce ourselves. We
>     are Fernando Boronat and Mario Montagud, co-authors of the
>     Internet Draft (I-D) "RTCP for inter-destination media
>     synchronization" (draft-ietf-avtcore-idms-01.txt).
>     As the I-D was accepted as a WG document, any changes will have to
>     be approved by the AVTCORE group. So, we would like to know if you
>     consider appropriate to introduce some additional functionalities
>     to the proposed IDMS approach in the I-D.
>
>     In many distributed applications it is required that all the
>     receivers start the playout of the media stream almost
>     simultaneously (we refer this as Coarse Sync) and, after that, all
>     of them play-out the media in a synchronous way (we refer this as
>     Fine Sync). Those processes are essential for acquiring IDMS. A
>     Global Initial Playout Instant for all the geographically
>     distributed receivers (SCs) in a media session could prevent from
>     an initial playout time discrepancy (asynchrony) at the beginning
>     of the playout of the media stream/s (if a fixed global initial
>     buffering delay is set) mainly due to the variable network delays
>     from the media server to each one of the SCs.
>
>
>
>     Thus, we are thinking about including a new section in the I-D
>     about possible packets for Coarse Sync for both the initial
>     playout instant (at the begining of a media session) and the
>     initial instant at each stage in which the session can be divided
>     (we consider that a stage ends when no streams are transmitted
>     during a fixed interval (it could be defined depending on the
>     applications), and that the next stage starts when data is
>     transmitted again).
>     [Qin]:Your proposal looks like to me is to add Fine Sync
>     functionality to IDMS draft in the middle of session, however it
>     is not clear to me the exact use case (is it periodical
>     playout)and what's the real difference between Coarse Sync and
>     Fine Sync in terms of RTCP signaling? are you saying the initial
>     at each stage is calculated more accurate than initial playout
>     instant?
>
[Answer] The goal of our proposal in our last mail was not related with 
fine synchronization. Fine Sync technique is used to maintain the 
playout processes between distributed SCs in a synchronized manner 
during the evolution of the session (or during each stages of the 
session, if it is divided into different phases).  During the session 
(or its phases), SCs report on their arrival/playout timing, and the 
MSAS can send to them playout setting instructions in order to maintain 
fine sync, using RTCP IDMS packets (defined in the I-D), if an out of 
sync situation is detected.

The coarse sync technique we here propose to be included in our I-D 
would mainly aim to prevent from initial playout time discrepancies at 
the beginning of the playout of the media stream/s in a multimedia 
session (or at the beginning of each one of the stages in which a 
session can be divided), due to the delay variability during the session 
from the sender to each group of separated SCs (Sync Clients).

It can be achieved by distributing to the SCs a Global Initial Playout 
Instant, carried out in a RTCP IDMS packet type for IDMS (already 
defined in our I-D), prior the transmission of the initial RTP data 
packets of each stage. This way, we can ensure concurrently sincronized 
playout points at the starting point of each stage, despite the variable 
network delays from the sender to the SCs

>     This technique has been considered in some previous IDMS works
>     (see reference [Boronat09] in the I-D), but using proprietary
>     protocols. The methods we propose here are based on the use of
>     already defined and standard RTCP packets, which would avoid the
>     introduction of proprietary closed solutions.
>
>     Regarding the Initial Playout Instant, we have primarily thought
>     about the use of already proposed RTCP XR packets (RFC 3611):
>
>     1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC
>     3611) for measuring the delay between MSAS and SCs, allowing MSAS
>     to estimate the RTT for all the SCs, then calculate a common
>     initial playout instant and then communicate it to all SCs by
>     sending them an RTCP IDMS Packet (defined in the I-D). The RTCP
>     IDMS packet must include the RTP Timestamp of the first MU to be
>     sent by the source and its proper playout instant, which will be
>     common for all of them.
>     MSAS may estimate its round trip time (RTT) to the SCs by sending
>     them an RTCP XR with the Receiver Reference Time Report Block and
>     forcing (according to RFC 3611) them to reply by sending an RTCP
>     XR with a DLRR Report Block. Notice that both XR blocks are
>     defined in RFC 3611 to be used in the opposite way we propose.
>     [Qin]: Why not use round trip time computation method defined in
>     the figure 2 of RFC3550, are you saying it is not allowed to use
>     SR/RR reports in IDMS case.
>
[Answer] To the best of our knowledge, prior the transmission of RTP 
data packets, neither RTCP SR nor RR are sent, aren't they?. So, the 
delay from the sender to the SCs could not be calculated using those 
packets at least at the starting point of the session (maybe at the 
initial points of each stage, but we are not sure). If, at the beginning 
of each stage, the session has been stopped during a long period and, 
therefore, the network conditions (e.g., delays to each SCs) have 
significantly varied we will need to monitor them.

>
>     If this solution is not considered appropriate we could think
>     about another solution based on the packets already defined in the
>     I-D, but maybe we would need to change the format adding new field/s.
>
>     2. Once joined the session, if it is not started yet, all the SCs
>     could start sending RTCP XR with IDMS block (until they receive
>     the Initial Playout Instant indication, sent using the RTCP IDMS
>     Packet) as it is defined in the I-D, but including only the
>     essential timing information (e.g. the wallclock time at which the
>     packet is sent by the SC) to let the MSAS estimate the one-way
>     network delays (not round-trip as in the previous case) for each
>     SC (assuming symmetric delays as in TCP) and calculate the Initial
>     Playout Instant. For that purpose, some field of the RTCP XR IDMS
>     block should be used to indicate the XR IDMS block is carrying out
>     temporal information for Coarse Sync, and not for reporting about
>     arrival/playout timing of a specific RTP packet.
>     From the Initial Instant they will continue playing the streams
>     and sending the RTCP XR with IDMS complete block (as currently
>     defined in the I-D). It could be a possible solution.
>     [Qin]: You can use Delay metric report defined in
>     draft-ietf-avt-rtcp-xr-delay-02 to directly get one-way network
>     delays. Also maximum and minimum network delays can be obtained
>     from this XR report.
>
Thank you for the suggestion.

In our response to Kevin Gross we propose an alternative to calculate 
one-way delays from source to SCs using only the packets defined in the 
I-D. Please, tell us your opinion about it.

We thought about the use of RTCP XR RRTR and DLRR (already defined in an 
RFC 3611 and not about packets defined in a ¿old/expired? draft -2009-) 
because these XR blocks are already standardized and could be useful for 
our Coarse Sync purposes. Moreover, in such a way, SCs must only send 
RTCP XR with DLRR blocks as a response to an incoming RTCP XR with RRTR 
block, sent by the source, which is who really knows the initial 
transmission instant (thus, unnecessary RTCP packet would not be sent).
Then, the Initial Playout Instant would be calculated by taking into 
consideration the estimated network delays, in order to allow all the 
SCs to have buffered sufficient RTP data packets to smooth out the 
effect of network jitter, possible playout rate deviations or sporadic 
congestion cases, thus maintaining a continuous playout process during 
the session.

Do you think that the use of the packets defined in the ¿old/expired? 
draft should be used to this purpose? In that case we would need to 
modify their format to make them more appropriate for our needs.

>     The process of the calculation of the optimum Initial Playout
>     Instant must take into consideration some factors such as the
>     maximum and minimum estimated delays, jitter values, expected
>     duration of the session, or probable clock deviations, in order to
>     allow enough buffered MUs to start the playout and to maintain it
>     continuously, thus avoiding underflow/overflow situations (playout
>     discontinuities), during the session. This process is out of the
>     scope of the ID.
>     [Qin] I think you can rely on draft-ietf-avt-rtcp-xr-meas-identity
>     to know expected duration of the session.
>     you may rely on draft-ietf-xrblock-rtcp-xr-pdv-00 to get jitter
>     values.
>     But XRBLock is not the right place to seek for the measurement
>     method, which is defined somewhere else, e.g., in other RFC like
>     RFC3550, other WGs, or other SDOs.
>
[Answer] Thank you for your helpful suggestion. In the I-D we only want 
to propose the packets to be used for our purpose. The calculation 
methods, as we mentioned above, are out of the scope of the ID.

Thank You again for your comments

More feedback about it from the AVTCore group members will be much 
appreciated.

>
>     With the introduction of the Coarse Sync functionality, the IDMS
>     proposal can counteract the effect of the delay variability at the
>     beginning of the playout of the media stream/s in each one of the
>     stages in which a media session can be divided.
>
>     We prefer the first method because there is no need to define new
>     IDMS control messages (or to include some fields to already
>     defined packets), but the use of already defined RTCP reports (RFC
>     3611) can be adapted for that purpose.
>
>     Moreover, with the use of the first method, SCs do not have to
>     send control messages once they join the session, which may
>     possibly result on inefficient control traffic overhead. They will
>     only have to send RTCP XR DLRR messages in response to a new
>     incoming RTRR message from the source, which is who really knows
>     the initial transmission time for the RTP media stream. Moreover,
>     the Initial Playout Instant can be sent to the receivers by using
>     the RTCP IDMS packet, already introduced in the I-D.
>
>     Feedback will be much appreciated.
>
>     Regards
>     ========================================================================
>     Dr. Fernando Boronat Seguí
>     IEEE Senior Member
>     Profesor Titular / Lecturer	
>     Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
>     Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
>     UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
>     Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
>     ========================================================================
>
>     ------------------------------------------------------------------------
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/avt
>

-- 
Saludos/Regards
========================================================================
Dr. Fernando Boronat Seguí
Profesor Titular / Lecturer	
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================