Subject: [ippm] Some comments on OWDP requirements

From: Steven Van den Berghe <[email-masked]>
Date: Fri, 17 Aug 2001 10:01:58 +0200

Hi ippmers,

I have some (very late) comments on the owdp requirements draft.
Although i agree that the current text is sufficient to deliver the
requirements for the current OWDP-specs, i think we need to tune the
reqs a little bit more to allow other owdp approaches. (Note1: with
other, i mean mostly other means of driving the control plane), (Note 2:
i know everything is technically possible with the current text, it just
seem to favour one approach a bit more:).

Just some of my thoughts:

Section 3: add text:
    the standard should however allow more lightweight control of the
measurements (e.g. through SNMP configurations instead of signalling),
while still re-using the same basic test-stream generation capability as
the "one-way-ping" case.

Section 4.1/4.2: remove
    i think it is depending on the type of control, wat should be stored
and how much must be analyzed. The OWDP-control needs everything, while
other applications might want to retrieve a summarized metric. Anyway,
is it really necessary for a measurement protocol spec to define the
storage/analysis ?

Section 4.3: says exactly what i mean

Section 4.4:
    Drop reference to OWDP-control. We could want to use varying packet
sizes and network services that are not negotiated on the control plane
(e.g. suprise the network :)

Section 4.5:
    "A control protocol MAY provide abilities to"

Section 6.0:
    "The security impact depends on the environment in which the
measurements are performed. If there are risks known, a control
mechanism must be used which provides the security services described in
the following sections. The impact of these security mechanism on the
format of the test-stream packets must be taken into account when
designing the test protocol."

So, hope something of the above ends up being useful :),

Best regards,
Steven

--
Steven Van den Berghe
[email-masked]
Workgroup Broadband-Networks
Department Information Technology
Ghent University - Belgium
Phone:  +32 (0)9 267 35 86 | Fax  :  +32 (0)9 267 35 99
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Press any key to continue or any other key to quit...

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Fri, 17 Aug 2001 12:14:02 +0200 (CEST)

Steven, others,

> while still re-using the same basic test-stream generation capability as

I don't understand this.  The requirement is that we can set up
measurement sessions between devices from different vendors.  The text
says so.  How we do this (signalling, config files, etc) is not a
requirement but implementation discussed elsewhere.

> (e.g. suprise the network :)

But: what is the difference (for the network and the measurement) between
sending packets with varying sizes with and without informing the
receipient about this in advance?

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.5354414
1016 AB Amsterdam                    Fax: +31.20.5354445
The Netherlands                   Mobile: +31.6.55861746
------------------------------------------------------------------------------

As long as you don't tell your friends how I played the hand,
then I won't tell my friends how you defended it.                 (Anonymous)

---

From: Steven Van den Berghe <[email-masked]>
Date: Fri, 17 Aug 2001 14:07:39 +0200

Hi Henk et al.,

I have responded inline...

> requirement but implementation discussed elsewhere.

OK, my fault (read a may as a must, i guess)

> receipient about this in advance?

The difference is, as the text is stated now, it seems that there must be a
control level negotiation to define the size. The main reason why i think this
should be relaxed a bit, is to allow other forms of test-traffic (e.g. with sizes
according to some smart statistical traffic model). Requiring a must here, is of
course much more interesting for engineering the receiving buffers It comes down
to the question: does ippm think something like this will ever be needed... If
so, we should keep a requirements document open enough to handle this (while
still providing the necessary basis to proceed with owdp).

Best regards,
Steven

The software said Windows95 or better, so I got a Linux!

---

From: stanislav shalunov <[email-masked]>
Date: 17 Aug 2001 15:20:27 -0400

Steven,

Before we launch into discussion of textual changes, we need to
understand what the requirements need to express.  We have discussed
this extensively before, but let's get back to it.

The model of current requirements document is that it provides a
closed system that is sufficient to conduct one-way active
measurements (set them up, run them, and get the results).  It is
understood that setting the measurement up and getting the results can
be accomplished by means outside the scope of protocol but that
standartization of these mechanisms is necessary for inter-domain
interoperability and easy deployment.

Do you agree with the above?  If not, do you agree with the goals of
inter-domain interoperability and easy deployment?

> while still re-using the same basic test-stream generation capability as

This is OWAMP requirements document.  It doesn't specify when
particular OWAMP mechanisms (such as OWAMP-Control) are used and
doesn't assume that support for OWAMP or any part of it will be
mandated for all or some Internet hosts by the actual protocol
specification.

In what sense does it need to allow [...]?  How could it possibly
disallow something like that?

