Subject: [ippm] Re: draft-ietf-ippm-owdp: optional fields

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Wed, 31 Jan 2001 15:30:39 +0100 (CET)

Stanislav, Matt, others,

> You said you'd clarify your suggestion about introducing optional
> fields and give us a list of desired fields.  Could you do that?

Two fields are essential, IMHO:

* Experimental error.

  This follows from RFC2330 which indicates that experimental errors
  for OWD should be reported.  Reporting errors becomes even more 
  important when OWD sessions can be set up between different devices
  operated/manufactured by different organizations.  (Typical example,
  if one sync's his clock from a nearby NTP server, there will be a large
  statistical error on the time compared to a situation where one has 
  a GPS receiver inside the device.  These errors propagate into the
  result, and should be quoted in order to fully appreciate the 
  final result for a OWD measurement).

  This number can be expressed using the same format as an NTP timestamp.

* Clock status.
  This word should indicate whether the clock is sychronized or not.
  This is typically necessary during startup and to detect experimental
  problems.

  How one deals with unsynchronized clocks, is up to the application.
  What we do, is to simply record the clock status when a packet is
  sent and received, and only in our offline analysis decide if a
  data-point should be included in the analysis.  

  This is simple and has the advantage that one continues to measure
  packet losses even if the clock becomes unsynchronized.  (We measure
  packet losses by counting the number of sent and received delay 
  packages).  It also saves the hassle of stopping the session and having
  to restart it in case of short hickup in the GPS receiver.  

  The alternative is to let the OWDP control program check the status
  of the sending and receiving clock as it is taking data, then, when
  one of the clocks becomes unsynchronized, stop the session.  

  NTP use 13 bits for this, see /usr/local/include/time.h on your unix
  box for the definition.  In order to accomodate other time keeping
  mechanisms, we could use 1 word of the send message, and split that
  into a few bytes to indicate the time keeping method, followed by
  13 others if that's NTP or N others for any other timekeeping 
  mechanism.  (For example, if one directly reads from the GPS clock, 
  one probably only wants to use points when the receiver actually
  sees something).

Combining these two, I can see something like:

           0                   1                   2                   3  
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Sequence Number                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Timestamp                            |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Timestamp Error                      |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Clock Type |               Clock status bits                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                                                               .
        .                   Packet padding 

For the unauthenticated packet mode, and similar for the other modes.

Henk

PS. While reading draft-ietf-owdp-01.txt

Page 6: "In unautheniticated mode, KID, ..."  
        but KID is only defined in the next paragraph

Page 6: The response message: I think the text should specify here
        that YES==0 and NO != 0

Page 8/9, creating sessions:
        I'm not sure how the sender can say anything about the receiver
        precision during setup of a session.  Related to this, precision
        may vary during a session as clocks tend to drift.

        Packet length: this does not seem to deal with sessions where
        one sends packets of varying length.

        Packets: there should a value for infinite.

Page 11/12: Why do the 1st and 3rd message have a specific value in the
        first 8 bytes, while the second 1 only has 0 or non-zero. 
        Wouldn't it be easier to simply use values for the different
        messages (for example 1=start, 2=ack, 3=stop, 4=... ).  

Page 16: Shouldn't we specify that the sequence numbers increase by 1?
        If not, then why start at 0?

Page 18: RFC958 is obsolete and has been replaced by 1305.

Page 19: " [RIPE] Ripe Test-Traffic home... " should be
         " [RIPE] RIPE NCC Test-TRaffic Measurements home..."
         
Page 19: [RIPE-NLUUG] : The URL should be:

          http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz

         (This one is guaranteed, the other is filesystem dependend).
         And the file is now gzip'd ps.

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

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

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Wed, 31 Jan 2001 15:30:39 +0100 (CET)

Stanislav, Matt, others,

* Experimental error.

* Clock status.

           0                   1                   2                   3  

Henk