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

From: Fernando Boronat Seguí <[email-masked]>
Date: Tue, 11 Oct 2011 11:54:24 +0200

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

---

From: Kevin Gross <[email-masked]>
Date: Tue, 11 Oct 2011 15:36:04 -0600

Welcome to the group. I've removed the cross-post to xrblock. We've been
discussing IDMS in this group (AVTCORE a.k.a. AVT). 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.
   2. 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.
   3. Since the sender and all receivers have an NTP time reference, it is
   possible to measure propagaion time directly. It is not necessary to measure
   RTT and divide by two.
   4. 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.

-- 
Kevin Gross
+1-303-447-0517
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í <[email-masked]>

> Fernando Boronat and Mario Montagud, co-authors of the Internet Draft (I-D)
> “RTCP for inter-destination media synchronization”
> 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.
>
> 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).
>
> 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.
>
> (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.
>
> 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.
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 12 Oct 2011 13:54:02 +0800

Hi,
If you want XRBlock folks to provide feedback, I think you should post  to [email-masked]. I have help you forward to XRBlock list in this thread. 
Also I have some quick comments below.

Regards!
-Qin
  ----- Original Message ----- 
  From: Fernando Boronat Seguí 
  To: [email-masked] ; [email-masked] 
  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?

  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.

  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.

  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.

  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.

Regards

------------------------------------------------------------------------------

---

From: Qin Wu <[email-masked]>
Date: Thu, 20 Oct 2011 17:26:28 +0800

Hi, Fernando:
  ----- Original Message ----- 
  From: Fernando Boronat Seguí 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Thursday, October 20, 2011 2:50 AM
  Subject: Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms

  Dear Qin,

  Thank You very much for your comments. I try to answer them below.

      ----- Original Message ----- 
      From: Fernando Boronat Seguí 
      To: [email-masked] ; [email-masked] 
      Sent: Tuesday, October 11, 2011 5:54 PM
      Subject: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms

      Dear Group members,

  [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

  [Qin]: So you proposal is to  fix the asynchronization from the beginning of session before media stream is sent from the media source. Isn't it a simple way to measure each propagation time from MSA to each SC and choose the largest propratation time to calcualte the Initial Playout Instant? Is this what you want to say? 

  [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.

  [Qin]: I agree usually SR/RR are sent after the transmissionof RTP data packets. But in my understanding, it is not problem to send SR/RR prior the transmission of RTP data packets since the irrelavant fields in the SR/RR can be set to zero when there is no media stream exchanged.

  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.

  [Qin]: My point is one way delays from source to SC may be not 1/2 of network round trip delay since:
  Network round trip delay = one way delay from source to SC + one way delay from SC to the Source, 
  One way delay from source to SC may not equal to one way delay from SC to the Source.

  Therefore, even you rely on RTCP XR with RRTR and DLRR, you still get round trip time between source and SC rather than one way delay.

  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.

  [Qin]: As I said above, one way delay from source to SC may be not 1/2 round trip time between source and SC. If you want to measure one way delay from source to SC more precisely, you need a new measurement method for one way delay from source to the SC.
  Yes, draft-ietf-avt-rtcp-xr-delay-02 has been revived into draft-ietf-xrblock-rtcp-xr-delay-00. It is not a problem you use delay metric in the draft-ietf-xrblock-rtcp-xr-delay-00 by extending it for your purpose. Also you can write a new draft to define a new metric for your purpose. Such draft should be sumitted to XRBlock WG.

      [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.

Regards

--------------------------------------------------------------------------
      _______________________________________________
      Audio/Video Transport Core Maintenance
      [email-masked]
      https://www.ietf.org/mailman/listinfo/avt

-- 
Saludos/Regards

---

From: Kevin Gross <[email-masked]>
Date: Thu, 20 Oct 2011 07:48:57 -0600

My comments below marked with [kg].

2011/10/19 Fernando Boronat Seguí <[email-masked]>

>
>    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).
>
>
[kg] I'm afraid I'm not fully familiar with all the existing XR
functionality you reference. For now I will clarify and expand my previous
comment: Under IDMS senders and receivers are required to have a common
accurate real-time clock (NTP, IEEE 1588, GPS, etc.). The standard RTCP
sender report contains a 64-bit real-time timestamp which indicates exactly
when an RTP packet was sent. A receiver can determine one-way delivery delay
of this packet by comparing that timestamp to the time that RTP packet was
received according to his own version of the shared real-time clock. This
same technique can be used to measure the one-way delay for any transmission
in either direction.

>
>    1. One way of achieving coarse sync without modification to the IDMS
>  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?
>
> [kg] By null data I mean a data stream of RTP packets that resembles the
expected media stream in terms of bandwidth, packet size etc. but decodes to
silence (audio) or black (video). Clearly it is easier to construct such a
stream for some formats than it is for others.

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

[kg] I hope you appreciate that this option is simpler than your proposal. I
would also argue that this option is more reliable and accurate because it
more directly measures the quantities of concern using the same IDMS
mechanisms that will be used once the stream is up and running. Your
proposal potentially has an advantage in quicker start-up time but I think
similar startup speed is possible if we specify accelerated RTCP reporting
at the onset of a new stream.

---

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

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).

>     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
> +1-303-447-0517
> 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í <[email-masked] 
> <mailto:[email-masked]>>
>
>     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.
>
>     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.
>
>     [email-masked] <mailto:[email-masked]>

---

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

Dear Qin,

>     *From:* Fernando Boronat Seguí <mailto:[email-masked]>
>     *To:* [email-masked] <mailto:[email-masked]> ;
>     [email-masked] <mailto:[email-masked]>
>     *Sent:* Tuesday, October 11, 2011 5:54 PM
>     *Subject:* [AVTCORE] Possible Additional functionalities
>     fordraft-brandenburg-avt-rtcp-for-idms
>
>     Dear Group members,
>
>     [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

>     [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.

>     [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.
>

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.

>     [Qin] I think you can rely on draft-ietf-avt-rtcp-xr-meas-identity
>     to know expected duration of the session.
>     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.

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

>     ------------------------------------------------------------------------

---

From: Qin Wu <[email-masked]>
Date: Fri, 21 Oct 2011 09:30:41 +0800

Hi,
  ----- Original Message ----- 
  From: Kevin Gross 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Thursday, October 20, 2011 9:48 PM
  Subject: Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms

        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).

  [kg] I'm afraid I'm not fully familiar with all the existing XR functionality you reference. For now I will clarify and expand my previous comment: Under IDMS senders and receivers are required to have a common accurate real-time clock (NTP, IEEE 1588, GPS, etc.). The standard RTCP sender report contains a 64-bit real-time timestamp which indicates exactly when an RTP packet was sent. A receiver can determine one-way delivery delay of this packet by comparing that timestamp to the time that RTP packet was received according to his own version of the shared real-time clock. This same technique can be used to measure the one-way delay for any transmission in either direction.

  [Qin]: I tend to agree with Kevin's propsal. But I am not going to jude if Kevin's is better than Fernando's. Actually besides the option proposed by Fernando, RFC3611 provide another similar way as both your proposals to calcualte one way delay. That's Packet Receipt Times Report Block defined in the section 4.3 of RFC3611. You may look at the second paragraph of section 4.3, it said:
  "
     Packet receipt times are expressed in the same units as in the RTP
     timestamps of data packets.  This is so that, for each packet, one
     can establish both the send time and the receipt time in comparable
     terms.  Note, however, that as an RTP sender ordinarily initializes
     its time to a value chosen at random, there can be no expectation
     that reported send and receipt times will differ by an amount equal
     to the one-way delay between sender and receiver.  The reported times
     can nonetheless be useful for the purposes mentioned above.

  "
  That's to say this XR Block can be used to calculate one way delay.

---

From: Fernando Boronat Seguí <[email-masked]>
Date: Fri, 21 Oct 2011 12:43:05 +0200

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.

If you consider appropriate our proposal using the packets already 
defined in the I-D, but with 64 bits NTP timestamps, we can try to 
define it more precisely and timely  to include it in the next ID version.

Regards

El 21/10/2011 3:30, Qin Wu escribió:
>     *From:* Kevin Gross <mailto:[email-masked]>
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Sent:* Thursday, October 20, 2011 9:48 PM
>     *Subject:* Re: [AVTCORE] Possible Additional functionalities
>     2011/10/19 Fernando Boronat Seguí <[email-masked]
>>          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).
>
>
>     functionality you reference. For now I will clarify and expand my
>     previous comment: Under IDMS senders and receivers are required to
>     have a common accurate real-time clock (NTP, IEEE 1588, GPS,
>     etc.). The standard RTCP sender report contains a 64-bit real-time
>     timestamp which indicates exactly when an RTP packet was sent. A
>     receiver can determine one-way delivery delay of this packet by
>     comparing that timestamp to the time that RTP packet was received
>     according to his own version of the shared real-time clock. This
>     same technique can be used to measure the one-way delay for any
>     transmission in either direction.
>     [Qin]: I tend to agree with Kevin's propsal. But I am not going to
>     jude if Kevin's is better than Fernando's. Actually besides the
>     option proposed by Fernando, RFC3611 provide another similar way
>     as both your proposals to calcualte one way delay. That's Packet
>     Receipt Times Report Block defined in the section 4.3 of RFC3611.
>     You may look at the second paragraph of section 4.3, it said:
>     "

---

From: Kevin Gross <[email-masked]>
Date: Sun, 23 Oct 2011 08:44:40 -0600

I do not consider the loading with null or dummy data "unnecessary". 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í <[email-masked]>

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

---

From: Fernando Boronat Seguí <[email-masked]>
Date: Mon, 24 Oct 2011 14:17:17 +0200

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í <[email-masked] 
>     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).
>
>     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.
>