Return-Path: 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 12C563A6895 for ; Mon, 28 Jun 2010 07:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599] 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 X0fdwnywcb1a for ; Mon, 28 Jun 2010 07:53:07 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 252713A6851 for ; Mon, 28 Jun 2010 07:53:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,497,1272859200"; d="scan'208";a="225281144" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Jun 2010 10:53:16 -0400 X-IronPort-AV: E=Sophos;i="4.53,497,1272859200"; d="scan'208";a="476582961" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Jun 2010 10:53:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jun 2010 16:53:03 +0200 Message-ID: In-Reply-To: <201006281417.o5SEHthw022056@alpd052.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PMOL] Informal pmol lunch session at IETF-78 Thread-Index: AcsWzMGlEPk5g21tQtOFSDiqh1GmlgABH0bg References: <201006281417.o5SEHthw022056@alpd052.aldc.att.com> From: "Romascanu, Dan (Dan)" To: "Al Morton" , Subject: Re: [PMOL] Informal pmol lunch session at IETF-78 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 14:53:08 -0000 I would like to make sure that discussing the follow-up of pmol is part of the 'other business'. We need to wrap up the long time due documents in works and to make a recommendation about similar work will be made in the IETF in the future.=20 Dan > -----Original Message----- > From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On=20 > Behalf Of Al Morton > Sent: Monday, June 28, 2010 5:18 PM > To: pmol@ietf.org > Subject: [PMOL] Informal pmol lunch session at IETF-78 >=20 > Folks, >=20 > the pmol wg will meet informally for a (bring-your-own) lunch=20 > on Friday, July 30, at 11:30 local time. >=20 > the meeting place will be announced later. >=20 > the Agenda includes the status of both our current drafts,=20 > and any other business. >=20 > regards, > Al > pmol co-chair >=20 > _______________________________________________ > PMOL mailing list > PMOL@ietf.org > https://www.ietf.org/mailman/listinfo/pmol >=20 Return-Path: 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 7D2F228C110 for ; Mon, 28 Jun 2010 07:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.382 X-Spam-Level: X-Spam-Status: No, score=-105.382 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 zYLzvd3tXJsw for ; Mon, 28 Jun 2010 07:18:02 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id BB19228C11F for ; Mon, 28 Jun 2010 07:18:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1277734690!57860985!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 3071 invoked from network); 28 Jun 2010 14:18:11 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jun 2010 14:18:11 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o5SEIPYu014229 for ; Mon, 28 Jun 2010 10:18:25 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o5SEIIZ7014153 for ; Mon, 28 Jun 2010 10:18:18 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o5SEI39m022242 for ; Mon, 28 Jun 2010 10:18:03 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o5SEHthw022056 for ; Mon, 28 Jun 2010 10:17:56 -0400 Message-Id: <201006281417.o5SEHthw022056@alpd052.aldc.att.com> Received: from acmt.att.com (dn135-16-251-71.dhcpn.ugn.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100628141755gw100s4ppoe>; Mon, 28 Jun 2010 14:17:55 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Jun 2010 10:18:13 -0400 To: pmol@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [PMOL] Informal pmol lunch session at IETF-78 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 14:18:05 -0000 Folks, the pmol wg will meet informally for a (bring-your-own) lunch on Friday, July 30, at 11:30 local time. the meeting place will be announced later. the Agenda includes the status of both our current drafts, and any other business. regards, Al pmol co-chair Return-Path: 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 9D1113A6839 for ; Fri, 4 Jun 2010 08:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.026 X-Spam-Level: ** X-Spam-Status: No, score=2.026 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 o9wgsc77LB1w for ; Fri, 4 Jun 2010 08:06:56 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 88B373A6800 for ; Fri, 4 Jun 2010 08:06:56 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o54F6dqm010381; Fri, 4 Jun 2010 09:06:40 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Fri, 4 Jun 2010 09:06:39 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 4 Jun 2010 09:06:40 -0600 From: Daryl Malas To: Marian Delkinov , Robert Sparks Date: Fri, 4 Jun 2010 09:06:40 -0600 Thread-Topic: [PMOL] DISCUSS: draft-ietf-pmol-sip-perf-metrics Thread-Index: AcsDLQ9YG+rpdBo7QsWWi7zREsG1tgAk4f/QAA28aVM= Message-ID: In-Reply-To: <0F407DE9946A304F81F5C37C1DB6002A02298EAFB8@ESESSCMS0359.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.4.0.100208 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:06:57 -0000 Mario, Thanks for the feedback. It appears I may have gone to far to the "basic telephony" side, and I will change the metric names back to their -04 names= . Regards, Daryl On 6/4/10 6:09 AM, "Marian Delkinov" wrote: > =20 > Regarding the new issues with -05: >=20 > I have similar concerns about relabeling the following metrics: >=20 > Session Duration Time (SDT) --> Call Hold Time (CHT) >=20 > Although this metric corresponds to Call Holding Time in the telephony, t= his > may lead to confusion that it's exactly the same thing. Still, here we re= fer > to sessions that may not always relate to calls. So, I would prefer keepi= ng > the term "Session". >=20 > Session Establishment Ratio (SER) --> Answer Seizure Ratio (ASR) >=20 > The term "Seizure" is used in the telephony signalling. In SIP we have > "Invite". If in the telephony we use "Answer to Seizure Ratio" to identif= y the > % of answered vs all initiated calls, I strongly feel we should avoid usi= ng > the same terms "Answer" and "Seizure" in SIP. If there is any real need t= o > change the metric label, it would make more sense to use "Invite Success = Rate" > or similar.=20 >=20 > Session Establishment Effectiveness Ratio (SEER) --> Network Effectivenes= s > Ratio (NER) > The same thoughts: If we use NER, perhaps many will start comparing the > measurement results with the TDM telephony, while here we have larger sco= pe > and different results. >=20 > In earlier Comments Robert wrote: > 19 The ratio metrics don't define (or convey) the interval that totals > are taken over. Are these supposed to be "# requests received since > this instance was manufactured' or "since last reboot" or "since last > reset of statistics" or something else? What is the implementation > supposed to report when the denominator of a ratio is 0? >=20 > I propose a text to be inserted for all ratio metrics (may be valid for t= ime > metrics as well) specifying recommended measurements granularity of a 15 = min > interval. That interval can be used for benchmarking. All other granulari= ties > can also be supported, e.g. 1 min (for real time measurements), 3 min, 5 = min, > 30 min, 60 min etc. Thus various reports can later be generated based on = these > granularities. The same granularity intervals are widely used for the sim= ilar > metrics in the TDM Telephony. How the counters are organized can be left = to > the manufacturers, but I also thought about the option to consider a stan= dard > MIB (like MIB II) for the counters that SIP end-to-end performance metric= s are > derived from. >=20 > At the end of chapter 4.7: > "Reference the example flow is Section 4.7." > Looks like the intention was to refer to Section 4.6? >=20 > Regards! > Mario. >=20 >=20 > -----Original Message----- > From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf Of R= obert > Sparks > Sent: Thursday, 03 June, 2010 16:57 > To: Daryl Malas > Cc: pmol@ietf.org > Subject: Re: [PMOL] DISCUSS: draft-ietf-pmol-sip-perf-metrics >=20 > PDD is the one I feel strongly about. >=20 > If any of the others risk the same concerns, it would make sense to switc= h > them back too. >=20 > RjS >=20 > On Jun 3, 2010, at 9:49 AM, Daryl Malas wrote: >=20 >> Hi Robert, >>=20 >> Is it your opinion I switch all of the metrics back to their original >> names or just PDD? >>=20 >> Regards, >>=20 >> Daryl >>=20 >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D NEW ISSUES with -05 =3D=3D=3D=3D=3D=3D=3D >>>=20 >>> 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 worki= ng >>> 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 ri= sky >>> enough. Using the same name makes it even more likely that someone wi= ll >>> come to the conclusion that it is measuring exactly the same thing. I= t >>> 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 exa= mple) >>> where the metric might behave very much like PDD in the PSTN, but tha= t >>> will not be true in the general case. >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > PMOL mailing list > PMOL@ietf.org > https://www.ietf.org/mailman/listinfo/pmol > _______________________________________________ > PMOL mailing list > PMOL@ietf.org > https://www.ietf.org/mailman/listinfo/pmol Return-Path: 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 C614E3A6979 for ; Fri, 4 Jun 2010 05:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 VXi7tTzcPtAK for ; Fri, 4 Jun 2010 05:09:18 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 807393A67EA for ; Fri, 4 Jun 2010 05:09:18 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-5a-4c08ecdf5a19 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 65.A8.06817.FDCE80C4; Fri, 4 Jun 2010 14:09:03 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.2.92]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 4 Jun 2010 14:09:03 +0200 From: Marian Delkinov To: Robert Sparks , Daryl Malas Date: Fri, 4 Jun 2010 14:09:01 +0200 Thread-Topic: [PMOL] DISCUSS: draft-ietf-pmol-sip-perf-metrics Thread-Index: AcsDLQ9YG+rpdBo7QsWWi7zREsG1tgAk4f/Q Message-ID: <0F407DE9946A304F81F5C37C1DB6002A02298EAFB8@ESESSCMS0359.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 12:09:19 -0000 =20 Regarding the new issues with -05: I have similar concerns about relabeling the following metrics: Session Duration Time (SDT) --> Call Hold Time (CHT) Although this metric corresponds to Call Holding Time in the telephony, thi= s may lead to confusion that it's exactly the same thing. Still, here we re= fer to sessions that may not always relate to calls. So, I would prefer kee= ping the term "Session".=20 Session Establishment Ratio (SER) --> Answer Seizure Ratio (ASR) The term "Seizure" is used in the telephony signalling. In SIP we have "Inv= ite". If in the telephony we use "Answer to Seizure Ratio" to identify the = % of answered vs all initiated calls, I strongly feel we should avoid using= the same terms "Answer" and "Seizure" in SIP. If there is any real need to= change the metric label, it would make more sense to use "Invite Success R= ate" or similar.=20 Session Establishment Effectiveness Ratio (SEER) --> Network Effectiveness = Ratio (NER) The same thoughts: If we use NER, perhaps many will start comparing the mea= surement results with the TDM telephony, while here we have larger scope an= d different results. In earlier Comments Robert wrote: 19 The ratio metrics don't define (or convey) the interval that totals are taken over. Are these supposed to be "# requests received since this instance was manufactured' or "since last reboot" or "since last reset of statistics" or something else? What is the implementation supposed to report when the denominator of a ratio is 0? I propose a text to be inserted for all ratio metrics (may be valid for tim= e metrics as well) specifying recommended measurements granularity of a 15 = min interval. That interval can be used for benchmarking. All other granula= rities can also be supported, e.g. 1 min (for real time measurements), 3 mi= n, 5 min, 30 min, 60 min etc. Thus various reports can later be generated b= ased on these granularities. The same granularity intervals are widely used= for the similar metrics in the TDM Telephony. How the counters are organiz= ed can be left to the manufacturers, but I also thought about the option to= consider a standard MIB (like MIB II) for the counters that SIP end-to-end= performance metrics are derived from. At the end of chapter 4.7: "Reference the example flow is Section 4.7." Looks like the intention was to refer to Section 4.6? Regards! Mario. -----Original Message----- From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf Of Rob= ert Sparks Sent: Thursday, 03 June, 2010 16:57 To: Daryl Malas Cc: pmol@ietf.org Subject: Re: [PMOL] DISCUSS: draft-ietf-pmol-sip-perf-metrics PDD is the one I feel strongly about.=20 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, >=20 > Is it your opinion I switch all of the metrics back to their original=20 > names or just PDD? >=20 > Regards, >=20 > Daryl >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D NEW ISSUES with -05 =3D=3D=3D=3D=3D=3D=3D >>=20 >> 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 workin= g >> group. SRD as defined by -04 is similar, but not an exact reflection o= f >> PDD. Saying it is "like" Post-Dial-Delay as defined in the PSTN is ris= ky >> enough. Using the same name makes it even more likely that someone wil= l >> 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 exam= ple) >> where the metric might behave very much like PDD in the PSTN, but that >> will not be true in the general case. >>=20 >>=20 >=20 _______________________________________________ PMOL mailing list PMOL@ietf.org https://www.ietf.org/mailman/listinfo/pmol Return-Path: 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 017BD3A6A2E for ; Thu, 3 Jun 2010 13:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.196 X-Spam-Level: X-Spam-Status: No, score=-107.196 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 0+JIUKWaA8Vz for ; Thu, 3 Jun 2010 13:00:56 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id CD9603A6A2A for ; Thu, 3 Jun 2010 13:00:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-10.tower-129.messagelabs.com!1275595242!48332706!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 12872 invoked from network); 3 Jun 2010 20:00:43 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-10.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Jun 2010 20:00:43 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o53K0ujC007571 for ; Thu, 3 Jun 2010 16:00:56 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o53K0oxP007400 for ; Thu, 3 Jun 2010 16:00:50 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o53K0a1j025416 for ; Thu, 3 Jun 2010 16:00:36 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o53K0XqI025242 for ; Thu, 3 Jun 2010 16:00:33 -0400 Message-Id: <201006032000.o53K0XqI025242@alpd052.aldc.att.com> Received: from acmt.att.com (dn135-16-251-71.dhcpn.ugn.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100603200033gw100s4p33e>; Thu, 3 Jun 2010 20:00:33 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Jun 2010 15:59:34 -0400 To: pmol@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [PMOL] Fwd: IETF 78 - Meeting and Sponsorship Information X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 20:00:57 -0000 >From: IETF Secretariat >To: Working Group Chairs >Subject: IETF 78 - Meeting and Sponsorship Information >Date: Thu, 3 Jun 2010 12:51:40 -0700 (PDT) >X-BeenThere: wgchairs@ietf.org >X-Mailman-Version: 2.1.9 >List-Id: Working Group Chairs >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >Sender: wgchairs-bounces@ietf.org > >Working Group Chairs, > >Can you please forward this message to your individual working group >emails lists. We want to ensure that as many people as possible are aware >of the sponsorship opportunities available at IETF meetings. > >Thank you. >========================================== >78th IETF Meeting >Maastricht, Netherlands >July 25-30, 2010 > >1. Sponsorship Opportunities >2. Registration Types >3. Visas and Letters of Invitation >4. Accommodations & Breakfast Information >5. IETF 79 (Beijing) Visa Information > >1) Sponsorship Opportunities >There are still sponsorship opportunities and benefits for high profile >company/organizational exposure at the upcoming IETF meeting in >Maastricht, Netherlands from July 25-30, 2010. All sponsorship fees go >directly to fund the operations of the IETF. See the options at: >http://www.ietf.org/meeting/78/index.html "Sponsorship Opportunities" >under "General". Each of the sponsorship options provide extended and >repeat exposure at this weeklong meeting. > >Please contact Drew Dvorshak, dvorshak@isoc.org, with any questions >and/or to reserve your organization's spot. Thanks in advance for >supporting the critical work of the IETF! > >2) Register online at: http://www.ietf.org/meetings/78/ > >3) Letters of Invitation and Visas >Letters of Invitation >After you complete the meeting registration process, you will be given the >option to request a letter of invitation. You can request the Letter of >Invitation as soon as you finish registration, or at a later time by >following the link provided in the confirmation email. > >Visas >Please check the Netherlands Ministry of Foreign Affairs site >(http://www.minbuza.nl/en/Services/Consular_Services/Visa) for list of >countries with visa exemptions. > >We recommend you give yourself at least one month to complete the visa >process. > >4) Accommodations & Breakfast Information >http://www.ietf.org/meeting/78/hotel.html > >5) If you want to start planning for your trip to IETF 79 in Beijing, we >have visa information online here: >http://www.ietf.org/meeting/79/visa.html > >Only 52 days until IETF 78! Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: Date: Thu, 3 Jun 2010 09:56:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Daryl Malas 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 14:57:25 -0000 PDD is the one I feel strongly about.=20 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, >=20 > Is it your opinion I switch all of the metrics back to their original = names > or just PDD? >=20 > Regards, >=20 > Daryl >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D NEW ISSUES with -05 =3D=3D=3D=3D=3D=3D=3D >>=20 >> 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. >>=20 >>=20 >=20 Return-Path: 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 4B1813A68BE for ; Thu, 3 Jun 2010 07:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.137 X-Spam-Level: ** X-Spam-Status: No, score=2.137 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 gzPyQ2RSF4NU for ; Thu, 3 Jun 2010 07:49:55 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 7400D3A67BD for ; Thu, 3 Jun 2010 07:49:55 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o53EnaX7024650; Thu, 3 Jun 2010 08:49:36 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 3 Jun 2010 08:49:36 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 3 Jun 2010 08:49:36 -0600 From: Daryl Malas To: Robert Sparks Date: Thu, 3 Jun 2010 08:49:35 -0600 Thread-Topic: [PMOL] Re: DISCUSS: draft-ietf-pmol-sip-perf-metrics Thread-Index: AcsCn/s+79r/4NFYQiCWskERhmeXLAAjABfJ Message-ID: In-Reply-To: <20100602220734.7638F3A6A1F@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.4.0.100208 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "pmol@ietf.org" Subject: [PMOL] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 14:49:56 -0000 Hi Robert, Is it your opinion I switch all of the metrics back to their original names or just PDD? Regards, Daryl >=20 > =3D=3D=3D=3D=3D=3D=3D NEW ISSUES with -05 =3D=3D=3D=3D=3D=3D=3D >=20 > 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 workin= g > group. SRD as defined by -04 is similar, but not an exact reflection o= f > PDD. Saying it is "like" Post-Dial-Delay as defined in the PSTN is ris= ky > enough. Using the same name makes it even more likely that someone wil= l > 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 exam= ple) > where the metric might behave very much like PDD in the PSTN, but that > will not be true in the general case. >=20 >=20