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

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

Dear members,

In order to move the discussion further, below I try to summarize the 
different alternatives to obtain Intial Playout Instant Synchronization 
for each stage in which we can divide a media session, that we have been 
discussing about during the last week:

1. Our proposal: Use control packets already defined in the draft, or in 
other RFCs or drafts, in order to obtain the mean one-way delay between 
source and SCs. It would be an initial phase with exchange of control 
packets, before the starting of the media session, i.e., the 
transmission of RTP packets with valid media data.

2. Kevin Gross' proposal: As propagation time is often a function of 
packet size, measuring with small RTCP packets won't give us the same 
results as with larger packets containing media. One simpler way of 
achieving coarse sync, and without modification to the IDMS proposal, is 
to just start streaming with null media data. Once the MSAS receives 
IDMS XR reports from all receivers and distributes sync information to 
receivers and the receivers have done whatever they need to do to get in 
sync, the sender can be queued to start sending real data.

Since the sender and all receivers have an NTP time reference, it is 
possible to measure propagation time directly and both proposals would 
work. As Kevin states, in his last mail to the list, our proposal will 
potentially give us a quick assessment of parameters but since the 
measurement conditions are different (unloaded) from operating 
conditions (loaded), the accuracy may not be as good as in the method he 
proposes.

We only need a reference of the maximum one-way delay between source and 
SCs, not the exact value, as the initial playout instant will be larger 
than that value (allowing receivers to have received enough media units 
to guarantee a continuous playout, avoiding underflow/overflow 
situations). So we are not sure that the level of accuracy is so 
important here.

So, I would like to ask to the list members for choosing one of the 
alternatives (or both) in order to go on working on and include the most 
supported one in the I-D, if you agree, as a way to obtain initial 
playout instant synchronization.

Thank you in advance.

Regards from Spain

> You will often get different measurements on an unloaded network. Your 
> proposal will potentially give us a quick assessment of parameters but 
> since the measurement conditions are different (unloaded) from 
> operating conditions (loaded), the accuracy may not be as good as in 
> the method I have proposed.
> I do however appreciate that parameters may change a great deal over 
> the duration of a session so the importance of accuracy of these 
> measurements should be given due consideration in this discussion. The 
> reason for my proposal is primarily for simplicity - we use the same 
> protocol mechanisms for startup as we do for the running case.
> Kevin
>
> 2011/10/21 Fernando Boronat Seguí <[e-mail] 
> <mailto:[e-mail]>>
>
>     Qin,
>
>     I understand that the Packet Receipt Times Report Block defined in
>     the section 4.3 of RFC3611 is to provide feedback of the reception
>     time of data RTP packets. It could be used in the solution
>     proposed by Kevin (sending null data packets).
>
>     Our aim is to calculate the one-way delay with the lower overhead
>     possible. If we adopt the Kevin's proposal we understand that
>     sending RTP packets at the same data rate than during the session
>     will suppose an unnecessary extra load prior the starting of the
>     session that can be avoided with our solution. Notice that prior
>     the session start is when all the users join the session with the
>     corresponding control packets implosion.
>
>     We only need a reference of the maximum one-way delay between
>     source and SCs, not the exact value, as the initial playout
>     instant will be larger than that value (allowing receivers to have
>     received enough media units to guarantee a continuous playout
>     avoiding underflow/overflow situations). The calculation of this
>     is out of the scope of the I-D.
>

-- 
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
========================================================================