Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-06.txt

Kevin Gross <kevin.gross@avanw.com> Thu, 26 September 2013 23:28 UTC

Return-Path: <kevin.gross@avanw.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1460721F9E46 for <avt@ietfa.amsl.com>; Thu, 26 Sep 2013 16:28:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.742
X-Spam-Level: *
X-Spam-Status: No, score=1.742 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1, SARE_SUB_6CONS_WORD=0.356]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpKeVCAWswgp for <avt@ietfa.amsl.com>; Thu, 26 Sep 2013 16:27:57 -0700 (PDT)
Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5AB21F9B85 for <avt@ietf.org>; Thu, 26 Sep 2013 16:27:55 -0700 (PDT)
Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta02.emeryville.ca.mail.comcast.net with comcast id VyYL1m00G0cQ2SLA2zTvwu; Thu, 26 Sep 2013 23:27:55 +0000
Received: from mail-we0-f180.google.com ([74.125.82.180]) by omta10.emeryville.ca.mail.comcast.net with comcast id VzRs1m00Y3tS2US8WzRttM; Thu, 26 Sep 2013 23:25:54 +0000
Received: by mail-we0-f180.google.com with SMTP id u57so1879030wes.39 for <avt@ietf.org>; Thu, 26 Sep 2013 16:25:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aIAfFU/8loaQJKrw23nQ7l1ogM9pSB7qe3g6kWqMdRs=; b=dlqni8tEtP6Mq8NOmBbOLhwjeuBBzWFO9AY5AxIuNVjTfMiQ/lt6BWtIrVRRptlTYm vG3zApYIiLsPWUXCUFhTLIx16uNU7b+vxfpozn9XSqdM/Sr3GTy2d3W+gsgeyU6oOqdh /HdsdUuHzK5ouFe3cRTpYLYarUit8UpAYuFGFwy+PZigRCFGXZxX23zW0Kj417Igg7DX 0/qbdgSIrHtI6fsdUiMYEyLbXMqSs8xp/aFsismDVOzdHFUVjDSMraCPEA992RoDh3Rp v4cJPk8lks0ZkFPk5rfl7sagxNHetjOlk+/GVMgiRZIyF25y6oHVyAQk7AjxfSx+Uhws 8Z7A==
MIME-Version: 1.0
X-Received: by 10.194.9.70 with SMTP id x6mr3085419wja.22.1380237952078; Thu, 26 Sep 2013 16:25:52 -0700 (PDT)
Received: by 10.216.97.1 with HTTP; Thu, 26 Sep 2013 16:25:51 -0700 (PDT)
In-Reply-To: <5231A9CD.9080108@ericsson.com>
References: <20130911001349.28088.35324.idtracker@ietfa.amsl.com> <52301853.4070306@ericsson.com> <18036806.1238.1378969595799.JavaMail.aidan@praxis.audinate.com> <5231A9CD.9080108@ericsson.com>
Date: Thu, 26 Sep 2013 17:25:51 -0600
Message-ID: <CALw1_Q3=0VZkpxt9hmtzOSGpJQ_=+7XvQaaE5YPD3E4REVcneg@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary=047d7b5d57ced6db6204e751b07e
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380238075; bh=aIAfFU/8loaQJKrw23nQ7l1ogM9pSB7qe3g6kWqMdRs=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=GruRi3EMtjQ4uyj3arN6arh5B989CeGUm45LDfbZYoJbkaPD8P5Q2qUr2c/e3UFcI LsjjYdzMp4VmzGg2/Cr2VK0wGQLKeJsG8AoLl+DhN0vlHPTL1pYriMmd42qj0YbcIl xkquW4zPkvSGVWFCaI4Q/jN7Qeh/8l89To5GgtlBRZTMfgr1RK80scnG5ucM277Ze0 V63WnG6dXO8LceTOF5XQddNx/f6RBDNFzaQ6b33RLEXGHpM4e5fLE78NFsK2UNZ5UH AMYss/X5nfqa7SmQe/mFg2RJkg8MH+jXGtuHFgDokwr22YRgeCnr8lZNxzZ+Gj4gU6 OdQCl/piT/xTA==
Cc: "avt@ietf.org" <avt@ietf.org>, "draft-ietf-avtcore-clksrc@tools.ietf.org" <draft-ietf-avtcore-clksrc@tools.ietf.org>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-06.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 26 Sep 2013 23:28:02 -0000

Sorry again. I missed this part of the thread. The implementations we've
done so far all use TAI timestamp reference clocks. I've now worked through
the details for an NTP reference.

The era of accurate timekeeping really only started in 1972 (and is
well-defined retroactively to 1970). Not everyone agrees on what
happened before
then so I think we do need to give the RFC 868 figure to ensure
interoperability when using NTP.

Here's proposed replacement text with all the gory details:

The signalling optionally indicates a media clock offset value.  The offset
indicates the RTP timestamp value at the epoch (time of origin) of the
reference clock. To use the offset, implementations need to compute
RTP timestamps from reference clocks. To simplify these calculations,
streams utilizing offset signaling SHOULD use a TAI timestamp reference
clock to avoid complications introduced by leap seconds. See
[draft-ietf-avtcore-leap-second] for further discussion of leap-second
issues in timestamp reference clocks.

To compute the RTP timestamp against an IEEE 1588 (TAI-based) reference,
the time elapsed between the 00:00:00 1 January IEEE 1588 epoch and the
current time must be computed. Between the epoch and 1 January 2013, there
were 15,706 days (including extra days during leap years). Since there are
no leap seconds in a TAI reference, there are exactly 86,400 seconds during
each of these days or a total of 1,356,998,400 seconds from the epoch to
00:00:00 1 January 2013. A 90 kHz RTP clock for a video stream would have
advanced 122,129,856,000,000 units over this period. With a signaled offset
of 0, the RTP clock value modulo the 32-bit unsigned representation in the
RTP header would have been 2,460,938,240 at 00:00:00 1 January 2013. If an
offset of 23,465 had been signaled, the clock value would have
been 2,460,961,705.

In order to use an NTP reference, the actual time elapsed between the
00:00:00, 1 January 1900 NTP epoch to the current time must be
computed. 2,208,988,800
seconds elapsed between the NTP epoch and 00:00:00 1 January 1970 [RFC
868]. Between the beginning of 1970 and 2013, there were 15,706 days
elapsed (including extra days during leap years) and 25 leap seconds
inserted. There is therefore a total of 3,565,987,225 seconds from the NTP
epoch to 00:00:00 1 January 2013. A 90 kHz RTP clock for a video stream
would have advanced 320,938,850,250,000 units over this period. With a
signaled offset of 0, the RTP clock value modulo the 32-bit unsigned
representation would have been 1,714,023,696 at 00:00:00 1 January 2013.

If no offset is signalled, the offset can be inferred at the receiver by
examining RTCP sender reports which contain NTP and RTP timestamps which
combined define a mapping. The NTP/RTP timestamp mapping provided by RTCP
SRs takes precedence over that provided by the SDP, however the media clock
rate implied by the SRs MUST be consistent with the rate announced in the
SDP.


Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>


On Thu, Sep 12, 2013 at 5:47 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> On 2013-09-12 09:06, Aidan Williams wrote:
> > Hi Magnus,
> >
> > Thanks for your comments - they were very helpful.  I was going to
> > respond to your previous email point by point, but you've beaten me to
> it.
> >
> >
> > ------------------------------------------------------------------------
> >
> >     *From: *"Magnus Westerlund" <magnus.westerlund@ericsson.com>
> >     *To: *avt@ietf.org, draft-ietf-avtcore-clksrc@tools.ietf.org
> >     *Sent: *Wednesday, 11 September, 2013 5:14:27 PM
> >     *Subject: *Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-06.txt
> >
> >     Hi,
> >
> >     Great to see a new version. I have checked this version against my
> >     previous comments and believe that it cares of all except the below
> two
> >     issues.
> >
> >     Section 5.2:
> >
> >        The signalling optionally indicates a media clock offset value.
>  The
> >        offset indicates the RTP timestamp value at the epoch (time of
> >        origin) of the reference clock.  If no offset is signalled, the
> >        offset can be inferred at the receiver by examining RTCP sender
> >        reports which contain NTP and RTP timestamps which combined
> define a
> >        mapping.
> >
> >
> >     > First, I am not certain that I understand the offset. So the
> indicated
> >     > value is an RTP timestamp, i.e. the integer representation of the
> >     32-bit
> >     > value of the RTP timestamp. So the epoch time is dependent on the
> >     clock
> >     > system, but the current epoch for an NTP reference clock would be
> >     1 jan
> >     > at 0:00 year 1900. Thus you need to take all the leap seconds etc
> into
> >     > account to determine how many time has actually passed since then
> and
> >     > then calculate how many wrapping of the timestamp this means. This
> >     seems
> >     > error prone, at least without being more explicit of how to do it
> for
> >     > the various reference clocks.
> >
> >     I still think I need an author response on this to determine if
> there is
> >     an issue here.
> >
> > Kevin and I discussed this off list - we decided not to describe how to
> > count all the leap seconds but to recommend the use of a non-leapsecond
> > bearing clock (e.g. TAI):
> >
> > Implementations SHOULD use a TAI timestamp reference clock
> > to avoid complications due to leap seconds.  The NTP/RTP timestamp
> > mapping provided by RTCP SRs takes precedence over that provided by
> > the SDP, however the media clock rate implied by the SRs MUST be
> > consistent with the rate announced in the SDP.
> >
> > Are you OK with this as a resolution?
>
> I personally think this is a little to dense to be easily understood. I
> think it assumes a fairly good understanding of clocks and different
> representations and potential issues to do correctly. I would definitely
> like the text to be more explicit about several things.
>
> First what the basic calculation that needs to be done is. Secondly, the
> to be clear about the pitfalls with leap seconds, especially to put the
> TAI recommendation into perspective.
>
> The full paragraph currently says:
>
>    The signalling optionally indicates a media clock offset value.  The
>    offset indicates the RTP timestamp value at the epoch (time of
>    origin) of the reference clock.  If no offset is signalled, the
>    offset can be inferred at the receiver by examining RTCP sender
>    reports which contain NTP and RTP timestamps which combined define a
>    mapping.  Implementations SHOULD use a TAI timestamp reference clock
>    to avoid complications due to leap seconds.  The NTP/RTP timestamp
>    mapping provided by RTCP SRs takes precedence over that provided by
>    the SDP, however the media clock rate implied by the SRs MUST be
>    consistent with the rate announced in the SDP.
>
> I would suggest this to be changed to something more like this:
>
>
> The signalling optionally indicates a media clock offset value.  The
> offset indicates the RTP timestamp value at the epoch (time of origin)
> of the reference clock. So for example if the reference clock used is
> NTP that is UTC based, then the epoch was the 0:00:00 on the 1st of
> January 1900. As the offset is the value the RTP timestamp would have
> had at the time of the epoch, one needs to determine the amount of time
> since the epoch. In formats that includes leap seconds, like NTP this
> isn't simply to take the reference clock value multiplied by the
> timestamp rate and subtract that from the RTP Timestamp media clock
> value for the correspondingly used reference clock value modulus 2^32.
> For example for UTC compared to the leap second less TAI format there is
> a 35 second time difference at the time of writing. To get this
> correctly for systems with leap seconds, the leap seconds must be
> tracked. Implementations SHOULD use a TAI timestamp reference clock to
> avoid complications due to leap seconds. If no offset is signalled, the
>    offset can be inferred at the receiver by examining RTCP sender
>    reports which contain NTP and RTP timestamps which combined define a
>    mapping.    The NTP/RTP timestamp
>    mapping provided by RTCP SRs takes precedence over that provided by
>    the SDP, however the media clock rate implied by the SRs MUST be
>    consistent with the rate announced in the SDP.
>
> Trying to write the above I actually got confused about the epoch for
> NTP. After some reasoning I deduced that it must be the format epoch,
> i.e. 1900 rather than the epoch of the UTC time which I believe is 0h 1
> January 1972.
>
> I think it is important to remember that some of the implementors of
> this specification will basically get an order: Go implement this for
> our system. They may additionally know which clock system it is
> coordinated with.
>
> >
> >     > 5. Section 5.2 and Figure 7:
> >     >
> >     >    A rate modifier may be specified.  The modifier is expressed as
> the
> >     >    ratio of two integers and modifies the rate specified or
> implied by
> >     >    the media description by this ratio.  If omitted, the rate is
> >     assumed
> >     >    to be the exact rate specified or implied by the media format.
>  For
> >     >    example, without a rate specification, the media clock for an 8
> kHz
> >     >    G.711 audio stream will advance exactly 8000 units for each
> second
> >     >    advance in the reference clock from which it is derived.
> >     >
> >     > and looking at this example in Figure 7:
> >     >
> >     >           m=audio 5004 RTP/AVP 96
> >     >           a=rtpmap:96 L24/44100/2
> >     >           a=sendonly
> >     >           a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
> >     >           a=mediaclk:direct=963214424 rate=1000/1001
> >     >
> >     > I realize that I don't understand what the rate modifier means.
> >     Without
> >     > the rate modifier there would be 44100 RTP timestamp ticks per
> >     second of
> >     > reference clock. Does the rate modifier multiply with the nominal
> rate
> >     > so that this example means 441000*1000/1001 RTP TS ticks per
> second of
> >     > reference clock?
> >     >
> >     > Some clarification may be required here.
> >
> >     Also this I would like to receive some answer to.
> >
> > The rate modifier means exactly what you think it does.
> > So it would appear that the text is sufficiently clear .. ;-)
> >
> > Do you still feel more clarification is needed?
>
> Maybe not, even if I would prefer a clarification.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>