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

From: Fernando Boronat Seguí <[email-masked]>
Date: Wed, 19 Oct 2011 20:56:41 +0200

Magnus,

Yes, you are right. That is our purpose.

What do you think about our proposal? Any suggestion will be much 
appreciated.

Thank you for your response.

El 19/10/2011 16:41, [email-masked] escribió:
> Date: Wed, 19 Oct 2011 11:15:40 +0200
> From: Magnus Westerlund<[email-masked]>
> To: [email-masked]
> Subject: Re: [AVTCORE] Possible Additional functionalities for
> 	draft-brandenburg-avt-rtcp-for-idms
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi,
>
> If I understand the main issue you have is to determine the set of
> transmission delays from a given media source to its population of
> receivers so that an appropriate playout time can be selected by the
> media source prior to actually having sent any media?
>
> Cheers
>
> Magnus
>
> On 2011-10-11 15:37, Fernando Boronat Segu? wrote:
>> 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).
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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
>> [email-masked]
>> 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
========================================================================