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

From: [email-masked]
Date: Tue, 10 Sep 2013 17:13:49 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.

	Title           : RTP Clock Source Signalling
	Author(s)       : Aidan Williams
                          Kevin Gross
                          Ray van Brandenburg
                          Hans Stokking
	Filename        : draft-ietf-avtcore-clksrc-06.txt
	Pages           : 28
	Date            : 2013-09-10

Abstract:
   NTP format timestamps are used by several RTP protocols for
   synchronisation and statistical measurements.  This memo specifies
   SDP signalling identifying timestamp reference clock sources and SDP
   signalling identifying the media clock sources in a multimedia
   session.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-clksrc-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Sep 2013 09:14:27 +0200

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.

> 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.

Cheers

Magnus

On 2013-09-11 02:13, [email-masked] wrote:
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 
> 

-- 

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: [email-masked]
----------------------------------------------------------------------

---

From: Aidan Williams <[email-masked]>
Date: Thu, 12 Sep 2013 17:06:38 +1000 (EST)

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. 

----- Original Message -----

> From: "Magnus Westerlund" <[email-masked]>
> To: [email-masked], [email-masked]
> Sent: Wednesday, 11 September, 2013 5:14:27 PM
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-06.txt

> I still think I need an author response on this to determine if there

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? 

> 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? 

- aidan

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Sep 2013 13:47:25 +0200

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" <[email-masked]>
>     *To: [email-masked], [email-masked]
>     *Sent: *Wednesday, 11 September, 2013 5:14:27 PM
>     *Subject: *Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-06.txt
> 
>     Hi,
> 
> 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):
> 

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:

   mapping.  Implementations SHOULD use a TAI timestamp reference clock

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.

> Do you still feel more clarification is needed?

Maybe not, even if I would prefer a clarification.

Cheers

Magnus Westerlund

---

From: Kevin Gross <[email-masked]>
Date: Thu, 26 Sep 2013 17:25:51 -0600

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/>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 27 Sep 2013 07:54:30 +0200

Hi,

Thanks for writing up this text. I think this are making clear the
calculations that are needed and the difference between NTP and TAI
usage. So I am happy.

Cheers

Magnus

On 2013-09-27 01:25, Kevin Gross wrote:
> done so far all use TAI timestamp reference clocks. I've now worked
> through the details for an NTP reference.
> 
> 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.
> 
>     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.
> 
> 
>

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 27 Sep 2013 07:58:23 +0200

Hi,

With the new text in the other messages I think I am fine and I
revisited section 5.2 and I think it sufficient clear.

If any one in the WG wants to give their input on this it would be
appreciated.

So, after a revised ID has been submitted with the offset example text
lets progress.

Cheers

Magnus

On 2013-09-26 02:27, Kevin Gross wrote:
> Sorry about that Magnus. I circulated a proposed response on these
> issues among authors back in August but it looks like I never got that
> to you and the avt list. Let me know if you would like to see any
> changes based on this response.
> 
> A naive implementation would simply add 2208988800 (as defined in RFC
> 868) to current Unix time(). However, because of the way Unix time is
> defined, this does not include leap seconds. We appreciate that guidance
> is required to correctly calculate the actual number of elapsed seconds
> since the epoch for a leap-second-bearing reference. We can try to add
> this guidance or we can simply advise against specifying an offset for
> leap-second-bearing reference clocks. This issue does not exist for TAI
> reference clocks.
> 
> This is correct. There is a fair amount of clarification 5.2 that you
> have not quoted. The fact that you properly understand it indicates to
> me that it may actually be adequately clear. To clarify further I think
> would require a lesson on NTSC and digital audio history.
> 
> Kevin Gross
> +1-303-447-0517
> Media Network Consultant
> On Wed, Sep 11, 2013 at 1:14 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     Hi,
> 
>     On 2013-09-11 02:13, [email-masked]
>     <mailto:[email-masked]> wrote:
>     >
>     > until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>     >
>     > [email-masked] <mailto:[email-masked]>
>     <tel:%2B46%2010%207148287>
>     <tel:%2B46%2073%200949079>
>     <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 

Magnus Westerlund