Subject: RE: One-way delay

From: "Sundar Raman" <[email-masked]>
Date: Fri, 3 Dec 1999 14:11:44 -0600

I guess in most applications it truly is irrelevant what the one-way delay is,
since the originator needs to respond to the destination (ie, round trip time is
what matters).

But in apps such as IP telephony, IP video, and other multimedia situations, is
there not a need to determine if the message is delayed getting to the
destination?  I would think that this is where one-way metrics are very
important.  Most multi-media apps use UDP, rather than TCP.  Since there's no
connection, I would think that there would be high need to be able to accurately
determine which leg, if any, was problematic.  Also, since there's no inherent
error correction in UDP, it's possible that the return leg is so delayed that we
constantly assume that we need to resend the first leg also, which would be hard
to trouble shoot unless we could accurately state the delays for each leg.

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.  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.  Delta determination of packet delay from a
known value is probably as close as we can get (at least as well as i can
imagine).  Deviation from a "standard" delay, and just profiling the change in
delay as more packets are sent would give some kind of a metric.  Problem with
this strategy is how to account for clock drift and skew, which almost all
hardware (hosts) seems to have to some degree.

There are other options, but still none that I would think are really feasible
or practical.  But I'm not really all that familiar with this topic and would
defer to the experts on what's more workable.

Cheers.

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Sat, 4 Dec 1999 18:10:41 +0100 (CET)

On Fri, 3 Dec 1999, Sundar Raman wrote:

> 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: Jon Crowcroft <[email-masked]>
Date: Sun, 05 Dec 1999 18:23:59 +0000

the same reason GPS (or other external clock fro mseperate network) is
useful is a clue as to when applications don't always do that 2 way
(but do a 3rd party) handshake - other networks - the e-trading
exacmple is when the users use a thurd party net to actually committ
any spending seperate fro mthe network used for advertsiging the share
price "now"..

j.