Subject: [TICTOC] comments on draft-frost-packet-timing-framework-00.txt

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 11 Mar 2008 21:33:09 +0100

In-line.
		
¨

Best regards,

- kurtis -

.8
 >
 >
 >1.   Introduction
 >
 >At IETF 68 (March 2007) the TICTOC BOF was held to discuss the
 >emerging need to distribute highly accurate time and frequency
 >information over IP and over MPLS packet switched networks (PSNs).  A
 >variety of applications require time and/or frequency information to a
 >precision which existing protocols cannot supply, and these are well
 >documented in the BOF's problem statement [TICTOC].
 >
 >Several other groups are working on related issues. For example, the
 >NTP Working Group in IETF is working on an upgrade of the long-
 >standing Network Time Protocol [NTPv4]. The IEEE has recently gone to
 >ballot on a revision of the Precision Time Protocol [IEEE1588v2]. The
 >ITU-T has also begun work on Synchronous Ethernet, a physical layer
 >technology for transfer of frequency across native Ethernet [G.8261].
 >
 >However, as [TICTOC] notes, none of these efforts are sufficient by
 >themselves to create a complete and robust time and frequency transfer
 >ecosystem in the IP and MPLS network environment.  This draft attempts
 >to document what else needs to be put in place in order to enable the
 >technology to deliver the performance necessary to meet the various
 >application requirements.  It is hoped that this will spawn a series
 >of other drafts to address each of the issues noted.
 >
 >
 >2.   Creating a Packet Timing Framework
 >
 >In order to create a suitable ecosystem for the adoption of packet
 >timing methods, the following elements need to be in place:
 >
 >  - the basic time transfer protocol (e.g. PTP or NTP)
 >
 >  - transport specification over the network layer protocol to be used

First of all, I find the use of "network layer protocol here a bit
ambigous, http://en.wikipedia.org/wiki/Network_layer. Also, I believe
that we normally describe packet formats over transport protocols and
that they are running over IPv4 and IPv6. IP will then work over any
frame format where there is a IPvN over spec for..

 >  - application profile, defining the various parameters and optional
 >    values to be used for the applications in mind

I assume this is an applicability document you are referring to?

 >  - network engineering guidelines for creating timing-grade network
 >    flows

I don't understand what this point means. 'timing-grade network
flows'. ???

If this means "The Internet MUST migrate to universal deployment of
Ethernet links with 1588 support ", I am dead against it. If it means
an operational analysis ala BCP regading what impacts, oversubcribing,
packet loss, etc might have I think it's reasonable but not high on
the todo list.

It's possible it means something else..:-)

 >  - service level specifications for timing-grade connections
 >
Again, don't understand. You mean requirements - or?

 >  - routing considerations, especially with regards to sensitivity of
 >    time alignment algorithms to the symmetry of the forward and
 >    reverse paths

This is the Internet. It will be asymmetric at one point or other.

 >  - redundancy considerations
 >
 >  - security considerations
 >
 >
 >3.   Framework Elements
 >
 >The discussion below assumes the use of PTP version 2 [IEEE1588v2] as
 >the base time transfer protocol. This is not meant to rule out the use
 >of any other protocol (e.g. NTP), but is meant to focus the
 >discussion. Similar requirements may be framed around the use of any
 >other suitable protocol.

I think this more foregoes a WG decision than focuses a discussion,at
least if the document assumes to address the entire charter of
TICTOC. The ITP document that me and Peter wrote, pretty much goes
through the same but at a higher level and with a somewhat more
agnositc view. Still, I agree that there is great value in documenting
various framwork approaches to the WG. Even better would be to try and
compare frameworks and pick the best if we believe one protocol fit's
all. If that process fails, we need to look at next steps. I believe
that is what the WG charter outlines. Mergeing the documents might
also be worth doing.

 >  3.1.       Basic time transfer protocol
 >
 >       PTP version 2 has now been defined in [IEEE1588v2].
 >
 >
 >  3.2.       Transport specifications

