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