Guy,
Thanks for the comments. I agree with Les' thoughts on your comments.
I'd like to add a couple other things on these issues.
First, it is certainly not our intention to conflict with, modify, or
suggest changes to 2679 or 2681. In fact, the general spirit of the
whole section should be captured (or we tried to capture) in the first
two sentences, which try to refer the reader to those docs for more
information. There are essentially three purposes to the section:
- list and explain the delay characteristics in the hierarchy
- briefly summarize the most important issues
- discuss differences between the right way (IPPM) and existing ways of
measuring/reporting data
--On Friday, March 19, 2004 02:48:43 PM -0500 Guy T Almes
<almes@internet2.edu> wrote:
[Section 8: Delay Characteristics]
Near the bottom of page 20, the text notes that "The above raises several
issues including:" and lists three points.
The nature of the three 'issues' seems neither clear nor consistent.
The first seems to be an observation that it's hard to measure one-way
delay without synchronizing time. Maybe this is really just an
observation. If so, it's exactly right: doing a good job of measuring
one-way delay usually requires lots of work to succeed at achieving good
synchronization. Is the 'issue' more than that observation?
The second seems to perhaps be seeking clarification on how one-way delay
is defined when the packet is fragmented. If this is a claim that RFC
2679 is incomplete on this point, then that would be good to state.
Otherwise, it's not clear what the 'issue' is.
The third seems similar to the first -- achieving accuracy in
measurements is hard work, and characterizing the accuracy of a
measurement is subtle. Is that what is being said?
In short, this portion of the document is vague and may or may not be
asking questions about the accuracy or completeness of RFC 2679. Both
the intent and the substance of the section should be (dropped or)
clarified.
I might try to clarify the text by replacing "The above raises several
issues including:"
with something like
"Issues complicating the precise measurement of delay include:"
[Section 8.3: Issues in Measuring Delay]
The next-to-last paragraph goes off topic and discusses an interesting
issue of reporting and of statistics of sets of delay measurements,
specifically in the context of how to deal with delay Observations that
cannot be completed since the launched packet never arrives. My first
point is that this is off-topic (since it does not relate to "issues in
measuring") and should perhaps be placed under a separate section called
something like "interpretation of sets of Observations".
The cited RFCs take what might be characterized as a cautious -- perhaps
over-cautious -- view and should perhaps be critiqued from time to time.
The NM-WG should consider that these cautious positions were not lightly
taken, of course.
Specifically, as regards isolated instances of One-way Delay Observations
(what 2679 calls Singletons), it would seem to be useful, and certainly
not harmful, to retain the idea that attempts to launch a one-way delay
Observation that do not complete due to packet loss can be characterized
as having Infinite delay. How that infinite delay is interpreted is a
separate matter. In some cases, it might make sense to interpret
Infinite as 'inconclusive' (in all good humor, I append a lame joke
peculiar to my native land in which a similar interpretation is made).
We indeed have much to learn about about the phenomena of delay and its
impacts on applications. Three points summarize part of what the
cautious view is taken in 2679:
I don't think that the authors of the hierarchy document could possibly
agree more with the principle of recording lost packets, or with trying
to stop people from using mean and stddev to describe such non-gaussian
behavior as delay. There is an issue here in that we are trying to
maximize compatibility and portability, so all existing measurement
systems can be described, rather than specify absolute correctness (as is
rightly the mission of IPPM). I think we fell too far in that direction
here (actually I think 8.3 used to be longer, but someone, quite possibly
me, edited it down too far). The points I would like to be made are:
- this is the right way to do it
- this is the way you should do it
- some systems don't report it this way
- we can't actually kill them for this, but should apply pressure
As written now, I think it appears to brush off the issue, which it
shouldn't.
I hope that with some rewording, we can make sure this section is clear
on its intentions.
Bruce Lowekamp