Subject: Re: Measurement protocol for one-way performance metrics

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Mon, 4 Sep 2000 11:02:41 +0200 (CEST)

On Wed, 9 Aug 2000, Lijun Qian wrote:

> 
> Hi, all, here are some explanations about our approach of measurement
> protocol for one-way performance metrics presented at the IETF meeting.
> A protocol which measures one-way performance metrics(loss, delay, etc.)
> in REAL TIME is indispensible in many cases, for example, Traffic
> Engineering.

I'm not quite sure what to what protocol you are referring to here, since
there are 2 protocols involved here:

A) The protocol that specifies what measurement packets look like.  This
   protocol is real-time by definition, since, as soon as one has measured
   a delay or loss, this result is available.  How it should be made
   available is another question.

B) The protocol that specifies how results should be presented to the
   application that uses the measurements (and perhaps, how to specify
   what you want the measurement device to measure in the near future).

I think that for TE (and related) purposes, we should concentrate on B.
The metrics (A) have been chewed on long enough, and the protocols used
between the measurement devices are mainly an implementation detail.  

> Q: How to get one-way packet loss?
> 
> A:    The source encodes a Source Sequence Number to notify the
>       destination how many probe packets have been transmitted by the
>       source. The destination encodes a destination Sequence Number
>       to notify the source how many probe packets have been received
>       by the destination so far.

Sending packets back is only necessary if the source has to know the
packet loss seen by the destination.  Otherwise it just complicates
things. 

The other problem with this approach occurs when there is a complete
outage.  The source will continue to send, but never see anything back.
This can be caused by 2 things: the connection is lost _or_ the process on
the receiving box has died.  In the former case, there is indeed 100%
loss, in the latter it only _appears_ that there is 100% loss.  (Yes, I
realize that this won't happen in a lab setup, but try measuring losses on
a large scale in real life).

What IS full proof, is to record packets sent and packets received at
sender and receiver, then collect these data through an independent path
and combine the 2, but then there will be a delay between measurement and
availability of the result.

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

A man can take a train and never reach his destination.
                                               (Kerouac, well before RFC2780).

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Mon, 4 Sep 2000 11:02:41 +0200 (CEST)

Henk

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Sep 2000 08:43:53 -0700

actually, i suspect there could be issues with what protocol the measurement
packets use.  e.g. icmp can be treated differently than udp.

randy

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Mon, 4 Sep 2000 18:03:35 +0200 (CEST)

> packets use.  e.g. icmp can be treated differently than udp.

Yes, many sites do that.  We've never measured this in a systematic way,
but ping's rtt, is more often not equal to the sum of the 2 1-way-delays,
than not. 

What one should do, is to make the measurement packets look as close as
possible like the real data.  This means UDP, not ICMP.  One should also
add random padding in order to avoid compression along the way by some
smart device.

Henk