Subject: Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Jul 2009 14:49:11 +0100

Mike,

Apologies - I was perhaps influenced by Art Allison's response, which  
made a stronger recommendation. Still, the suggestion that NTPv4 be  
implemented for synchronisation is stronger than I think desirable for  
a general draft such as this (although, of course, perfectly fine for  
some restricted domains in which RTP is used).

Cheers,
Colin

On 30 Jun 2009, at 23:41, Michael A Dolan wrote:

> Colin-
>
> I thought I was very careful to use "should" in my proposed  
> reference clock language, and thus it is a recommendation and not  
> required.  So, I am not sure I understand your comment below. If you  
> prefer, "It is recommended....", that's fine of course.  But I do  
> think we need to be much clearer that a common timebase is really  
> important for sync.
>
> I'll look at -03 "soon" and reply.
>
> Thanks,
>
>         Mike
>
> At 11:12 PM 6/30/2009 +0100, Colin Perkins wrote:
>> Michael,
>>
>> On 17 Jun 2009, at 20:46, Michael A Dolan wrote:
>>> Colin-
>>>
>>> Thanks.  I think we're close.
>>>
>>> 3550 only imprecisely recommends (not requires) using a common  
>>> clock, and when it does, it uses the term, "wallclock", without  
>>> defining it.  In order for the sync to even approach the numbers  
>>> implied in this draft, the clocks must indeed be synchronized and  
>>> they must use the same timebase.  Failing to minimally recommend  
>>> this (even if you believe it is a restatement of 3550), it is not  
>>> possible to achieve the implied sync times.  I really think you  
>>> need to say MUST, but I leave that to you and Thomas.  And, it  
>>> should be tied back to NTP fields since that it is a popular  
>>> source of clock.  Here's a suggestion:
>>>
>>>> 2.3 Clock Synchronization
>>>> In order to achieve more rapid and accurate sync, as recommended  
>>>> in RFC 3550, all senders and receivers should use a common  
>>>> reference clock. When NTPv4 is used, all instances of NTP packets  
>>>> should set the Reference ID (refid) field to the same timebase  
>>>> value (e.g. "GPS" - see NTPv4 Figure 12). Signaling for what  
>>>> Reference ID value is tp be used is accomplished out of band.  
>>>> When NTPv3 is used, all instances of NTP packets should use the  
>>>> same timebase, even if it is not explicitly signaled in the  
>>>> Reference ID field.
>>>> ==============
>>>> Replace all uses of "wallclock", "NTP format clock", "NTP format  
>>>> wallclock", etc with a single term, such as "common reference  
>>>> clock", to be consistent with the first use in section 1, and to  
>>>> remove the ambiguity of all the varying uses in the text.
>>>> ==============
>>>> Add a reference to NTPv4 (or maybe replace [7] RFC 1305?):
>>>> https://datatracker.ietf.org/drafts/draft-ietf-ntp-ntpv4-proto/
>>
>> We can't require that senders and receivers use a common reference  
>> clock, or a particular clock synchronisation protocol - that's not  
>> realistic given the range of environments in which RTP is used -  
>> but I will add some text recommending that a common clock is used  
>> where possible.
>>
>>> Regarding the access point timing, I think a note would be good  
>>> surrounding the tables to diffuse the implication that the 0.04  
>>> times in the table are realistic for an expected sync time (even  
>>> if good for other purposes). We all agree there are other good  
>>> reasons to send more frequent RTCP SR records that also improve  
>>> clock accuracy, and are thus directly relevant to this draft. I  
>>> did not mean to imply otherwise.  But I think it would be helpful  
>>> to more clearly separate those reasons (e.g. decoder clock  
>>> stability) from sync time expectations.  Let me know if you want a  
>>> specific text suggestion.
>>
>> I added some text to section 2.2 of the -03 draft. Is that  
>> sufficient?
>>
>> Cheers,
>> Colin
>>
>>
>>
>>
>>
>>> Co-locating the RTCP SR records and the media access points is a  
>>> helpful recommendation, and less systemic than the above points.
>>>
>>> Thanks for considering these improvements (I think).
>>>
>>> Regards,
>>>
>>>         Mike
>>>
>>>
>>> At 06:57 PM 6/17/2009 +0100, Colin Perkins wrote:
>>>> Michael,
>>>>
>>>> On 16 Jun 2009, at 21:27, Michael A Dolan wrote:
>>>>> FYI, I started out in March with a number of comments, some  
>>>>> related to multicast UDLR with 1-2 links and I sense that's too  
>>>>> big a topic to try and add at this point.  My comments therefore  
>>>>> have distilled to addressing two major factors in syncing RTP  
>>>>> sessions that I believe overshadow the time resolutions being  
>>>>> discussed in the draft, and therefore it is an omission not to  
>>>>> address them:
>>>>>
>>>>> 1. Common timebase
>>>>> 2. Media-specific access points
>>>>>
>>>>> I stopped short of suggesting we should design anything.  
>>>>> Therefore I still believe both topics belong here, and in this  
>>>>> draft, and they are not so big as to defer at this point.
>>>>>
>>>>> For clarification, I wasn't proposing we define a timebase  
>>>>> signaling mechanism (although I do think that's a good idea).   
>>>>> All I am proposing is to add some text that explains that a  
>>>>> common timebase is needed to achieve anything near the implied  
>>>>> sync times discussed in this draft. How the senders and  
>>>>> receivers figure that out is out of band. But if they don't and  
>>>>> just go along with "wallclock", it makes much of the rest of  
>>>>> this draft irrelevant since the timebase error will be huge by  
>>>>> comparison.
>>>>
>>>> That's already stated in RFC 3550. I'm not sure it needs  
>>>> repeating here, but can add something if you want.
>>>>
>>>>> Regarding the issue about access points, I'm not sure how much  
>>>>> background to add, so apologies if this is obvious to everyone.  
>>>>> Every media stream type has "access points" that arrive  
>>>>> periodically - the point where a decoder can begin to decode the  
>>>>> stream. In general, these are a function of the encoding, not  
>>>>> constant per type, and not constant per stream. For example in H. 
>>>>> 264, these typically center around the presence of an IDR  
>>>>> frame.  HE AAC has a simpler coding structure, but one still  
>>>>> can't start decoding anywhere in the stream.  The "typical"  
>>>>> periods of the H.264 access points range from 0.5 to 2 seconds,  
>>>>> depending on the coding.  The exact period is application  
>>>>> dependent, but is not relevant.  The point is that these periods  
>>>>> greatly exceed the times shown in the tables which are implied  
>>>>> to be the sync times - going as low as 0.04 seconds.  The tables  
>>>>> in this draft suggesting that RTCP SR packets be sent 0.04  
>>>>> seconds apart for high rate streams. This is interesting (as  
>>>>> Thomas notes) for jitter management and clock settling, but that  
>>>>> high rate does not help you sync since you can't even start  
>>>>> decoding the video for a relatively long time after the 0.04  
>>>>> seconds. This is mostly related to issues of late joiners of  
>>>>> course.  Therefore, I was suggesting we make note of this fact  
>>>>> to clarify there are other factors to sync and acquisition  
>>>>> beyond receipt of NTP and the RTCP SR packet, and that these  
>>>>> other times far exceed 0.04 seconds.
>>>>
>>>> Okay, that's what I thought you meant. That certainly affects the  
>>>> join times, although I'm not sure I'd call that issue  
>>>> synchronisation latency. We can certainly add some wording to  
>>>> highlight it though.
>>>>
>>>>> Co-locating in time the RTCP SR packets with their related  
>>>>> access points further improves the sync time.  For example, if  
>>>>> the IDR is every 2 seconds, there is no benefit (for syncing) to  
>>>>> sending the RTCP SR more frequently than that, especially if it  
>>>>> is aligned with this access point in time.  If the RTCP SR  
>>>>> packets are sent randomly in time, the sync time is the IDR  
>>>>> period plus 1/2 the RTCP SR packet period, on average. This is  
>>>>> more of an optimization, but then, that's what this whole draft  
>>>>> is about - optimizing the sync time.
>>>>
>>>> I agree that co-locating the SR information in time with the  
>>>> random access points helps, and will add something to the draft  
>>>> to say that explicitly if it's not already there. I disagree  
>>>> that's sufficient: sending the SR information more frequently  
>>>> gives the receiver more samples from which to estimate any skew  
>>>> between NTP and RTP timestamps, and gives more information to  
>>>> help filter out any incorrect mappings.
>>>>
>>>> -- 
>>>> Colin Perkins
>>>> http://csperkins.org/

---

From: Michael A Dolan <[email-masked]>
Date: Thu, 02 Jul 2009 08:33:55 -0700

Colin-

I proposed below (paraphrased): WHEN NTPv4 is used, then do X, and 
WHEN NTPv3 is used then do Y. I never said NTPv4 was preferred 
(except perhaps implied with my parenthetical to replace the older 
RFC reference). But I suggested that since NTPv4 is getting pretty 
close to pub and obsoletes NTPv3 (1305).  So trying to hang on to 
NTPv3 only is problematic, I think. But that's really a separate 
issue from my concern about the common timebase. Without a common 
timebase, the techniques described in this ID will be ineffective by 
an order of magnitude, no matter what version of NTP is used. So, I 
feel that some language substantively like what I propose below be 
added to this ID as necessary guidance.

Regards,

         Mike

At 02:47 PM 7/2/2009 +0100, Colin Perkins wrote:
>Mike,
>
>Apologies - I was perhaps influenced by Art Allison's response, 
>which made a stronger recommendation. Still, the suggestion that 
>NPTv4 be implemented for synchronisation is stronger than I think 
>desirable for a general draft such as this (although, of course, 
>perfectly fine for some restricted domains in which RTP is used).
>
>Cheers,
>Colin
>
>
>
>>required.  So, I am not sure I understand your comment below. If 
>>you prefer, "It is recommended....", that's fine of course.  But I 
>>do think we need to be much clearer that a common timebase is 
>>really important for sync.
>>
>>>>>reference clock. When NTPv4 is used, all instances of NTP 
>>>>>packets should set the Reference ID (refid) field to the same 
>>>>>timebase value (e.g. "GPS" - see NTPv4 Figure 12). Signaling for 
>>>>>what Reference ID value is tp be used is accomplished out of 
>>>>>band. When NTPv3 is used, all instances of NTP packets should 
>>>>>use the same timebase, even if it is not explicitly signaled in 
>>>>>the Reference ID field.
>>>>>==============
>>>>stability) from sync time expectations.  Let me know if you want 
>>>>a specific text suggestion.
>>>
>>>I added some text to section 2.2 of the -03 draft. Is that sufficient?
>>>
>>>Cheers,
>>>Colin
>>>
>>>
>>>
>>>
>>>
>>>>>>big a topic to try and add at this point.  My comments 
>>>>>>therefore have distilled to addressing two major factors in 
>>>>>>syncing RTP sessions that I believe overshadow the time 
>>>>>>resolutions being discussed in the draft, and therefore it is 
>>>>>>an omission not to address them:
>>>>>>
>>>>>>1. Common timebase
>>>>>>signaling mechanism (although I do think that's a good 
>>>>>>idea).  All I am proposing is to add some text that explains 
>>>>>>that a common timebase is needed to achieve anything near the 
>>>>>>implied sync times discussed in this draft. How the senders and 
>>>>>>this draft irrelevant since the timebase error will be huge by comparison.
>>>>>
>>>>>>periodically - the point where a decoder can begin to decode 
>>>>>>the stream. In general, these are a function of the encoding, 
>>>>>>not constant per type, and not constant per stream. For example 
>>>>>>in H.264, these typically center around the presence of an IDR 
>>>>>>dependent, but is not relevant.  The point is that these 
>>>>>>periods greatly exceed the times shown in the tables which are 
>>>>>>implied to be the sync times - going as low as 0.04 
>>>>>>seconds.  The tables in this draft suggesting that RTCP SR 
>>>>>>packets be sent 0.04 seconds apart for high rate streams. This 
>>>>>>is interesting (as Thomas notes) for jitter management and 
>>>>>>clock settling, but that high rate does not help you sync since 
>>>>>>you can't even start decoding the video for a relatively long 
>>>>>>time after the 0.04 seconds. This is mostly related to issues 
>>>>>>of late joiners of course.  Therefore, I was suggesting we make 
>>>>>>note of this fact to clarify there are other factors to sync 
>>>>>>and acquisition beyond receipt of NTP and the RTCP SR packet, 
>>>>>>and that these other times far exceed 0.04 seconds.
>>>>>
>>>>>Okay, that's what I thought you meant. That certainly affects 
>>>>>the join times, although I'm not sure I'd call that issue 
>>>>>>the IDR is every 2 seconds, there is no benefit (for syncing) 
>>>>>>to sending the RTCP SR more frequently than that, especially if 
>>>>>>it is aligned with this access point in time.  If the RTCP SR 
>>>>><http://csperkins.org/>http://csperkins.org/
>>_______________________________________________
>>Audio/Video Transport Working Group
>><mailto:[email-masked]>[email-masked]
>>https://www.ietf.org/mailman/listinfo/avt
>
>
>
>--
>Dr Colin Perkins
>
>Department of Computing Science
>Sir Alwyn Williams Building
>University of Glasgow
>Glasgow G12 8QQ
>
>The University of Glasgow, charity number SC004401

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Jul 2009 16:42:46 +0100

