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

["Henk Uijterwaal (RIPE NCC)" <henk at ripe.net>]

Stas, others,

* General: The document should specify that the implementation MUST have
  rate limitations in unauthenticated mode (to avoid that we end up with
  the same discussion as the requirements doc).

* Page 4, 2nd drawing. Why is the fetch_client sitting in the sending
  box.  I'd think that results are typically requested by a machine
  outside the pair sender and receiver.

* Section 5.1. Server Greeting: Why does one send 12 unused octets
  in the server greeting first?

* Page 10: I cannot find the definition of MBZ anywhere.

* 5.4. First sentence:  this is not correct, the receiver only knows
  that packets were sent _if_ it knows that sending machine did send
  what it was supposed to send.  The receiver cannot tell from the
  measurements if the sending machine stopped sending or all packets
  were lost.

  Same paragraph: are 0 and 1: poisson and periodic the only values
  that can be used here, or is this a point for future extension?

* 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

* Page 18-19: 'if a receiver ... invalidated'
  Doesn't this mean that if the server crashes near the end, all results
  are suddenly invalid, even though they are perfectly good measurements?
  (We typically run measurements for weeks, and the chances that they
  are terminated by an outside source are pretty close to 1)

* Page 21: the test session data.  Typically, the error estimates and
  time stamp will be in 4 variables in the code:

    Send-error-estimate    16 bits
    Receive time stamp     32 bits (seconds), 32 bits (microseconds)
    Receive error estimate 16 bits

  To store this in the  format described here one has to:

   - Multiply the SEE by 2^16
   - Take the seconds word of the RTS and split it into 2 16 bit words
   - Divide the top half by 2^16 and add to the SEE
   - Multiply the bottom half by 2^16, store
   - Take the microsecond word, split in two times 16 bits
   - Divide the top half by 2^16 and add to the bottom half of the RTS
   - Multiply the bottom half by 2^16 and add to the REE.

  Then do exactly the opposite on the receiving side.  Wouldn't it make
  more sense to use the first 2 word for the timestamp, then the
  next one for the EE.  That way, most of this will be a straight copy,
  one only has to manipulate the SEE bits.

* Page 23: Is there a technical reason to start sequence numbers with
  0 and not 1?

* Page 23: I've made this comment before, but I think this way to
  express the EE introduces a lot of complexity at a point where one
  wants to use the minimum number of CPU cycles.

  When timestamping a packet, one wants to extract a timestamp just before
  the packet is sent, insert it in the packet, then write the packet to
  the socket.  Any CPU cycle between reading the time stamp and writing
  the packet means introducing a delay and making the measurement less
  accurate.  Using this method, one has to do a lot of calculations to
  file the word, if we'd use RFC 1305 timestamps for everything, the
  operation would be reduced to a simple copy.

  Also, implementations of the metrics where the ethernet card inserts
  the timestamp have been suggested.  In this case, it is impossible to
  use this method for inserting errors.


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

_______________________________________________
ippm mailing list
ippm at ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm