Re: [ippm] WGLC for draft-ietf-ippm-delay-var-as.

"Geib, Ruediger" <Ruediger.Geib@t-systems.com> Fri, 10 October 2008 06:50 UTC

Return-Path: <ippm-bounces@ietf.org>
X-Original-To: ippm-archive@megatron.ietf.org
Delivered-To: ietfarch-ippm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59ABA3A6AC5; Thu, 9 Oct 2008 23:50:58 -0700 (PDT)
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11BED3A6A03 for <ippm@core3.amsl.com>; Thu, 9 Oct 2008 23:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Z1pQjYAt0Ce for <ippm@core3.amsl.com>; Thu, 9 Oct 2008 23:50:56 -0700 (PDT)
Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id B34A33A68E3 for <ippm@ietf.org>; Thu, 9 Oct 2008 23:50:55 -0700 (PDT)
Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Fri, 10 Oct 2008 08:51:30 +0200
Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Oct 2008 08:51:29 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 10 Oct 2008 08:51:28 +0200
Message-Id: <1B6169C658325341A3B8066E23919E1C01D6E47E@S4DE8PSAANK.mitte.t-com.de>
In-Reply-To: <200810092000.m99K0mLH018742@klph001.kcdc.att.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ippm] WGLC for draft-ietf-ippm-delay-var-as.
thread-index: AckqScJRdP/v2HXLRrSszhi3VjSRKQAV9Z9w
References: <48D793F6.70702@ripe.net> <48EB2039.9090105@ripe.net> <1B6169C658325341A3B8066E23919E1C01D6DD81@S4DE8PSAANK.mitte.t-com.de> <48EDC969.5050706@cisco.com> <200810092000.m99K0mLH018742@klph001.kcdc.att.com>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: acmorton@att.com
X-OriginalArrivalTime: 10 Oct 2008 06:51:29.0496 (UTC) FILETIME=[9F741D80:01C92AA4]
Cc: ippm@ietf.org
Subject: Re: [ippm] WGLC for draft-ietf-ippm-delay-var-as.
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ippm>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org

Hi Al, 

[snipped larger parts]

[Al wrote]
For example, some of your observations on re-routes may not hold for
the IPDV defined in the memo - lost packets and undefined pairs
are a key factor when trying to detect path changes with
"consecutive source packet" IPDV, as we explained.

[Ruediger]
Yes, respecting loss is one way to detect a reroute. The approach 
working with IPDV data only is described in 
draft-ietf-ippm-delay-var-as for the loss less path change (6.2.1). 
As soon as the IPDV measurement ignores losses, the method 
described there can always be applied.
I don't think that an IPDV selection funtion based on pairs of
packets in the sequence as they arrive is hard to implement. I 
further think, that this selection function has a couple of 
advantages over one respecting sequence numbers (and with that 
of course losses).

[Ruediger]
My impression is, if the aim is to learn the required dimensions of
de-jitter buffers a priori, PDV is the better choice. A network 
operator interested in learning more about the status of his 
network, may additionally use IPDV (with suitable selection and 
reporting functions).

[Ruediger]
Yes, maybe I felt the selection function your draft describes to be 
as strange as the you feel the one I describe to be...


Regards

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