Re: [TICTOC] Delay and delay variation as a function of network path computation contribution to ccamp
Al Morton <acmorton@att.com> Wed, 10 November 2010 06:52 UTC
Return-Path: <acmorton@att.com>
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 7FFDF3A698C for <tictoc@core3.amsl.com>; Tue, 9 Nov 2010 22:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.821
X-Spam-Level:
X-Spam-Status: No, score=-104.821 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 1ptgXt3VOrF1 for <tictoc@core3.amsl.com>; Tue, 9 Nov 2010 22:52:00 -0800 (PST)
Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 7606D3A696A for <tictoc@ietf.org>; Tue, 9 Nov 2010 22:52:00 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-13.tower-146.messagelabs.com!1289371934!15388421!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [144.160.20.145]
Received: (qmail 23544 invoked from network); 10 Nov 2010 06:52:15 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-13.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Nov 2010 06:52:15 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oAA6qXhW011879 for <tictoc@ietf.org>; Wed, 10 Nov 2010 01:52:33 -0500
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oAA6qSna011841 for <tictoc@ietf.org>; Wed, 10 Nov 2010 01:52:28 -0500
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oAA6q9tk010209 for <tictoc@ietf.org>; Wed, 10 Nov 2010 01:52:09 -0500
Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oAA6q5Wt010115 for <tictoc@ietf.org>; Wed, 10 Nov 2010 01:52:06 -0500
Message-Id: <201011100652.oAA6q5Wt010115@alpd052.aldc.att.com>
Received: from acmt.att.com (vpn-135-70-176-31.vpn.mwst.att.com[135.70.176.31](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101110065204gw1004lksde>; Wed, 10 Nov 2010 06:52:05 +0000
X-Originating-IP: [135.70.176.31]
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 10 Nov 2010 01:52:27 -0500
To: Greg Dowd <GDowd@symmetricom.com>, tictoc@ietf.org
From: Al Morton <acmorton@att.com>
In-Reply-To: <CB45EB047BD43041BF1F4CC7D6DB21BF05B1C0AE@sjmail2.symmetric om.com>
References: <CB45EB047BD43041BF1F4CC7D6DB21BF05B1C0AE@sjmail2.symmetricom.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Subject: Re: [TICTOC] Delay and delay variation as a function of network path computation contribution to ccamp
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/mail-archive/web/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>
X-List-Received-Date: Wed, 10 Nov 2010 06:52:01 -0000
GMPLS extensions to communicate latency as a TE performance metric
draft-wang-ccamp-latency-te-metric-01
http://tools.ietf.org/html/draft-wang-ccamp-latency-te-metric-01" rel="nofollow"> http://tools.ietf.org/html/draft-wang-ccamp-latency-te-metric-01
Heres a submission defining support for communicating node/path latency and variation. This is the type of effort I think we could incorporate into our discussions of synch network detection/construction.
Any comments?
Based on a quick look, this requires one-way measurement
and therefore, some degree of synchronization for accuracy.
It would be good to keep the "round-trip" option
completely out of this capability - and specify that "one-way"
latency must not be derived from arithmetic on a round-trip (RT)
measurement result. In particular, the delay variation
derived from RT/2 will not be useful, AFAIK.
my 2 cents,
Al
- [TICTOC] Delay and delay variation as a function … Greg Dowd
- [TICTOC] MPLS-TP loss delay draft Stewart Bryant
- Re: [TICTOC] Delay and delay variation as a funct… Al Morton