Thanks for your review, please see replies below.
Al
At 10:24 AM 5/8/2012, Vijay K. Gurbani wrote:
...
- Document: draft-ietf-ippm-reporting-metrics-08
- Reviewer: Vijay K. Gurbani
- Review Date: May-08-2012
- IETF LC End Date: April-11-2012
- IESG Telechat date: May-10-2012
- Summary: This draft is ready as an Informational but has some minor
- issues and nits that should be fixed before publication.
- Major issues: 0
- Minor issues: 6
- Nits/editorial comments: 5
- Minor issues:
- - S3.1: I suspect that the metrics like packet loss and packet delay
- discussed in S3.1 are for hosts on the (I)nternet and not in a
- laboratory setting, yes? If so, it may be good to state this.
IPPM's metrics are able to be used in either the cap-I Internet
or the isolated test lab, and several BMWG RFCs reference IPPM
metric definitions. When the RFC 2330 considerations are followed,
these metrics are safe to use in any setting.
- - S4.1: I would mention at the end of the paragraph that you intend
- to fill the gap in RFC2680 by providing a reasonable value for the
- waiting time.
I'll add: "We estimate a practical bound on waiting time below."
- - S4.1.1: In Figure 1, t_0 is probably the delay in the initial
- link before you get to the first router. If so, please make this
- explicit.
To address Adrian Farrell's Comment, we've added path models for
the normal and loop cases, above each equation.
- - S4.1.1: Just curious --- you provide a rationale for the choice
- of link delay of 100ms and queue length of 100ms. But n=5 and L=4
- seem to be magic numbers. I suspect that the choice of these is
- sound, but a couple of words on why the values of these variables
- are set to the ones shown would be good.
there's nothing special about n=5 and L=4.
Together n, L and TTL determine C_max, which I will note that
we use in the calculation, just to be clear.
- - S5.1.1: In the two bullet items here, you posit that processes
- are spawned when an unexpected condition occurs. Why should this
- be a process? Why not a thread? Or a light-weight process? Or
- an event loop? My point is to stay away from well known and
- contextual words that dictate a specific architecture; i.e., the
- receiver spawns processes to handle an event. Better to be generic,
- something like the following (please modify as you see fit):
I thought process *was* generic, but will try your suggested text.
Is "operations" sufficiently generic?
- OLD:
- o Packets that arrive within expected tolerance are handled by
- processes that remove headers, restore smooth delivery timing (as
- in a de-jitter buffer), restore sending order, check for errors in
- payloads, and many other operations.
- o Packets that do not arrive when expected spawn other processes
- that attempt recovery from the apparent loss, such as
- retransmission requests, loss concealment, or forward error
- correction to replace the missing packet.
- NEW:
- o Packets that arrive within expected tolerance are handled by
- removing headers, restoring smooth delivery timing (as
- in a de-jitter buffer), restoring sending order, checking for
- errors in payloads, and many other operations.
- o Packets that do not arrive when expected lead to an attempted
- recovery from the apparent loss, such as retransmission
- requests, loss concealment, or forward error correction to
- replace the missing packet
- - S5.1.2: Figure 3 --- if I understand the surrounding text for Figure
- 3 correctly, then to show a "small fraction of packets are lost",
- the CDF curve should be asymptotic to the Y-axis and then become
- stable at the Y=1 value (i.e., be asymptotic to it). We want to
- denote that almost 100% of the packets exhibit a loss close to 0.
I think that might be the Loss CDF, but this is the Delay CDF when
Lost Packets are assigned delay = +infinity.
The text says:
- "As further evidence of overlap, consider the Cumulative Distribution Function (CDF) of Delay when the value "positive infinity" is assigned to all lost packets."
on the same dimension...
- Nits:
- - S1: While characterizing the main audience, I am not sure what
- "consumer" means --- is it synonymous with "user"? And if so, I
- think that replacing consumer with user may be better. If these
- terms are not synonymous, then please provide a definition (even a
- loose one) of what a consumer is.
"user" is too vague and also has a strong precedent in the computer
networking context - we can add an adjective:
s/consumer/report consumer/
- - S3.1, seems like a grammatical error in the sentence:
- "We have calculated a waiting time above that should be sufficient
- to differentiate between packets that are truly lost or have long
- finite delays under general measurement circumstances, 51 seconds."
- Probably better to rephrase as:
- "We have calculated that under general measurement circumstances,
- 51 seconds is an appropriate length of time to differentiate between
- packets that are truly lost from packets that are experiencing
- long finite delays."
My grammar-checker accepted a slightly revised version,
with s/above/in section 4.1.1/
- - S4.1.1: Right before Figure 1, you define D. My suggestion would
- be to replace the text:
- "The normal path delay across n hops without encountering a
- loop, D, is"
- with
- "The normal path delay, D, across n hops without encountering a
- loop is"
- Here, "D" is qualifying the delay, not the loop. So it is best
- close to the word "delay".
OK
- - S5.1.2: In Figure 3, I would suggest using "+Inf" instead of
- "+o0" to denote infinity. It took me a while to figure out that
- the latter is an ASCII approximation to infinity.
So far, everybody else got it...
OK
- - S6.6: In the section heading, I would advise spelling out
- "Avail." completely. Truncating it as such serves no purpose that
- I could see and simply acts as a detraction.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
