Subject: RE: draft-ietf-ippm-npmps-01.txt

From: [email-masked]
Date: Thu, 11 May 2000 13:09:03 +0300

Al,

thanks for the comments. The per-domain issue should (and will) be further
clarified along the lines that you outlined. The quoted sentence in the
draft is really a placeholder for more detailed information, and I have some
references for that.

	Regards,
		Vilho

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
 Vilho Räisänen                           
 [email-masked]                 
 Nokia Research Center, Helsinki, Finland 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

> -----Original Message-----
> From: EXT Al Morton [mailto:[email-masked]]
> Sent: 09. May 2000 15:32
> To: [email-masked]
> Subject: Re: draft-ietf-ippm-npmps-01.txt
> 
> 
> [email-masked],
> New Draft, a few more suggestions:
> 
> Section 3.2, first Paragraph, 3rd sentence:
> "End-to-end delay may be best managed in the general case 
> by assigning maximum per-domain quotas (e.g. 50 ms for a 
> particular IP domain)." 
> 
> I agree that in some cases, delay can be managed
> on a per-domain basis by setting only a maximum. An example
> would be where the max delay threshold for a domain
> is very low (e.g., 10 ms), and the application is fairly
> tolerant of end-end delay variation.
> However, the general case must evaluate:
> * Domains with long 1-way delays (>100 ms).
> * Domains with considerable delay variation (100 ms Max, >80 ms range
> for a sample).
> * Applications of periodic streams with stringent delay variation
> requirements.
> So the general case should include both delay max and some measure of
> delay variation (ipdv, or 1-way delay range). You could mention this
> general case, then go on to describe the case where a Max delay quota 
> may be sufficient.
> 
> Section 3.5.2 Paired one way measurement, second paragraph.
> "Moreover, paired one way delay measurement emulates a full-duplex
> VoIP call more accurately than a single one-way measurement only."
> 
> To motivate paired one way measurement, it may be helpful to cite
> the possible reasons for better accuracy.  For example: 
> - Performance of some 1-way links depends on conditions in the reverse
> direction.
> - Many two-way real-time applications have unsatisfactory 
> performance if
> packet transfer suffers in a single direction.
> 
> (more to follow)
> Al
>