Return-Path: X-Original-To: pmol-archive@optimus.ietf.org Delivered-To: ietfarch-pmol-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890ED3A69A0; Tue, 29 Apr 2008 00:52:03 -0700 (PDT) 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 ADE883A69FF for ; Tue, 29 Apr 2008 00:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 9kQx4qwxiyDz for ; Tue, 29 Apr 2008 00:51:58 -0700 (PDT) Received: from mx2.sjtu.edu.cn (mx.sjtu.edu.cn [202.112.26.52]) by core3.amsl.com (Postfix) with ESMTP id E57B03A6975 for ; Tue, 29 Apr 2008 00:51:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.sjtu.edu.cn (Postfix) with ESMTP id E6CC12D1AA; Tue, 29 Apr 2008 15:51:54 +0800 (CST) X-Virus-Scanned: Debian amavisd-new at sjtu.edu.cn Received: from mx2.sjtu.edu.cn ([127.0.0.1]) by localhost (mx2.sjtu.edu.cn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OcUVsIFe7-D; Tue, 29 Apr 2008 15:51:52 +0800 (CST) Received: from msc07ad750c26b (unknown [202.120.39.240]) (Authenticated sender: sunwq) by mx2.sjtu.edu.cn (Postfix) with ESMTP id 6AB252C95F; Tue, 29 Apr 2008 15:51:52 +0800 (CST) From: "Weiqiang Sun" To: Date: Tue, 29 Apr 2008 15:51:41 +0800 Organization: Shanghai Jiao Tong University Message-ID: <000301c8a9cd$dcf4a6f0$96ddf4d0$@edu.cn> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acipzdu7M1xUVN+DQziiIiWQSDKp1w== Content-Language: zh-cn Cc: 'Rajiv Papneja' , 'gjhhit' , 'zhangguoying' , sunwq@sjtu.edu.cn, 'Bin Gu' , 'xqwei' , 'blithe' Subject: [PMOL] Soliciting comments on GMPLS performance metrics draft in CCAMP X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sunwq@sjtu.edu.cn List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0193902230==" Sender: pmol-bounces@ietf.org Errors-To: pmol-bounces@ietf.org 这是一封 MIME 格式的多部分邮件。 --===============0193902230== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C8AA10.EB17E6F0" Content-Language: zh-cn 这是一封 MIME 格式的多部分邮件。 ------=_NextPart_000_0004_01C8AA10.EB17E6F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Recently the LSP dynamic provisioning performance draft is adopted as a working item of CCAMP. The draft, abstract shown below, defines a set of metrics to characterize the performance of a signaling protocol in the control plane, which normally runs on top of a packet switched control network. The draft proposes the metrics be tested in an active fashion. It also proposes that some of the metrics be implemented in an online or passive fashion. The authors would now like to solicit comments among the performance metric experts, regarding the structure of the document and the definition of the metrics. Please send your comments directly to the authors, or, to the CCAMP working group mail list (ccamp@ops.ietf.org). We do appreciate your help. Title: Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, G. Zhang, J. Gao, G. Xie, R. Papneja, B. Gu, X. Wei Filename : draft-ietf-ccamp-lsp-dppm-01.txt Pages : 39 Date : 2008-4-14 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for the future data transmission network. The GMPLS has been developed to control and cooperate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro area. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the dynamical LSP setup/release performance. These metrics can depict the features of the GMPLS network in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-01.txt Best regards, Weiqiang ------=_NextPart_000_0004_01C8AA10.EB17E6F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Recently the LSP dynamic = provisioning performance draft is adopted as a working item of CCAMP. The draft, abstract shown = below, defines a set of metrics to characterize the performance of a signaling protocol = in the control plane, which normally runs on top of a packet switched control = network. The draft proposes the metrics be tested in an active fashion. It also = proposes that some of the metrics be implemented in an online or passive = fashion.

 

The authors would now like to = solicit comments among the performance metric experts, regarding the structure = of the document and the definition of the metrics. Please send your comments = directly to the authors, or, to the CCAMP working group mail list (ccamp@ops.ietf.org). We do = appreciate your help.

 

Title: Label Switched Path = (LSP) Dynamical Provisioning Performance Metrics in Generalized MPLS = Networks

         Author(s) = : W. Sun, G. Zhang, J. Gao, G. Xie, R. Papneja, B. Gu, X. = Wei

         = Filename  : draft-ietf-ccamp-lsp-dppm-01.txt

         = Pages           &n= bsp;     : 39

         = Date           &nb= sp;       : 2008-4-14

         =

Generalized Multi-Protocol = Label Switching (GMPLS) is one of the most

promising candidate = technologies for the future data transmission

network.  The GMPLS has = been developed to control and cooperate

different kinds of network = elements, such as conventional routers,

switches, Dense Wavelength = Division Multiplexing (DWDM) systems, Add-

Drop Multiplexors (ADMs), = photonic cross-connects (PXCs), optical

cross-connects (OXCs), = etc.  Dynamic provisioning ability of these

physically diverse devices = differs from each other drastically.  At

the same time, the need for = dynamically provisioned connections is

increasing because optical = networks are being deployed in metro area.

As different applications = have varied requirements in the

provisioning performance of = optical networks, it is imperative to

define standardized metrics = and procedures such that the performance

of networks and application = needs can be mapped to each other.

 

This document provides a = series of performance metrics to evaluate

the dynamic LSP provisioning = performance in GMPLS networks,

specifically the dynamical = LSP setup/release performance.  These

metrics can depict the = features of the GMPLS network in LSP dynamic

provisioning.  They can = also be used in operational networks for

carriers to monitor the = control plane performance in realtime.

 

A URL for this Internet-Draft = is:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-01.txt=

 

Best = regards,

Weiqiang

------=_NextPart_000_0004_01C8AA10.EB17E6F0-- --===============0193902230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PMOL mailing list PMOL@ietf.org https://www.ietf.org/mailman/listinfo/pmol --===============0193902230==-- Return-Path: X-Original-To: pmol-archive@optimus.ietf.org Delivered-To: ietfarch-pmol-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776153A6E33; Fri, 25 Apr 2008 08:48:25 -0700 (PDT) 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 4656A3A6E33 for ; Fri, 25 Apr 2008 08:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, 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 kvV5L1zQR1Tl for ; Fri, 25 Apr 2008 08:48:18 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 4830628C36B for ; Fri, 25 Apr 2008 08:46:03 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m3PFk5dQ028865; Fri, 25 Apr 2008 09:46:06 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 25 Apr 2008 09:46:05 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 25 Apr 2008 09:46:05 -0600 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491936577@srvxchg3.cablelabs.com> In-Reply-To: <200804230330.m3N3U1K8015170@alph001.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PMOL] SIP Metrics draft: Timers wording Thread-Index: Acik8lwTA+/lSg9hTQ+tcMN5ThjEqQB+Qnwg References: <160DE07A1C4F8E4AA2715DEC577DA49193643B@srvxchg3.cablelabs.com> <200804230330.m3N3U1K8015170@alph001.aldc.att.com> From: "Daryl Malas" To: "Al Morton" , , "Greg Dowd" X-Approved: ondar Subject: Re: [PMOL] SIP Metrics draft: Timers wording 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pmol-bounces@ietf.org Errors-To: pmol-bounces@ietf.org Thanks Al. I will incorporate this and the other changes discussed in Philly into the draft. Look for a new revision soon. --Daryl -----Original Message----- From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf Of Al Morton Sent: Tuesday, April 22, 2008 9:30 PM To: Daryl Malas; pmol@ietf.org; Greg Dowd Subject: Re: [PMOL] SIP Metrics draft: Timers wording At 08:04 PM 3/25/2008, Daryl Malas wrote: >Thank you for the extensive feedback at the IETF conference in Philly >regarding the SIP Performance Metrics draft. During the session, there >were volunteers to provide me some verbiage for the draft regarding the >variability of timers relative to the draft. For those who >volunteered, please send me your suggested wording, and I will include >it in my next revision of the draft. I took a shot at this, further suggestions encouraged, Al 2. Terminology ... Time Begin (TB), remove, replaced by definition below. Time Stop (TS), remove, replaced by definition below. 3. Time Interval Measurement and Reporting Many of the metrics defined in this memo utilize a clock to assess the time interval between two events. This section defines time- related terms and reporting requirements. T1 - start time This is the time instant (when a request is sent) that begins a continuous time interval. T1 occurs when the designated request has been processed by the SIP application and the first bit of the request packet has been sent from the proxy or UA (and is externally observable at some logical or physical interface). T1 represents the time at which each request-response test begins, and SHALL be used to designate the time-of-day when a particular measurement was conducted (e.g., The Session Request Delay at "T1" and was measured to be X ms.) T4 - end time This is the time instant that concludes the continuous time interval begun when the related request is sent. T4 occurs when the last bit of the designated response is received by the SIP application at the requesting device (and is externally observable at some logical or physical interface). Note: The designations T2 and T3 are reserved for future use at another interface involved in satisfying a request. Section 10.1 of [RFC2330] describes time-related issues in measurements, and defines the errors that can be attributed to the clocks themselves. These definitions are used in the material below. Time of Day Accuracy As defined above, T1 is associated with the start of a request and also serves as the time-of-day stamp associated with a single specific measurement. The time offset [RFC2330] is the difference between T1 and a recognized primary source of time, such as UTC (offset = T1-UTC). When measurement results will be correlated with other results or information using time-of-day stamps, then the time clock that supplies T1 SHOULD be synchronized to a primary time source, to minimize the time offset. Time Interval Accuracy The accuracy of the T4-T1 interval is also critical to maintain and report. The relevant definition from [RFC2330] is "skew": the difference between time offsets at T1 and T4 is the error for the measurement interval associated with the clock's skew. A stable and reasonably accurate clock is needed to make the time interval measurements required by this memo. The clock error SHOULD be constrained to less than +/- 1 ms, implying 1 part per 1000 frequency accuracy for a 1 second interval. There are several other important aspects of clock operation: 1. Synchronization protocols require some ability to make adjustments to the local clock. However, these adjustments (clock steps or slewing) can cause large errors if they occur during the T1 to T4 measurement interval. Clock correction SHOULD be suspended during a T1 to T4 measurement interval, unless the time interval accuracy requirement above will be met. 2. If a free-running clock is used to make the time interval measurement, then value of T1 reported SHOULD be derived from a different clock that meets the time of day accuracy requirements described above. 3. The physical operation of reading time from a clock may be constrained by the delay to service the interrupt. Therefore, the accuracy of the time stamp read at T1 or T4 always includes the interrupt delay, and this source of error SHOULD be known and included in the error assessment. _______________________________________________ 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-archive@optimus.ietf.org Delivered-To: ietfarch-pmol-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2B63A69BB; Tue, 22 Apr 2008 20:30:13 -0700 (PDT) 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 48F913A69BB for ; Tue, 22 Apr 2008 20:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.098 X-Spam-Level: X-Spam-Status: No, score=-105.098 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 seFFg0aWn7fD for ; Tue, 22 Apr 2008 20:30:11 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 1D8BC3A6944 for ; Tue, 22 Apr 2008 20:30:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1208921415!19973841!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 12243 invoked from network); 23 Apr 2008 03:30:15 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 23 Apr 2008 03:30:15 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3N3UFQR021453 for ; Tue, 22 Apr 2008 23:30:15 -0400 Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3N3U6C0021406 for ; Tue, 22 Apr 2008 23:30:07 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m3N3U6XY015287 for ; Tue, 22 Apr 2008 23:30:06 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m3N3U1K8015170 for ; Tue, 22 Apr 2008 23:30:02 -0400 Message-Id: <200804230330.m3N3U1K8015170@alph001.aldc.att.com> Received: from acmt.att.com (unknown[135.210.96.25](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20080423033000gw100l7oske>; Wed, 23 Apr 2008 03:30:01 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Apr 2008 23:30:00 -0400 To: "Daryl Malas" , , "Greg Dowd" From: Al Morton In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA49193643B@srvxchg3.cablelabs. com> References: <160DE07A1C4F8E4AA2715DEC577DA49193643B@srvxchg3.cablelabs.com> Mime-Version: 1.0 Subject: Re: [PMOL] SIP Metrics draft: Timers wording 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pmol-bounces@ietf.org Errors-To: pmol-bounces@ietf.org At 08:04 PM 3/25/2008, Daryl Malas wrote: >Thank you for the extensive feedback at the IETF conference in Philly >regarding the SIP Performance Metrics draft. During the session, there >were volunteers to provide me some verbiage for the draft regarding the >variability of timers relative to the draft. For those who volunteered, >please send me your suggested wording, and I will include it in my next >revision of the draft. I took a shot at this, further suggestions encouraged, Al 2. Terminology ... Time Begin (TB), remove, replaced by definition below. Time Stop (TS), remove, replaced by definition below. 3. Time Interval Measurement and Reporting Many of the metrics defined in this memo utilize a clock to assess the time interval between two events. This section defines time- related terms and reporting requirements. T1 =96 start time This is the time instant (when a request is sent) that begins a continuous time interval. T1 occurs when the designated request h= as been processed by the SIP application and the first bit of the request packet has been sent from the proxy or UA (and is external= ly observable at some logical or physical interface). T1 represents the time at which each request-response test begins, and SHALL be used to designate the time-of-day when a particular measurement was conducted (e.g., The Session Request Delay at =93T= 1=94 and was measured to be X ms.) T4 =96 end time This is the time instant that concludes the continuous time interv= al begun when the related request is sent. T4 occurs when the last b= it of the designated response is received by the SIP application at t= he requesting device (and is externally observable at some logical or physical interface). Note: The designations T2 and T3 are reserved for future use at another interface involved in satisfying a request. Section 10.1 of [RFC2330] describes time-related issues in measurements, and defines the errors that can be attributed to the clocks themselves. These definitions are used in the material belo= w. Time of Day Accuracy As defined above, T1 is associated with the start of a request and also serves as the time-of-day stamp associated with a single specific measurement. The time offset [RFC2330] is the difference between T1 and a recognized primary source of time, such as UTC (offset =3D T1-UTC). When measurement results will be correlated with other results or information using time-of-day stamps, then the time clock that supplies T1 SHOULD be synchronized to a primary time source, to minimize the time offset. Time Interval Accuracy The accuracy of the T4-T1 interval is also critical to maintain and report. The relevant definition from [RFC2330] is =93skew=94: the difference between time offsets at T1 and T4 is the error for the measurement interval associated with the clock=92s skew. A stable and reasonably accurate clock is needed to make the time interval measurements required by this memo. The clock error SHOULD be constrained to less than +/- 1 ms, implying 1 part per 1000 frequency accuracy for a 1 second interval. There are several other important aspects of clock operation: 1. Synchronization protocols require some ability to make adjustme= nts to the local clock. However, these adjustments (clock steps or slewing) can cause large errors if they occur during the T1 to = T4 measurement interval. Clock correction SHOULD be suspended duri= ng a T1 to T4 measurement interval, unless the time interval accur= acy requirement above will be met. 2. If a free-running clock is used to make the time interval measurement, then value of T1 reported SHOULD be derived from a different clock that meets the time of day accuracy requirements described above. 3. The physical operation of reading time from a clock may be constrained by the delay to service the interrupt. Therefore, t= he accuracy of the time stamp read at T1 or T4 always includes the interrupt delay, and this source of error SHOULD be known and included in the error assessment. _______________________________________________ PMOL mailing list PMOL@ietf.org https://www.ietf.org/mailman/listinfo/pmol Return-Path: X-Original-To: pmol-archive@optimus.ietf.org Delivered-To: ietfarch-pmol-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED0F3A6E0F; Tue, 22 Apr 2008 08:25:42 -0700 (PDT) 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 9FB6B3A6E0F for ; Tue, 22 Apr 2008 08:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.496 X-Spam-Level: X-Spam-Status: No, score=-104.496 tagged_above=-999 required=5 tests=[AWL=1.300, 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 5jo6CDFUMlw5 for ; Tue, 22 Apr 2008 08:25:37 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id BD4123A68D2 for ; Tue, 22 Apr 2008 08:25:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-4.tower-203.messagelabs.com!1208877934!15228970!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 6284 invoked from network); 22 Apr 2008 15:25:35 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-4.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 22 Apr 2008 15:25:35 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3MFPgjU002398 for ; Tue, 22 Apr 2008 11:25:42 -0400 Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3MFPYkq002308 for ; Tue, 22 Apr 2008 11:25:35 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m3MFPYVA028412 for ; Tue, 22 Apr 2008 11:25:34 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m3MFPSxc028279 for ; Tue, 22 Apr 2008 11:25:28 -0400 Message-Id: <200804221525.m3MFPSxc028279@alph001.aldc.att.com> Received: from acmt.att.com (dyp004256dys.mt.att.com[135.16.251.231](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20080422152527gw100l7ojee>; Tue, 22 Apr 2008 15:25:27 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Apr 2008 11:25:27 -0400 To: pmol@ietf.org From: Al Morton In-Reply-To: <200804082045.m38KjWpv030353@klph001.kcdc.att.com> References: <200804082045.m38KjWpv030353@klph001.kcdc.att.com> Mime-Version: 1.0 Subject: Re: [PMOL] Call for Comments: Adoption of Framework I-D as a WG draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pmol-bounces@ietf.org Errors-To: pmol-bounces@ietf.org Reminder, last day to comment: At 04:45 PM 4/8/2008, Al Morton wrote: >PMOL Working Group, > >Our meeting minutes state: >http://www3.ietf.org/proceedings/08mar/minutes/pmol.html > >3. Metrics Framework Draft (Alan) >http://www.ietf.org/internet-drafts/draft-morton-perf-metrics-framework-02.txt >... >About 8 people had read the draft, and there was even stronger >support (12 people) to take-up this draft as a working group item >(to be ratified on the pmol list). >... > >So, if you have read the draft, please indicate your opinion >whether or not it should become a Working Group draft >(and please provide any comments that occurred to you while reading). > >The comment period will close on April 22, 2008. > >Note that Alan already has some plans to revise the draft, >as outlined in his presentation to the working group: >http://www3.ietf.org/proceedings/08mar/slides/pmol-2.ppt >and the working group has suggested other changes, see the minutes. > >regards, >Al >pmol co-chair > >_______________________________________________ >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-archive@optimus.ietf.org Delivered-To: ietfarch-pmol-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870543A6C23; Tue, 8 Apr 2008 13:45:57 -0700 (PDT) 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 87CA628C42D for ; Tue, 8 Apr 2008 13:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[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 V5NoOwZG+eaj for ; Tue, 8 Apr 2008 13:45:54 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id D848C28C428 for ; Tue, 8 Apr 2008 13:45:27 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-8.tower-121.messagelabs.com!1207687539!23738909!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 28045 invoked from network); 8 Apr 2008 20:45:39 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-8.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 8 Apr 2008 20:45:39 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m38Kjcft018227 for ; Tue, 8 Apr 2008 13:45:38 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m38KjbvZ018198 for ; Tue, 8 Apr 2008 13:45:37 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m38Kjbo0030567 for ; Tue, 8 Apr 2008 15:45:37 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m38KjWpv030353 for ; Tue, 8 Apr 2008 15:45:33 -0500 Message-Id: <200804082045.m38KjWpv030353@klph001.kcdc.att.com> Received: from acmt.att.com (dyp004256dys.mt.att.com[135.16.251.231](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20080408204531gw100l7oo9e>; Tue, 8 Apr 2008 20:45:31 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Apr 2008 16:45:30 -0400 To: pmol@ietf.org From: Al Morton Mime-Version: 1.0 Subject: [PMOL] Call for Comments: Adoption of Framework I-D as a WG draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pmol-bounces@ietf.org Errors-To: pmol-bounces@ietf.org PMOL Working Group, Our meeting minutes state: http://www3.ietf.org/proceedings/08mar/minutes/pmol.html 3. Metrics Framework Draft (Alan) http://www.ietf.org/internet-drafts/draft-morton-perf-metrics-framework-02.txt ... About 8 people had read the draft, and there was even stronger support (12 people) to take-up this draft as a working group item (to be ratified on the pmol list). ... So, if you have read the draft, please indicate your opinion whether or not it should become a Working Group draft (and please provide any comments that occurred to you while reading). The comment period will close on April 22, 2008. Note that Alan already has some plans to revise the draft, as outlined in his presentation to the working group: http://www3.ietf.org/proceedings/08mar/slides/pmol-2.ppt and the working group has suggested other changes, see the minutes. regards, Al pmol co-chair _______________________________________________ PMOL mailing list PMOL@ietf.org https://www.ietf.org/mailman/listinfo/pmol Return-Path: X-Original-To: pmol-archive@optimus.ietf.org Delivered-To: ietfarch-pmol-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27EEA28C645; Thu, 3 Apr 2008 21:54:02 -0700 (PDT) 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 4BE4228C3F8; Thu, 3 Apr 2008 21:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 AdaUlJPUCcYa; Thu, 3 Apr 2008 21:53:58 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 063D328C357; Thu, 3 Apr 2008 21:53:58 -0700 (PDT) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A2D4D2C03E0CC; Fri, 4 Apr 2008 06:54:02 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g5WhOX08gMW; Fri, 4 Apr 2008 06:54:02 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 75CF92C03E0C9; Fri, 4 Apr 2008 06:53:32 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 06:53:31 +0200 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF630AB7@mx1.office> In-Reply-To: <1C6541574A2FC447B53A6B4522B678AF01951C94@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bmwg] FW: [Sipping] Draft agenda / No overload design teamupdate? Thread-Index: AciVNrtN2g0VDRg0TfitEY79bk+NQQAdlsCQAAgHSBAAEDDxwA== References: <160DE07A1C4F8E4AA2715DEC577DA4919364AC@srvxchg3.cablelabs.com> <1C6541574A2FC447B53A6B4522B678AF01951C94@moe.nextone.local> From: "Saverio Niccolini" To: "Scott Poretsky" , "Daryl Malas" , Cc: Rosario Garroppo , pmol@ietf.org, bmwg@ietf.org Subject: Re: [PMOL] [bmwg] FW: [Sipping] Draft agenda / No overload design teamupdate? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pmol-bounces@ietf.org Errors-To: pmol-bounces@ietf.org Dear all, I think there are many unclear points and I do not know what is the best mailig list where to discuss this (I added PMOL but maybe the cross posting become too big now...) I think the bmwg draft (http://www3.tools.ietf.org/html/draft-poretsky-bmwg-sip-bench-meth-02) does not really help in getting what the sense of "goodput" means in the overload control simulation resutls presented by Volker. Would you (Daryl) suggest such metric is: "Maximum Session Attempt Rate"? Or whatelse? Are we sure that the goodput Volker is referring to is not the same metric as you (Daryl) describe in Session Establishment Rate (SER): http://tools.ietf.org/html/draft-malas-performance-metrics-08#section-3.6 Actually, in my opinion, is none of both. I understand that the "goodput" is a *load* metric but that Volker and the design team simulated it with *performance* constraints, i.e., if call set up delay is high than a configurable treshold T then the call is not considered in the goodput --> which leads to the assumption that it is a kind of a mixed metric... Other interesting sentence from Volker in his email is: "T does not have a significant impact, as long as it is chosen reasonably, since the buffer occupancy stays within a given limit with overload control" I hope someone can clarify, from my perspective: -- either such metric must be included in the drafts (as I wrote I do not see cuh a metric in any draft) -- or the goodput should be adapted to show metrics that are described in the drafts Am I missing something? Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On > Behalf Of Scott Poretsky > Sent: Thursday, April 03, 2008 11:02 PM > To: Daryl Malas; sipping@ietf.org > Cc: bmwg@ietf.org > Subject: Re: [bmwg] FW: [Sipping] Draft agenda / No overload > design teamupdate? > > Thanks Daryl. We will make sure this is considered in the > next revision. > > Scott > > -----Original Message----- > From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On > Behalf Of Daryl Malas > Sent: Thursday, April 03, 2008 1:09 PM > To: sipping@ietf.org > Cc: bmwg@ietf.org > Subject: [bmwg] FW: [Sipping] Draft agenda / No overload > design team update? > > FYI...I believe there was a draft written in BMWG to help > clarify some of these single DUT performance metric terms. I > am forwarding this thread to the BMWG mailing list for > additional review as necessary. > > --Daryl > > -----Original Message----- > From: sipping-bounces@ietf.org > [mailto:sipping-bounces@ietf.org] On Behalf Of Volker Hilt > Sent: Wednesday, April 02, 2008 8:59 PM > To: Saverio Niccolini > Cc: Rosario Garroppo; sipping@ietf.org > Subject: Re: [Sipping] Draft agenda / No overload design team update? > > Saverio, > > > > I have two questions regarding the overload topic: > > > > 1- in the simulations results reported in > > http://www3.ietf.org/proceedings/08mar/slides/tsvarea-3.ppt > > I see that many mechanisms reach the theoretical bound and the > > performance is referred to as "goodput" > > > > What is the meaning of goodput here? Is the "call set up delay" > > of the calls a parameter investigated in the simulations? > > > It is the number of calls that were successfully set up, > i.e., for which an INVITE transaction could be successfully > completed. The call setup delay is considered in that a > request is abandoned if it could not be set up within 10 > seconds. The number of seconds does not have a significant > impact, as long as it is chosen reasonably, since the buffer > occupancy stays within a given limit with overload control. > > > I try to explain my question better: > > is the 140 cps goodput all related to calls that achieve a > call setup > > delay which is acceptable for a real-time call? (e.g. a > call that is > > set up but with a 20 sec can not be really considered goodput) > > > Yes. See above. > > Volker > > > > > 2- terminology problem > > I have a problem with seeing the term overload "control" > used here, if > > > you refer to the literature you will see terms like > > congestion/overload "avoidance" and "control" > > > > the former refers to avoiding a congestion/overload > situation happens > > (this is what the mechanisms and the simulations investigated in > > http://www3.ietf.org/proceedings/08mar/slides/tsvarea-3.ppt > > in my opinion) > > the latter refers to controlling such a situation once it happened > > (e.g., because a server went down, because something unexpected > > happened) > > > > Can you please clarify and tell me why we are not using overload > > avoidance when referring to this work? > > > > Thanks a lot in advance, > > Saverio > > > > ============================================================ > > Dr. Saverio Niccolini > > Senior Researcher > > NEC Laboratories Europe, Network Research Division > > Kurfuerstenanlage 36, D-69115 Heidelberg > > Tel. +49 (0)6221 4342-118 > > Fax: +49 (0)6221 4342-155 > > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > > ============================================================ > > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL Registered in England 2832014 > > > > > > > >> -----Original Message----- > >> From: sipping-bounces@ietf.org > >> [mailto:sipping-bounces@ietf.org] On Behalf Of Jonathan Rosenberg > >> Sent: Friday, February 29, 2008 10:43 PM > >> To: Mary Barnes > >> Cc: sipping; Gonzalo Camarillo > >> Subject: Re: [Sipping] Draft agenda / No overload design > team update? > >> > >> There has also been progress since last ietf. > >> > >> One of the main points of feedback from last ietf, was that all of > >> the proposed algorithms showed the overall goodput going > to zero. As > >> we dug into this, the real problem is the simulation > model; the model > > >> assumes the senders never back off, and assumes that there > is finite > >> resources in all nodes, some amount of which is needed even to > >> discard a request. > >> So, when you put those together, the simulation model means ALL > >> algorithms would have this property. > >> > >> SO we've adjusted the models to focus on server to server > first, and > >> see whether the algorithms can adjust the load between servers by > >> asking the previous hop to reduce its rate. We don't worry for now > >> about how the previous hop does that. > >> > >> Volker will be presenting results that show several > algorithms do a > >> pretty good job of coming close to the optimal goodput > curve. Another > > >> result in the slides is that rate-based feedback, where the > >> downstream node tells the upstream to slow down to a > specific rate, > >> works better than 'bang-bang' algorithms which use the Retry-After > >> field in a > >> 503 to tell the upstream neighbor to stop completely for a > specific > >> amount of time. So, though we are not ruling such > algorithms out yet, > > >> our focus will be on driving additional simulation cases > around the > >> rate-based mechanisms, all of which perform pretty > similarly based on > > >> current simulations. > >> > >> Thanks, > >> Jonathan R. > >> > >> Mary Barnes wrote: > >>> Thank you for asking, as I wanted to highlight that Volker > >> Hilt will > >>> be presenting on behalf of the Overload Design team at the ICCRG > >>> meeting next week. Related to that presentation, Lars Eggert > >>> (Transport AD) has given agenda time in the Transport Open Area > >>> meeting for Volker to provide a summary of that presentation: > >>> http://www.ietf.org/proceedings/08mar/agenda/tsvarea.txt > >>> > >>> Note that this does conflict with XCON (and folks in SIMPLE > >> will have > >>> to run to catch the presentation as the TSVAREA slot > >> overlaps the 10 > >>> minute break), but this is likely that best that could have > >> been done > >>> given the difficulty in scheduling RAI sessions in general. > >>> > >>> As folks might recall, the primary feedback at IETF-70 on > >> the Overload > >>> presentation was that we needed to involve the congestion control > >>> experts in the Transport area to get their input in this area, so > >>> that's why this topic is being discussed there this time around. > >>> > >>> Regards, > >>> Mary. > >>> > >>> -----Original Message----- > >>> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > >>> Sent: Friday, February 29, 2008 9:40 AM > >>> To: Gonzalo Camarillo; sipping > >>> Cc: Barnes, Mary (RICH2:AR00) > >>> Subject: Draft agenda / No overload design team update? > >>> > >>> Noticed the absence of an update from overload design team, > >> and am now > >>> wondering whether there is any new data ready to be shared > >> with the WG. > >>> Maybe some non-WG meeting to inform the curious crowd? > >>> > >>> Thanks, > >>> Tolga > >>> > >>>> -----Original Message----- > >>>> From: sipping-bounces@ietf.org > [mailto:sipping-bounces@ietf.org] On > >>> Behalf > >>>> Of Gonzalo Camarillo > >>>> Sent: Friday, February 29, 2008 7:02 AM > >>>> To: sipping > >>>> Cc: Mary Barnes > >>>> Subject: [Sipping] Draft agenda > >>>> > >>>> Folks, > >>>> > >>>> as you probably know, you can find the draft agenda for > >> the SIPPING > >>>> sessions at: > >>>> > >>>> http://www.ietf.org/proceedings/08mar/agenda/sipping.htm > >>>> > >>>> Cheers, > >>>> > >>>> Gonzalo > >>>> > >>>> _______________________________________________ > >>>> Sipping mailing list > https://www.ietf.org/mailman/listinfo/sipping > >>>> This list is for NEW development of the application of SIP Use > >>>> sip-implementors@cs.columbia.edu for questions on > current sip Use > >>>> sip@ietf.org for new developments of core SIP > >>> _______________________________________________ > >>> Sipping mailing list > https://www.ietf.org/mailman/listinfo/sipping > >>> This list is for NEW development of the application of SIP Use > >>> sip-implementors@cs.columbia.edu for questions on current sip Use > >>> sip@ietf.org for new developments of core SIP > >>> > >> -- > >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > >> Cisco Fellow Edison, NJ 08837 > >> Cisco, Voice Technology Group > >> jdrosen@cisco.com > >> http://www.jdrosen.net PHONE: > (408) 902-3084 > >> http://www.cisco.com > >> _______________________________________________ > >> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > >> This list is for NEW development of the application of SIP Use > >> sip-implementors@cs.columbia.edu for questions on current sip Use > >> sip@ietf.org for new developments of core SIP > >> > > _______________________________________________ > > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP > > > -- > Volker Hilt Bell Labs / Alcatel-Lucent > phone: +1 732 888 7206 791 Holmdel-Keyport Rd > email: volkerh@bell-labs.com Holmdel, NJ 07733 > > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > _______________________________________________ > bmwg mailing list > bmwg@ietf.org > https://www.ietf.org/mailman/listinfo/bmwg > _______________________________________________ > bmwg mailing list > bmwg@ietf.org > https://www.ietf.org/mailman/listinfo/bmwg > _______________________________________________ PMOL mailing list PMOL@ietf.org https://www.ietf.org/mailman/listinfo/pmol