Subject: Re: [avtext] Comments on draft-ietf-avtext-multiple-clock-rates-05

From: Bo Burman <[email-masked]>
Date: Fri, 14 Sep 2012 15:54:22 +0200

Hi,

I too have now reviewed -05, taking Magnus' comments into account.

In section 3.2.1, Table 2, I believe it is worth pointing out more explicitly that while the sender side RTP TS is set using the described differential method, the Transit calculation (for the receiver side) is using the non-differential approach with straight mapping of RTP TS to estimated capture time, which will result in an incorrect estimate and also becomes visible as false Jitter.

I specifically agree to Magnus' comments about the start_offset calculation in -05 is incorrect, and that it would be useful with another Table, using same data as Table 2 and 3, but based on the (corrected) suggested formulas in 4.2 and 4.3.

A tentative Table 4 should then, in my view, look something like
   +-------+-------+-----------+---------+---------+--------+----------+
   | Capt. | Clock | RTP       | Arrival | Transit | Jitter | Average  |
   | time  | rate  | timestamp | time    |         |        | jitter   |
   +-------+-------+-----------+---------+---------+--------+----------+
   | 0     | 8000  | 0         | 0.1     | 800     |        |          |
   | 0.02  | 8000  | 160       | 0.12    | 800     | 0      | 0        |
   | 0.04  | 8000  | 320       | 0.14    | 800     | 0      | 0        |
   | 0.06  | 8000  | 480       | 0.16    | 800     | 0      | 0        |
   | 0.08  | 16000 | 640       | 0.18    | 1600    | 0      | 0        |
   | 0.1   | 16000 | 960       | 0.2     | 1600    | 0      | 0        |
   | 0.12  | 16000 | 1280      | 0.22    | 1600    | 0      | 0        |
   | 0.14  | 8000  | 1600      | 0.24    | 320     | 0      | 0        |
   | 0.16  | 8000  | 1760      | 0.26    | 320     | 0      | 0        |
   +-------+-------+-----------+---------+---------+--------+----------+

For your guidance, failing to update start_offset with previous value, before accounting for Magnus' comment, would instead yield this (incorrect) table:
   +-------+-------+-----------+---------+---------+--------+----------+
   | Capt. | Clock | RTP       | Arrival | Transit | Jitter | Average  |
   | time  | rate  | timestamp | time    |         |        | jitter   |
   +-------+-------+-----------+---------+---------+--------+----------+
   | 0     | 8000  | 0         | 0.1     | 800     |        |          |
   | 0.02  | 8000  | 160       | 0.12    | 800     | 0      | 0        |
   | 0.04  | 8000  | 320       | 0.14    | 800     | 0      | 0        |
   | 0.06  | 8000  | 480       | 0.16    | 800     | 0      | 0        |
   | 0.08  | 16000 | 640       | 0.18    | 1600    | 0      | 0        |
   | 0.1   | 16000 | 960       | 0.2     | 1600    | 0      | 0        |
   | 0.12  | 16000 | 1280      | 0.22    | 1600    | 0      | 0        |
   | 0.14  | 8000  | 960       | 0.24    | 960     | 640    | 40       |
   | 0.16  | 8000  | 1120      | 0.26    | 960     | 0      | 38       |
   +-------+-------+-----------+---------+---------+--------+----------+

Cheers,
Bo Burman

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7141311
Färögatan 6                 | Mobile +46 73 0949021
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Monday, June 25, 2012 1:06 PM
To: Glen Zorn
Cc: [email-masked]
Subject: Re: [avtext] Comments on draft-ietf-avtext-multiple-clock-rates-05

On 2012-06-24 02:54, Glen Zorn wrote:
> On Wed, 2012-06-20 at 09:42 +0200, Magnus Westerlund wrote:
>> Hi,
>>
>> I have reviewed the draft and found some significant issues that I 
>> think should be addressed prior to a WG last call.
>>
>> 1. Section 4.1: The RTP extension defined in Perkins & Schierl 
>> [RFC6051] MAY be used to accelerate the synchronization.
>>
>> I would suggest that you change this to:
>>
>> The RTP header extension defined in "Rapid Synchronisation of RTP Flows"
>> [RFC6051] MAY be used to accelerate the synchronization.
>>
>> That tells the reader more about which type of extension and what it 
>> is for than the previous formulation.
> 
> The "Perkins & Schierl" construct was an attempt to avoid the typical 
> practice of writing something like "[RFC6051] defines...", which is 
> abominable.  However, reproducing the title of a referenced document 
> is even worse stylistically.  How does the existing text not tell the 
> reader what the extension is for?

We are at least in agreement that just an RFC number is insufficient. I have to say that I am currently not confused by the old sentence due to it containing sufficient context to determine which specification it is without remembering all the RFC numbers. I do say that my proposal can be improved significantly when it comes to removing redundancy and make it more readable. That it is horribly stylistically I don't agree with, and I think the benefit in many cases warrants such an approach.

Take this as a suggestion from me.

> 
>>
>> 2. Section 4.2: I found one sever error in the formula:
>>
>> First:
>> start_offset = (capture_time - capture_start)
>>                               * previous_clock_rate
>>
>> This is missing to add the original start_offset to the new offset 
>> calculated. Thus the start_offset calculation should be:
>>
>> start_offset = (capture_time - capture_start)
>>                               * previous_clock_rate + start_offset
> 
> I'm not sure I understand.  By "original start offset", do you mean 
> the initial vale of the start_offset variable?  That is zero, so I 
> don't see how it helps to add it in every time, so it must be something else?

