[TICTOC] Comments on architecture doc

"STUART VENTERS" <stuart.venters@adtran.com> Wed, 06 August 2008 21:38 UTC

Return-Path: <tictoc-bounces@ietf.org>
X-Original-To: tictoc-archive@optimus.ietf.org
Delivered-To: ietfarch-tictoc-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDAB3A6925; Wed, 6 Aug 2008 14:38:40 -0700 (PDT)
X-Original-To: tictoc@core3.amsl.com
Delivered-To: tictoc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7719D3A6984 for <tictoc@core3.amsl.com>; Wed, 6 Aug 2008 14:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.955
X-Spam-Level:
X-Spam-Status: No, score=-4.955 tagged_above=-999 required=5 tests=[AWL=1.643, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byRiMynQ9G8B for <tictoc@core3.amsl.com>; Wed, 6 Aug 2008 14:38:38 -0700 (PDT)
Received: from p02c12o148.mxlogic.net (p02c12o148.mxlogic.net [208.65.145.81]) by core3.amsl.com (Postfix) with ESMTP id 1C6793A68F7 for <tictoc@ietf.org>; Wed, 6 Aug 2008 14:38:34 -0700 (PDT)
Received: from unknown [208.251.151.99] by p02c12o148.mxlogic.net (mxl_mta-5.6.1-1) with SMTP id ef91a984.3514428336.12110.00-060.p02c12o148.mxlogic.net (envelope-from <stuart.venters@adtran.com>); Wed, 06 Aug 2008 15:39:10 -0600 (MDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 06 Aug 2008 16:38:58 -0500
Message-ID: <8F242B230AD6474C8E7815DE0B4982D70B99D4C6@EXV1.corp.adtran.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on architecture doc
Thread-Index: Acj4DNWnl2rNwML0TQuO7qfXnw3F7A==
From: STUART VENTERS <stuart.venters@adtran.com>
To: tictoc@ietf.org
X-Spam: [F=0.1000000000; S=0.100(2008062001)]
X-MAIL-FROM: <stuart.venters@adtran.com>
X-SOURCE-IP: [208.251.151.99]
Subject: [TICTOC] Comments on architecture doc
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1895399310=="
Sender: tictoc-bounces@ietf.org
Errors-To: tictoc-bounces@ietf.org

These are from reading the draft-stein-tictoc-modules-02
  (Which is overall an nice job)


Section 2.3 second paragraph
    another category affecting observed packet arrival times is inaccuracies in the implementation.
      (Especially in the ability to accurately timestamp incoming and outgoing packets.)


Section 3.1 fifth paragraph
   I'm concerned about the words 'overriding design consideration'.
   In theory using an optimal frequency protocol and an optimal time protocol could result in needing two separate protocols to get time.
   I think a single 'compromise' protocol might be better than 2 'optimal' protocols for the dual application of time.


Section 4.2 third paragraph
   Seems like another bullet might be
    'analysis of the stability of the packet path to and from potential masters'
   (I'm not sure if this would be a third bullet or just replace the second one.)


Section 5.2 third paragraph
    Another 2 likely suspects are
      'algorithm and implementation quality'
      'timing packet rate'
    (Maybe given a good implementation and a specific application requirement,
       success depends on a suitable balance between the oscillator, packet statistics, and packet rate.)


Section 5.3 first paragraph last sentence
    and since PDV values are generally larger than our application's timing accuracy requirements.


Section 5.4 first paragraph
    Asymmetry is ok if you know about it apriori and can compensate for it.
    uncompensated asymmetry still causes offset errors


_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc