Subject: [xrblock] Shall we add one way delay in Delay Metric Block

From: Qin Wu <[email-masked]>
Date: Sat, 29 Oct 2011 16:38:17 +0800

Hi, folks:
I like to draw your attention to the draft-brandenburg-avt-rtcp-for-idms. This draft is going to propose to define a new method to measure one way delay by relying on RTCP IDMS packet and
RTCP XR packet with IDMS report block defined in draft-brandenburg-avt-rtcp-for-idms.
Apparently there are many other ways to calculate one way delay, e.g.,
a. Calculate one way delay from Round Trip delay.Round trip delay between the source and receiver is estimated by sending Receiver Reference Time Report Block and receiving DLRR Report Blocks
b. Calculate one way delay from Round Trip delay. Round trip delay is estimated based on SR/RR reports, t 
c. Calculate one way delay directly by using NTP timestamp in the SR/RR reports minus arrival time of that report.
d. Calculate one way delay directly by using NTP timestamp in the Receiver Reference Time Report Block minus arrival time of that report
e. Calculate one way delay by using Packet Receipt Times Report Block defined in RFC3611
......

However one way delay may be not be symmetric in two directions and the total Round trip delay may be not one way delay multiply 2 in such case.
Also I think one way delay is more related to Delay Metric Block draft at the following link:
http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-delay-00

Would it be good to extend Delay XR Block and add one way delay as one new metric into Delay metric Block?

Regards!
-Qin

----- Original Message ----- 
From: Fernando Boronat Seguí 
To: Kevin Gross 
Cc: [email-masked] 
Sent: Monday, October 24, 2011 8:17 PM
Subject: Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms

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

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

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

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

---

From: [email-masked]
Date: Mon, 31 Oct 2011 17:05:46 +0800 (CST)

I agree the one way delay is relevant to round trip delay.

Your proposal looks good to me.

Cheers!

JingZhao

Shanghai Research Institute of China Telecom Coporation Limited.

------------------ 原始邮件 ------------------

发件人：Qin Wu

时　间：2011/10/29 16:38:17 星期六

收件人：[email-masked]

抄送人：

主　题：[xrblock] Shall we add one way delay in Delay Metric Block

Hi, folks:

......

Regards!

-Qin

----- Original Message -----

From:
Fernando Boronat Seguí

To:
Kevin Gross

Cc:
[email-masked]

Dear members,

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.

Thank you in advance.

Regards from Spain

Kevin

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

Qin,

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

[email-masked]