Re: [ippm] Multi-Metrics Comments

[<[e-mail]>]

Hi Joseph,

Many thanks for the deep and precise review.
 
I addressed most of yours comments. See below for more details.

Regards
Emile

> -----Message d'origine-----
> De : Joseph Kopena [mailto:[e-mail]]
> Envoyé : mardi 4 décembre 2007 01:34
> À : [e-mail]
> Objet : [ippm] Multi-Metrics Comments
> 
> 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.
> 
reflected

> 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.
> 
Reflected as 
" do not guaranty the ordering of the hosts "

Section clarified:
the delay looks to decrease: dTi > DTi+1. This may occur despite it does not make sense per definition:
*	This seem typically du to some clock synchronisation issue. This point is discussed in the section 3.7.1. "Errors or uncertainties related to Clocks" of. Consequently, times of a measure at different hosts do not guaranty the ordering of the hosts on the path of a measure.
*	During some change of routes the order of 2 hosts may change on the main path;
*	The location of the point of interest in the device influences the result. If the packet is not obsverved directly on the input interface the delay includes buffering time and consequently an uncertainty due to the difference between 'wire time' and 'host time'

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

Section clarified: 
the result includes the sequence 1,0. This may occur despite it does not make sense per definition:
*	During some change of routes a packet may be seen by a host but not by it successor on the main path;
*	A packet may not be observed in a host due to some buffer or CPU overflow in the point of interest;
*	
> 
> 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.

These sections differ dramatically. Delay variation definition is based on 2 packets. References differ too. Each metric name must introduced separately in a formal way.

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


Reflected in the motivation part:
"and overlay multicast" added to bullet 4.

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

Reflected in section 6 and 7.

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

Sorry I miss the meaning. Is it about mixing spatial and multicast ?

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

I don't known. The doc is a bit long. Vector and matrix are common to the 2 family of metrics. 2 docs may be simpler to follow up in WGLC and IESG review. That may be discussed during next meeting.


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

I use the naming of RFC 2679, 80.


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

Reflected.


> !! Minor Typographic Points
> 
> * Sec 2.2, ".. called "points of interest", where one" should be "..
> called "points of interest," where one"

Not sure in understand.


> * Sec 2.5, odd capitalization of "One-to-group" in "Points of interest
> of One-to-group metrics are the intended,"

Reflected


> * Sec 2.7, odd capitalization of "One-way" in "For instance, if One-way
> delay,"

Reflected

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

Reflected


> * Sec 3.3, odd capitalization of "Group-to-one" and "Group-to-group"
> in "measurements on Group-to-one and Group-to-group topologies."

Reflected


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

Reflected

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

Reflected

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

Reflected

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

Not reflected because I quote the title of the section of RFC2679.

> * Sec 4.2, odd capitalization of "one-way-Packet-Loss" in "end-to-end
> one-way-Packet-Loss measurements"

Reflected

> * Sec 4.2.5, "the result includes the sequence 1,0." should be "The
> result..." but see the above discussion on this section.

Reflected

> * Sec 4.2.4, "value of Bi of 0 means that dTi is a finite value"
> should be "value of 0 for Bi means..."

Reflected

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

Reflected

> * Sec 4.4.1, odd capitalization of "Loss" in "depending on the
> consistency of the Loss threshold among the points"

Reflected


> * 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?"

Reflected

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

Right, I reviewed this section introducing an example with micro loop.

> 
> (skipped Section 5)
> 
> * Sec 6.1, odd capitalization of "Definition," "One-way," and "Delay"
> in "A Definition for one-to-group One-way Delay"

Reflected

> * Sec 6.1.2, "This parameter is to identify the measured traffic"
> should be "... to differentiate the measured traffic"

Reflected

> * Sec 6.1.2, "It is set to be optional" should be "It is optional"

Reflected


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

Reflected

> * In that same line, "singletons" metrics should perhaps be "singleton"
> 

Reflected as a "a set of Type-P-One-way-Delay singletons".


> (giving up on the odd capitalization here)

I take care of them. But several one must me handled by Lei.

> 
> * Sec 7, "They managed to collect" should be "They collect"

Reflected

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

Reflected

> * Sec 7, "However, these metrics can not" should be "... cannot"

Reflected

> * Sec 7, "later one can have statistics" should be "latter..."

Reflected

> 
> (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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/ippm