Subject: RE: One-way delay

From: "David Smrdel" <[email-masked]>
Date: Mon, 6 Dec 1999 08:30:04 -0500

Henk,

That is exactly how  I am determining latency in the simple socket program.
With the OS/2 system, we can achieve ms accuracy.  I am able to use this tool to
identify problematic areas in customer networks with much success.

From all of the emails that I have seen on this topic, I believe that the
consensus is that there is a need and purpose for one-way delay
measurement...now the original question still needs to be answered...what is the
best way for someone to measure it?

Although I feel comfortable that my homebrew solution supports my needs, I agree
that there are more elegant solutions that would also provide a higher degree of
granularity.  I am interested in Chien-Lung Wu's question as to what is the best
approach in measuring this delay...

Dave

"Henk Uijterwaal (RIPE-NCC)" <[email-masked]> on 12/04/99 12:10:41 PM

                                                              

 To:      [email-masked]                                   
                                                              
 cc:      (bcc: David Smrdel/ENG/Computerm)                   

 Subject: RE: One-way delay                                   

On Fri, 3 Dec 1999, Sundar Raman wrote:

> But is there any way to REALLY determine one way delay unless we can put a
clock
> on the packet?  We can't expect to be able to sync up clocks due to skew and
> drift on the host machines.

Yes, you put a GPS receiver in every measurement station and use that to
synchronize the internal clock to sub-ms second levels.

>  Even connecting them to a GPS transponder provides inaccuracy in the
> time the API call takes to get the time from the external device and
> put it into the packet.

The solution is to follow a slightly different approach: you add the
timekeeping stuff to the O/S kernel and make sure that the internal clock
of the machine (that is, the value that you get back on a gettimeofday();
call) is synchronized to the external source.  When a packet has to be
time-stamped, all you have to do is read out a counter on your machine and
this is a fast operation.  The time needed to process packets, get
timestamps etc, is of the order of 0.1 ms, this is small compared to the
10...1000 ms delays that one typically sees on the Internet.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.535-4414,  Fax -4445
1016 AB Amsterdam                   Home: +31.20.4195305
The Netherlands                   Mobile: +31.6.55861746
------------------------------------------------------------------------------

The Committee (...) was unable to reach a consensus that substantial merit was
lacking. Thus, the appeal was deemed meritorious.          (Orlando NABC #19).

---

From: [email-masked]
Date: Mon, 06 Dec 1999 15:44:13 +0100

> From all of the emails that I have seen on this topic, I
> believe that the consensus is that there is a need and purpose
> for one-way delay measurement...now the original question still
> needs to be answered...what is the best way for someone to
> measure it?

The best way for someone to measure it is (briefly) to have a
measurement machine at either end of the path under study, each of
them synchronized to a known good time source.  See the RFCs and the
Internet-drafts (if there are still any for one-way delay; I somehow
doubdt it) for the nitty-gritty details.

In practice, this means that it will take quite some effort in order
to accurately measure the one-way delay and loss characteristics of
a given path, and the technique thus isn't all that amenable to
measuring these metrics for "random" paths due to the need for good
infrastructure to carry out the measurements.

Regards,

- Håvard

---

From: Constantinos <[email-masked]>
Date: Mon, 6 Dec 1999 09:43:01 -0600 (CST)

I was wondering, is the GPS type of solution the only way to
measure accurately one-way delays? 

I mean, suppose that we have nothing more than two hosts 
at the ends of  a path, with a certain clock skew between 
them (assume that the clock drift is zero as a first-order 
approximation).

Is it "proven", either in a practical or theoretical sense,
that we cannot measure the path one-way delay in a given 
accuracy, independent of the measuring technique used? 

Obviously, even if the clocks are perfectly synchronized, 
the maximum accuracy that we can get is determined by the clock 
resolution at the two hosts. What about, though, some lower
accuracy level? Say in the order of 1ms or so (compared to
the microsecond clock resolution of current machines)?

Constantinos

---

From: Joerg Micheel <[email-masked]>
Date: Tue, 7 Dec 1999 10:53:47 +1300

> accuracy, independent of the measuring technique used? 

It might be possible to get the drift under control by having a
very accurate PPS source, such as derived from SONET/SDH, but
still: how will you be able to tell the clock offset at both ends ?

	Joerg
-- 
Joerg B. Micheel			Email: <[email-masked]>
Waikato Applied Network Dynamics 	Phone: +64 7 8384794
The University of Waikato, CompScience	Fax:   +64 7 8384155
Private Bag 3105			Pager: +64 868 38222
Hamilton, New Zealand			Plan:  TINE and the DAG's

---

From: Constantinos <[email-masked]>
Date: Tue, 7 Dec 1999 09:33:13 -0600 (CST)

> still: how will you be able to tell the clock offset at both ends ?

If you know the clock offset, you can easily measure the one-way
delay. If you known the one-way delay, you can easily measure the 
offset. They are equivalent in this sense. If you know neither, though,
I was wondering if it is impossible to measure the one-way
delay (or the offset), independent of what measurement technique
you use (without an external common clock source).

Constantinos