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

Kevin Gross <kevin.gross@avanw.com> Tue, 25 October 2011 19:22 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 ADA161F0C44 for <avt@ietfa.amsl.com>; Tue, 25 Oct 2011 12:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.428
X-Spam-Level: *
X-Spam-Status: No, score=1.428 tagged_above=-999 required=5 tests=[AWL=-1.301, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=2.601, RDNS_NONE=0.1]
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 eV7yyh+lZ1fi for <avt@ietfa.amsl.com>; Tue, 25 Oct 2011 12:22:07 -0700 (PDT)
Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 71B291F0C3F for <avt@ietf.org>; Tue, 25 Oct 2011 12:22:03 -0700 (PDT)
Received: (qmail 29293 invoked by uid 0); 25 Oct 2011 19:22:02 -0000
Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy1.bluehost.com with SMTP; 25 Oct 2011 19:22:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:MIME-Version; bh=OU+hxP5m5KoTuRtbwv1sOTcPot4Fm6CZXRTZINHNovk=; b=V6UKy0JZUGg0z8/1GEtTRjNoYrok2PJ7WBG6oA/20S25HalXHNfK+BeEsh39x9bh+h0APE7AzP+Pbkh/j9+ndN6ixoYnDLHE4cu1BVL4lXLBlSBQvZ4W2uV4X+CE5Zle;
Received: from mail-fx0-f44.google.com ([209.85.161.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from <kevin.gross@avanw.com>) id 1RImZV-0000Gs-TJ for avt@ietf.org; Tue, 25 Oct 2011 13:22:02 -0600
Received: by faas12 with SMTP id s12so1024240faa.31 for <avt@ietf.org>; Tue, 25 Oct 2011 12:21:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.14.140 with SMTP id g12mr20399665faa.34.1319570519404; Tue, 25 Oct 2011 12:21:59 -0700 (PDT)
Received: by 10.223.93.202 with HTTP; Tue, 25 Oct 2011 12:21:59 -0700 (PDT)
Date: Tue, 25 Oct 2011 15:21:59 -0400
Message-ID: <CALw1_Q12H_s=EZ+pTq-k093M0jTFr_ajwQ+YnmuHrhsMWvp4Zg@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: avt@ietf.org
Content-Type: multipart/alternative; boundary=000e0cd25de810b01604b024746f
X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.161.44 authed with kevin.gross@avanw.com}
Subject: [AVTCORE] draft-ietf-avtcore-idms-01 leap seconds
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: Tue, 25 Oct 2011 19:22:17 -0000

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
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org