[resending from an address that's subscribed to the AVT list]

Mike,

The only thing RTP uses from NTPv3 is the timestamp format. I don't  
see why the older reference is problematic.

Colin

On 2 Jul 2009, at 16:33, Michael A Dolan wrote:
>>>>> implied in this draft, the clocks must indeed be synchronized  
>>>>> and they must use the same timebase.  Failing to minimally  
>>>>> recommend this (even if you believe it is a restatement of  
>>>>> 3550), it is not possible to achieve the implied sync times.  I  
>>>>> really think you need to say MUST, but I leave that to you and  
>>>>> Thomas.  And, it should be tied back to NTP fields since that it  
>>>>> is a popular source of clock.  Here's a suggestion:
>>>>>
>>>>>> In order to achieve more rapid and accurate sync, as  
>>>>>> recommended in RFC 3550, all senders and receivers should use a  
>>>>>> common reference clock. When NTPv4 is used, all instances of  
>>>>>> NTP packets should set the Reference ID (refid) field to the  
>>>>>> same timebase value (e.g. "GPS" - see NTPv4 Figure 12).  
>>>>>> Signaling for what Reference ID value is tp be used is  
>>>>>> accomplished out of band. When NTPv3 is used, all instances of  
>>>>>> NTP packets should use the same timebase, even if it is not  
>>>>>> explicitly signaled in the Reference ID field.
>>>>>> ==============
>>>>>> Replace all uses of "wallclock", "NTP format clock", "NTP  
>>>>>> format wallclock", etc with a single term, such as "common  
>>>>>> reference clock", to be consistent with the first use in  
>>>>>> section 1, and to remove the ambiguity of all the varying uses  
>>>>>> in the text.
>>>>>> ==============
>>>> We can't require that senders and receivers use a common  
>>>> reference clock, or a particular clock synchronisation protocol -  
>>>> that's not realistic given the range of environments in which RTP  
>>>> is used - but I will add some text recommending that a common  
>>>> clock is used where possible.
>>>>
>>>>> did not mean to imply otherwise.  But I think it would be  
>>>>> helpful to more clearly separate those reasons (e.g. decoder  
>>>>> clock stability) from sync time expectations.  Let me know if  
>>>>> you want a specific text suggestion.
>>>>
>>>>>>> related to multicast UDLR with 1-2 links and I sense that's  
>>>>>>> too big a topic to try and add at this point.  My comments  
>>>>>>> receivers figure that out is out of band. But if they don't  
>>>>>>> and just go along with "wallclock", it makes much of the rest  
>>>>>>> of this draft irrelevant since the timebase error will be huge  
>>>>>>> by comparison.
>>>>>>
>>>>>>> background to add, so apologies if this is obvious to  
>>>>>>> everyone. Every media stream type has "access points" that  
>>>>>>> arrive periodically - the point where a decoder can begin to  
>>>>>>> decode the stream. In general, these are a function of the  
>>>>>>> encoding, not constant per type, and not constant per stream.  
>>>>>>> For example in H.264, these typically center around the  
>>>>>>> presence of an IDR frame.  HE AAC has a simpler coding  
>>>>>>> structure, but one still can't start decoding anywhere in the  
>>>>>>> stream.  The "typical" periods of the H.264 access points  
>>>>>>> range from 0.5 to 2 seconds, depending on the coding.  The  
>>>>>>> exact period is application dependent, but is not relevant.   
>>>>>>> The point is that these periods greatly exceed the times shown  
>>>>>>> in the tables which are implied to be the sync times - going  
>>>>>>> as low as 0.04 seconds.  The tables in this draft suggesting  
>>>>>>> that RTCP SR packets be sent 0.04 seconds apart for high rate  
>>>>>>> streams. This is interesting (as Thomas notes) for jitter  
>>>>>>> management and clock settling, but that high rate does not  
>>>>>>> help you sync since you can't even start decoding the video  
>>>>>>> for a relatively long time after the 0.04 seconds. This is  
>>>>>>> mostly related to issues of late joiners of course.   
>>>>>>> Therefore, I was suggesting we make note of this fact to  
>>>>>>> clarify there are other factors to sync and acquisition beyond  
>>>>>>> receipt of NTP and the RTCP SR packet, and that these other  
>>>>>>> times far exceed 0.04 seconds.
>>>>>>
>>>>>>> to sending the RTCP SR more frequently than that, especially  
>>>>>>> if it is aligned with this access point in time.  If the RTCP  
>>>>>>> SR packets are sent randomly in time, the sync time is the IDR  
>>>>>>> more of an optimization, but then, that's what this whole  
>>>>>>> draft is about - optimizing the sync time.
>>>>>>
>>> [email-masked]
> [email-masked]

-- 
Colin Perkins
http://csperkins.org/

---

From: Michael A Dolan <[email-masked]>
Date: Thu, 02 Jul 2009 08:49:57 -0700

Colin-

Sorry, I didn't mean to wade into NTPv3 versus NTPv4 and withdraw 
that suggestion.  Given the clarifications, are you OK with the 
proposed text below, dropping the parenthetical about replacing 1305?

         Mike

At 04:41 PM 7/2/2009 +0100, Colin Perkins wrote:
>>timebase, the techniques described in this ID will be ineffective 
>>by an order of magnitude, no matter what version of NTP is used. 
>>So, I feel that some language substantively like what I propose 
>>below be added to this ID as necessary guidance.
>>
>>Regards,
>>
>>         Mike
>>
>>>>you prefer, "It is recommended....", that's fine of course.  But 
>>>>I do think we need to be much clearer that a common timebase is 
>>>>>>defining it.  In order for the sync to even approach the 
>>>>>>numbers implied in this draft, the clocks must indeed be 
>>>>>>synchronized and they must use the same timebase.  Failing to 
>>>>>>minimally recommend this (even if you believe it is a 
>>>>>>restatement of 3550), it is not possible to achieve the implied 
>>>>>>sync times.  I really think you need to say MUST, but I leave 
>>>>>>that to you and Thomas.  And, it should be tied back to NTP 
>>>>>>fields since that it is a popular source of clock.  Here's a suggestion:
>>>>>>
>>>>>>>recommended in RFC 3550, all senders and receivers should use 
>>>>>>>a common reference clock. When NTPv4 is used, all instances of 
>>>>>>>section 1, and to remove the ambiguity of all the varying uses in the text.
>>>>>>>==============
>>>>>reference clock, or a particular clock synchronisation protocol 
>>>>>- that's not realistic given the range of environments in which 
>>>>>RTP is used - but I will add some text recommending that a 
>>>>>common clock is used where possible.
>>>>>
>>>>>>times in the table are realistic for an expected sync time 
>>>>>>(even if good for other purposes). We all agree there are other 
>>>>>>good reasons to send more frequent RTCP SR records that also 
>>>>>>improve clock accuracy, and are thus directly relevant to this 
>>>>>>draft. I did not mean to imply otherwise.  But I think it would 
>>>>>>be helpful to more clearly separate those reasons (e.g. decoder 
>>>>>>Co-locating the RTCP SR records and the media access points is 
>>>>>>a helpful recommendation, and less systemic than the above points.
>>>>>>
>>>>>>>>Therefore I still believe both topics belong here, and in 
>>>>>>>>this draft, and they are not so big as to defer at this point.
>>>>>>>>
>>>>>>>>implied sync times discussed in this draft. How the senders 
>>>>>>>>and receivers figure that out is out of band. But if they 
>>>>>>>>don't and just go along with "wallclock", it makes much of 
>>>>>>>>the rest of this draft irrelevant since the timebase error 
>>>>>>>>will be huge by comparison.
>>>>>>>
>>>>>>>>Regarding the issue about access points, I'm not sure how 
>>>>>>>>much background to add, so apologies if this is obvious to 
>>>>>>>>exact period is application dependent, but is not 
>>>>>>>>relevant.  The point is that these periods greatly exceed the 
>>>>>>>>times shown in the tables which are implied to be the sync 
>>>>>>>>times - going as low as 0.04 seconds.  The tables in this 
>>>>>>>>draft suggesting that RTCP SR packets be sent 0.04 seconds 
>>>>>>>>apart for high rate streams. This is interesting (as Thomas 
>>>>>>>>notes) for jitter management and clock settling, but that 
>>>>>>>>course.  Therefore, I was suggesting we make note of this 
>>>>>>>>fact to clarify there are other factors to sync and 
>>>>>>>>acquisition beyond receipt of NTP and the RTCP SR packet, and 
>>>>>>>>that these other times far exceed 0.04 seconds.
>>>>>>>
>>>>>>>>access points further improves the sync time.  For example, 
>>>>>>>>if the IDR is every 2 seconds, there is no benefit (for 
>>>>>>>>syncing) to sending the RTCP SR more frequently than that, 
>>>>>>>>especially if it is aligned with this access point in 
>>>>>>>>time.  If the RTCP SR packets are sent randomly in time, the 
>>>>>>>>sync time is the IDR period plus 1/2 the RTCP SR packet 
>>>>>>>>period, on average. This is more of an optimization, but 
>>>>>>>>then, that's what this whole draft is about - optimizing the sync time.
>>>>>>>
>>>>>>>random access points helps, and will add something to the 
>>>>>>>draft to say that explicitly if it's not already there. I 
>>>>>>>disagree that's sufficient: sending the SR information more 
>>>>>>>frequently gives the receiver more samples from which to 
>>>>>>>estimate any skew between NTP and RTP timestamps, and gives 
>>>>>>>more information to help filter out any incorrect mappings.
>>>>>>>
>>>>>>>--
>>>>>>>Colin Perkins

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Jul 2009 18:38:34 +0100

Mike,

I'd prefer not to mention NTP at all. The text in -03 is:

    Furthermore, to achieve more rapid and accurate synchronisation, it
    is RECOMMENDED that senders and receivers use a common reference
    clock where possible (recognising that this is often not possible
    when RTP is used outside of controlled environments); the means by
    which that common reference clock is distributed are outside the
    scope of this memo.

It's important to specify a reference clock, and to discuss how that  
clock is distributed, but that's highly domain specific, and so  
outside the scope of this draft (I believe - maybe the chairs want to  
give some guidance). If you, or anyone else, want to write a draft  
discussing the synchronisation requirements for various domains, and  
how they can be met using RTP and various clock distribution  
mechanisms, then I'd support it.

Cheers,
Colin

On 2 Jul 2009, at 16:49, Michael A Dolan wrote:
>>>>> reference clock language, and thus it is a recommendation and  
>>>>> not required.  So, I am not sure I understand your comment  
>>>>> below. If you prefer, "It is recommended....", that's fine of  
>>>>> course.  But I do think we need to be much clearer that a common  
>>>>> timebase is really important for sync.
>>>>>
>>>>>>> clock, and when it does, it uses the term, "wallclock",  
>>>>>>> without defining it.  In order for the sync to even approach  
>>>>>>> the numbers implied in this draft, the clocks must indeed be  
>>>>>>> restatement of 3550), it is not possible to achieve the  
>>>>>>> implied sync times.  I really think you need to say MUST, but  
>>>>>>> I leave that to you and Thomas.  And, it should be tied back  
>>>>>>> to NTP fields since that it is a popular source of clock.   
>>>>>>> Here's a suggestion:
>>>>>>>
>>>>>>>> a common reference clock. When NTPv4 is used, all instances  
>>>>>>>> of NTP packets should set the Reference ID (refid) field to  
>>>>>>>> the same timebase value (e.g. "GPS" - see NTPv4 Figure 12).  
>>>>>>>> accomplished out of band. When NTPv3 is used, all instances  
>>>>>>>> of NTP packets should use the same timebase, even if it is  
>>>>>>>> not explicitly signaled in the Reference ID field.
>>>>>>>> ==============
>>>>>>> Regarding the access point timing, I think a note would be  
>>>>>>> good surrounding the tables to diffuse the implication that  
>>>>>>> the 0.04 times in the table are realistic for an expected sync  
>>>>>>> time (even if good for other purposes). We all agree there are  
>>>>>>> other good reasons to send more frequent RTCP SR records that  
>>>>>>> also improve clock accuracy, and are thus directly relevant to  
>>>>>>> this draft. I did not mean to imply otherwise.  But I think it  
>>>>>>> would be helpful to more clearly separate those reasons (e.g.  
>>>>>>> decoder clock stability) from sync time expectations.  Let me  
>>>>>>> know if you want a specific text suggestion.
>>>>>>
>>>>>>>>> resolutions being discussed in the draft, and therefore it  
>>>>>>>>> is an omission not to address them:
>>>>>>>>>
>>>>>>>>> 1. Common timebase
>>>>>>>>> that a common timebase is needed to achieve anything near  
>>>>>>>>> the implied sync times discussed in this draft. How the  
>>>>>>>>> senders and receivers figure that out is out of band. But if  
>>>>>>>>> they don't and just go along with "wallclock", it makes much  
>>>>>>>>> of the rest of this draft irrelevant since the timebase  
>>>>>>>>> error will be huge by comparison.
>>>>>>>>
>>>>>>>>> encoding, not constant per type, and not constant per  
>>>>>>>>> stream. For example in H.264, these typically center around  
>>>>>>>>> the presence of an IDR frame.  HE AAC has a simpler coding  
>>>>>>>>> structure, but one still can't start decoding anywhere in  
>>>>>>>>> the stream.  The "typical" periods of the H.264 access  
>>>>>>>>> points range from 0.5 to 2 seconds, depending on the  
>>>>>>>>> coding.  The exact period is application dependent, but is  
>>>>>>>>> not relevant.  The point is that these periods greatly  
>>>>>>>>> exceed the times shown in the tables which are implied to be  
>>>>>>>>> the sync times - going as low as 0.04 seconds.  The tables  
>>>>>>>>> Thomas notes) for jitter management and clock settling, but  
>>>>>>>>> that high rate does not help you sync since you can't even  
>>>>>>>>> start decoding the video for a relatively long time after  
>>>>>>>>> the 0.04 seconds. This is mostly related to issues of late  
>>>>>>>>> joiners of course.  Therefore, I was suggesting we make note  
>>>>>>>>> of this fact to clarify there are other factors to sync and  
>>>>>>>>> acquisition beyond receipt of NTP and the RTCP SR packet,  
>>>>>>>>> especially if it is aligned with this access point in time.   
>>>>>>>>> If the RTCP SR packets are sent randomly in time, the sync  
>>>>>>>>> time is the IDR period plus 1/2 the RTCP SR packet period,  
>>>>>>>>> on average. This is more of an optimization, but then,  
>>>>>>>>> that's what this whole draft is about - optimizing the sync  
>>>>>>>>> time.
>>>>>>>>

