[AVTCORE] draft-ietf-avtcore-idms-01 leap seconds

[Kevin Gross <[e-mail]>]

I've prepared the following paragraphs which discuss the issue and
describe measures required to avoid leap second problems. I propose
this be inserted into section 8 of draft-ietf-avtcore-idms-01. A
subset of these recommendations are applicable to RFC 3550
applications that make use of the NTP timestamp in sender reports. I’d
be happy to propose corresponding revisions to RFC 3550 once we’ve
ironed out IDMS.

"IDMS implementation is simplified by using a clock reference with
timescale which does not include leap seconds. IEEE 1588, GPS and
other TAI (Inernational Atomic Time) references do not include leap
seconds. NTP time, operating system clocks and other UTC (Coordinated
Universal Time) references include leap seconds (though the ITU is
studying a proposal which could eventually eliminate leap seconds from
UTC). If a timescale with leap seconds is used for IDMS, receivers
must take care not to generate any IDMS XR reports in the immediate
vicinity of the leap second. Synchronization servers must ignore any
such reports that may inadvertently generated. Senders using a
leap-second-bearing reference must not generate sender reports
containing an origination NTP timestamp in the vicinity or a leap
second. Receivers should ignore timestamps in any such reports
inadvertently generated. Receivers working to a leap-second-bearing
reference must also be careful to take leap seconds into account if a
leap second occurs between the time a RTP packet is originated and
when it is to be presented.

"Leap seconds are potentially scheduled at the end of the last day of
December and June each year. NTP inserts a leap second at the
beginning of the last second of the day. This results in the clock
freezing for one second immediately prior to the last second of the
affected day. Most system clocks insert the leap second at the end of
the last second. This results in repetition of the last second of the
day. Generating or using timestamps during the entire last second of a
day on which a leap second has been scheduled should therefore be
avoided. Note that the period to be avoided has a real-time duration
of two seconds. It is also important that all participants correctly
implement leap seconds and have a working communications channel to
receive notification of leap second scheduling. Without prior
knowledge of leap second schedule, NTP servers and clients may be
offset by exactly one second with respect to their UTC reference. This
potential discrepancy begins when a leap second occurs and ends when
all participants receive a time update from a server or peer. Such a
long-lived discrepancy can be particularly disruptive to RTP and IDMS
operation."

On Fri, Sep 23, 2011 at 9:48 AM, Kevin Gross <[e-mail]> wrote:
>
> Qin,
> Thank you for this reminder. I have revisited the IDMS draft and am reminded that it does define a means to specify wallclock source. I think it could use a little work but it is an excellent start.
> The IDMS draft doesn't mention leap seconds but since it is a draft, that can easily be changed!
> I will contact Ray Brandenburg and see if I can offer to help with this.
> I think it would still be useful to add some leap second discussion to 3550 but I would propose to work it out under IDMS first since IDMS receivers is where these NTP timestamps will be most relied upon.
> Kevin Gross
>
> On Thu, Sep 22, 2011 at 3:52 AM, Qin Wu <[e-mail]> wrote:
>>
>> Hi, Kevin:
>> Regarding how to know where the leap seconds are, I think, you may follow two potential ways:
>> 1. you may take take David's suggestion, compare the NTP/RTP pairs in the two consecutive SRs to know if exception happen.
>> 2. you may look at IDMS draft, the parameter clock source is  defined in SDP to signal the source for clock
>>    synchronization. Using this parameter, the receiver may know where the leap seconds are.
>> Does this make sense?
>>
>> Regards!
>> -Qin