Subject: RE: One-way delay

From: "Glossbrenner, Kenneth C." <[email-masked]>
Date: Fri, 3 Dec 1999 06:51:52 -0800

IMHO there are no significant applications that care at all about one-way
delay, they only care about round-trip delay. If, for example, the
round-trip delay is X, I know of no real application that can even tell the
difference between X=X/2+X/2, X=X+0, and X=0+X. Certainly users of 2-way
video and audio cannot distinguish between these three cases. If I finish my
sentence and it always takes at least X time before I get a reply, how can I
tell which of the aforementioned three cases was in effect? There was an
undocumented agreement about this point in the ITU about a year and a half
ago.

One-way delay might be interesting for some telemetry applications.  If an
alarm goes off, the quicker it gets to the alarm monitoring station, the
sooner mitigation can be initiated.  Of course, one-way delay is only
important to telemetry applications if the mitigation is effected
out-of-band. If the mitigation is a command that returns across the same
communication network that carried the alarm, then once again it doesn't
matter whether the round-trip communications is X=X/2+X/2, X=X+0, or X=0+X,
it still takes at least X time to effect the mitigation.

(I also note that if the out-of-band mitigation is out-of-band, e.g. rolling
a repair truck and if is X on the order of 100s or 1000s of milliseconds,
then how much does it really help to roll trucks a few milliseconds
earlier?) 

The reason the ITU has steadfastly defined one-way delay metrics instead of
two-way delay metrics is that if you can afford to measure them (measurement
requires synchronized measurement devices, see e.g. X.138 for measurement
techniques), they provide additional diagnostic capabilities. If your
RT-delay is high, you will want to know why, and for IP networks in
particular, delay asymmetries are quite possible. If you can't afford to
measure one-way, then two-way measurements divided by two are usually taken
to be acceptable approximations of the one-way performance.

Ken Glossbrenner

-----Original Message-----
From: Grotefeld Glenn-cecl03 [mailto:[email-masked]]
Sent: Friday, December 03, 1999 8:54 AM
To: 'Chien-Lung Wu'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: One-way delay

The most prevalent reason is that certain applications, such as streaming
video and/or audio, are most influenced by one-way delay.

Glenn Grotefeld
Corporate Standards
Motorola, Inc.

~-----Original Message-----
~From: Chien-Lung Wu [mailto:[email-masked]]
~Sent: Thursday, December 02, 1999 3:11 PM
~To: [email-masked]
~Cc: [email-masked]; [email-masked]
~Subject: One-way delay
~
~
~Hi, all:
~There  are a lot of discussions about one-way delay metrics on 
~IPPM. Can
~anybody show me or point out how to measure one-way delay? I think many
~works have been done on round-trip delay. Why do we need 
~"one-way delay"?
~Thanks in advance.
~
~Regards,
~
~Chien-Lung
~
~
~***************************************************************
~*************
~Chien-Lung Wu						
[email-masked]
~Graduate Student of ECE 				(O) 919-513-1894
~at North Carolina State University			(H) 919-233-6724
~***************************************************************
~*************
~
~

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 03 Dec 1999 15:29:05 +0000

you can't always substitute 1/2 RTT for one way delay, and there are
applications that require knowledge of one way delays because of
_third party_ effects (rather than interaction) - e.g. electronic trading

there are large nets in use now that don't have symmetric paths,. let
alone delays (e.g. UDLR on satellite hops with terrestrial) - some of
these are used for distribution of trading data, and might (for even
regualtory reasons) require some sort of 1 way delay info.

cheers

jon.

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Fri, 3 Dec 1999 17:05:23 +0100 (CET)

On Fri, 3 Dec 1999, Glossbrenner, Kenneth C. wrote:

> delay, they only care about round-trip delay. 

The fact that the application cannot see the difference, does not mean
that it isn't important.

> If, for example, the round-trip delay is X, I know of no real
> application that can even tell the difference between X=X/2+X/2,
> X=X+0, and X=0+X.  Certainly users of 2-way video and audio cannot
> distinguish between these three cases. If I finish my sentence and it
> always takes at least X time before I get a reply, how can I tell
> which of the aforementioned three cases was in effect?

That is true, but now suppose that you want to improve X.  If X=X/2+X/2,
then the best strategy is to spend equal amounts of effort on both paths,
if X=X+0, then you better spend most of your efforts on reducing the delay
in the first path.

> There was an undocumented agreement about this point in the ITU about
> a year and a half ago.

I don't think that there is agreement on this in IPPM (and I like to see
the arguments that the ITU made to to come to this agreement sometime).

> If you can't afford to measure one-way, then two-way measurements
> divided by two are usually taken to be acceptable approximations of
> the one-way performance.

For most of the 1600 pairs of delays that we regularly measure, we see an
asymmetric behaviour, so if if you can't afford to measure one-way, then I
don't think that you should quote one-way values at all.

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).