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

Al Morton <acmorton@att.com> Tue, 21 August 2007 21:47 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 1INbZ1-0008V7-S5; Tue, 21 Aug 2007 17:47:03 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INbZ0-0008V2-Ut for ippm@ietf.org; Tue, 21 Aug 2007 17:47:03 -0400
Received: from mail146.messagelabs.com ([216.82.245.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INbZ0-0005Q4-Cc for ippm@ietf.org; Tue, 21 Aug 2007 17:47:02 -0400
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-3.tower-146.messagelabs.com!1187732820!8764353!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.53]
Received: (qmail 7943 invoked from network); 21 Aug 2007 21:47:00 -0000
Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-3.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 21 Aug 2007 21:47:00 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l7LLl0vN006557 for <ippm@ietf.org>; Tue, 21 Aug 2007 17:47:00 -0400
Received: from mlph070.sfdc.sbc.com (mlph070.sfdc.sbc.com [144.155.224.139]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l7LLkwvQ006531 for <ippm@ietf.org>; Tue, 21 Aug 2007 17:46:58 -0400
Received: from sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l7LLkwpb015637 for <ippm@ietf.org>; Tue, 21 Aug 2007 17:46:58 -0400
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l7LLks1S015113 for <ippm@ietf.org>; Tue, 21 Aug 2007 17:46:55 -0400
Message-Id: <200708212146.l7LLks1S015113@mlph070.sfdc.sbc.com>
Received: from acmt.att.com (acmt.mt.att.com[135.16.251.73](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20070821214654gw10010g1de>; Tue, 21 Aug 2007 21:46:54 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 21 Aug 2007 17:45:35 -0400
To: Benoit Claise <bclaise@cisco.com>, Alan Clark <alan.d.clark@telchemy.com>
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] Comments on draft-morton-ippm-delay-var-as-03.txt
In-Reply-To: <46CABF3A.6040707@cisco.com>
References: <E1IDLSs-000733-Eq@megatron.ietf.org> <46CABF3A.6040707@cisco.com>
Mime-Version: 1.0
X-Spam-Score: 3.2 (+++)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: 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="===============1310437951=="
Errors-To: ippm-bounces@ietf.org

Hi Alan,

I agree with (a) and (b), and wrote a summary of your 2003 contribution
(thanks for the reminder, it was a good one). Perhaps we can post it
on the Packet Performance document sharing site, with your permission.

I agree with Benoit, the easy SLA formulation is a good point, but
it's one I think will fit better in section 6.5, when we're making
comparisons.

We have a placeholder for the smoothing/queuing separation problem in
3.5.  I suggest that we see what can be done to solve this problem
before we introduce it as an evaluation criteria. We've both looked
at this, with no conclusion yet.  IPPM'ers -- For more background see
http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-toffset/" rel="nofollow"> http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-toffset/

Al

At 06:32 AM 8/21/2007, Benoit Claise wrote:
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" rel="nofollow">
https://www1.ietf.org/mailman/listinfo/ippm
  

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www1.ietf.org/mailman/listinfo/ippm" rel="nofollow"> https://www1.ietf.org/mailman/listinfo/ippm
_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm