Re: Data Publishing Policy?

["Henk Uijterwaal \(RIPE-NCC\)" <]

On Mon, 12 Jul 1999, Ingo Luetkebohle wrote:

> I don't have major problems with releasing the data to customers (option
> #2), but I doubt it'll be usefull for judging performance. Performance is
> much more than just delay measurements. I think, anybody who considers the
> Test Traffic project to be about performance measurements got something
> wrong. The data is much more usefull for other purposes -- for example, we
> have identified several frequent routing flaps to important destinations
> and intend to do something about it.

There are a number of parameters that determine the performance of a
connection.  1-way-delay and loss are two of them.  Bandwidth, delay
variations are others, and I can come up with a few more.  Depending on
your application, you have to decide which one is the most important.  For
example, bandwidth and losses are the most important parameters for FTP,
delay for interactive work, delay variations for "streaming" applications
(voice over IP), and so on.  

Besides that, lots of networks specify the delays between points and are
sold on that basis.  The Test-Traffic project provides a way to actually
measure them.

> I have one small reservation with regard to data publishing, though: The
> current plots are easy to misinterpret. Maybe the RIPE could create
> something more "cooked" and publish that instead.

We're certainly looking at "Summary pages", "Internet weather maps",
"Executive summaries"  or whatever you want to call them.  However, these
are one of those things that everybody seems to be talking about but
nobody seems to be able to define what should be in those plots. I'd love
to get some feedback on what people want to see on a summary page. 

> btw, what about going to a customers site with some print-outs, and
> showing that? It will impress the customer and it won't do much harm
> because its just a snapshot. Its also much easier to control future access
> that way.

But what if a customer calls and complains that "the net is so slow".  At
that point you want to give him the URL to show where the problem is.  

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: henk.uijterwaal@localhost
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).