Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt
Colin Perkins <csp@csperkins.org> Fri, 03 July 2009 17:28 UTC
Return-Path: <csp@csperkins.org>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9432228C251 for <avt@core3.amsl.com>; Fri, 3 Jul 2009 10:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHYLLiCas9W6 for <avt@core3.amsl.com>; Fri, 3 Jul 2009 10:28:19 -0700 (PDT)
Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by core3.amsl.com (Postfix) with ESMTP id C3F813A6CAA for <avt@ietf.org>; Fri, 3 Jul 2009 10:28:11 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1MMmYs-00030J-nP for avt@ietf.org; Fri, 03 Jul 2009 17:28:34 +0000
Message-Id: <831B0F3A-5DF2-4BD4-8995-281C4DAC1728@csperkins.org>
From: Colin Perkins <csp@csperkins.org>
To: "Audio/Video Transport (AVT) WG" <avt@ietf.org>
In-Reply-To: <0MKpCa-1MMR050eCE-000CDE@mrelay.perfora.net>
Content-Type: multipart/alternative; boundary="Apple-Mail-86--100542289"
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Fri, 03 Jul 2009 18:28:33 +0100
References: <20090309171502.518513A6359@core3.amsl.com> <4A6ACB13-0CBB-4DA7-84AD-28CDE56DB4C3@csperkins.org> <0MKpCa-1LoLs525qX-000cvA@mrelay.perfora.net> <49D1C793.9050409@hhi.fraunhofer.de> <0MKp8S-1Lof8c1LTC-000fjs@mrelay.perfora.net> <49D4AE9D.8060905@hhi.fraunhofer.de> <0MKpCa-1MEnZO1ysE-000d6S@mrelay.perfora.net> <4A323DC5.5020004@hhi.fraunhofer.de> <0MKpCa-1MGbjS2vGp-000cit@mrelay.perfora.net> <C0A963AC-4B17-49FC-904C-44A43DF0B8D7@csperkins.org> <0MKpCa-1MGfai3tWQ-000d7b@mrelay.perfora.net> <B5806023-20A3-4868-9195-7FA0D4D62053@csperkins.org> <0MKp8S-1MH15V3qqW-000fpm@mrelay.perfora.net> <AAFAF085-54E8-4FF1-968D-588A981C987B@csperkins.org> <0MKp8S-1MLm0o07oT-000SlS@mrelay.perfora.net> <14404518-B2BA-4B3C-8033-F60D69328397@dcs.gla.ac.uk> <0MKpCa-1MMOKc3UNx-000C4x@mrelay.perfora.net> <14F09148-E096-4D96-A2A8-C6682AEA6BBE@dcs.gla.ac.uk> <0MKpCa-1MMOYf45gr-000BwN@mrelay.perfora.net> <6E5AD523-A785-4933-BC15-06E724442B29@csperkins.org> <0MKpCa-1MMR050eCE-000CDE@mrelay.perfo ra.net>
X-Mailer: Apple Mail (2.935.3)
Subject: Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2009 17:28:24 -0000
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/
- [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp… Colin Perkins
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Ali C. Begen (abegen)
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Ye-Kui Wang
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Roni Even
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Thomas Schierl
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Stefan Döhla
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Ali C. Begen (abegen)
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Thomas.Schierl
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Stefan Döhla
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Thomas.Schierl
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Stefan Döhla
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Ye-Kui Wang
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Ye-Kui Wang
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Ye-Kui Wang
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Thomas.Schierl
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Thomas.Schierl
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Stefan Döhla
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Thomas.Schierl
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Stefan Döhla
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Randell Jesup
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Michael A Dolan
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Thomas.Schierl
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Michael A Dolan
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Thomas.Schierl
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Michael A Dolan
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Thomas Schierl
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Michael A Dolan
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Colin Perkins
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Michael A Dolan
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Colin Perkins
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Ali C. Begen (abegen)
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Michael A Dolan
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Allison, Art
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Ye-Kui Wang
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Ali C. Begen (abegen)
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Colin Perkins
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Colin Perkins
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Michael A Dolan
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Colin Perkins
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Michael A Dolan
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Colin Perkins
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Michael A Dolan
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Colin Perkins
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Michael A Dolan
- Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid… Colin Perkins