Subject: Re: npmps-04

From: Al Morton <[email-masked]>
Date: Wed, 13 Dec 2000 12:52:19 -0500

Vilho, Glenn, all,

I agree with your proposed resolution, to indicate that
incT is a nominal value and list this deviation in the error section.
(I was thinking about it as error when I suggested "incTerror".)
I'm not sure if the lone bullet item is sufficient (maybe
a short subsection will help explain it, extracted from e-mails).

At least, the suggestion below may be helpful.
Thanks for addressing this,
Al

<from npmps-04>
4.6 Errors and uncertainties

   The description of any specific measurement method should include an
   accounting and analysis of various sources of error or uncertainty.
   The Framework document [1] provides general guidance on this point, 
   but we note here the following specifics related to 
>>>_periodic_streams_and_<<<< delay metrics:

   +  Error due to variation of incT
   +  Errors or uncertainties due to uncertainties in the clocks of the
      MP(Src) and MP(Dst) measurement points.
   +  others...

At 06:06 AM 12/13/00 +0200, [email-masked] wrote:
>Hello,
>
>please find attached my (intended) slides, the results document, as well as
>the v-04 of the npmps draft. Lacking my slides, I forgot the IP version from
>the list of additions to the -03 version of the metric. Moreover, I had read
>Glenn's answer to Al sloppily, which I apologize. I now realize that Glenn
>was not in favour of including error of incT into the actual metric.
>
>After some thought, I came to the conclusion that I support Glenn's proposal
>of calling incT a nominal duration of the inter-packet interval and
>mentioning the possiblility of error in discussion later. If process
>scheduling or some other reason causes marked variations in incT, this
>should be treated as a deviation from the norm rather than a part of a
>normal measurement arrangement.
>
>The only changes in v-04 to v-03 are as follows:
>
>- changed definition of incT at p. 8 into
>
>   +  incT, nominal duration of inter-packet interval
>
>- added text on incT error into Sec. 4.6:
>
>   +  Error due to variation of incT
>
>- For clarity, I added a mention of packet loss as the second sentence to to
>Sec 4.4, which now reads
>
>   The sample metric thus defined is intended to probe the delays and
>   the delay variation as experienced by multimedia streams of
>   an application. Due to the definition of the metric, also packet loss
>   status of packets is recorded. The delay is assumed to be measured at
>   transport layer level. Since a range of packet sizes and nominal 
>   interval between packets is used, the method probes only a specific 
>   time scale of network QoS variations.
>
>For those intested in a computer repair story with a human interest tint,
>I'll attach one at the end of the message. For the rest, just read the docs
>& the slides and you'll do fine.
>
>	BR,
>	   Vilho
>
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
> Vilho Räisänen                           
> [email-masked]                 
> Senior research engineer                 
> Nokia Research Center, Helsinki, Finland 
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> * * * end of real business * * *
>
>~~ How to boot up a stubborn computer - a small tale of fatherly wisdom ~~
>
>At boot, my laptop reported that it was the modem driver that caused the
>crash. From previous experience, I knew that the order in which device
>drivers are loaded sometimes makes a difference, at least in some operating
>systems. Armed with this piece of what I thought of as profound knowledge, I
>booted NT with and without my PCMCIA NIC, without CD-ROM drive and
>experimenting with all combinations. I even tried the VGA mode. To no avail.
>
>At this point I remembered my father's tale of a dysfunctional old radio. He
>told me having opened the casing, and - lacking training in electronics -
>could not do very much more. So he just blew some dust off the valves and
>closed it again. Surprise, surprise: now it worked.
>
>Lacking better ideas, I did just the same: I located the modem, opened a
>tiny cover and blew some imaginary dust off the printed board. Reassembly,
>boot - succcess.
>
>
>Attachment Converted: "C:\Utilities\Eudora\Attach\npmps-res.ppt"
>
>Attachment Converted: "C:\Utilities\Eudora\Attach\1kalvo.ppt"
>
>Attachment Converted: "C:\Utilities\Eudora\Attach\results.pdf"
>
>Attachment Converted:
"C:\Utilities\Eudora\Attach\draft-ietf-ippm-npmps-04.txt"