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

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

Dear Kevin,

We try to answer to your comments below:

>  Welcome to the group. 
Thank you. It is a pleasure for us to be able to contribute with our 
comments to the AVTCORE list.

> Here are some initial comments:
>
>  1. The sender and the MSAS are not necessarily co-located. You want
>     to measure propagation time from sender to SCs not from MSAS to SCs.
>
Yes, you're right. We want to measure network delays from the sender to 
the SCs. It was a miss-understanding.
>
>  1. Propagation time is often a function of packet size. Measuring
>     with small RTCP packets won't give you the same results as with
>     larger packets containing media.
>
We agree. The purpose of collecting network delays for RTCP packets is 
to ensure that the common initial playout (end-to-end) delay for all the 
SCs is larger than the maximum estimated network delay and large enough 
in order to guarantee that SCs have buffered a minimum amount of media 
units before beginning the playout process (to avoid buffer underflow 
situations). The method to calculate the Initial Playout Instant is out 
of the scope of the I-D and should take into consideration such issue.

Suggestion about how to measure it taking into account that issue will 
be much appreciate.

>  1. Since the sender and all receivers have an NTP time reference, it
>     is possible to measure propagation time directly. It is not
>     necessary to measure RTT and divide by two.
>
RTT calculation was one of the alternatives we considered by using XR 
with RRTR and DLRR blocks because with the use of XR with RRTR and DLRR 
blocks we got the advantage that the SCs only have to send XR with DLRR 
blocks as a response to an incoming XR with RRTR block and the packets 
were already defined.

Of course that we are interested in on-way delays, not in RTT but we 
would need to define new packets (or adapt the ones already defined in 
the I-D) in order to calculate one-way delays. Should we do it? or do 
you consider it is enough with calculating RTT and divide it by 2?

One option using the packets already defined in the I-D to calculate 
Source-to-SC delays could be the following: Before the beginning of the 
media transmission, the source could start sending one (or several 
consecutive) RTCP IDMS reports (defined in section 7 of the I-D) with 
all the bits of the packet received RTP timestamp field set to 0 (no 
packet is referenced) and the 64-bit NTP timestamp of its sending time 
in the 64 'Packet received NTP Timestamp' field (NTP sending time). SCs 
should response to this packet with an XR with an IDMS Report Block 
(also defined in the section 6 of the I-D) including the 64-bit NTP 
timestamp of the instant in which that packet was received (NTP 
reception time), also including the packet received RTP timestamp field 
set to 0 (no packet is referenced) and copying the middle 32-bits of the 
64-bit NTP timestamp of the original packet received from the source (in 
order to allow the source identify the response with the original 
query). Once received an XR with the IDMS report block from an SC, the 
source could calculate the one-way source-to-SC delay by subtracting 
both 64-bit NTP timestamps (NTP reception time- NTPsending time).


>  1. One way of achieving coarse sync 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.
>
We are not sure about how to implement streaming with null media data. 
Do you mean empty RTP packets? If so, those RTP packets would be very 
short packets, so the propagation time would also be smaller than for 
RTP real data packets. Also it would introduce higher traffic overhead 
than when using our proposal, wouldn't it?

Do you really think this option would be more suitable than the use of 
RTCP control messages?

Thank You very much for your helpful comments.
> Kevin Gross
> [phone]
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org 
> <http://www.x192.org/>
>
>
> 2011/10/11 Fernando Boronat Seguí <[e-mail] 
> <mailto:[e-mail]>>
>
>     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
>     [e-mail] <mailto:[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
========================================================================