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

[Kevin Gross <[e-mail]>]

My comments below marked with [kg].

2011/10/19 Fernando Boronat Seguí <[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.


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