> is it really necessary for a measurement protocol spec to define the

Being a complete solution for measurements of singleton one-way
metrics, OWAMP needs to specify data distribution mechanisms.  It says
nothing about storage.

> (e.g. suprise the network :)

What prevents you from using authenticated mode where the control part
is encrypted?

>     "A control protocol MAY provide abilities to"

I don't understand your use of "MAY" (which to me implies
standard-speak that specifies implementation behavior requirements in
a protocol standard) in the context of a requirements document.  This
draft isn't a protocol specification.  What does "MAY" mean in the
context of listing *requirements* for a protocol specification?

> designing the test protocol."

I don't understand this.  The specific security requirements all say
that the protocol must be able to optionally support particular
security features.  The use of the security features by particular
hosts is up to them.  The job of OWAMP is to standartize them for
those hosts that need them.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Clothes make the man.  Naked people have little or no influence on
society.                                             -- Mark Twain
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: stanislav shalunov <[email-masked]>
Date: 17 Aug 2001 17:57:04 -0400

Steven Van den Berghe <[email-masked]> writes:

> [...] The main reason why i think this should be relaxed a bit, is
> to allow other forms of test-traffic (e.g. with sizes according to
> some smart statistical traffic model).

We're back to the discussion we went through with inter-packet
intervals.  How do you ask a remote sender to send you traffic
according to a statistical profile?  How do you, the receiver, report
the statistical profile that was used by the sender to the data
collector if you were never told what profile the sender uses?
Etc., etc.

For inter-packet intervals, we have an understanding that having more
than Poisson would be quite useful, even if it doesn't measure any
currently defined metric, and we have rough understanding of the
encoding that would be required to cover most typical cases.

If we want varying packet sizes (rather than using characteristic
mixes with given percentages, which you can do with the current model
using multiple sessions, one per size), we need to first understand
applications and usefulness of such technique, and then establish a
way to express most desired typical mixes.

Since I don't know of any application that would not be satisfied with
data obtained from multiple concurrent sessions with different packet
sizes, it's hard for me to select a typical subset from an empty set.

Please elaborate on the applications of this and on ways to encode
typical distributions.

.signature: I/O Error

---

From: Attila Pasztor <[email-masked]>
Date: Mon, 20 Aug 2001 11:00:24 +1000

Hi Stanislav,

> sizes, it's hard for me to select a typical subset from an empty set.

Please have a look at Lai, Baker: Measuring Link Bandwidths Using a
Deterministic Model of Packet Delay (Sigcomm 2000). To my understanding
the Sigma phase of the nettimer described in this paper is sending many
single packets of different sizes and to implement each of these as a
different session (at least in my opinion) would not be an optimal
solution.

Best regards,
Attila

---

From: Steven Van den Berghe <[email-masked]>
Date: Fri, 24 Aug 2001 10:12:15 +0200

Hi stanislav,

I agree that if the goal of the current document is to give requirements for
inter-domain interoperability and easy deployment, its wording is sufficient
to keep the current OWDP work going. My only fear was that the requirements
for measuring owam-like metrics in other environments can yield other
requirements. But as you stated, the document leaves possibilities open for
other approaches, and we can always write modified requirements to tackle
differences later on.

so, as it seems nobody sees a need to insert specific requirements for other
use-cases besides the inter-domain interoperability, there is indeed no need
to make modifications.

Best regards,
Steven

> disallow something like that?

OK

> metrics, OWAMP needs to specify data distribution mechanisms.  It says

The text says "All data obtained during a measurement session should be
available after it is finished if desired by endpoint". I (probably mis-)
interpreted this as: whatever mechanism you use to measure, any client of the
measurement protocol should  be able to expose all the data to the upper
layer, meaning a set-up like

endpoint A sends traffic --- endpoint B receives traffic and sends
notification if delay > x

would not be directly possible (you would need to build something on top of
endpoint B to check this)

> context of listing *requirements* for a protocol specification?

OK, just sounded as a real hard requirements to which any protocol should
comply (ps i didn't mean to use uppercase in the standard sense, it was just
meant as a way to emphasize without using html, please replace by *may*).

> those hosts that need them.

OK

--
Steven Van den Berghe
[email-masked]
Workgroup Broadband-Networks
Department Information Technology
Ghent University - Belgium
Phone:  +32 (0)9 267 35 86 | Fax  :  +32 (0)9 267 35 99
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Programming today is a race between software engineers
striving to build bigger and better idiot-proof programs,
and the Universe trying to produce bigger and better
idiots. So far, the Universe is winning. - Rich Cook
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*