Subject: [ippm] OWDP: Is measurement box access speed information required?

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 14 May 2001 12:17:54 +0200

Hi IPPMers,

should I come back on something already discussed, please drop this message.

My question is whether sender/receiver need to provide information on their access speeds. The access speed of the measurement equipment will determine the "resolution of time" the system can provide depending on the packet length. In some cases, it may be useful to know the minimum distance in time two packets can have due to access speed limitations.

I didn't thoroughly read the draft. But I didn't have the impression that this information is communicateable by OWDP. 

Regards, 

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

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Mon, 14 May 2001 13:34:21 +0200 (CEST)

On Mon, 14 May 2001, Geib, Ruediger wrote:

> My question is whether sender/receiver need to provide information on
> their access speeds. The access speed of the measurement equipment
> will determine the "resolution of time" the system can provide
> depending on the packet length. In some cases, it may be useful to
> know the minimum distance in time two packets can have due to access
> speed limitations.

But this only sets an upper limit on the number of packets a sender can
send to a receiver.  It will work if only one sender sends packets to a
receiver, but, in practice, usually more than 1 sender will be sending
packets to a receiver.

Wouldn't it be much more practical to have a receiver send a
OWDP-session-reject if a sender asks to send data to a receiver at a rate
that the receiver cannot cope with, taking into account all active
sessions?

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: stanislav shalunov <[email-masked]>
Date: 14 May 2001 08:19:59 -0400

"Geib, Ruediger" <[email-masked]> writes:

> My question is whether sender/receiver need to provide information
> on their access speeds.

Current spec doesn't have any place to provide such information.
When deciding whether to provide it we need to recognize that for an
application program it may be quite hard to obtain this information in
a reliable manner; further, a typical bottleneck-close-to-an-edge
might not be the access link (which is now typically 100Mbps and
GigE will likely become more typical later)--thus, the interesting
speed more often than not will not be available to the measurement
host at all (and when it is available, there will be no way to tell
whether it's the right number or not).

Surely, link speeds (all along the path and not just the remote end;
and utilizations with various averaging periods) are interesting
parameters.  It's possible that they are, in fact, the parameters that
the end user wants to know.  But should a delay measurement protocol
become a place to leran these things (or things that are just as
important, such as network topology)?  I think not...

It seems pretty meaningless to me to go to a great pain of figuring
out that the Ethernet card is in fact in 10Gbps mode only to omit the
fact that the Ethernet is behind a much slower link.

Making the end link capacity (probably the least interesting of all
intermediate capacities) a somehow preferred parameter seems not very
useful.

Short trains of back-to-back packets would provide more interesting
information (about the bottleneck, not about access link).  Whether
and how to allow to specify them (and other useful things) is the
question that I think needs to be discussed.

Concrete suggestions on how to specify a broader class of inter-packet
interval distributions would be most welcome.

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

This message is designed to be viewed at 600 dpi.
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: Andy Scherrer <[email-masked]>
Date: Mon, 14 May 2001 15:43:01 -0500 (CDT)

> interval distributions would be most welcome.

Why do interval distributions have to be _specified_ at all? The IPPM role
should be to point out that it may be of interest to chose this
distribution based on desired effects, and then maybe give some examples.
i.e., Uniform for ease of scheduling, pseudorandom from some distribution
for various other advantages (and disadvantages!). Maybe some guidelines
indicating that Poisson streams are achieved by using exponential
inter-packet delays. But forcing/assuming that all applications will be
served by a Poisson(lambda) test stream seems inappropriate.  

Specifying too much control over "recommended" data distributions has too
much bearing on the distribution of the _collected_ data, rather than on
the methods of collecting, which, IMO, is a more apt focus.

Assuming for the moment that someone agrees with that, then the problem
remains how to specify the distribution that you're using inside the
packet? i.e., the
 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Inv-Lambda                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

section? 

Well I guess one advantage of forcing everyone to use Poisson data streams
is that you can memorize from draft-ietf-ippm-owdp-02.txt the definition
of which parametrization (there are at least 2, and the units of
microseconds becomes very important) of Poisson distribution you're using,
and everyone would presumably know what it means. 

Alternatively, though, that field could house a code that refers to some
long-winded specification which is usable in a flexible way by a
particular experimenter. For example, I could say that for my experiments,
"Type 6 data stream is a Poisson stream whose lambda is Gaussian with
mean 90 and variance 200 milliseconds".

Given that as a general perspective, do you want more concrete? 

Andy Scherrer
Matrix.Net, Inc.
http://www.matrix.net/

---

From: stanislav shalunov <[email-masked]>
Date: 14 May 2001 17:59:47 -0400

Andy Scherrer <[email-masked]> writes:

> Why do interval distributions have to be _specified_ at all?

For the protocol implementation, the receiver has to know when to
expect packets to be able to decide when packets are lost.  Somehow,
the information about packet schedule has to be communicated.  Sending
the whole schedule beforehand is wasteful and inconvenient (you might
want to generate it as you go).  A way out is to specify given
distribution and describe how to generate pseudo-random numbers
matching that.

The question of which _metrics_ are defined is, strictly speaking,
orthogonal to the question of what the protocol can do.  Currently
defined metrics are all singleton (and Poisson inter-packet time
serves well here).  This doesn't mean the protocol _has_ to be
restricted to only measuring that.

Democracy is a form of government that substitutes election by the incompetent
many for appointment by the corrupt few.                         -- G. B. Shaw
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: Andy Scherrer <[email-masked]>
Date: Mon, 14 May 2001 17:53:25 -0500 (CDT)

> distribution and describe how to generate pseudo-random numbers

Well, if it needs to know a schedule at a per-packet level, you'd have to
specify not the distribution, but the complete algorithm and random seed. 
I.e., I'm gonna generate my poisson stream by using such and such an
algorithm, using drand48(), and the seed is blah. 

Otherwise, there's no hope of predicting the next packet, precisely
because of the properties of the Poisson stream that are considered
desirable. 

So you're still stuck with sending the schedule before you execute it,
whether in bursts or totally in advance. 

> restricted to only measuring that.

True enough... But I'm thinking more of the perturbation of the
distribution of the process that you're trying to measure (the network) by
the distribution that you're inserting in your data stream. At the
measurement end, the distribution you're recording is some weird mixture
of the two, and it makes statistical treatment, e.g., variance
calculations, much more awkward. 

Hopefully those who want to use a uniform inter-packet time will still
find it easy to do so. At the other extreme, it may be desirable to
construct & study much more complex packet-sending distributions than is
made available through a 1-dimensional Poisson model; my earlier example
is only slightly more complicated. 

Andy Scherrer
Matrix.Net, Inc.
http://www.matrix.net/

---

From: Ben Teitelbaum <[email-masked]>
Date: Tue, 15 May 2001 05:26:17 -0400

> algorithm, using drand48(), and the seed is blah.

Right. That's exactly what we have attempted to do in section 5.1 of
draft-ietf-ippm-owdp-01.txt.

-- 

                         ,,,

                        `o-o-  
                          <    Benjamin Teitelbaum
                           -   Advanced Network & Services, Inc.
                           .   Internet2

---

From: stanislav shalunov <[email-masked]>
Date: 15 May 2001 14:27:23 -0400

In draft-ietf-ippm-owdp-02.txt, section 5.1 pp. 18-19 it is said:

>   The time elapsed between packets is pseudo-random, with exponential
>   distribution (resulting in a Poisson stream of packets).  As
>   suggested in RFC 2330, the ith sampling interval Ei may be computed
>   using inverse transform:

>        Ei = -ln(Ui) * Inv-Lambda

>   where Ui is uniformly distributed between 0 and 1 and lambda is the
>   desired mean time between packets.

>   Pseudo-random stream of bits is obtained using AES with SID as the
>   key, running in counter mode (first encrypted block is 0, second
>   encrypted block is 1 in network octet order, etc.)  Each block of 64
>   bits is used to obtain one pseudo-random number uniformly distributed
>   between 0 and 1.  If the bits are Bj (j=1..64, numbered left to
>   right), the resulting value is
>        U = B1*2^{-1} + B2*2^{-2} + ... B64*2^{-64}

>   The parameter lambda is has the value requested in the Request-
>   Session message of the OWDP-Control negotiation that spawned the
>   session.

>   The logarithm and division in the formula above MUST be computed
>   using IEEE 754 standard floating point arithmetic. [HELP WANTED!:
>   Someone with a stronger background in numerical analysis to specify
>   how to compute the sampling intervals precisely and portably!]

If you have suggestions on how to make this clearer don't hesitate to
tell us.

> calculations, much more awkward. 

Poisson stream with low rate is fine (and a safe choice) for
measurement of singleton metrics in such a way that measurement
doesn't affect the state of the network.

We hear repeated requests for adding features for measurement of
characteristics not currently standartized (and measurement of which
relies on changing the network state).  Doing it in a flexible,
general, elegant, and economical way would be great.  Concrete
suggestions are welcome.

> is only slightly more complicated. 

In its current form, OWDP supports only a single distribution of
inter-packet intervals (exponential).

A fanatic is one who can't change his mind and won't change the
subject.                                   -- Winston Churchill
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: Andy Scherrer <[email-masked]>
Date: Thu, 17 May 2001 08:10:11 -0500 (CDT)

(sorry for the delay in following up...)

> In draft-ietf-ippm-owdp-02.txt, section 5.1 pp. 18-19 it is said:

[ . . . ] 

> If you have suggestions on how to make this clearer don't hesitate to

I did go back and read that section more carefully after Ben's note that
same morning. Of course I'll suggest any specific improvements I can think
of. 

> inter-packet intervals (exponential).

This is back to my original point. I was hoping that I'd missed something
in the document and that there _was_ a way to perform experiments within
the guidelines of draft-ietf-ippm-owdp-02.txt but not be restricted to
Poisson streams. I can certainly see that it's difficult to define a
single formula that's explicit and transportable, yet more general.

But, to reiterate, IMHO, restricting it that far degrades the utility of
the OWDP protocol. Emphasizing Poisson/Exponential to the exclusion of
Uniform or Gaussian or even 'equal spacing' -- is this really better than
just sending the whole schedule ahead of time? Maybe. Is it really
necessary?

I'm still hoping there is some way within the current structure (which I
probably don't understand fully) to circumvent that requirement so that
non-Poisson intervals can be negotiated, perhaps out of band, but at least
referred to in the OWDP framework.

Ideally it would be possible to implement something like, "Use Inverse
transform formula #3.2 from the table of formulae we previously
negotiated. Parameters are alpha,beta,lambda and seed X". This is
preferable (simpler and more flexible, but not so restrictive) to trying
to _specify_ a more general inverse transform (e.g., one covering all

>        Ei = -ln(Ui) * Inv-Lambda

A *default* inverse transform yielding Poisson/Exponential is not at all
objectionable to me. 

So can you see a practical way to employ the capability I describe?
Does anyone agree that it would be preferable not to be limited to
Poisson-only streams?

Thanks,

Andy Scherrer