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

[Michael A Dolan <md.1 at newtbt.com>]

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/

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.

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/