---

From: Michael A Dolan <[email-masked]>
Date: Thu, 02 Jul 2009 11:16:34 -0700

Colin-

I think not providing some NTP-specifics will lead to less clarity, 
but OK.  I understand, and your new -03 is much clearer now in general.

The paragraph below basically restates 3550, which is good, but still 
missing my point about timebase.  Due to the proliferation of "wall 
clock" in other publications, the industry does not assume a common 
timebase even if there is a common "reference clock". I think that 
needs to be explicit even if we abstract it from NTP.  And, the 
signaling of the timebase in use is also outside the scope of this 
memo, including where the timestamp is included in the RTP hdr ext.  How about:

    Furthermore, to achieve more rapid and accurate synchronisation, it
    is RECOMMENDED that senders and receivers use a common reference
    clock with common properties, especially timebase, where possible 
(recognising that this is often not possible
    when RTP is used outside of controlled environments); the means by
    which that common reference clock and its properties isare 
signaled and distributed is are outside the
    scope of this memo.

I'll ponder a future ID with domain-specific details.

Regards,

         Mike

At 06:38 PM 7/2/2009 +0100, Colin Perkins wrote:
>outside the scope of this draft (I believe - maybe the chairs want 
>to give some guidance). If you, or anyone else, want to write a 
>draft discussing the synchronisation requirements for various 
>domains, and how they can be met using RTP and various clock 
>distribution mechanisms, then I'd support it.
>
>Cheers,
>Colin
>
>
>
>>>The only thing RTP uses from NTPv3 is the timestamp format. I 
>>>don't see why the older reference is problematic.
>>>
>>>Colin
>>>
>>>
>>>
>>>>I proposed below (paraphrased): WHEN NTPv4 is used, then do X, 
>>>>and WHEN NTPv3 is used then do Y. I never said NTPv4 was 
>>>>preferred (except perhaps implied with my parenthetical to 
>>>>replace the older RFC reference). But I suggested that since 
>>>>NTPv4 is getting pretty close to pub and obsoletes NTPv3 
>>>>(1305).  So trying to hang on to NTPv3 only is problematic, I 
>>>>think. But that's really a separate issue from my concern about 
>>>>the common timebase. Without a common timebase, the techniques 
>>>>described in this ID will be ineffective by an order of 
>>>>magnitude, no matter what version of NTP is used. So, I feel that 
>>>>some language substantively like what I propose below be added to 
>>>>this ID as necessary guidance.
>>>>
>>>>Regards,
>>>>
>>>>         Mike
>>>>
>>>>>NPTv4 be implemented for synchronisation is stronger than I 
>>>>>think desirable for a general draft such as this (although, of 
>>>>>course, perfectly fine for some restricted domains in which RTP is used).
>>>>>
>>>>>Cheers,
>>>>>Colin
>>>>>
>>>>>
>>>>>
>>>>>>course.  But I do think we need to be much clearer that a 
>>>>>>common timebase is really important for sync.
>>>>>>
>>>>>>>>3550 only imprecisely recommends (not requires) using a 
>>>>>>>>common clock, and when it does, it uses the term, 
>>>>>>>>"wallclock", without defining it.  In order for the sync to 
>>>>>>>>even approach the numbers implied in this draft, the clocks 
>>>>>>>>must indeed be synchronized and they must use the same 
>>>>>>>>timebase.  Failing to minimally recommend this (even if you 
>>>>>>>>believe it is a restatement of 3550), it is not possible to 
>>>>>>>>achieve the implied sync times.  I really think you need to 
>>>>>>>>say MUST, but I leave that to you and Thomas.  And, it should 
>>>>>>>>be tied back to NTP fields since that it is a popular source 
>>>>>>>>of clock.  Here's a suggestion:
>>>>>>>>
>>>>>>>>>recommended in RFC 3550, all senders and receivers should 
>>>>>>>>>use a common reference clock. When NTPv4 is used, all 
>>>>>>>>>instances of NTP packets should set the Reference ID (refid) 
>>>>>>>>>field to the same timebase value (e.g. "GPS" - see NTPv4 
>>>>>>>>>Figure 12). Signaling for what Reference ID value is tp be 
>>>>>>>>>used is accomplished out of band. When NTPv3 is used, all 
>>>>>>>>>instances of NTP packets should use the same timebase, even 
>>>>>>>>>if it is not explicitly signaled in the Reference ID field.
>>>>>>>>>==============
>>>>>>>reference clock, or a particular clock synchronisation 
>>>>>>>protocol - that's not realistic given the range of 
>>>>>>>environments in which RTP is used - but I will add some text 
>>>>>>>recommending that a common clock is used where possible.
>>>>>>>
>>>>>>>>the 0.04 times in the table are realistic for an expected 
>>>>>>>>sync time (even if good for other purposes). We all agree 
>>>>>>>>there are other good reasons to send more frequent RTCP SR 
>>>>>>>>records that also improve clock accuracy, and are thus 
>>>>>>>>directly relevant to this draft. I did not mean to imply 
>>>>>>>>otherwise.  But I think it would be helpful to more clearly 
>>>>>>>>separate those reasons (e.g. decoder clock stability) from 
>>>>>>>>sync time expectations.  Let me know if you want a specific text suggestion.
>>>>>>>
>>>>>>>>Co-locating the RTCP SR records and the media access points 
>>>>>>>>is a helpful recommendation, and less systemic than the above points.
>>>>>>>>
>>>>>>>>>>idea).  All I am proposing is to add some text that 
>>>>>>>>>>explains that a common timebase is needed to achieve 
>>>>>>>>>>anything near the implied sync times discussed in this 
>>>>>>>>>>draft. How the senders and receivers figure that out is out 
>>>>>>>>>>of band. But if they don't and just go along with 
>>>>>>>>>>"wallclock", it makes much of the rest of this draft 
>>>>>>>>>>irrelevant since the timebase error will be huge by comparison.
>>>>>>>>>
>>>>>>>>>>arrive periodically - the point where a decoder can begin 
>>>>>>>>>>to decode the stream. In general, these are a function of 
>>>>>>>>>>the encoding, not constant per type, and not constant per 
>>>>>>>>>>exceed the times shown in the tables which are implied to 
>>>>>>>>>>be the sync times - going as low as 0.04 seconds.  The 
>>>>>>>>>>tables in this draft suggesting that RTCP SR packets be 
>>>>>>>>>>sent 0.04 seconds apart for high rate streams. This is 
>>>>>>>>>>interesting (as Thomas notes) for jitter management and 
>>>>>>>>>>clock settling, but that high rate does not help you sync 
>>>>>>>>>>since you can't even start decoding the video for a 
>>>>>>>>>>relatively long time after the 0.04 seconds. This is mostly 
>>>>>>>>>>related to issues of late joiners of course.  Therefore, I 
>>>>>>>>>>was suggesting we make note of this fact to clarify there 
>>>>>>>>>>are other factors to sync and acquisition beyond receipt of 
>>>>>>>>>>NTP and the RTCP SR packet, and that these other times far exceed 0.04 seconds.
>>>>>>>>>
>>>>>>>>>Okay, that's what I thought you meant. That certainly 
>>>>>>>>>affects the join times, although I'm not sure I'd call that 
>>>>>>>>>issue synchronisation latency. We can certainly add some 
>>>>>>>>>wording to highlight it though.
>>>>>>>>>
>>>>>>>>>>time.  If the RTCP SR packets are sent randomly in time, 
>>>>>>>>>>the sync time is the IDR period plus 1/2 the RTCP SR packet 
>>>>>>>>-----------------------------------
>>>>>>>>Michael DOLAN
>>>>>>>>Television Broadcast Technology, Inc. (TBT)
>>>>>>>>PO Box 190, Del Mar, CA 92014 USA
>>>>>>>>+1-858-755-6661    FAX: +1-858-755-6669
>>>>>>>>URL:http://www.newtbt.com

---

From: Colin Perkins <[email-masked]>
Date: Fri, 3 Jul 2009 18:28:33 +0100

Mike,

That change looks good to me. I just submitted -04 including this text.
Colin

On 2 Jul 2009, at 19:16, Michael A Dolan wrote:

> The paragraph below basically restates 3550, which is good, but  
> still missing my point about timebase.  Due to the proliferation of  
> "wall clock" in other publications, the industry does not assume a  
> common timebase even if there is a common "reference clock". I think  
> that needs to be explicit even if we abstract it from NTP.  And, the  
>> It's important to specify a reference clock, and to discuss how  
>> that clock is distributed, but that's highly domain specific, and  
>> so outside the scope of this draft (I believe - maybe the chairs  
>> want to give some guidance). If you, or anyone else, want to write  
>> a draft discussing the synchronisation requirements for various  
>>>>> magnitude, no matter what version of NTP is used. So, I feel  
>>>>> that some language substantively like what I propose below be  
>>>>>> which made a stronger recommendation. Still, the suggestion  
>>>>>> that NPTv4 be implemented for synchronisation is stronger than  
>>>>>> I think desirable for a general draft such as this (although,  
>>>>>> of course, perfectly fine for some restricted domains in which  
>>>>>> RTP is used).
>>>>>>
>>>>>> Cheers,
>>>>>> Colin
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> say MUST, but I leave that to you and Thomas.  And, it  
>>>>>>>>>> instances of NTP packets should set the Reference ID  
>>>>>>>>>> (refid) field to the same timebase value (e.g. "GPS" - see  
>>>>>>>>>> NTPv4 Figure 12). Signaling for what Reference ID value is  
>>>>>>>>>> tp be used is accomplished out of band. When NTPv3 is used,  
>>>>>>>>>> all instances of NTP packets should use the same timebase,  
>>>>>>>>>> even if it is not explicitly signaled in the Reference ID  
>>>>>>>>>> field.
>>>>>>>>>> ==============
>>>>>>>>>>> FYI, I started out in March with a number of comments,  
>>>>>>>>>>> some related to multicast UDLR with 1-2 links and I sense  
>>>>>>>>>>> that's too big a topic to try and add at this point.  My  
>>>>>>>>>>> comments therefore have distilled to addressing two major  
>>>>>>>>>>> factors in syncing RTP sessions that I believe overshadow  
>>>>>>>>>>> the time resolutions being discussed in the draft, and  
>>>>>>>>>>> therefore it is an omission not to address them:
>>>>>>>>>>>
>>>>>>>>>>> 1. Common timebase
>>>>>>>>>>> draft. How the senders and receivers figure that out is  
>>>>>>>>>>> out of band. But if they don't and just go along with  
>>>>>>>>>>> stream. For example in H.264, these typically center  
>>>>>>>>>>> around the presence of an IDR frame.  HE AAC has a simpler  
>>>>>>>>>>> coding structure, but one still can't start decoding  
>>>>>>>>>>> anywhere in the stream.  The "typical" periods of the H. 
>>>>>>>>>>> 264 access points range from 0.5 to 2 seconds, depending  
>>>>>>>>>>> on the coding.  The exact period is application dependent,  
>>>>>>>>>>> but is not relevant.  The point is that these periods  
>>>>>>>>>>> greatly exceed the times shown in the tables which are  
>>>>>>>>>>> packets be sent 0.04 seconds apart for high rate streams.  
>>>>>>>>>>> This is interesting (as Thomas notes) for jitter  
>>>>>>>>>>> help you sync since you can't even start decoding the  
>>>>>>>>>>> video for a relatively long time after the 0.04 seconds.  
>>>>>>>>>>> This is mostly related to issues of late joiners of  
>>>>>>>>>>> access points further improves the sync time.  For  
>>>>>>>>>>> example, if the IDR is every 2 seconds, there is no  
>>>>>>>>>>> benefit (for syncing) to sending the RTCP SR more  
>>>>>>>>>>> frequently than that, especially if it is aligned with  
>>>>>>>>>>> this access point in time.  If the RTCP SR packets are  
>>>>>>>>>>> sent randomly in time, the sync time is the IDR period  
>>>>>>>>>>> plus 1/2 the RTCP SR packet period, on average. This is  
>>>>>>>>>> I agree that co-locating the SR information in time with  
>>>>>>>>>> the random access points helps, and will add something to  
>>>>>>>>>> the draft to say that explicitly if it's not already there.  
>>>>>>>>>> I disagree that's sufficient: sending the SR information  
>>>>>>>>>> more frequently gives the receiver more samples from which  
>>>>>>>>>> to estimate any skew between NTP and RTP timestamps, and  
>>>>>>>>>> gives more information to help filter out any incorrect  
>>>>>>>>>> mappings.
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Colin Perkins
>>>>>>>>>> http://csperkins.org/
>>>>>>>>>

-- 
Colin Perkins
http://csperkins.org/