Subject: [ippm] Comments on draft-ietf-ippm-owdp-01.txt

From: "Cucchiara, Joan" <[email-masked]>
Date: Tue, 13 Feb 2001 09:42:12 -0500

Hello Stanislav, Ben, and Matt,

As you probably know BRIX Networks has also implemented
a One-Way Delay Measurement Protocol with GPS.
We have read the draft-ietf-ippm-owdp-01.txt and have
a few comments and questions for you.

First, we want to say that what you are proposing is
very similar to what we have in place. We have separated
our protocol into a control plane using TCP and a 
data plane using UDP also.  So it was good to see that
you were also approaching the protocol in that same way.

We have divided the following into 2 parts:

Part I.   Questions on the draft.

Part II.  Requests for changes/additions to the draft.

Thanks.

Part I.  Questions on the draft?
-------------------------------------

   * Can both conf-sender and conf-receiver be set in the Request-Session
     message?  If so, what is the behavior?   If not, could this
     be clearly stated in the draft?

   * Why can't the server close the TCP connection when it 
     rejects a Request-Session command?  If the request
     is rejected, the server should be able to close the 
     connection in order to save resources.

   * What format is Start Time in the Request-Session message?

   * Why is sender/receiver precision repeated when data is sent during the 
     Retrieve-Session process?

   * Padding test packets with zero's should be optional.  Tests may
     want to xmit non-zero data to mimic multi-media traffic.

Part II.  Request for Changes or Additions to the Draft
------------------------------------------------------

1) A clearer picture of the requirements/goals and non-goals
   upfront would be helpful. This was also discussed recently 
   on the list.

2) In addition to the software-based timestamp method presented
   in the draft, could an option be added for out-of-band 
   communication of hardware-based timestamps from the 
   session-sender be added?

   This could be between either the session-sender
   and session-receiver, or between session-sender and the server.
   
   Please note, hardware-based timestamping prevents the transmission
   of timestamps inside packets (by its nature, the timestamp is
   retrieved after the packet is sent out).

3) We'd like to see suppport for an "application level" mimicing capability.

   This could be assigned in the control plane.  For example, having
   the UDP mimic the RTP format.  

   We'd especially like to see multimedia (voice, video) data 
   mimiced and would request support of VoIP and Streaming protocols
   added as a requirement.

4) Are there any plans for a "flights of packets" approach?

5) There should be a way to choose other encryption options
   such as SSL.  Having AES be the only one and having this
   as required is not particularly flexible or extensible,
   Are there any plans to add additional options here?

6) We would also like to see the one-way delay in both 
   directions, so from  A to B, and then back from B to A.
   This would be a good indication of where time is spent in the
   round-trip time (which leg, from A to B or B to A.)
   (It has been particularly appreciated by our customers).

   This could be an option and may require adding a "bi-directional" 
   flag somewhere, perhaps, in the request-session message and 
   another "mode" to indicate this capability in the server 
   greeting message (i.e. as a option when the session starts.)

7) For a standard, we thought the format of the control
   plane messages should be modeled after a TLV.  The TLV
   format is flexible and extensible.  
   We believe this approach would help to advance the 
   one-way delay protocol as a standard. 

   Also, this would allow vendors to add their own features.
   Assuming that a type code was for "vendor's use".

8) The calculation for acceptible jitter may be simplified
   (and perhaps made more precise?) by including a "length of time 
   for test". Since you are including how many packets, this
   would also be a reasonable piece of information to include
   in the control plane.

   Also, this would eliminate the requirement for AES based
   pseudo-random sample interval calculation that allows the receiver to
   determine the packet send time.

   We'd also like to see an acceptable jitter parameter that could
   be used to tag late packets vs. lost packets.  This is
   the approach take by most VoIP equipment.  This would be an option
   instead of sending the inverse-lambda in the Request-Session
   message.

9) Has support for Keep-Alives (or another message that could be 
   exchanged during the session) with the ability to append user
   data to the messages, been considered?

Thank you for this opportunity to comment!
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: stanislav shalunov <[email-masked]>
Date: 13 Feb 2001 22:05:52 -0500

Joan,

Thanks a lot for the comments and suggestions.

> Part I.  Questions on the draft?

You can set both.  Setting each means that the server is asked to
configure the corresponding end-point.  Setting both therefore is
meant to ask the server to configure both.

Example: a set of measurement nodes under same administrative control,
with a single OWDP-Control gateway to them can be used to provide
on-demand measurements to third parties.

I suppose we'll need to clarify this (work item).

>      connection in order to save resources.

If you requested three sessions, and they were accepted (but not
started yet), it'd be inconvenient to lose them all if the forth
session is rejected for a policy reason of some sort...

>    * What format is Start Time in the Request-Session message?

It was supposed to be in the normal NTP-style format.  

I suppose we'll need to clarify this (work item).

>      Retrieve-Session process?

This way, the only thing a collection database would need to know
about a session is its SID.  (Remember that Control-Client and
Retrieve-Client can be different hosts.)

>      want to xmit non-zero data to mimic multi-media traffic.

We say now (page 17):

   Finally, Packet Padding SHOULD be pseudo-random (generated
   independently of any other pseudo-random numbers mentioned in this
   document).  However, implementations MUST provide a configuration
   parameter, an option, or a different means of making Packet Padding
   consist of all zeros.

And further down (page 18):

   OWDP-Test sessions could be used as covert channels of information.
   Environments that are worried about covert channels should take this
   into consideration.

Pseudo-random padding is meant for situations where there can be
hardware compression in the path (modems like to do that).

Emulating any particular application wasn't a goal.

> Part II.  Request for Changes or Additions to the Draft

...and will be provided.

>    retrieved after the packet is sent out).

I'm not sure I understand.  If timestamps aren't in the packets, where
are they?  I'm not sure what you mean.  Say, when SmartBits puts
timestamps into their packets on the PIC, they insert it in the packet
(where else?).

> 3) We'd like to see suppport for an "application level" mimicing capability.

This was not a goal. One of the reasons is that effective application
emulation would require substantial new (non-existing) research far
beyond packet formats.

> 4) Are there any plans for a "flights of packets" approach?

I'm not sure I understand.  Do you mean non-Poisson inter-packet
distribution?

We had some pretty extensive discussion on this internally, and the
short summary of what I believe we came to was that it'd be nice to be
able to specify a number of other distributions (in particular,
back-to-back tuples), but we don't really have ideas on how to do it
in a good general way.  Since there's an IPPM singleton metric, which
essentially implies Poisson, we decided we'll stick with just that for
now.

This doesn't mean non-Poisson distribution is off the agenda for the
future.

>    Are there any plans to add additional options here?

There are no such plans.  Why would you want an extensible or flexible
something where requirements are quite clear?

In particular regard to SSL, none of the ciphers, versions, or modes
(all the zillions of total combinations provided because of U.S. govt
stance on encryption technology) provide individual message
authentication.

Blocks of zeros in CBC mode for an 128-bit-block block cipher provides
it.

>    round-trip time (which leg, from A to B or B to A.)

The idea is that once you have the primitive that allows you to
measure one-way, you can easily measure in both directions with two
individual OWDP-Test sessions.

>    plane messages should be modeled after a TLV.

This wasn't really ingestigated as any serious extensibility goes
contrary to the goal of having a really simple easy-to-implement
control protocol.  We didn't have a goal to design a flexible
general-purpose protocol for "passing things".

If you feel strongly about the issue and have a specific model in
mind, do tell us!

>    Assuming that a type code was for "vendor's use".

While it's a limited expansion machanism, one can steal a mode bit now
for "I support Frobnitz extensions set".

>    would also be a reasonable piece of information to include

I don't think I understand how calculation of jitter would be
simplified by that, since the way it is now you can compute jitter in
one pass while getting Retrieve-Session results back (it's just the
standard deviation of the difference of send/receive timestamps).
How could it possibly be any simpler than one pass on the data as it
is coming?

Or do I misunderstand something?  Where do you want to have total
duration--in Request-Session or in Retrieve-Session results?

>    determine the packet send time.

How so?  You still need to know when the next packet is scheduled to
be sent to know when to decide it's not coming, right?

>    instead of sending the inverse-lambda in the Request-Session

Inverse-Lambda is the mean time between packets.  It determines the
properties of the test stream and must be in the protocol.

Max latency threshold, on the other hand, is a matter of processing.
You can always discard packets that you consider "late".

We decided that the protocol needs to provide complete information.
What you do with it is your choice.  It's always easy to discard some
data.

>    data to the messages, been considered?

No, why?  Any traffic on the TCP connection during the session
(between Start-Sessions and Stop-Sessions) was considered bad for two
reasons:

* If there's a lot of it, it can affect measurement results.

* If there's connectivity loss during a session (say, an hour), we'd
  like to continue to record losses rather than have the session fail.

Thanks again for your feedback!

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

All revolutions are bloody.  The October Revolution was bloodless,
but it was only the beginning.               -- Dmitri Volkogonov
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm