Subject: Re: [ippm] draft-ietf-ippm-owdp-08.txt

From: stanislav shalunov <[email-masked]>
Date: 01 Aug 2004 00:00:49 -0400

"Henk Uijterwaal (RIPE NCC)" <[email-masked]> writes:

> > > * Page 16: 'The server should start ...'.
> > >   Suppose the start time is specified as t=0 with a rate of 100 packets.
> > >   For some reason, the server takes more time to start, so the first
> > >   packet cannot be sent before t=1.  What should be done with the 100
> > >   packets that had to be sent between t=0 and t=1?
> > >
> > >    - Send as fast as possible?  Possibly overloading the network,
> > >      with the risk of making a complete run invalid.
> > >    - Send with a (minimum) gap?
> > >    - Skip
> >
> > The way it is written now, the implication is that they should be
> > skipped.  The send schedule is rigid and reproducible, with exact
> > timestamps attached to every packet to be sent.  If some packets are
> > in the past, they would have to be skipped.
> >
> > Is this reasonable?
> 
> Perfectly reasonable, this is just so we know how to implement this, I
> don't think that there is a need for anything more complex.

After re-reading and conferring with Jeff I think this aspect will
need to be clarified.  The feature that I originally put in with
starts in the past---which enable you to start a session ``as soon as
this OWAMP-Control message gets to you''---is more trouble than it's
worth.  If it's taken out, everything falls into place nicely:
You'd send the packets that you were supposed to send less than
timeout time ago as quickly as you can.  (This prevents a large burst
of packets that would be discarded by the receiver anyway because they
are too late.)

> Well, yes, I know it can be done somewhat more efficient, but whatever you
> do, you will end up splitting 2 16-bits and 2 32-bits numbers over 3 32
> bit words.  If the order is changed to 32 bits for the 2 timestamps, then
> 1 word for the 2 16 bit EE, you have to put 2x16 bits into one word (and
> this requires some manipulation) but the rest are straight copies. This is
> code that is sitting in the most time-critical part of your application,
> anything we can do to reduce the number of operations there, will improve
> the measurements.
> 
> If there is a techical argument for this, then please tell me, if not, I
> don't see why the order cannot be changed.

I'm not sure I understand the packet format you describe.  Why don't
we talk about it in San Diego?  Otherwise, could you elaborate a
bit---perhaps a diagram with bits allocated or another description
would help me.

> > Regarding error estimates: Firstly, there is no need to generate the
> > error estimate in the protocol format for every packet.  The error
> > estimate changes infrequently.
> 
> I tend to disagree.

That is certainly true for NTP.  It's difficult to imagine the
semantics of a frequently changing error estimate.

> Also, if one decides that error estimate is only checked and
> recalculated once every N seconds, then there will be 2 classes of
> packets: one where the error estimation code was called and one
> where it was not.  In the former case, the systematic errors will be
> different than in the latter, but the user has no way to tell.

Not necessarily.  You don't want the error estimate preparation in the
critical path (between obtaining a timestamp and issuing the send()
call---in Unix-speak) at all.  One way to accomplish this is to
prepare the error estimate before obtaining the timestamp.  (If the
interface for getting the error estimate also gives you time, as is
the case, with, e.g., ntp_gettime(), you discard the timestamp
obtained in the call to the interface made to obtain the error
estimate.  By the way, for whatever reasons, on FreeBSD ntp_gettime()
produces about three times the overhead of gettimeofday(), if I am not
mistaken; so it is anyway preferable to separate the two
functions---frequently obtaining timestamps and infrequently obtaining
error estimates---into two different calls.)

Maybe we should add an implementor's note to describe all this.

> The set of natural numbers excluding 0 is smaller but still contains
> sufficient numbers for all packets :-)

Well, we could have saved 0 for special value.  I think 0xFFFFFFFF
(which is already used as a special value, by the way) is more
convenient.  I don't think this really matters.

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

This message is designed to be viewed upside down.

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE NCC)" <[email-masked]>
Date: Sun, 1 Aug 2004 22:46:10 +0200 (CEST)

> bit---perhaps a diagram with bits allocated or another description

Right now, we have:

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      12|      Send Error Estimate      |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      16|                       Receive Timestamp                       |
        +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      20|                               |    Receive Error Estimate     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

with 2 32 bit quantities starting halfway a 32 bit word.  That makes it
hard to map the packet on an array of 32 bit words.  I suggest:

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      12|      Send Error Estimate      |   Receive Error Estimate      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
      16|                       Receive Timestamp                       |
      20|                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

so everything is nicely aligned.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Process and Procedure are the last hiding place of people without the wit
and wisdom to do their job properly.                          (David Brent).

---

From: "Jeff W. Boote" <[email-masked]>
Date: Mon, 02 Aug 2004 15:04:41 -0600

> hard to map the packet on an array of 32 bit words.  I suggest:

Speaking as an implementor...
I don't think this is much of a big deal. From the point of view of a
typical C program it is simply a matter of a memcpy verses an
assignment. This would be a very minimal difference for any reasonable
compiler/hardware.
 
However, the only down side to this change would be the fact that
currently deployed software would not be compatible. But, the TTL and
lost packet changes already make our currently deployed software
incompatible. Therefore, I would say that as long as this change happens
quickly, it would not bother me. (I have not deployed the "ttl/lost
packet version yet and could just put this additional change into that
version.)

jeff

---

From: stanislav shalunov <[email-masked]>
Date: 02 Aug 2004 17:27:35 -0400

> Right now, we have:

Is that in the response to the Fetch-Session command?  (The OWAMP-Test
packets don't have receive timestamps.)  Fetch-Session response isn't
necessarily aligned (each packet record contains 25 octets), so it
would not let you replace memory copy calls with assignments in the C
code.  (I mention C code, because the compiled version would be
scarcely different even if you did replace the memcpy() calls with
assignments to *(this+that).)

Note that when the response is generated and transmitted, you don't
actually need to deal with packet records individually---these would
only need to be generated once when the packets are received and the
session data is stored.

Jeff said it's OK with him to change this, from the point of view of
compatibility.  If no-one chimes in and objects in a few days, I would
put the change in since it doesn't hurt anything and might perhaps
save a cycle or two for some implementations.

Note that the proposed change does not affect OWAMP-Test, so it
wouldn't break, e.g., the just-described hardware implementation.

"The power of accurate observation is commonly called cynicism by
those who have not got it."			-- G. B. Shaw