Subject: [ippm] RFC 2679 : comment on time handling

From: Jerome Benoit <[email-masked]>
Date: Wed, 28 Apr 2010 00:10:59 +0200

3.5

"Since delay values will often be as low as the 100 usec to 10 msec
range, it will be important for Src and Dst to synchronize very
closely.  GPS systems afford one way to achieve synchronization to
within several 10s of usec.  Ordinary application of NTP may allow
synchronization to within several msec, but this depends on the
stability and symmetry of delay properties among those NTP agents
used, and this delay is what we are trying to measure.  A
combination of some GPS-based NTP servers and a conservatively
designed and deployed set of other NTP servers should yield good
results, but this is yet to be tested."

3.6

"Arrange that Src and Dst are synchronized; that is, that they have
clocks that are very closely synchronized with each other and each
fairly close to the actual time."

I fail to understand the strong requirement for Src et Dst host to be
synchronised very closely. 

My point of view : 

In IPPM, timestamps are always expressed in unix time-stamp format
(RFC1305) to start measurement time on Src host, so yes, you need Dst
and Src host to synchronized. 

Now let's imagine you can't have both synchronised, the Dst host is,
just it. Why do not rely only the wire-time of the Dst to do the
timestamping (Server and Session-Receiver are the same here).
Uncertainty on time-stamping calibration must take in account more
elements (packets travel time, runtime cf. below) but you can compute
it. 

I really think it's important to develop measurements where you can't
trust measurements Src host clock. You can only have on the Src host
clock :
- resolution 
- accuracy error calibration (or say skew probability distribution)  

Given that, you only send to the Src host a time difference between the
desired measurement start time-stamp and Src client session to fetch
the measurement configuration. It include runtime uncertainty, it's far
from perfect but it's a more realistic scenario when you what end
user to do measurements ...

Cheers.  

-- 
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 29 Apr 2010 11:05:51 +0200

Jerome,

I'm not quite sure if I can follow your reasoning but the key seems

> synchronised very closely.

In 2679 we want to do 1 way delay measurements from one host to another,
where the path between the two is unknown.  The delay is determined
by unknown cable lenghts and queuing effects in routers (where in
particular the latter will vary from 1 measurement to another).

The only way one can do this, is by calibrating the clocks at both
ends against a known time standard.    If not, then it is impossible
to tell if an extra delay is caused by one of the clocks being off
by some fraction of a millisecond, or by an extra 100 km of fiber
between the src and dst, or by the packet being in a buffer a little
bit longer.

You are right if you say that it is sufficient to know the difference
between the clocks and time standard and correct for this later, but this
is effectively the same as synchronizing the clocks against a reference.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Nobody ever went broke underestimating the taste of the American public.
                                                                  H.L.Mencken

---

From: Jerome Benoit <[email-masked]>
Date: Thu, 29 Apr 2010 21:54:23 +0200

Le Thu, 29 Apr 2010 11:05:51 +0200,

> I'm not quite sure if I can follow your reasoning but the key seems

I will try to make myself clearer :)

I work on the following architecture : 

* Logical design 

S1 is the server, the server do
	- measurement configuration diffusion
	- measurement probes receiver (any kind)

{A1,...,An} are the set of measurement agents, they can do any kind of
measurement (yes, we're in an ideal world ;-)

* Time handling in the logical design 

S1 is synchronized via NTP or GPS, system clock is UTC, accuracy is
know, resolution also, etc. and any kind of inaccuracy on the
wire-time can be at least calibrated via standard mechanisms. 

{A1,...,An} are in an unknown state : we do not know if system clock
is UTC, we do not know the clock resolution, etc. 

* Tim-stamping inaccuracy calibration  

S1 ask {A1,...,An} agents do to the following "measurement" : 

S1 compute a ramdom time-stamp series {T1,...Tn} in the future, this
series will be used to ask the n agents to send one UDP packet to
S1.

Agents contact S1 to fetch the "measurement"'s configuration but in the
configuration we do not put the time-stamp, we put Di = Ti -
S1-first_configuration_packets-wire-time (resolution matter here). Ai
then know that in Di (s|ms| ns) it will have to send one UDP packet to
S1 and then have computed locally a time-stamp LTi for the
measurement.    

Ai send the packet, Ai compute difference between LTi and the packet
wire-time (with a local capture for example) : Ai-wire-time-difference

S1 receive the packet (hopefully). 

S1 gather all Ai-wire-time-difference. 

Repeat, repeat, and so on.

The idea is : when server ask agents to do measurements, if we
can compute the error on remote agents wire-time time-stamping without
requiring them to be synchronized, we can do measurement without the
need to have both Src and Dst synchronized.  

S1 ask Ai to send a packets train (Poisson-like or whatever)
{(P1,T1),...,(Pn,Tn)}, if on each agents we know the wire-time
inaccuracy for Ti wished packets departure time-stamp, it's enough. 

There's a lot of details I've skipped but I wanted to expose the
general idea. 

Regards,