Subject: RE: One-way delay

From: Stefan Savage <[email-masked]>
Date: Fri, 3 Dec 1999 11:40:48 -0800

If the measured path is the only causal channel then there is clearly no way
to disambiguate between one-way delay and round-trip delay.

However, it is clearly possible for an application to have more than one
causal channel.  Trivially, if you and I are both watching CNN, see NASDAQ
plummet, and then both try to unload all of our Web stocks ASAP, then I will
have an advantage if I have a shorter one-way delay to the trading floor
than you.  

Here's a more realistic example.  In an interactive multi-user network game
suppose that clients send location updates both to each other and to the
server (to improve responsiveness).  However "operations" (e.g. checking if
you killed someone) must be serialized through the server to ensure
consistent state changes.  To be concrete, lets draw the following picture,
with server S and clients A and B:

               S
              / \
             /   \    
            /     \
           A-------B

Now suppose that RTT(AB), RTT(AS), and RTT(BS) are equal.  In addition, AB
and AS have symmetric one-way delays, but DELAY(B->S) < DELAY(S->B). Client
B has an advantage because if A and B enter range of each other they will
both learn this fact at the same time, but B's operations will reach the
server first.

I'm dubious that this is a common issue today because most applications are
strictly peer-to-peer or single client, single server.  However, as more
complicated distributed applications emerge I think this difference may
matter.

- Stefan

-----Original Message-----
From: Glossbrenner, Kenneth C. [mailto:[email-masked]]
Sent: Friday, December 03, 1999 8:47 AM
To: [email-masked]
Cc: Annie Gravey (E-mail); Neal B. Seitz (E-mail)
Subject: RE: One-way delay

*** Please see below.

-----Original Message-----
From: Henk Uijterwaal (RIPE-NCC) [mailto:[email-masked]]
Sent: Friday, December 03, 1999 11:05 AM
To: [email-masked]
Subject: RE: One-way delay

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

> IMHO there are no significant applications that care at all about one-way
> 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.

*** It is not important to any applications that I understand.
*** If it's not important to the users of service, then
*** I don't care to spend a lot of extra money to measure it.
*** Synchronizing clocks with precision at opposite ends 
*** of a network is complex and expensive.
*** The exception, as you and I both note below, is not that an
*** application finds one-way delay important, but it is the need
*** to diagnose and fix a problem with excessive round-trip delay.

*** I would like to know more about the 
*** "third_party_effects" mentioned by Jon Crowcroft. I can
*** imagine the relevance if the only acknowledgement back to the
*** first party must come via a third party.

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

*** I agree that one-way delay is important in diagnosing and fixing
*** round-trip delay problems.  Without more details from Jon, I don't
*** agree that there are major communications applications that can 
*** see or care about one-way delay.

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

*** I agree that estimating one-way delay with half of
*** round-trip delay is probably too cavalier for IP network.
*** If one needs to investigate one-way delay in IP, it will
*** have to be done correctly.
*** Please pardon my experience with measurement of
*** conventional networks.

*** Ken 

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:20:32 +0000

good points - and to make this more current consider this:

actually, in the RMT wg we are trying to devise TCP friendly
congestion control - one way to do this is to mimic a TCP
"equibvalent"£ throughput by modeling the sender as a rate
adjusting algorithm rying to track a TCP rate given by the various TCP
throughput equaitions (e.g. padhye et al from sigcomm 98 or more
recent ones for shorter lived connectins)

in these, you need to know a value for RTT on an "edge" of the
multicast tree - but yo uCANNOT measure it n a scaalble way with 2 way
exchanges in the same timescale as TCP ...so we are trying to figure
out 3rd party ways - roger kermode disd work on this in his thesis at
MIT....more ideas always welcome

the games you refer to may well inciroprate GPS or other soruces of
clock synch to enable true 1-way delay meaasurement tho...

 >>*** conventional networks.

 cheers

   jon