Yes, the first time you switch it will be zero. The next time it will be non-zero and must be included to avoid erronous values after a second switch.

> 
>>
>>
>> 3. Section 4.2: Then I think the timestamp calculation should make 
>> clear where the initial random offset is to be added.
> 
> The first paragraph of the section says:
> 
>    An RTP Sender with RTCP turned off (i.e. by setting the RS and RR
>    bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for
>    each different clock rate but MAY use different clock rates on the
>    same SSRC as long as _the RTP timestamp without the random offset 
> is calculated_
>    as explained below[...]
> 

Yes, but I think we can improve this by including the random offset into the calculation so they don't do it in the wrong step with the wrong result. Either initially or at the end works. Doing it somewhere in the middle is not a good idea.

> 
>> And to my understanding
>> it needs to be added in the timestamp formula which thus should read:
>>
>> timestamp = (capture_time - capture_start) * clock_rate
>>                       + start_offset + random_initial_offset
>>
>> Or as an alternative, set the initial values, i.e:
>>  start_offset = 0
>>
>> to
>>
>>  start_offset = random_initial_offset'
> 
> ...

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
avtext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/avtext

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 26 Sep 2012 08:56:04 -0700

I apologize for the time it took me to answer this.

On 06/20/2012 12:42 AM, Magnus Westerlund wrote:
> Hi,
> 
> I have reviewed the draft and found some significant issues that I think 
> should be addressed prior to a WG last call.
> 

[...]

> First: start_offset = (capture_time - capture_start) * previous_clock_rate
> 
> start_offset = (capture_time - capture_start) * previous_clock_rate +
> start_offset

Agreed.  I would suggest to adopt the more compact and readable formula below:

start_offset += (capture_time - capture_start)
                               * previous_clock_rate

> 
> 
> 3. Section 4.2: Then I think the timestamp calculation should make clear 
> where the initial random offset is to be added. And to my understanding it
> needs to be added in the timestamp formula which thus should read:
> 
> timestamp = (capture_time - capture_start) * clock_rate + start_offset +
> random_initial_offset
> 
> Or as an alternative, set the initial values, i.e: start_offset = 0
> 
> to
> 

I slightly prefer the current text that does not use the random offset, but if
the random offset has to be added to the formula, I prefer to see it as the
line just above.

Note that the text in the first paragraph of 4.2 needs also to be modified in
this case (i.e. we need to remove "without the random offset").

> 
> 
> And that works to.
> 
> 4. Section 4.3:
> 
> I think one has to clarify that "j" is the newer arrival compared to "i" 
> which is the previous arrival.

This is the same usage of "j" and "i" than in RFC 3550, that does not define
them either, without generating any complaints over the years.  People who
successfully implemented RFC 3550 should not have any issue figuring that out.

> 
> 5. Section 4.3: For interoperability with legacy RTP implementations, an
> RTP receiver MAY use the information in two consecutive SR packets to
> calculate the clock rate used, i.e. if Ni is the NTP timestamp for the SR 
> packet i, Ri the RTP timestamp for the SR packet i and Nj and Rj the NTP
> timestamp and RTP timestamp for the previous SR packet j, then the clock
> rate can be guessed as the closest to (Ri - Rj) / (Ni - Nj).
> 
> Frankly, I don't see how this is correct or which information around the 
> used clock rate that you try to derive. I have to assume that you know the
> previous RTP clock rate. But you have failed to receive any new RTP packets
> so the receiver doesn't yet know which clock rate is used. Lets assume that
> you have three clock rates in use in this RTP session, lets say 32k, 16k
> and 8k. You where running at 32k. Applying the above formula when the
> switch was very close before sending the second SR packet to 8k. Then you
> could plug in values like the following:
> 
> Ri = 400000 Ni = 0
> 
> Switch happens 3.8 seconds into this interval Rj = 400000 + 121600 + 1600 =
> 523200 Nj = 4.0 s
> 
> Then the above formula yields a value of = (400000 - 523200) / (0 - 4) = 
> 30800
> 
> That says you only that a switch to a lower than current clock rate has 
> happened. Not which of them. This formula will only yield a correct result
> when there are no switches in between the two SR used to calculate the
> value.
> 
> To my understanding in the presence of packet loss you require both a RTP
> packet indicating the current payload type and an RTCP SR or equivalent
> time sync info to determine correctly where the switch happened (assuming a
> correct monotonically increasing timestamp space).

OK, that was an attempt to do something in that case but if that does not work
then I suggest to remove the whole paragraph.

> 
> 6. I wonder if not this specification should clarify the unclarity 
> regarding monotonically increasing RTP timestamp values that this is 
> required. Not only the clock one derives it from. And that put into section
> 4.

If I understand you correctly, this draft would now say that from now on, the
clock AND the RTP timestamp must increase monotonically.

I am OK with this, but do you have some text to suggest we can add?

> 
> 7. Section 4. I think Section 4 should contain the equivalent of table 2 
> and 3 to provide what values that the formulas in 4.2 and 4.3 provides.

Good idea, the Table 4 proposed by Bo Burman looks fine to me.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug