Subject: [AVTCORE] Leap seconds

From: Kevin Gross <[email-masked]>
Date: Wed, 14 Sep 2011 11:22:18 -0600

I am working on a means of using an IEEE 1588 timebase for RTP streaming. I
am aware of IEEE 1733 and will use that if necessary. First I am exploring
using existing NTP mapping function in RTCP sender reports. While
researching how to translate a 1588 timestamp to its NTP equivalent, I was
reminded of the wrinkle leap seconds put into things.

The RTCP sender report maps RTP timestamps to NTP timestamps. RTP timestamps
are monotonically increasing. The RTP timestamps are based on UTC and have
an occasional wobble due to leap seconds. During the leap second, there is
an ambiguous mapping between RTP and NTP/UTC. I find no recommendations in
RFC 3550 for dealing with this.

-- 
Kevin Gross
AVA Networks
+1-303-447-0517

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 14 Sep 2011 13:48:29 -0400

As I understand it the UTC clock will monotonically increase after
January 2017 (no more leap seconds). What happens at 03:14:07 UTC
<http://en.wikipedia.org/wiki/Coordinated_Universal_Time>  on Tuesday,
19 January 2038 (32 bit count overflow) will need to be addressed by
someone, - your guess if any equipment being built today will be in
service then. 

See
http://www.agi.com/downloads/resources/white-papers/Debate-Over-UTC-and-
Leap-Seconds.pdf  for more information.

Art Allison 
Senior Director Advanced Engineering, Science and Technology 
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418
Fax  202 775 4981 
www.nab.org <blocked::http://www.nab.org>  
Advocacy  Education  Innovation 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kevin Gross
Sent: Wednesday, September 14, 2011 1:22 PM
To: [email-masked]
Subject: [AVTCORE] Leap seconds

I am working on a means of using an IEEE 1588 timebase for RTP
streaming. I am aware of IEEE 1733 and will use that if necessary. First
I am exploring using existing NTP mapping function in RTCP sender
reports. While researching how to translate a 1588 timestamp to its NTP
equivalent, I was reminded of the wrinkle leap seconds put into things.

The RTCP sender report maps RTP timestamps to NTP timestamps. RTP
timestamps are monotonically increasing. The RTP timestamps are based on
UTC and have an occasional wobble due to leap seconds. During the leap
second, there is an ambiguous mapping between RTP and NTP/UTC. I find no
recommendations in RFC 3550 for dealing with this.

-- 

Kevin Gross

AVA Networks

+1-303-447-0517

---

From: Kevin Gross <[email-masked]>
Date: Wed, 14 Sep 2011 12:10:11 -0600

The overflow in 2038 is discussed in RFC 3550. That might get a little messy
but at least it is not a mystery.

The proposal to eliminate UTC leap seconds is controversial and still under
consideration. In any case, I don't think I can wait until 2017 for a
solution/answer.

Kevin

On Wed, Sep 14, 2011 at 11:48 AM, Allison, Art <[email-masked]> wrote:

> As I understand it the UTC clock will monotonically increase after  January
> 2017 (no more leap seconds). What happens at 03:14:07 UTC<http://en.wikipedia.org/wiki/Coordinated_Universal_Time>on Tuesday, 19 January 2038 (32
> bit count overflow) will need to be addressed by someone, - your guess if
> any equipment being built today will be in service then. ****
>
> See
> http://www.agi.com/downloads/resources/white-papers/Debate-Over-UTC-and-Leap-Seconds.pdf
> for more information.****
>
> ** **
>
> ** **
>
> *Art Allison*
> *www.nab.org*
> *Advocacy  Education  Innovation* ****
>
> *
> *
>

---

From: Stephen Casner <[email-masked]>
Date: Wed, 14 Sep 2011 11:11:38 -0700 (PDT)

Those issues are addressed in RFC 3550:

   Wallclock time (absolute date and time) is represented using the
   timestamp format of the Network Time Protocol (NTP), which is in
   seconds relative to 0h UTC on 1 January 1900 [4].  The full
   resolution NTP timestamp is a 64-bit unsigned fixed-point number with
   the integer part in the first 32 bits and the fractional part in the
   last 32 bits.  In some fields where a more compact representation is
   appropriate, only the middle 32 bits are used; that is, the low 16
   bits of the integer part and the high 16 bits of the fractional part.
   The high 16 bits of the integer part must be determined
   independently.

   An implementation is not required to run the Network Time Protocol in
   order to use RTP.  Other time sources, or none at all, may be used
   (see the description of the NTP timestamp field in Section 6.4.1).
   However, running NTP may be useful for synchronizing streams
   transmitted from separate hosts.

   The NTP timestamp will wrap around to zero some time in the year
   2036, but for RTP purposes, only differences between pairs of NTP
   timestamps are used.  So long as the pairs of timestamps can be
   assumed to be within 68 years of each other, using modular arithmetic
   for subtractions and comparisons makes the wraparound irrelevant.

The timestamp is not required to be synchronized with UTC at all.  For
some applications it would be convenient to use UTC in order to
synchronize the RTP stream with some other kinds of events, but RTP
does not require it.

                                                        -- Steve

---

From: Kevin Gross <[email-masked]>
Date: Wed, 14 Sep 2011 12:49:35 -0600

To be clear, "Those issues" refers to the year 2038 problem.

By my reading, my original concern about leap seconds is not addressed in
this excerpt or anywhere else in the RFC. I'm hoping to see some additional
discussion about that.

I do recognize that the unsynchronized clock option allows me to replace NTP
time with 1588 time. Apparently I should set the MS bit in the timestamps if
I do this (and possibly expect problems after 2038).

Kevin

On Wed, Sep 14, 2011 at 12:11 PM, Stephen Casner <[email-masked]> wrote:

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 14 Sep 2011 14:55:58 -0400

So far, there has not needed to be a negative leap second. I have  thought
for some time that if the outer core favored us with a negative leap second,
leap seconds would be abandoned. However...

On Wed, Sep 14, 2011 at 1:48 PM, Allison, Art <[email-masked]> wrote:

> 2017 (no more leap seconds).
>

With either positive or negative leap seconds, a proper UTC clock will
only monotonically increase now, just as the calendar only monotonically
increases even given leap days.

> What happens at 03:14:07 UTC<http://en.wikipedia.org/wiki/Coordinated_Universal_Time>on Tuesday, 19 January 2038 (32
> **

That is a pending recommendation. It has not been approved. It comes up for
approval at RA-12 *Geneva, in Switzerland, 16 January-20 January 2012.*
*
*
*Regards*
*Marshall*

> **
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Kevin
> Gross
> *Sent:* Wednesday, September 14, 2011 1:22 PM
> *To:* [email-masked]
> *Subject:* [AVTCORE] Leap seconds****
>
> ** **
>
> reminded of the wrinkle leap seconds put into things.****
>
> ** **
>
> timestamps are monotonically increasing. The RTP timestamps are based on UTC
> and have an occasional wobble due to leap seconds. During the leap second,
> there is an ambiguous mapping between RTP and NTP/UTC. I find no
> recommendations in RFC 3550 for dealing with this.****
>
> ** **
>
> -- ****
>
> Kevin Gross****
>
> AVA Networks****
>
> +1-303-447-0517****
>
> ** **
>

---

From: Stephen Casner <[email-masked]>
Date: Wed, 14 Sep 2011 12:00:30 -0700 (PDT)

No, I meant that the leap-second issue was addressed by not syncing to
UTC and therefore not including leap seconds.  You need not set the MS
bit to use 1588 time.

The key point is that RTP uses NTP format timestamps, not necessarily
NTP.

                                                        -- Steve

---

From: Jamie Gordon <[email-masked]>
Date: Wed, 14 Sep 2011 12:06:23 -0700

RTP timestamps are not monotonically increasing nor based on UTC,
they are based on media sampling/rendering time (based on a
monotonically increasing sampling/playback clock).

Leap second is only relevant if you need to accurately consider the NTP
time as a UTC date/time, which RTP/RTCP do not need at all - per 3550
the NTP timestamp in the SR is not required to represent the actual
wallclock UTC time! It is present to allow conveyance and calculation
of elapsed times, for purposes such as audio/video sync and RTT
estimation, and should be based on actual elapsed time rather than 
calendar time.

Receivers do not expect - or certainly should not expect - the RTCP NTP
clock to change midstream due to leap seconds and senders should not
change it. Once that clock starts the important thing is to maintain
proper elapsed time, rather than using a wallclock time which might
change due to leap second, or even due to the system re-synching to an
SNTP server, or the user changing the current time.

-Jamie

---

From: David Singer <[email-masked]>
Date: Wed, 14 Sep 2011 12:02:24 -0700

On Sep 14, 2011, at 11:49 , Kevin Gross wrote:

> By my reading, my original concern about leap seconds is not addressed in this excerpt or anywhere else in the RFC. I'm hoping to see some additional discussion about that.

NTP timestamp are, as I recall, simply counts of seconds and fractions of seconds since a well-defined origin.  How you choose to interpret and display that count is entirely up to you; I don't think RTP really cares which year something happened in, for example.  You could use any calendar system you like..

> 
> I do recognize that the unsynchronized clock option allows me to replace NTP time with 1588 time. Apparently I should set the MS bit in the timestamps if I do this (and possibly expect problems after 2038).
> 
> Kevin
> 

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Kevin Gross <[email-masked]>
Date: Wed, 14 Sep 2011 13:46:28 -0600

I'm getting the clear impression from this discussion and from the RFC that
the NTP timestamp is not sacred. I'm free to us that for any timebase I wish
and I may well do so.

With all these different timebases in play, how do receivers know which
senders is running off which timebase?

For example, if a receiver receives 48 kHz audio from two different senders,
how does the receiver know that those two sources can be directly mixed
without requiring sample-rate conversion to first synchronize them? Is this
an SDP thing?

Kevin

-- 
Kevin Gross
AVA Networks
+1-303-447-0517

---

From: Kevin Gross <[email-masked]>
Date: Wed, 14 Sep 2011 13:46:32 -0600

If you do want to use the default mode and consider the wallclock in the SRs
be a NTP/UTC time, the presence of a leap seconds in that timebase does
appear to cause problems.

Other timebase discontinuities (initial sync to time server) might be
considered an error and interruption is expected. Leap seconds are scheduled
and ideally should not cause interruption. Senders should not have to lie
about what time it is to keep their receivers happy.

Kevin

On Wed, Sep 14, 2011 at 1:06 PM, Jamie Gordon <[email-masked]> wrote:

> estimation, and should be based on actual elapsed time rather than calendar
> time.
>

-- 
Kevin Gross
AVA Networks
+1-303-447-0517

---

From: Kevin Gross <[email-masked]>
Date: Wed, 14 Sep 2011 13:54:23 -0600

RFC 5905 indicates that the 64-bit NTP timestamps used by the NTP protocol
are a bit more complex than that. Specifically, these NTP timestamps have
discontinuities around leap seconds. RFC 3550 does not spell it out exactly
but I assume the 64-bit NTP timestamp in the RTCP sender report sould behave
according to the definition in RFC 5905.

Kevin

On Wed, Sep 14, 2011 at 1:02 PM, David Singer <[email-masked]> wrote:

> NTP timestamp are, as I recall, simply counts of seconds and fractions of
> seconds since a well-defined origin.  How you choose to interpret and
> display that count is entirely up to you; I don't think RTP really cares
> which year something happened in, for example.  You could use any calendar
> system you like..
>
>
> I do recognize that the unsynchronized clock option allows me to replace
> NTP time with 1588 time. Apparently I should set the MS bit in the
> timestamps if I do this (and possibly expect problems after 2038).
>
> Kevin
>

-- 
Kevin Gross
AVA Networks
+1-303-447-0517

---

From: David Singer <[email-masked]>
Date: Wed, 14 Sep 2011 15:18:48 -0700

OK, I am not an expert, but 1305 does say:

The insertion of leap seconds in UTC and subsequently
into NTP does not affect the UTC or NTP oscillator, only the conversion
to conventional civil UTC time.

On Sep 14, 2011, at 12:54 , Kevin Gross wrote:

> RFC 5905 indicates that the 64-bit NTP timestamps used by the NTP protocol are a bit more complex than that. Specifically, these NTP timestamps have discontinuities around leap seconds. RFC 3550 does not spell it out exactly but I assume the 64-bit NTP timestamp in the RTCP sender report sould behave according to the definition in RFC 5905.
> 
> Kevin
> 

David Singer

---

From: Kevin Gross <[email-masked]>
Date: Wed, 14 Sep 2011 18:47:23 -0600

As is hinted there, UTC as a timebase can be made to work but it is tricky
and deserves to be documented. Senders and receivers especially need to be
aware of leap seconds when mapping wallclock to the media clock. This
requires a level of integration between the NTP agent and the media player.

Receivers that are unaware of leap seconds will slew a second ahead of
others when there's a leap second while streams are running. This is is
likely to result in ongoing buffer underruns at the receiver until the
stream is restarted.

Alternatively applications can agree (through SDP?) to use a TAI timebase
(e.g. IEEE 1588) and avoid the complexity and potential implementation
errors leap seconds introduce.

This all only applies to receivers that use NTP to determine playout time.
Most RTP receivers now use local data arrival time to determine playout
time. The IDMS proposal (
https://datatracker.ietf.org/doc/draft-brandenburg-avt-rtcp-for-idms/) relies
on NTP timestamps. It would seem to be necessary to address the leap second
issue as part of the IDMS project.

Kevin

---

From: David Singer <[email-masked]>
Date: Thu, 15 Sep 2011 09:43:22 -0700

On Sep 14, 2011, at 17:47 , Kevin Gross wrote:

> As is hinted there, UTC as a timebase can be made to work but it is tricky and deserves to be documented. Senders and receivers especially need to be aware of leap seconds when mapping wallclock to the media clock. This requires a level of integration between the NTP agent and the media player.
> 
> Receivers that are unaware of leap seconds will slew a second ahead of others when there's a leap second while streams are running. This is is likely to result in ongoing buffer underruns at the receiver until the stream is restarted.

Only if they calculate the NTP 'seconds since' by calculating from a calendar date and time. The number of seconds-since doesn't change (the length of a second is fairly precisely defined).  "X seconds since the zero-time" is precise; calculating that from "13:45:23 on september 10th 2011" means you have to know not only the length of a day in seconds, but what leap second adjustments to make.

> Alternatively applications can agree (through SDP?) to use a TAI timebase (e.g. IEEE 1588) and avoid the complexity and potential implementation errors leap seconds introduce.
> 

, and that map between calendar date+time and seconds counts.

> Most RTP receivers now use local data arrival time to determine playout time.

Yes, true; receive data, de-jitter, play (taking into account re-ordering issues).

> The IDMS proposal (https://datatracker.ietf.org/doc/draft-brandenburg-avt-rtcp-for-idms/) relies on NTP timestamps. It would seem to be necessary to address the leap second issue as part of the IDMS project.

Only if calendar date+time mapping comes into play, I think.

David Singer

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Sep 2011 17:31:29 +0200

On 2011-09-14 21:46, Kevin Gross wrote:
> I'm getting the clear impression from this discussion and from the RFC
> that the NTP timestamp is not sacred. I'm free to us that for any
> timebase I wish and I may well do so.
> 
> For example, if a receiver receives 48 kHz audio from two different
> senders, how does the receiver know that those two sources can be
> directly mixed without requiring sample-rate conversion to first
> synchronize them? Is this an SDP thing?

It is beyond the assumption of RTP makes about clock bases. All SSRCs
that have a common CNAME can be assumed to come from a common
synchronziation context, and thus the same underlying wall clock.
Sources that are from different contexts needs to be dealt with as non
synchronized sources, with possible drifting clocks in relation to each
other.

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

---

From: Kevin Gross <[email-masked]>
Date: Mon, 19 Sep 2011 10:01:28 -0600

David Singer and I spent some time last week working through this offline.
We're using the same sources and coming to different conclusions. We need
some help resolving this open question.

David's position is that the NTP timestamp continues to increment, with the
system oscillator, through a leap second. The leap second is not visible in
the NTP timestamp but in a higher layer process that converts NTP timestamps
to UTC.

My reading is that the NTP timestamp *is* UTC time and that the clock is
paused for 1 second and a new timeline established at the leap second. This
behavior will either upset or complicate media systems attempting to
reference their playback to the NTP timestamps delivered in RTCP sender
reports.

RFC 3550 (RTP) does not discuss leap seconds.

RFC 5905 (NTP) describes the mechanism used to convey
an upcoming leap second but does not appear to discuss timestamp behavior
associated with the leap second.

The following two references from David Mills (RFC 5905 author) directly
discuss leap second behavior:

   1. http://www.eecis.udel.edu/~mills/leap.html Section 5
   2. Last section of http://doc.ntp.org/4.1.2/leap.htm

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

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 19 Sep 2011 13:10:47 -0400

If the David Mills' documents are taken as normative...

On Mon, Sep 19, 2011 at 12:01 PM, Kevin Gross <[email-masked]> wrote:

> David's position is that the NTP timestamp continues to increment, with
> the system oscillator, through a leap second. The leap second is not visible
> in the NTP timestamp but in a higher layer process that converts NTP
> timestamps to UTC.
>

Neither or both is true, depending on your taste. (See below.) I would not
regard a NTP time interval including a leap second as an UTC time interval.

"Thus, determination of UTC time intervals spanning leap seconds will be in
error, unless the exact times of insertion are known from the NIST table and
its successors."

>    2. Last section of http://doc.ntp.org/4.1.2/leap.htm
"In this design time stands still during the leap second, but is correct
commencing with the next second. Since clock readings must be positive
monotonic, the apparent time will increase by one nanosecond for each
reading. At the end of the second the apparent time may be ahead of the
actual time depending on how many times the clocks was read during the
second. Eventually, the actual time will catch up with the apparent time and
operation continues normally."

So, the time is frozen EXCEPT that it keeps incrementing by 1 nanosecond per
read. In older software, that was 1 microsecond / read. If you are reading
the clock at 90 KHz, that's

- 90 microseconds for a  clock with 1 nanosecond time units, or 8 clock
cycles
- 90 milliseconds for a  clock with 1 microsecond time units, or 8100 clock
cycles

The near frozen polling would continue for that many additional clock cycles
(plus ~ 800 more for clocks with 1 microsecond time units, to catch up with
the delay caused by the polling in the catch up interval.

Regards
Marshall

---

From: David Singer <[email-masked]>
Date: Mon, 19 Sep 2011 10:17:28 -0700

I guess there is some ... unclarity.  On the one hand we read that the tickers that count seconds do just that, tick every second, and that leap-second correction is only required if you want to convert these to civil time.  On the other hand we read of this 'stalling' behavior.  

If we stall periodically, then the counters always have {365 or 366 days} * 24 * 60 * 60 seconds per year.  If we don't, some years are +/-1 second if a second was inserted or deleted, and you need to know which years since your zero-point had leap seconds.

On Sep 19, 2011, at 9:01 , Kevin Gross wrote:

> David Singer and I spent some time last week working through this offline. We're using the same sources and coming to different conclusions. We need some help resolving this open question.
> 
> David's position is that the NTP timestamp continues to increment, with the system oscillator, through a leap second. The leap second is not visible in the NTP timestamp but in a higher layer process that converts NTP timestamps to UTC.
> 
> My reading is that the NTP timestamp *is* UTC time and that the clock is paused for 1 second and a new timeline established at the leap second. This behavior will either upset or complicate media systems attempting to reference their playback to the NTP timestamps delivered in RTCP sender reports.
> 
> RFC 5905 (NTP) describes the mechanism used to convey an upcoming leap second but does not appear to discuss timestamp behavior associated with the leap second.
> 
> The following two references from David Mills (RFC 5905 author) directly discuss leap second behavior:
> http://www.eecis.udel.edu/~mills/leap.html Section 5
> Last section of http://doc.ntp.org/4.1.2/leap.htm
> -- 
> Kevin Gross
> +1-303-447-0517
> Media Network Consultant
> AVA Networks - www.AVAnw.com, www.X192.org
> 
> 

David Singer

---

From: Kevin Gross <[email-masked]>
Date: Mon, 19 Sep 2011 14:07:34 -0600

Yes, well, there it is in all the gory detail.

The point I'm try to get to is that any behavior that doesn't move the
timestamp forward at a constant rate will be a problem for RTP. You appear
to be reading it as I have. NTP time is UTC time and so there's non-uniform
behavior around leap seconds.

On Mon, Sep 19, 2011 at 11:10 AM, Marshall Eubanks <
[email-masked]> wrote:

> On Mon, Sep 19, 2011 at 12:01 PM, Kevin Gross <[email-masked]>wrote:
>
> "Thus, determination of UTC time intervals spanning leap seconds will be
> in error, unless the exact times of insertion are known from the NIST table
> and its successors."
>
>
>>
> So, the time is frozen EXCEPT that it keeps incrementing by 1 nanosecond
> per read. In older software, that was 1 microsecond / read. If you are
> reading the clock at 90 KHz, that's
>
> The near frozen polling would continue for that many additional clock
> cycles (plus ~ 800 more for clocks with 1 microsecond time units, to catch
> up with the delay caused by the polling in the catch up interval.
>
> Regards
> Marshall
>
>
>>
>> --
>> Kevin Gross
>> +1-303-447-0517
>> Media Network Consultant

---

From: Kevin Gross <[email-masked]>
Date: Mon, 19 Sep 2011 14:10:14 -0600

If the experts here are unable to dispel the unclarity I would propose the
next step is to contact David Mills and see if he is able to to comment.

On Mon, Sep 19, 2011 at 11:17 AM, David Singer <[email-masked]> wrote:

> I guess there is some ... unclarity.  On the one hand we read that the
> tickers that count seconds do just that, tick every second, and that
> leap-second correction is only required if you want to convert these to
> civil time.  On the other hand we read of this 'stalling' behavior.
>
> If we stall periodically, then the counters always have {365 or 366 days} *
> 24 * 60 * 60 seconds per year.  If we don't, some years are +/-1 second if a
> second was inserted or deleted, and you need to know which years since your
> zero-point had leap seconds.
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Sep 2011 10:02:05 +0200

On 2011-09-19 22:07, Kevin Gross wrote:
> timestamp forward at a constant rate will be a problem for RTP. You
> appear to be reading it as I have. NTP time is UTC time and so there's
> non-uniform behavior around leap seconds.

Assuming that the NTP clock freezes or semi freezes during the leap
seconds I see two effect happening.

One issue is that an system reading it's clock during the leap second
itself will get different values depending on if the system uses true
NTP time or POSIX time. Thus potentially creating up to a second of
mismatch due to this.

The second issue appears to be that if the two systems are not precisely
aligned the leap second will appear to occur at different time from a
outside observer. That will result that the system that first implements
the leap second will appear to be out of sync with 1 second until the
second system also performs the leap second. Thus you suddenly see a 1
second sync correction that the receiver system might start correct for,
then that difference disappears when the other system also have had its
leap second event. Thus resulting in adjusting back again.

The above can cause different media streams to be out of sync at the
receiver for the time when only one of the media stream's SR has been
delivered.

I would note that leap seconds are rare. They have occurred 24 times
since 1970. And there has been only 2 during the 2000 decade.

>From my perspective, unless you have a really high performance
application, the leap second event will at most cause some sync
adjustments with potentially media out of sync that will be corrected as
soon as both sender and receiver has passed the leap second event and
SRs has been delivered in both cases.

I think the reasonable thing to do is simply to ignore SRs that indicate
an approximately 1 second adjustment on a media stream when in close
proximity to a leap second event. This would works fine as long as the
two involved nodes would not be more out of sync than the guard period
where this algorithm is active.

Cheers

Magnus Westerlund

---

From: Kevin Gross <[email-masked]>
Date: Tue, 20 Sep 2011 08:45:53 -0600

Magnus,

Thanks for thinking this through. The situation is worse if one of the
system clocks has a bad leap-second implementation. In that case, it could
be until the next NTP clock update before things get back to normal. On the
other hand I think if senders and receivers are all aware where the leap
second lives, and we make appropriate recommendations, a system can glide
through it without disruption. On the third hand, I'm not convinced
leap-second awareness for media applications is a reasonable requirement.

Things certainly are easier on a TAI timebase. I started picking into this
because I want to use IEEE 1588 time instead of NTP for some work I'm doing.
I figured it would be best for interoperability if I recommended translating
the 1588 timebase to the NTP epoch. When I realized that NTP timestamps were
UTC, it scuttled that idea but also opened this can of worms.

Kevin Gross

---

From: Colin Perkins <[email-masked]>
Date: Tue, 20 Sep 2011 23:21:03 +0100

I guess I'm confused. RTP was intended to use NTP *format* timestamps, but intentionally said nothing about synchronisation to any particular time source. I don't think it's valid to assume that the NTP format timestamps conveyed in RTP are synchronised to UTC, TAI, or anything else, *unless you have some explicit signalling to state that*.

Colin

On 20 Sep 2011, at 15:45, Kevin Gross wrote:
> Magnus,
> 
> Thanks for thinking this through. The situation is worse if one of the system clocks has a bad leap-second implementation. In that case, it could be until the next NTP clock update before things get back to normal. On the other hand I think if senders and receivers are all aware where the leap second lives, and we make appropriate recommendations, a system can glide through it without disruption. On the third hand, I'm not convinced leap-second awareness for media applications is a reasonable requirement.
> 
> Things certainly are easier on a TAI timebase. I started picking into this because I want to use IEEE 1588 time instead of NTP for some work I'm doing. I figured it would be best for interoperability if I recommended translating the 1588 timebase to the NTP epoch. When I realized that NTP timestamps were UTC, it scuttled that idea but also opened this can of worms.
> 
> Kevin Gross
> 
> 
> On Tue, Sep 20, 2011 at 2:02 AM, Magnus Westerlund <[email-masked]> wrote:

-- 
Colin Perkins
http://csperkins.org/

---

From: Kevin Gross <[email-masked]>
Date: Tue, 20 Sep 2011 17:17:54 -0600

Well, that would fix things. By my reading, RFC 3550 is not clear on this
however. I'm not sure trying to figure out the original intent of the RFC
will help us resolve things because nowhere in the text do I see any
indications that the RFC authors gave consideration to the NTP leap second
issue.

The RFC does say "Wallclock time (absolute date and time) is represented
using the *timestamp format* of the Network Time Protocol (NTP), which is in
seconds relative to 0h UTC on 1 January 1900." (emphasis on *timestamp
format* mine) Since it doesn't say anything about leap seconds, you could
interpret it as Dave Singer and Colin Perkins have to mean actual seconds
elapsed.

But a couple sentences later there's, "Running NTP may be useful for
synchronizing streams transmitted from separate hosts." Again, no mention of
leap-seconds but here, since we're talking about actual NTP (as opposed to
"NTP timestamp format"), wouldn't you be inclined to assume that leap
seconds are included in timestamps in this suggested implementation?

I have already determined that TAI time is best for my application. If
anyone knows of any existing signaling mechanism I can use to communicate
this to receivers (e.g. specific SDP a= records), I
would welcome suggestions.

Kevin Gross

On Tue, Sep 20, 2011 at 4:21 PM, Colin Perkins <[email-masked]> wrote:

> I guess I'm confused. RTP was intended to use NTP *format* timestamps, but
> intentionally said nothing about synchronisation to any particular time
> source. I don't think it's valid to assume that the NTP format timestamps
> conveyed in RTP are synchronised to UTC, TAI, or anything else, *unless you
> have some explicit signalling to state that*.
>
> Colin
>
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 21 Sep 2011 10:41:57 +0800

I am not sure Precision Time protocol defined in IEEE1588 is subject to leap seconds, but I am aware GPS and TAI are two timescales that don't follow leap seconds.
So one solution to overcome  leap seconds is to use GPS as clocksource and convert GPS time to NTP timestamp. Otherwise manually updated and maintained leap seconds table
will be used to correct UTC time and NTP time when leap seconds occurs.

Also I am aware that there is long debate in ITU-T Studay Group 7 regarding abolishing leap seconds. It was said that in 2017, the leap seconds will not be used. UTC will be continuous 
timescale. so shall we really need to be worried about this issue?

Regards!
-Qin

  ----- Original Message ----- 
  From: Kevin Gross 
  To: Colin Perkins 
  Cc: Magnus Westerlund ; [email-masked] ; Marshall Eubanks 
  Sent: Wednesday, September 21, 2011 7:17 AM
  Subject: Re: [AVTCORE] Leap seconds

  Well, that would fix things. By my reading, RFC 3550 is not clear on this however. I'm not sure trying to figure out the original intent of the RFC will help us resolve things because nowhere in the text do I see any indications that the RFC authors gave consideration to the NTP leap second issue.

  The RFC does say "Wallclock time (absolute date and time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900." (emphasis on timestamp format mine) Since it doesn't say anything about leap seconds, you could interpret it as Dave Singer and Colin Perkins have to mean actual seconds elapsed.

  But a couple sentences later there's, "Running NTP may be useful for synchronizing streams transmitted from separate hosts." Again, no mention of leap-seconds but here, since we're talking about actual NTP (as opposed to "NTP timestamp format"), wouldn't you be inclined to assume that leap seconds are included in timestamps in this suggested implementation?

  I have already determined that TAI time is best for my application. If anyone knows of any existing signaling mechanism I can use to communicate this to receivers (e.g. specific SDP a= records), I would welcome suggestions.

  Kevin Gross

    Colin

------------------------------------------------------------------------------

---

From: David Singer <[email-masked]>
Date: Wed, 21 Sep 2011 09:32:56 -0700

> I guess I'm confused. RTP was intended to use NTP *format* timestamps, but intentionally said nothing about synchronisation to any particular time source. I don't think it's valid to assume that th…

Yes, what RTP needs for its operation is correct measurement of interval durations.

Indeed, I think that for RTP purposes it's important that taking two sender reports -- RTP/'NTP' timestamp pairs -- we can form the difference between the two RTP values, and the two NTP values, and determine, for example, if the source's RTP clock is running slightly fast or slow.  If the NTP interval incorrectly counts seconds, this could be ... confusing.

David Singer

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 21 Sep 2011 12:43:24 -0400

> Yes, what RTP needs for its operation is correct measurement of interval

And I don't think that is what you are going to get if the interval crosses
a leap second.

Regards
Marshall

> Indeed, I think that for RTP purposes it's important that taking two sender
> reports -- RTP/'NTP' timestamp pairs -- we can form the difference between
> the two RTP values, and the two NTP values, and determine, for example, if
> the source's RTP clock is running slightly fast or slow.  If the NTP
> interval incorrectly counts seconds, this could be ... confusing.
>
>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Sep 2011 18:08:10 +0100

Dave, Kevin,

It might be worth you getting together to write a draft on this, since you seem to be converging on points that aren't immediately obvious from reading RFC3550.

> Indeed, I think that for RTP purposes it's important that taking two sender reports -- RTP/'NTP' timestamp pairs -- we can form the difference between the two RTP values, and the two NTP values, an…

Yes, agreed. This is probably something that should be documented in a draft, rather than being implied (unclearly) by RFC3550.

On 21 Sep 2011, at 00:17, Kevin Gross wrote:
...
> I have already determined that TAI time is best for my application. If anyone knows of any existing signaling mechanism I can use to communicate this to receivers (e.g. specific SDP a= records), I…

I don't know of any such mechanism, but it sounds like it would be useful to define one.

-- 
Colin Perkins
http://csperkins.org/

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 21 Sep 2011 13:13:26 -0400

On Tue, Sep 20, 2011 at 7:17 PM, Kevin Gross <[email-masked]> wrote:

> using the *timestamp format* of the Network Time Protocol (NTP), which is
> in seconds relative to 0h UTC on 1 January 1900." (emphasis on *timestamp
Yes, I don't know why leap seconds aren't treated as are the time zones and
DST (i.e., instead of keeping UTC and displaying UTC + Z, you would keep TAI
and display TAI + L  + Z). I urged that many years ago, but got absolutely
no traction.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 21 Sep 2011 16:56:36 -0400

On Wed, Sep 21, 2011 at 4:07 PM, Frederick, Ron
<[email-masked]>wrote:

> On Sep 21, 2011, at 10:13 AM, Marshall Eubanks wrote:
> On Tue, Sep 20, 2011 at 7:17 PM, Kevin Gross <[email-masked]
> <mailto:[email-masked]>> wrote:
> using the timestamp format of the Network Time Protocol (NTP), which is in
> seconds relative to 0h UTC on 1 January 1900." (emphasis on timestamp format
> mine) Since it doesn't say anything about leap seconds, you could interpret
> it as Dave Singer and Colin Perkins have to mean actual seconds elapsed.
>
> this to receivers (e.g. specific SDP a= records), I would welcome
> suggestions.
>
>
> It sounds like what we would really want is to have RTP's timestamp is in
> NTP format with a timebase of 1 January 1900 0h TAI instead of UTC (which
> are actually the same time, since that date predates any added leap
> seconds). The challenge I see, though, is that operating system functions
> which applications are likely to use to get wallclock time are likely to
> return UTC, not TAI, and short of hardcoding a schedule of leap-seconds in
> the applications it will be difficult to convert back. Even then, if the
> system really does "freeze" the time it returns for a second during a leap
> second, there's no way to recover the correct TAI time and strange results
> will be seen when an SR is generated during that second.
> --
>

The 800 kg elephant in the room is of course the suspicion that different
implementations do different things during that second.

I know back when I was doing VLBI ops the policy was, "don't schedule  an
observation over a leap second."  Media doesn't always
have that luxury.

Regards
Marshall

> Ron Frederick
> [email-masked]<mailto:[email-masked]>
>
>

---

From: David Singer <[email-masked]>
Date: Wed, 21 Sep 2011 17:08:21 -0700

On Sep 21, 2011, at 13:56 , Marshall Eubanks wrote:

> 
> 
> On Wed, Sep 21, 2011 at 4:07 PM, Frederick, Ron <[email-masked]> wrote:
> On Tue, Sep 20, 2011 at 7:17 PM, Kevin Gross <[email-masked]<mailto:[email-masked]>> wrote:
> Yes, I don't know why leap seconds aren't treated as are the time zones and DST (i.e., instead of keeping UTC and displaying UTC + Z, you would keep TAI and display TAI + L  + Z). I urged that many years ago, but got absolutely no traction.
> 
> It sounds like what we would really want is to have RTP's timestamp is in NTP format with a timebase of 1 January 1900 0h TAI instead of UTC (which are actually the same time, since that date predates any added leap seconds). The challenge I see, though, is that operating system functions which applications are likely to use to get wallclock time are likely to return UTC, not TAI, and short of hardcoding a schedule of leap-seconds in the applications it will be difficult to convert back. Even then, if the system really does "freeze" the time it returns for a second during a leap second, there's no way to recover the correct TAI time and strange results will be seen when an SR is generated during that second.
> --
> 
> The 800 kg elephant in the room is of course the suspicion that different implementations do different things during that second.
> 
> I know back when I was doing VLBI ops the policy was, "don't schedule  an observation over a leap second."  Media doesn't always 
> have that luxury.

Yes, I agree.

I think the easy fix is to clarify in RTP that the time in RTP sender reports always increments by one second for every second that elapses, such that subtracting any pair of these gives a true count of the number of seconds in between the two events.  This is consistent with the permission that one can use any clock as the source of these timestamps; NTP sync is not required.

Then a footnote to the effect that care should be taken with leap seconds if either these timestamps are derived from a 'civil time' clock that provides a timestamp in calendar format, or if the timestamps are converted to calendar format, e.g. for display purposes.

David Singer

---

From: Qin Wu <[email-masked]>
Date: Thu, 22 Sep 2011 18:11:07 +0800

Hi,
I think this is a good proposal since this helps RTP node to know if leap seconds really affect itself. The questions are:
Does this help the RTP node to fix leap seconds? what RTP node will do if it knows the leap seconds affect itself?
Another questions are if we rely on two continuous sender reports, what if the second sender report in them  is lost 
during leap seconds event? what if the seond sender report is delayed due to congestion during the leap seconds event?
How it is accurate?

Regards!
-Qin

  ----- Original Message ----- 
  From: David Singer 
  To: Colin Perkins 
  Cc: Magnus Westerlund ; Marshall Eubanks ; [email-masked] 
  Sent: Thursday, September 22, 2011 12:32 AM
  Subject: Re: [AVTCORE] Leap seconds

    Colin

      Kevin Gross

        Cheers

        Magnus Westerlund

      -- 
      Kevin Gross

      +1-303-447-0517
      Media Network Consultant

    -- 
    Colin Perkins
    http://csperkins.org/

  David Singer

---

From: "Frederick, Ron" <[email-masked]>
Date: Wed, 21 Sep 2011 20:07:02 +0000