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.