Subject: RE: FW: draft-ietf-ippm-npmps-03.txt; IPPM-style measurement res ults

From: Grotefeld Glenn-cecl03 <[email-masked]>
Date: Fri, 8 Dec 2000 08:57:00 -0600

Al,

One item to be concerned about is that with a MP(Src) that is truly independent of Src, MP (Src)is NOT responsible for sending times, but merely reports on them.  I wanted the flexibility for Src can generate packets that may not follow the "incT" interval, but without any other signaling or messaging that could distort the performance compared to times when Src is NOT being measured.

I am NOT convinced that we should introduce this change. Rather than introducing a new variable, I would prefer to change the description to " +  nominal periodic packet interval incT, a time duration".  This would increase the tie-in to section 4.3, where the general description of the procedure calls incT a "nominal interval".

If we do go forward with a change, I would suggest something other than "incTerror", which suggests incremental terror. 8-)

Glenn Grotefeld

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

~-----Original Message-----
~From: Al Morton [mailto:[email-masked]]
~Sent: Thursday, December 07, 2000 7:59 PM
~To: [email-masked]
~Subject: Re: FW: draft-ietf-ippm-npmps-03.txt; IPPM-style measurement
~results
~
~
~Vilho, Glenn, and all,
~
~Your new draft deserves at least one (minor) comment.
~
~Section 4.2.1 gives the Global Metric Parameters,
~one of which is: 
~+  periodic packet interval incT, a time duration
~
~In practice, it may be difficult for measurement sources
~to maintain this periodic sending interval exactly.
~I'd like to suggest adding a new parameter for section 
~4.2.2 Metrics Reported at MP(Src) to cover the cases
~where sending times have some variation from the ideal interval.
~Something like:
~+ incTerror, offset from the specified incT 
~(could be reported on a per packet basis, or as a range
~at the end of test).
~
~Note that packetized real-time media streams from users
~may also exhibit variation from strict periodic launch times. 
~The point is to capture and report any variation
~so it doesn't get lost.
~
~Regards,
~Al Morton
~
~
~
~At 03:47 PM 11/22/00 +0200, [email-masked] wrote:
~>
~>
~>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
~> Vilho Räisänen                           
~> [email-masked]                 
~> Senior research engineer                 
~> Nokia Research Center, Helsinki, Finland 
~>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
~>
~>Dear IPPM list members,
~>
~>I submitted the latest revised form (-03) of the npmps draft 
~>today to [email-masked]; it is also available at
~>
~>http://www-nrc.nokia.com/netperf/npmps-03.txt
~>
~>Moreover, following the advice of IPPM chairs, I made an 
~>independent draft submission of VoIP media stream emulation 
~>measurement results using metrics using npmps-like metrics. 
~>The full draft with figures is available from
~>
~>http://www-nrc.nokia.com/netperf/results.pdf
~>
~>and a version with good old ASCII from
~>
~>http://search.ietf.org/internet-drafts/draft-raisanen-ippm-npm
~ps-results-00.
~>txt
~>
~>	Cheers,
~>		Vilho
~>
~>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
~> Vilho Räisänen                           
~> [email-masked]                 
~> Senior research engineer                 
~> Nokia Research Center, Helsinki, Finland 
~>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
~>
~>
~>
~