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:

> 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:
>> 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:
>>> 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:
>>>> 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:
>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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/
>>>>>>>>>
>>>>>>>>> -----------------------------------
>>>>>>>>> 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
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt



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