Subject: RE: One-way delay

From: KERBERENES Jacques CNET/DAC/LAN <[email-masked]>
Date: Tue, 7 Dec 1999 10:16:16 +0100

Hi,

You are right, but the problem is that such commercial products are very
expansive. Since I have worked very closely with HP and Netcom Systems
during several years, I have suggested them to design a low cost active
probe. But the solution they have choosen are too expansive for a large
deployement (IMHO). I am aware that and EC project intend to use the Netcom
Product, but only with a few number of boxes because of their hight cost.
So,  I am waiting the new version of RIPE-NCC test project probe , or may be
we will develop our own box in our lab. I have also suggested to Accumatics
to integrate this kind of tool, since we are satisfied with his commercial
version of OC3Mon.

Jacques

Jacques Kerberenes

e-mail : [email-masked]

Phone : +33  (0)2 96 05 29 13
Fax :      +33  (0)2 96 05 18 52

CNET/DAC/NTR
2, av Pierre Marzin
BP 40 22301 LANNION CEDEX
FRANCE

> ----------
> De : 	Robin Uyeshiro[SMTP:[email-masked]]
> Répondre à : 	[email-masked]
> Date :	Monday, December 06, 1999 7:46 PM
> A :	[email-masked]'
> Objet :	FW: One-way delay
> 
> There are a few commercial testers that are able to do one-way
> measurements 
> very accurately.  If you send me an email, I can provide a somewhat biased
> 
> list.  I believe most use GPS to obtain higher accuracy.
> 
> Robin Uyeshiro
> Adtech, Inc.
> 
> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Monday, December 06, 1999 4:44 AM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: One-way delay
> > 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,
> 
> - Havard
>

---

From: Dan Cohn <[email-masked]>
Date: Tue, 7 Dec 1999 07:08:17 -0800 (PST)

FYI,

	Cisco is developing a special image with what they call 'RTR', a
set of tools designed to do end to end performance measurement within IOS.
Its coming out of their diffserv group, and I haven't had time to follow
up on it, but I believe it also included a one-way delay test with GPS
sync. I got the impression that it wasn't very far into development yet,
but that most basic tests were working by now. I don't think its hit
any documentation yet, either.

	dc

---

From: Kui Zhang <[email-masked]>
Date: Tue, 7 Dec 1999 09:46:33 -0800 (PST)

> any documentation yet, either.

I happened to be involved in this project at Cisco. 
RTR (Response Time Reporter, now renamed to Service Assurance Agent) is a
feature in regular IOS release. 
It does response time (RTT) measurement for a number of traffic types:
ICMP, UDP, TCP, HTTP, DNS, DHCP. It also measures UDP jitter (one way 
delay variance). 
The ability to measure one-way latency will be released early next year.
To measure one way latency, we require the clock on source and destination to
be synchronized. In real life, this kind of measurement is often performed
by an ISP from one POP to another POP. In this case, ISP would install an
NTP server with GPS clock to each POP location, then all routers in that POP 
would sync up to that NTP server via NTP. 
This approach could get source and destination synced close to a couple of 
milliseconds. Also it is not too expensive -- this kind of NTP server costs
about US$ 2000.

If you need more info on RTR(SAA), please email to me. I don't want to 
bore this list with infomercials :-)

Cheers,

.kui

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Wed, 8 Dec 1999 10:56:40 +0100 (CET)

> milliseconds. Also it is not too expensive -- this kind of NTP server costs

If you have a uncertainties in the synchronization of the order of a few
milliseconds, then the experimental uncertainty in your measurement will
be huge compared to the effect you are trying to measure.

A 2 ms error in the clock synchronization on each ends translates into an
overall error of around 3 ms.  This is a lot compared to the delays of
10...50 ms that one typically sees between ISP's, and makes measurements
on internal networks (delays of the order of 1 ms) totally impossible.

Also note that CHANGES in the network (for example, somebody replaces a
router or cable, traffic starts to take a different path with one hop
more/less) result in changes of the order of a few ms in the one-way
delay.  This is something you want to know but cannot detect with a device
with an accuracy of the order of a few ms.

In short, you have to do at least order of magnitude better in clock
synchronization before this is useful.

> > > So,  I am waiting the new version of RIPE-NCC test project probe , 

Just for the record:  We are not developing a new version of our
"test-boxes", for the next series we plan to continue with essentially the
same setup as we've done for the past two years. However, we do have to
have a new batch of PCB's made from scratch, and we are using this
opportunity to make a few minor changes to the hardware based on our
experience with the previous version.  Nothing major, no rocket science,
it just takes time.  

These boxes will be made available to the RIPE membership early next year,
as soon as we have worked out a number of practical details and received
approval from the RIPE membership to proceed.    For details, please
contact me directly.

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