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

[Fernando Boronat Seguí <[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.

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ó:
> Hi,
>
>     ----- Original Message -----
>     *From:* Kevin Gross <mailto:[e-mail]>
>     *To:* [e-mail] <mailto:[e-mail]>
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *Sent:* Thursday, October 20, 2011 9:48 PM
>     *Subject:* Re: [AVTCORE] Possible Additional functionalities
>     fordraft-brandenburg-avt-rtcp-for-idms
>
>     My comments below marked with [kg].
>
>     2011/10/19 Fernando Boronat Seguí <[e-mail]
>     <mailto:[e-mail]>>
>
>>          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.
>

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