Re: [TICTOC] NSH Timestamp

"Browne, Rory" <rory.browne@intel.com> Wed, 28 October 2015 10:15 UTC

Return-Path: <rory.browne@intel.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E201B4EDC; Wed, 28 Oct 2015 03:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YOWsTufEdMJ; Wed, 28 Oct 2015 03:15:31 -0700 (PDT)
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 6498D1B4EDE; Wed, 28 Oct 2015 03:15:31 -0700 (PDT)
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 28 Oct 2015 03:15:31 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.20,209,1444719600"; d="scan'208";a="821316206"
Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga001.fm.intel.com with ESMTP; 28 Oct 2015 03:15:30 -0700
Received: from irsmsx108.ger.corp.intel.com ([169.254.11.138]) by IRSMSX102.ger.corp.intel.com ([169.254.2.98]) with mapi id 14.03.0248.002; Wed, 28 Oct 2015 10:15:29 +0000
From: "Browne, Rory" <rory.browne@intel.com>
To: Tal Mizrahi <talmi@marvell.com>, "sfc@ietf.org" <sfc@ietf.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: NSH Timestamp
Thread-Index: AdENsicJjhUXF3fsRGKpi9V4P6fQMwBbxK5QAHDb19AAHhd7gAAAEiIgAAGOwgA=
Date: Wed, 28 Oct 2015 10:15:28 +0000
Message-ID: <798BB24857DDC040825B6C22A8D797C11BC015FB@IRSMSX108.ger.corp.intel.com>
References: <798BB24857DDC040825B6C22A8D797C11BC009CB@IRSMSX108.ger.corp.intel.com> <e79f0ef0780d45768257d3ebd08f9866@IL-EXCH01.marvell.com> <798BB24857DDC040825B6C22A8D797C11BC0138B@IRSMSX108.ger.corp.intel.com> <e1a643bedf4d492093aa6d732e3f25b7@IL-EXCH01.marvell.com>
In-Reply-To: <e1a643bedf4d492093aa6d732e3f25b7@IL-EXCH01.marvell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [163.33.239.182]
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tictoc/2hw32Ob6T0xOQaOk4b18L8V4-mI>
X-Mailman-Approved-At: Sat, 31 Oct 2015 10:46:02 -0700
Subject: Re: [TICTOC] NSH Timestamp
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 28 Oct 2015 10:15:32 -0000

More inline Tal


BR Rory

-----Original Message-----
From: Tal Mizrahi [mailto:talmi@marvell.com] 
Sent: Wednesday, October 28, 2015 9:05 AM
To: Browne, Rory; sfc@ietf.org; tictoc@ietf.org
Subject: RE: NSH Timestamp

Hi Rory,

Thanks for the detailed response.

A few follow-up questions/comments:


>1.      The draft currently does not clarify the use case. While the 
>draft describes how the timestamp is inserted into the NSH, I could not 
>find a description of how the timestamp is *used*, and what is the 
>expected accuracy. It is hard to assess whether the solution is 
>adequate without understanding the requirement.
>
>RB: We want to be able to tell if a VNF or and underlay segment is 
>misbehaving on subscriber traffic. Expected accuracy in the low 10s of 
>microseconds.

10s of microsecond: do you see this as a requirement, or is it a best practice based on what common IEEE 1588 equipment can provide?
Can you please give a short example that explains why 10s of microseconds is necessary?
I would strongly recommend to add a section in the draft (preferably at the beginning) that would describe these use cases and accuracy requirements in detail.

RB: That's probably a good idea. 10s of microsecond is a requirement as the transit times we are seeing for reasonably simple VNFs is in the order of low 100s of microseconds to over a millisecond depending on packet size, load etc. So an accuracy in the low 10s of microseconds should be ample to indicate user plane performance issues. We will know more once this is coded and tested.


>.        Could you explain why you require very accurate frequency 
>synchronization, but inaccurate time synchonization (section 3.1)?
>
>RB: The time of day used at the start of the header does not have to be 
>very accurate (Can be 10's of ms out for example) the PTP needs to me 
>more accurate (in 10s of microsecond range)

- Can you please clarify this point: what is the difference between how the timestamp-at-the-start-of-the-header is used and how the other timestamps are used?
- PTP provides the time-of-day with a microsecond accuracy, so why would we need an additional less accurate time reference?

RB: The reasoning behind this is if the classifier does not support 1588, but does support NTP. This seems to be the case for some vendors at least with appliance based SCLs.


>
>.        The format of the fields "UTC Reference", "Ingress Timestamp", 
>and "Egress Timestamp" is not clear.
>RB: Can you explain
>

Based on your response, I understand that <UTC Reference> uses the NTP 64-bit timestamp format.
Is the same format used also for <Ingress Timestamp> and <Egress Timestamp>? This should be defined explicitly in the draft.

RB: Agreed

Cheers,
Tal.
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.