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

From: "Cucchiara, Joan" <[email-masked]>
Date: Thu, 22 Feb 2001 15:04:54 -0500

Hi Stanislav,

Part 1 is removed.  Thank you for those clarifications.
Additional comments and questions on Part 2 are inline.

  -Joan

> "Cucchiara, Joan" <[email-masked]> writes:
> 
> 
> > 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.
> 
> ...and will be provided.

Thanks!

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

Our system has a very accurate method of timing packets without
incorporating
software time into the measurement. In this context software time means the
time spent in the IP stack and network drivers of the 
measurement system. We timestamp packets as they are transmitted 
onto the wire. Therefore we have the timestamp after the 
packet has left the box. This is the only true measurement 
of timing that is not affected by system timing and load. 
As you can see our timestamps are not inside
the packets and have to be communicated out of band.

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

I agree with your comment however emulating certain data streams 
is in effect emulating certain packet formats (i.e RTP). 
Our intention is not to emulate the whole application 
but to emulate the application's stream. (more on this later).

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

We are eager to contribute to non-Poisson distribution. 
Non-poisson inter-packet distribution is another means to 
emulate certain application stream patterns. We feel that 
is a more effective way to measure performance metrics for 
a given application with certain non-poisson inter-packet distribution. 
(this is related to number 3 above.)

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

We are not against having AES only wonder why other encryption methods
are not offered.  These could be negotiated between the endpoints during
setup.

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

Although this is not so much an issue for UDP, there is the issue of
"same path" being used in both directions.    
The idea on our system is that you can lower the overhead 
of the test from control connection, etc. 
if you do both measurements at the same time.

Our customers initial feedback indicates that they find
this a useful feature.

> 
> > 7) For a standard, we thought the format of the control
> >    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!

The TLV format would offer consistency in the packet format.  
It is also somewhat widely used and understood so would help 
to advance the protocol.  This format is also easy to extend, 
which may not be a goal at the moment but assuming there is a 
rev 2 of the protocol, then adopting a consistent packet format 
would make a rev 2 much easier, e.g. packets could be deprecated
based on the "type" and new types added, and that is much 
easier than trying to rewrite various kinds of packet formats.  
It is also a lot less coding, debugging, etc.

We consider this fairly important because of the reasons 
stated above, and would encourage use of this format for packets. 
We can provide examples if you think that would be helpful.

> 
> >    Also, this would allow vendors to add their own features.
> >    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".

We believe a more flexible method is needed.

> 
> > 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.
> 
> 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?
> 
> >    Also, this would eliminate the requirement for AES based
> >    pseudo-random sample interval calculation that allows 
> the receiver to
> >    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?
> 
> >    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.
> 
> 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.

By late packets we are refering to packets that arrive to the 
receiver but with a jitter higher than a given amount. We 
are not concerned with latency. We are concerned with jitter. 
Typically VoIP endpoint have a jitter buffer with a certain length. 
All packets that arrive with a jitter higher than the length of 
the buffer are marked late and discarded. Specifying an 
acceptable jitter allows computation of the late packet metric. 
This is an extremely useful information for media based applications.

> 
> > 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?
> 
> 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 that is a concern, the information can be transmitted 
when the test is done with transfering its data.

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

Without keep alives there is no way for transfer of out 
of band data. As we mentioned above we would like 
the flexibility of not passing timestamp information 
in the packets (and instead passing timestamp info out-of-band). 

Keep alives are also a flexible method for systems that may 
want to send other forms of out of band data.

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

---

From: stanislav shalunov <[email-masked]>
Date: 26 Feb 2001 14:39:33 -0500

Joan,

There are quite a few issues that you raise, so I'll answer
one-by-one.  I apologize for not sending a reply earlier.

	In re a posteriori packet sending time acquisition: We have
not anticipated using a mechanism such as the one that you describe
for timestamping.  I'm not even sure what would be the "right" way of
coping with such scenario.  Transmitting timestamps as packets are
sent on the control connection probably isn't right, as it would
hinder one's ability to observe extended periods of losses.  This
needs further understanding and discussion.  Can you provide more
details about the mechanism?

	In re application traffic simulation: I think we should at
least define metrics we're interested in before we attempt to measure
them.  Defining useful and relevant metrics for application simulation
can be hard, and non-destructive measurement will likely be impossible
(it's sort of like Heisenberg principle if applications send a lot of
traffic).  In any case, defining these metrics would be outside of
scope of draft-ietf-ippm-owdp, which defines a protocol for
measurement of metrics that already exist, not new metrics.

	In re AES or other encryption schemes: We have rather specific
requirements for encryption (see security considerations section).
These requirements appear to be adequately met by the current scheme.
Allowing any other options would seems to be a disadvantage for the
following reasons:

* To interoperate, one would need to require implementation of more
  than half of total ways to encrypt or requiring to always implement
  a particular way to encrypt.  The former begs the question of why
  all the other ways are necessary at all, while the latter would
  quickly bloat the code.  For a protocol that we hope can be
  implemented in embedded systems this is a significant problem.
  (Say, SSL tarball is currently at 1.5MB compressed with installed
  package requiring about 3.3MB; it also takes a significant amount of
  RAM for each session to run.)

* To assess overall security, one would need to consider all of the
  options.  The task of assessing security is hard as it is (by the
  way, security reviews are *very* welcome), why complicate it?

* With general purpose encryption layers, we would need to guarantee
  integrity using a separate approach inside the protocol (using MACs
  presumably).  Thus, instead of generalizing and abstracting, we'd
  just keep introducing new algorithms.  Computing a MAC isn't any
  easier than doing a block cipher (in fact, many MACs are
  special applications of block ciphers).

* To advance on the Standard Track, one will need to demonstrate
  interoperability of all options.  This means, if we agree to include
  a whole bunch of options now, we'll need to implement them.

What are the advantages and how do they outweigh the disadvantages?

	In re bidirectional measurements: I think a primitive to
perform a unidirectional session is enough.  If you will allow to use
an analogy (imperfect as all analogies are), embedding bidirectional
measurements right into the protocol is like designing an API to copy
files, coming up with a function "int filecopy(char* src, char* dst)"
and then deciding to provide ability to copy two files at once with
"struct two_results* two_filecopy(char* src1, char* src2, char* dst1,
char* dst2)".  It's kludgey, makes it harder to use with all the
auxiliary stuff around, is just as "limited" (why only two files are
supported?), and doesn't actually reduce work, since both files still
need to be copied (or, in our case, parameters for two sessions still
need to be passed along with answers and all you're saving is possibly
a measly few bytes on the control connection).  Am I missing
something?

	In re extensibility: You're welcome to suggest ways to improve
it.  Could you also please clarify what you believe is wrong with the
scheme of using mode bits for extensions?

	In re "late packets": I believe that this is strictly a
question of post-processing of measurement data and is therefore
outside of scope of the protocol.

	In re keep-alives: Keep-alives per se would be something we'd
rather *avoid*, because we *don't* want the TCP connection to break if
there's a connectivity outage.  We specifically and deliberately took
care to not send anything on the control connection while the session
is progress.  Adding keep-alives to purposefully remove an
advantageous property that the protocol currently possesses appears to
be counter-intuitive.

P.S.: draft-ietf-ippm-owdp-02.txt is out and is in all the usual
places.  I don't think changes in it have to do with any of your
concerns, except the intro section stuff.

---

From: Stephen Donnelly <[email-masked]>
Date: Tue, 27 Feb 2001 09:47:43 +1300

> advantageous property that the protocol currently possesses appears to

Just a quick thought on keep-alives. Our site uses Cisco's stateful
firewalling on the border router. To prevent the router running out of
memory, it will reset any connection idle for more than one hour. I
realise this isn't 'correct' behaviour, in fact it is a real nuisance,
but in practise this kind of thing is probably common?

This could be a real problem for owdp-control connections, assuming it
is common to perform individual measurements for longer periods than one
hour?

Stephen.
-- 
-----------------------------------------------------------------------
    Stephen Donnelly (BCMS)             email: [email-masked]
    WAND Group                      Room GG.15 phone +64 7 838 4086
    Computer Science Department, University of Waikato, New Zealand
-----------------------------------------------------------------------
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: stanislav shalunov <[email-masked]>
Date: 26 Feb 2001 16:21:57 -0500

Stephen Donnelly <[email-masked]> writes:

> firewalling on the border router. To prevent the router running out
> of memory, it will reset any connection idle for more than one hour.

As a work-around for this particular broken behavior, you could set
TCP keep-alive option on the control connection.  In fact, you
probably have already set net.inet.tcp.always_keepalive or your OS
equivalent already--or your life must be really painful...

Layer 4 keep-alives are already there.  Why would you need layer 5
ones?

> I realise this isn't 'correct' behaviour, in fact it is a real
> nuisance, but in practise this kind of thing is probably common?

If your "stateful firewall" is in fact a NAT, there are far worse
problems than keeping the control connection from breaking.  OWDP
won't do anything interesting across NATs, and fundamentally there
isn't anything practical one can do in order to run *any* one-way
measurements to a host behind a NAT.

That's just a general implication of NAT that has ot be taken into
account when you deploy it.

Even if your firewall isn't a NAT, how would it like OWDP-Test
traffic?  I'm willing to bet it'll drop it all.

Practically speaking, you'd probably place an OWDP-Control server in
the DMZ to be able to measure from it to the outside world, and place
another one somewhere inside your network close to "the exit" to be
able to measure your network performance.

"Computer Science is no more about computers than astronomy is about
telescopes."					-- E. W. Dijkstra
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm