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