Subject: RE: npmps-04

From: Grotefeld Glenn-cecl03 <[email-masked]>
Date: Fri, 15 Dec 2000 15:25:13 -0600

Vilho,

It appears that your text REPLACE command played a trick on you.  In a number of places (I won't say every case), where you intended to update the expiration from "May 2001" to "June 2001", it also replaced " may" in the text with "June".

I leave it to our chairs to inform us whether we should be using the official IETF file identifiers in a version that is circulated directly rather than sent to the Internet drafts sited and then posted and announced.  Do we need to go to -05 for the next version?

Glenn Grotefeld

Motorola, Inc.
[email-masked]
US  847 576-5992
      847 538-7455  FAX

~-----Original Message-----
~From: [email-masked] [mailto:[email-masked]]
~Sent: Tuesday, December 12, 2000 10:07 PM
~To: [email-masked]
~Cc: [email-masked]; [email-masked]
~Subject: npmps-04
~
~
~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.
~
~