Transport in the IETF means transport protocols. TCP, UDP, SCPT,
etc. So not sure how relevant the second reference is then?

 >       [IEEE1588v2] includes normative appendices that defines the
 >       transport of PTP over both UDP/IPv4 and UDP/IPv6, amongst other
 >       protocols.
 >
 >       [PTP-MPLS] is the first draft of an attempt to define the
 >       operation of PTP over an MPLS pseudowire.  Further work will be
 >       required in the IETF to complete this specification.
 >

 >
 >  3.4.       Network engineering guidelines
 >
 >       Every network element (e.g. router or switch) in a packet
 >       network adds varying amounts of delay to the packet.  This
 >       variation is typically correlated to the load on that network
 >       element at the time, and especially to the shared load on the
 >       output port.
 >
 >       Therefore, there is some maximum limit on the number of network
 >       elements that a packet timing flow can traverse before being
 >       degraded beyond the point at which the recovered time or
 >       frequency is outside of the specification for the given
 >       application.
 >
 >       This maximum limit will change depending on:
 >       - stringency of the application requirements
 >       - stability and environment of the local oscillator at the
 >         time/frequency client device
 >       - load in the network
 >       - topology of the network
 >       - physical layer aspects of the network.
 >
 >       While the first two are outside the scope of the network
 >       planner, the remainder must be considered when planning a
 >       time/frequency service. It cannot be expected that such
 >       services will perform adequately over any arbitrary network.
 >       Guidelines will need to be provided for each application to
 >       help the network operator assess whether the network is capable
 >       of running the time/frequency service, and to engineer the
 >       network accordingly.

So, if this is what meant above. I would rewrite this to say that, "the
following network characteristics [...] will impact the timeing
distribution and the ability to do [...]. A timing protocol can not
recover beyond XXX under other conditions, and if a timing requirement
is beyond this, additional care is needed in network planning. Simply
because the above sounds prescribing in areas where we can't
presecribe.

 >  3.5.       Service level specifications
 >
 >       The traditional approach to specifying network performance has
 >       been to define a series of metrics such as packet loss and
 >       packet delay variation.  However, these metrics are not good
 >       predictors of how a packet timing scheme is going to perform.
 >       For instance, the packet delay variation metric is too
 >       abstract, since it doesn't take into account the distribution
 >       of delays, or the correlation of delays over a longer interval.
 >
 >       Recent research has examined the application to PDV of new
 >       metrics borrowed from synchronization standards such as TDEV
 >       and a modified version called minTDEV [minTDEV].  The goal is
 >       to define a metric that is both measurable and capable of
 >       continuous monitoring.  This can then form the basis of a
 >       service level specification for time/frequency services.
 >
 >       Further, the network operator needs to know how to tune the
 >       network to stay within the specified limit, since no operator
 >       is going to sign up to a service level specification that he
 >       has no control over.

I don't believe this is relevant to the framework.

 >  3.6.       Routing considerations
 >
 >       The basic method for calculating a time offset of a remote
 >       slave connected over a packet network makes an assumption that
 >       the network delays in each direction are the same.  Any
 >       asymmetry between the forward and reverse directions yields an
 >       error in the time offset estimation.
 >
Yes, but the Internet is asymmetric.

 >       While there may be various inferences that an algorithm can
 >       make concerning the size of that asymmetry, there are no
 >       currently known techniques for directly calculating its
 >       magnitude.  Therefore it is important that the routing is
 >       constrained to make the packet flow take the same path in each
 >       direction.  This in itself will not guarantee that the time
 >       delay is the same in each direction, but it should minimize any
 >       difference.

I don't think this is reasonable in any generic packet network. IT
might be in a specially taylored network but that should not be a
requirement in an IETF spec.

 >  3.7.       Redundancy considerations
 >
 >       Since synchronization is a critical function in many network
 >       applications, operators conventionally protect it from single
 >       points of failure.  Redundant sources of synchronization are
 >       normally provisioned, connected via diverse paths to prevent
 >       loss of synchronization at the end station.
 >
 >       This is also required in packet synchronization.  It may be
 >       necessary to provision alternative paths, or techniques such as
 >       fast re-route to ensure that connection between a time server
 >       and client devices is not lost for too long.

I believe this is a pure implemention choice and not a protocol design
choice. Again, we can make no assumption of the packet path.

 >  3.8.       Security considerations
 >
 >       Time and frequency services are a significant element of
 >       network infrastructure, and are critical for certain emerging
 >       applications.  The ability to disrupt network synchronization
 >       could be used as the key to disrupting an entire network, and
 >       especially any real-time services carried over the network.
 >
 >       Hence it is extremely important that time and frequency
 >       transfer services are protected from being compromised.
 >
 >       There are several possible threats to time and frequency
 >       services:
 >
 >       - acceptance of a false time or frequency server
 >
 >         This may enable a hacker to bring down critical services.

'hacker' is perhaps not proper security terminology :-)

 >         Hence it is particularly important to know where a source of
 >         packet timing is coming from, and whether it is genuine.
 >
 >       - excessive packet delay variation, such as might be caused by
 >         a targeted denial of service attack
 >
 >         Timing distribution is highly sensitive to packet delay, and
 >         thus can deteriorate under congestion conditions. When a
 >         service is disrupted by such means, the client needs to go
 >         into "holdover" mode, and its accuracy will consequently be
 >         degraded.
 >
 >         Work performed by the IETF PWE3 WG on congestion would seem
 >         to be applicable to this problem area.

I won't object to this text right now, but again - life is life. And
DDoS is part of it. So I think this text is a good pointer, but needs
to be elaborated.

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: "Tim Frost" <[email-masked]>
Date: Fri, 28 Mar 2008 10:37:22 -0700

Hi Kurtis,
I'm sorry, I've only just noticed that you posted some comments on my draft. Thanks for that, unfortunately I missed this in the slew of other messages around the recent meeting.

I've added some comments in line, stripping out some of the extraneous material.

Note that the main intention of this draft was not to create requirements for a protocol (we have more than enough of those, what with PTPv2 and NTPv4), but to identify the areas that needed further work in order to create all the elements of a successful and deployable eco-system for packet timing. 

In a sense, it was an early attempt at a "modules" draft before Stewart and Yaakov wrote theirs.  There may be good sense in merging the two, since there is a lot of overlap between them.  If you keep this in mind, it may make the draft more comprehensible.

Best regards,
Tim Frost

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kurt Erik Lindqvist
Sent: 11 March 2008 20:33
To: [email-masked]
Subject: [TICTOC] comments on draft-frost-packet-timing-framework-00.txt

In-line.
		
¨

Best regards,

- kurtis -

Tim: In the PTP spec, there are a number of "PTP over ..." extensions, including IPv4 and IPv6. Ron Cohen attempted to expand that with his "PTP over MPLS" draft, a little along the lines of a draft I wrote on timing pseudo-wires a couple of years ago (draft-frost-pwe3-timing-pw-reqs-01 - long since expired!)

The intention was to be vague and not rule anything out at this stage, we can do this as we refine and target the work.

Tim: No, this is a PTP profile (or something similar for NTP), as described in section 19 of the PTPv2 spec - or see Silvana's presentations from the last two TICTOC meetings for more information.

Tim: Clearly the internet is NOT going to migrate to universal deployment of Ethernet links with 1588 support. Nor should it - I agree with you here.
However, we do need to understand that applications for timing have performance requirements, and we need to understand what constraints that places on the packet network. 

A network that meets these constraints (for any given application) is a "timing-grade network". It doesn't refer to a technology, merely a set of performance constraints.

Tim: see above

Tim: Accurate time delivery will depend on reducing this asymmetry as much as possible. For example, cellular basestations will need time accuracy to within a couple of microseconds, which is seriously tight. If we can reduce the asymmetry via enhancements to routing protocols or by any other means within the scope of the internet, then we should consider these.

TICTOC. 

Tim: the draft was written before the charter, so may be out of date in some respects now. I have been approached since then to re-write the draft to include more reference to NTP - at the time I just wanted to get something out for discussion, so I wrote about what I knew, which was PTP.

The ITP document that me and Peter wrote, pretty much goes
through the same but at a higher level and with a somewhat more
agnositc view. 

Tim: Good. I still need to read your draft and see what feedback I can give.

Still, I agree that there is great value in documenting

Tim: Agreed.

Tim: OK, I agree some careful phrasing is necessary here. Operators hate this, they don't like to be told how to design their networks, but the performance of PTP and NTP is heavily dependent on the network. If they want a certain level of performance from timing protocols (in order to deliver a level of service to their customers), they need to follow certain guidelines.

Tim: It is critical, actually. If we can't guarantee a certain level of service from the network, we can't guarantee a level of service from the timing, and the application that is dependent on the timing won't run.

This is possibly one of the hardest problems in the space. The biggest question we get from customers wanting to deploy PTP or NTP is "under what conditions can I meet the performance requirements of application X?"

Coming up with a way to answer this question is key to the widespread adoption of packet timing in high precision wide-area applications.

What could be argued is that this might not be IETF's problem - it is possible that this work is better done in ITU (or even 3GPP, since one of the major applications is cellular basestation synchronization). In that case, it might not be part of the IETF framework, although it is still a problem that needs solving.

Tim: Packet timing protocols are not going to deliver the sort of precision timing performance we are talking about across the general internet.

This argument was rehearsed over and over in PWE3 - should pseudowires run over the general internet? To what level of fidelity should the service they carry be reproduced at the other end of the pseudowire? 

I can run PTP over the general internet, but I can't time a basestation over the internet, nor is any cellular operator who wants to stay in business going to attempt to do this. Does this mean it is not the IETF's problem? I don't think so, these are still going to run over an IP or MPLS network (i.e. under the IETF's design authority), but it may be tailored to the network's customers' requirements.

Tim: Agreed it is an implementation choice. I am not trying to design a protocol - we have that already. However, there is a lot of expertise in the IETF on technologies such as fast re-route that we can re-use here. I don't think it is a case of designing a protocol, but understanding how to use the protocols we already have.