Subject: [TICTOC] Draft TICTOC WG charter

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Jan 2007 16:29:33 +0000

Description of Working Group:

There is an emerging need to distribute highly accurate
time and frequency information over IP and over MPLS
packet switched networks (PSNs).

Network transport service providers and their users are
seeking to rationalize their networks by migrating their
existing services and platforms onto IP or MPLS enabled
IP packet switched networks (PSN). In some cases this
migration is only possible if the user equipment can be
provided with the high quality frequency service to
replace the timing (frequency) service provided to all
users of TDM networks. These applications include the
TDM emulation techniques developed by the PWE3 WG, and
the radio systems used in mobile phone networks.

There are applications that need require time with a
greater precision than can be achieved with the current
version of NTP. These applications span a range of
industries: telecommunications, financial, test and
measurement, government, industrial etc. The early
work in these areas indicates that the availability
of high accuracy time as a commodity allows the use
of techniques that were previously impossible. High
quality time is therefore an enabler for new
distributed technology. The best-known example of
an application that requires high quality time in
the telecommunications sector is the need to measure
one-way packet delay. Another network example is
the need to synchronize device operation of media
types at the MAC layer.

The TICTOC WG will be responsible for identifying
and satisfying the time and frequency needs of
the various services that need to be supported over
IP and MPLS PSNs.

The TICTOC WG will co-ordinate with the PWE3 and NTP
WGs.

WG Objectives:

The objectives of a WG are:

To compile the time and frequency requirements of
various services that need to be supported over the
PSN.

To research the influence of measurable network
characteristics on the achievable performance of
clock distribution.

To propose algorithms that approach optimal clock
recovery performance over existing networks, and yet
may take advantage of network upgrades (should
these be available).

To propose a suitable clock distribution protocol
that can run over the existing network architecture.
This protocol may have different operational modes,
depending on whether time or frequency distribution
is required.

Goals and Milestones:
XXXX	  	TICTOC WG started
XXXX            TICTOC requirements published
XXXX            TICTOC architecture published

Other goals to be established

Internet-Drafts:

RFCs:

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

---

From: "Ron Cohen" <[email-masked]>
Date: Thu, 18 Jan 2007 19:37:16 +0200

Stewart,

Can we add to the WG objectives to include the development of the timing
distribution solution (i.e. beyond the timing distribution protocol)?
This will include issues like discovery, management, congestion control,
and any other possible interaction with other IETF work. The WG would
than work with other WGs to develop extension to protocols if required.
Possible such extensions expected are for LDP, BGP, MPLS etc.

In addition I'm a bit nervous having the 'propose algorithms' and
'research the influence of measurable networks.." objectives. This may
divert the focus of the WG into IRTF work. 

Best
Ron

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 6:30 PM
To: [email-masked]
Subject: [TICTOC] Draft TICTOC WG charter

WG Objectives:

Goals and Milestones:
XXXX	  	TICTOC WG started

Internet-Drafts:

RFCs:

-- 
This message has been scanned for viruses and
dangerous content by ESVA, and is
believed to be clean.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Jan 2007 17:47:47 +0000

> distribution solution (i.e. beyond the timing distribution protocol)?

Yes - thanks for picking that I - I see that as a major value
add from the IETF

> Possible such extensions expected are for LDP, BGP, MPLS etc.

Yep - will update

> divert the focus of the WG into IRTF work. 

I agree that we need to be careful and maybe we should hand some of
this off to IRTF, but the knowledge of the need to do this comes
from the IETF. I guess we would start with a requirements document
listing issues that needed to be better understood and then figure
out whether they were research or engineering.

- Stewart

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 22 Jan 2007 09:31:38 +0200

> divert the focus of the WG into IRTF work.

Ron, 

I think that we need to understand our objectives
and how network degradations influence timing distribution accuracy 
in order to develop a solution.

If you look at NTP you see a tremendous effort being expended
in battling what was seen there as the most important network
degradations,
namely outliers ("falsetickers", "popcorn spikes") and asymmetric
delays.
You don't see anything similar in 1588.

In 1588 strong emphasis is placed on getting the timestamp right
(folow-up messages), but you don't see anything similar in NTP.

Why are the two so different ?

Basically because they are trying to solve different problems 
and assume different network models.

So, the first step MUST be to make a list of objectives for X
applications
and a study of network degradations on Y scenarios that we intend to
address.

Only then can we go about designing protocols or solutions.

Y(J)S

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 22 Jan 2007 06:36:34 -0500

I am fuzzy about the "one way delay".

"The best-known example of
> one-way packet delay."

I do not know of a good way to measure one way delay through the
network unless both ends have independent time coming from, e.g.,  
GPS, due to the possibility of network asymmetries.  (Taking the RTT  
and dividing by two is not sufficient.)

Do we plan to

- enable network paths with, say, GPS at both ends to determine the  
one way delay through the network (which sounds fairly easy) or to

- do this entirely autonomously, solving the problem of network  
asymmetry. If so, how ? Send references, please.

Regards
Marshall

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Jan 2007 12:40:00 +0000

Marshall Eubanks wrote:

> network unless both ends have independent time coming from, e.g.,  GPS, 
> due to the possibility of network asymmetries.  (Taking the RTT  and 
> dividing by two is not sufficient.)
> 
> Do we plan to
> 
> - enable network paths with, say, GPS at both ends to determine the  one 
> way delay through the network (which sounds fairly easy) or to
> 

Firstly you only need to solve the problem to the point where
the asymmetry error is small compared to the measurement interval,
and it only needs to be solved within the topology of interest.
Outside that zone, sure you need help from GNSS, but you would
like to limit the number of GNSS points in you network.

Secondly you can break the causes of asymmetry down to a number
of components and either eliminate the issue (for example
path asymmetry can be addressed in routing), or address it
by calibration, for example platform forwarding asymmetry is
a platform parameter.

- Stewart