Subject: [Gen-art] Gen-ART review of draft-ietf-ippm-reporting-metrics-08

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 08 May 2012 09:24:37 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

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.

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

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

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

- 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):

  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.

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.

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

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

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

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

Thanks!	

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Al Morton <[email-masked]>
Date: Tue, 08 May 2012 11:13:31 -0400

Hi Vijay,

Thanks for your review, please see replies below.

Al

At 10:24 AM 5/8/2012, Vijay K. Gurbani wrote:

...

Review Date: May-08-2012

Major issues: 0

Minor issues: 6

Minor issues:

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.

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

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.

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

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.

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

- 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."
I think you've helped make our case, it's confusing to mix Loss and
Delay

on the same dimension...

Nits:

"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

"user" is too vague and also has a strong precedent in the
computer

networking context - we can add an adjective:

s/consumer/report consumer/

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

"We have calculated that under general measurement
circumstances,

51 seconds is an appropriate length of time to differentiate
between

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

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

So far, everybody else got it...

"Avail." completely.  Truncating it as such
serves no purpose that

OK

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 08 May 2012 10:42:57 -0500

> Thanks for your review, please see replies below.

Al: Thanks for indulging me.  Points worth spending one more iteration
on are below.

> I thought process *was* generic, but will try your suggested text.

Thanks.

> Is "operations" sufficiently generic?

I think so; the term "operations" existed in your original writeup
and I simply reused it.

> I think that might be the Loss CDF,

Ah, right.

> but this is the Delay CDF when Lost Packets are assigned delay = +infinity.

OK.

> "user" is too vague and also has a strong precedent in the computer

I tried to re-read the sentences with s/consumer/report consumer/, but
I must admit that I am none the wiser.  Maybe s/consumer/audience/?

> with s/above/in section 4.1.1/

The original sentence seems odd --- the object of the calculated waiting
time (51 seconds) appears at the end of the sentence.  By the time the
reader gets to the ", 51 seconds", he or she may have lost the context
of why 51 seconds is important.

> So far, everybody else got it...

OK, no problem.  Please do retain the original text.

Thank you for your time, Al!

- vijay