[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:"[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: