Re: [ippm] Comments on draft-morton-ippm-delay-var-as-03.txt

Benoit Claise <bclaise@cisco.com> Tue, 21 August 2007 10:32 UTC

Return-path: <ippm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INR2F-0007L8-55; Tue, 21 Aug 2007 06:32:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INR2D-0007L1-QS for ippm@ietf.org; Tue, 21 Aug 2007 06:32:29 -0400
Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INR2C-0004Ul-C5 for ippm@ietf.org; Tue, 21 Aug 2007 06:32:29 -0400
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l7LAWRX05575; Tue, 21 Aug 2007 12:32:27 +0200 (CEST)
Received: from [10.61.65.81] (ams3-vpn-dhcp337.cisco.com [10.61.65.81]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l7LAWQQ11870; Tue, 21 Aug 2007 12:32:26 +0200 (CEST)
Message-ID: <46CABF3A.6040707@cisco.com>
Date: Tue, 21 Aug 2007 12:32:26 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: Alan Clark <alan.d.clark@telchemy.com>
Subject: Re: [ippm] Comments on draft-morton-ippm-delay-var-as-03.txt
References: <E1IDLSs-000733-Eq@megatron.ietf.org>
In-Reply-To: <E1IDLSs-000733-Eq@megatron.ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Cc: 'Al Morton' <acmorton@att.com>, ippm@ietf.org
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0314044452=="
Errors-To: ippm-bounces@ietf.org

Alan,
> General:
> (a). It may be useful to incorporate a reference to ITU-T G.1050.  
> This is an IP impairment model that is somewhat oriented toward 
> modeling congestion over limited bandwidth links, providing a useful 
> tool for experimenting with and testing PDV measurement techniques.  
> G.1050 is based on a time series model that was originally developed 
> as a potential PDV measurement algorithm.
>  
> (b) ITU-T COM12-D98 "Analysis, measurement and modelling of jitter" 
> (2003) provided some useful background on the sources and measurement 
> of jitter.  This also pointed out some significant characteristics of 
> the PPDV performance metrics that affect reported values with 
> particular patterns of delay (e.g. delay ramps, alternate pairs of 
> early late packets......)
>  
> 3.4 Service Level Comparison
> IMHO - percentile based approaches are particularly suitable for SLA 
> agreements.  It is both easy to specify and easy to implement an SLA 
> measurement of the type "no more than x% of packets shall arrive 
> later than y milliseconds". 
This is a good point when comparing IPDV versus PDV. The percentile in 
PDV represents a single simple metric.
We should add that into the draft.

Regards, Benoit.
> This is similar to (within the scope of?) Y.1540 however reports the 
> percentage of packets outside some given threshold rather than the 
> threshold that corresponds to some given percentile.
>  
> 3.5 Separation of scheduling/ smoothing PDV from PDV introduced by the 
> network. 
> Some delay variation may be introduced by packet scheduling for 
> smoothing purposes or the queuing of packets within sending systems.  
> Smoothing could potentially be introduced by shaping devices in the 
> network.  If packet spacing/ size is uniform then this smoothing or 
> shaping would not necessarily result in PDV however for any system 
> that uses irregular or bursty packet transmission smoothing/ shaping 
> is likely to result in PDV that could in some cases significantly 
> exceed the PDV due to network congestion.  From the perspective of 
> network performance monitoring it is very useful to separate the two 
> components of smoothing/ shaping PDV (which would result in strong 
> correlation between delay variation and the bandwidth of the test 
> signal) and PDV due to other sources (which "should" be weakly 
> correlated or uncorrelated with the current bandwidth of the test signal).
>   
> Regards
>  
> Alan
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org 
> https://www1.ietf.org/mailman/listinfo/ippm
>   

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm