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

["Brandenburg, R. (Ray) van" <[e-mail]>]

Hi all,

So far I haven't seen any comments on Kevin's proposal (detailed below) on the Leap Second issue . If you have any comments or opinions on the changes/updates Kevin proposes, please send them by Sunday at the latest.

In the absence of any further comments I will assume that no one objects and I will update the IDMS draft and publish the updated version before the deadline on Monday.

Best regards,

Ray van Brandenburg


From: [e-mail] [mailto:[e-mail]] On Behalf Of Kevin Gross
Sent: dinsdag 25 oktober 2011 21:22
To: [e-mail]
Subject: [AVTCORE] draft-ietf-avtcore-idms-01 leap seconds

Apologies if you've already received this. I first sent it out 19 October but it apparently didn't make it through for some reason. Ray Brandenburg is in the process of preparing a new IDMS draft and would appreciate any comments on my leap seconds proposal before including it.

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

--
Kevin Gross
[phone]<tel:%2B1-303-447-0517>
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org>


This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer