Re: [PMOL] DISCUSS: draft-ietf-pmol-sip-perf-metrics

Robert Sparks <rjsparks@nostrum.com> Thu, 03 June 2010 14:57 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: pmol@core3.amsl.com
Delivered-To: pmol@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30763A67D4 for <pmol@core3.amsl.com>; Thu, 3 Jun 2010 07:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.186
X-Spam-Level:
X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, SPF_PASS=-0.001]
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 qn4VOx8Gobli for <pmol@core3.amsl.com>; Thu, 3 Jun 2010 07:57:22 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 755893A67A3 for <pmol@ietf.org>; Thu, 3 Jun 2010 07:57:22 -0700 (PDT)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o53Euj2u057822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jun 2010 09:56:46 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <C82D1D1F.C74D%d.malas@cablelabs.com>
Date: Thu, 03 Jun 2010 09:56:45 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6B8FDF9-6405-4BFB-9AA0-71671539D99C@nostrum.com>
References: <C82D1D1F.C74D%d.malas@cablelabs.com>
To: Daryl Malas <D.Malas@cablelabs.com>
X-Mailer: Apple Mail (2.1078)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: "pmol@ietf.org" <pmol@ietf.org>
Subject: Re: [PMOL] DISCUSS: draft-ietf-pmol-sip-perf-metrics
X-BeenThere: pmol@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Performance Metrics at Other Layers <pmol.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pmol>, <mailto:pmol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pmol>
List-Post: <mailto:pmol@ietf.org>
List-Help: <mailto:pmol-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pmol>, <mailto:pmol-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2010 14:57:25 -0000

PDD is the one I feel strongly about. 

If any of the others risk the same concerns, it would make sense to switch them back too.

RjS

On Jun 3, 2010, at 9:49 AM, Daryl Malas wrote:

> Hi Robert,
> 
> Is it your opinion I switch all of the metrics back to their original names
> or just PDD?
> 
> Regards,
> 
> Daryl
> 
>> 
>> ======= NEW ISSUES with -05 =======
>> 
>> 27 I think relabeling SRD as PDD is a mistake. At the very least it is
>>   a change of such magnitude that it should be re-reviewed by the working
>>   group. SRD as defined by -04 is similar, but not an exact reflection of
>>   PDD. Saying it is "like" Post-Dial-Delay as defined in the PSTN is risky
>>   enough. Using the same name makes it even more likely that someone will
>>   come to the conclusion that it is measuring exactly the same thing. It
>>   does not. For example, it fails to capture any delay from when
>>   the user "finishes dialing" to when the INVITE is generated due to
>>   DNS processing. It would be possible to engineer highly constrained
>>   networks (that didn't use DNS or allow redirection or forking for example)
>>   where the metric might behave very much like PDD in the PSTN, but that
>>   will not be true in the general case.
>> 
>> 
>