Subject: [ippm] Multi-Metrics Comments

From: "Joseph Kopena" <[email-masked]>
Date: Mon, 3 Dec 2007 19:34:09 -0500

Hi all,

A number of comments on draft-ietf-ippm-multimetrics-05.txt follow.
They are also available here in slightly easier to read HTML form:

http://gicl.cs.drexel.edu/people/tjkopena/wiki/pmwiki.php?n=Reading.Draft-ietf-ippm-multimetrics-05

Thanks!

------------
! draft-ietf-ippm-multimetrics-05

!! Content Points

Sec 2.3, "A metric is said to be spatial if one of the hosts
(measurement collection points) involved is neither the source nor the
destination of the measured packet." should perhaps be "nor a
destination of the measured packet" in order to not preclude spatial
metrics from being applied to one-to-group metrics in the future.

Sec 4.1.5, "One consequence of these uncertainties is that times of a
measure at different hosts shall not be used to order hosts on the
path of a measure;" should perhaps be "One consequence of these
uncertainties is that times measured at different hosts SHALL NOT be
used to order hosts on the path of a measure;"  I'm not sure if that
"SHALL NOT" conforms to convention, but it should be more clear that
this is a significant (and correct) directive.

Sec 4.2.5 says something about the possibility of a "0" appearing in
the packet loss sequence after a "1."  This sentence is very unclear &
should be fixed.  Further, it should be elaborated on as to how
exactly that scenario could happen.  In the intuitive understanding of
packets and paths this isn't possible (at least in my view), but I
could believe there is some case or architecture which might permit
it.

It should be made more clear in this document how Sections 4.1 and 4.3
differ.  This is as simple as explicitly stating early in 4.3 that
it's talking about delay variation rather than delay.

Sec 6.1.2 notes that the metric is not necessarily tied directly to
multicast in order to enable measurement over a unicast link.  I note
that one use of the metrics here would be to make comparisons such as
multicast versus unicast fan-out.  They may also have use in overlay
multicast and other architectures not directly based on traditional IP
multicast.

Sec 7 should be reworded in terms of "the receiving group" or similar,
rather than "the multicast group" due to the reasons in Sec 6.1.2 and
the previous paragraph here.

I don't think it's exactly out of scope for the document to discuss
computation of single value metrics from either path or one-to-group
metrics.  Commentary on how best to handle the issues therein, such as
packet loss, seem to be something that readers will be really looking
for in reading this document.

I would also say it's worth considering splitting the draft into
two---one for path metrics, one for one-to-group metrics.  The draft
is fairly long, and there's not necessarily a lot of overlap between
them.  For example, I am very interested in the multicast metrics but
less so in the path metrics.  However, it is very easy to skip to that
section in the current draft and this is not a high priority
suggestion.  Perhaps it would be enough to simply note in the
introduction that they do not build on each other and sections may
skipped without loss.

!! Document Points

In general, I don't understand the convention on the case given metric
names and concepts.  They're sometimes in upper case and sometimes
not.  Examples are listed in typographic points below.  If there is a
convention, it's not clear and they come across as inconsistent.  If
there is no convention, they should be more consistently (lower)
cased.

Sec 6.1.2, in all previous sections a one line description of
identifiers is given, but here just the type in several cases.

!! Minor Typographic Points

* Sec 2.2, ".. called "points of interest", where one" should be "..
called "points of interest," where one"
* Sec 2.5, odd capitalization of "One-to-group" in "Points of interest
of One-to-group metrics are the intended,"
* Sec 2.7, odd capitalization of "One-way" in "For instance, if One-way delay,"
* Sec 2.8, "sampling interval at different places in a network at
different time" should be "... times"
* Sec 3.1, "Spatial measure typically give the individual performance
of an" should be "Spatial measures..."
* Sec 3.3, odd capitalization of "Group-to-one" and "Group-to-group"
in "measurements on Group-to-one and Group-to-group topologies."
* Sec 4.1.2, "i, An integer if the list <1,2,...,n> which ordered the
hosts in the path." should be "i, An integer in the ordered list
<1,2,...,n> of hosts in the path."
* Sec 4.1.2, "dT* a delay, the one-way delay for a measured packet."
should be "dT*, a delay, the one-way delay for a measured packet." to
be consistent.
* Sec 4.1.15, "the delay looks to decrease: dTi > DTi+1.  This seem
typically du" should be "The delay looks to decrease: dTi > DTi+1.
This is frequently due"
* Sec 4.1.5 odd capitalization of "Clocks" in "Errors or uncertainties
related to Clocks."  This occures again in 4.5.  I realize it's
probably taken directly from the existing RFC...
* Sec 4.2, odd capitalization of "one-way-Packet-Loss" in "end-to-end
one-way-Packet-Loss measurements"
* Sec 4.2.5, "the result includes the sequence 1,0." should be "The
result..." but see the above discussion on this section.
* Sec 4.2.4, "value of Bi of 0 means that dTi is a finite value"
should be "value of 0 for Bi means..."
* Sec 4.3, "Following we adapt some of them and introduce points
specific which are to spatial measurement." should be "In the
following we adapt some of them and introduce points specific to
spatial measurement."
* Sec 4.4.1, odd capitalization of "Loss" in "depending on the
consistency of the Loss threshold among the points"
* Sec 4.4.1, "The analysis of such results is not deterministic: has
the path change?" should be "The analysis of such results is not
deterministic: Has the path changed?"
* Sec 4.4.2 has some obvious issues in: "A perfect Host Path Digest
(hum! of cource from the measurement point of view only, that is,
corresponding to the real path the test packet experimented) may
include several times several hosts"

(skipped Section 5)

* Sec 6.1, odd capitalization of "Definition," "One-way," and "Delay"
in "A Definition for one-to-group One-way Delay"
* Sec 6.1.2, "This parameter is to identify the measured traffic"
should be "... to differentiate the measured traffic"
* Sec 6.1.2, "It is set to be optional" should be "It is optional"
* Sec 6.1.3, odd capitalization in "The value of a
Type-P-one-to-group-One-way-Delay-Vector is a set of singletons
metrics Type-P-One-way-Delay [RFC2679]."
* In that same line, "singletons" metrics should perhaps be "singleton"

(giving up on the odd capitalization here)

* Sec 7, "They managed to collect" should be "They collect"
* Sec 7, "They can provide sufficient information regarding the
network performance in terms of each receiver and guide engineers to
identify potential problem happened on each branch of a multicast
routing tree." should be "They provide sufficient information
regarding network performance in terms of each receiver to guide
engineers and identify potential problems on each branch of a
multicast routing tree."
* Sec 7, "However, these metrics can not" should be "... cannot"
* Sec 7, "later one can have statistics" should be "latter..."

(moving on from Section 7)

>From here on in the content here is largely good and useful, but could
be tightened up & cleaned a fair bit, so I'll defer detailed
typographic comments.
------------

-- 
- joe kopena
  drexel university

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm