Subject: [ippm] Fwd: WGLC for Spatial Composition of Metrics

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 14 Apr 2010 12:01:59 +0200

IPPM group,

This is a WGLC for the draft: Spatial Composition of Metrics

This draft has been stable for a while and no issues have been raised.
Publication of the framework draft does not require any changes to this
document either.  With the framework draft published as RFC 5835, we think
that now is the time to start a WGLC on this draft.  Please raise any
remaining issues by Monday, May 10, 9:00 UTC.

An URL for the draft is:

   http://datatracker.ietf.org/doc/draft-ietf-ippm-spatial-composition/

Note that the draft will expire during this LC.  Authors, please submit
a new version identical to the one that is there now.

Matt & Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
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
------------------------------------------------------------------------------

Nobody ever went broke underestimating the taste of the American public.
                                                                  H.L.Mencken

---

From: Al Morton <[email-masked]>
Date: Wed, 14 Apr 2010 10:57:48 -0400

At 06:01 AM 4/14/2010, Henk Uijterwaal wrote:
>...An URL for the draft is:
>

The new version is posted. Two references moved from I-D to RFC,
so they were updated to avoid errors.

Al

---

From: Donald McLachlan <[email-masked]>
Date: Wed, 14 Apr 2010 12:49:25 -0400

Henk et al,

Below are the comments I provided to Al Morton (slightly edited and 
minus 1 comment) on version 10 of the draft.

Don

-------- Original Message --------
Subject: 	Re: 
http://tools.ietf.org/wg/ippm/draft-ietf-ippm-spatial-composition/
Date: 	Tue, 06 Apr 2010 16:44:46 -0400
From: 	Donald McLachlan <[email-masked]>
To: 	Al Morton <[email-masked]>

Hi Al,

I hope (at least some of) the following comments are useful.

Don

Section 2.1.  First sentence. It reads:
    [...] between the source and the destination of the interest.
Should it maybe read:
    [...] between the source and the destination of interest.

Section 3.1.  4'th bullet.  Ref to possible future work of another
working group.  Thus inaccessible to the reader. ...

Section 4.1.8.1, Section 5.2.6 (and possibly others.)  Question. Is it
possible that (e.g. policy based routing or MPLS) could put pkts from A
to C into different priority queues, than it would put pkts from A to B
and from B to C, thus invalidating the composite metric results?

Section 4.1.9.  I don't like the example given.  In the example given I
expect any change in one-way delay is more likely due to the time taken
for the (possibly heavily loaded) CPU to encrypt/decrypt the packets
than just due to the change in the length of the packet.  Not only that,
but IMO, encrypting changes the definition of packets of type-P.  While
it would be mundane, I think saying ping (or OWAMP) packets of length L1
versus ping (or OWAMP) packets of L2 is a better example of packets of
different length.

Section 4.1.10. Should "similar" be quantified.  E.g. same DCSP, proto,
similar length, encryption, etc?  Otherwise might DPI or policy affect
routing or queuing, etc?

Section 5.2 (or all of "chapter" 5) Poisson vs. Periodic streams.
Question.  While I understand the theoretical differences with using
Poisson versus Periodic streams.  In practice, has anyone ever measured
one-way delay across an Internet path with both stream types and
obtained statistically similar/different results? Is this chapter
proposing that one can perform Poisson OWD measurements on one sub-path
and periodic OWD measurements on a second sub-path and combine them to
form a sane composite full-path metric?  If so, that should be more
clearly stated.  If not, that should be stated.

Section 5.2.6.  Maybe replace bi-modal with multi-modal?

Section 5.2.9. Even if the sub-path distribution is (multi) modal, if
the sub-path is part of the real path, wouldn't the sample delays on the
full path be subject to the same (multi-)modal delays of the sub-path?
In which case is this really an issue?

Section 6.1.4.  Question.  Would it also be possible to use a similar
method to measure sub-path burst lost length, and combine them to obtain
an empirical loss-length probability?

Section 7.1.1, third bullet.  Not only length in bits, but Type-P, the
definition of which should maybe include DCSP, proto, src port, dst
port, encryption, etc.  IMO, anything which might change how the packet
might be handled by routers along the path should be specified.  Maybe
this comment should be applied to Section 4.1.1 instead, and would thus
covered by the first sentence of this Section, "In addtion to the
parameters of section 4.1.1:".

Section 7.1.1, fourth bullet. Section 7.1 says
Type-P-One-way-pdv-refmin-Poisson/Periodic-Stream.  This bullet refers
to packet pairs - which is IPDV.  If what is intended is IPDV, then the
idea of min delay does not apply.  If what is intended is PDV, then
packet pairs does not apply.

Assuming what is wanted is PDV, might I suggest:

F, a selection function unambiguously defining the packets from
      the stream that are selected for the computation of
      this metric.  F(packet), MUST
      have a valid Type-P-Finite-One-way-Delay less than Tmax (in other
      words, excluding packets which have undefined one-way delay) and
      MUST have been transmitted during the interval T, Tf.  F(min_packet) MUST be the packet with the
      minimum valid value of Type-P-Finite-One-way-Delay for the stream,
      in addition to the criteria for F(packet).  If multiple
      packets have equal minimum Type-P-Finite-One-way-Delay values,
      then the value for the earliest arriving packet SHOULD be used.

Section 7.1.4, last sentence.  Doesn't the PDV applicability statement
speak of %-iles, or P.99?  Was it a conscious decision to change the
nomenclature to Quantile?  (That said I prefer Quantile over %-ile and P.99).