From ken.ko@adtran.com Thu Feb 28 11:06:13 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAC921F8AB4 for ; Thu, 28 Feb 2013 11:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llRuGfka3G4E for ; Thu, 28 Feb 2013 11:06:10 -0800 (PST) Received: from p02c11o144.mxlogic.net (p02c11o144.mxlogic.net [208.65.144.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7303521F89C7 for ; Thu, 28 Feb 2013 11:06:06 -0800 (PST) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c11o144.mxlogic.net(mxl_mta-7.0.0-1) with ESMTP id e9aaf215.68dee940.44326.00-576.93670.p02c11o144.mxlogic.net (envelope-from ); Thu, 28 Feb 2013 12:06:06 -0700 (MST) X-MXL-Hash: 512faa9e3bbd5f59-90906a58973250e658575d3a0706a2cf2a943a16 Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c11o144.mxlogic.net(mxl_mta-7.0.0-1) over TLS secured channel with ESMTP id e6aaf215.0.43808.00-245.92485.p02c11o144.mxlogic.net (envelope-from ); Thu, 28 Feb 2013 12:06:02 -0700 (MST) X-MXL-Hash: 512faa9a14ad3f5a-0792832d9a8d99bc34db9ae692ac4184cedcc3db Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.01.0438.000; Thu, 28 Feb 2013 13:05:17 -0600 From: KEN KO To: dengguangqing Thread-Topic: [ippm] FW: New Version Notification for draft-ko-ippm-streaming-performance-00.txt Thread-Index: Ac4OP6doC0aeTAg0QxucUfNonLQELgHix5f/AAC2G9A= Date: Thu, 28 Feb 2013 19:05:17 +0000 Message-ID: References: <201302282346248720930@cnnic.cn> In-Reply-To: <201302282346248720930@cnnic.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.196] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB7045E3D52exmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=T5M7uY2Q c=1 sm=1 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a] X-AnalysisOut: [=aQomRHkrLCgA:10 a=Y5BTMJbwge8A:10 a=qZHQZMT3apYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=f2bJoBy7] X-AnalysisOut: [scwA:10 a=48vgC7mUAAAA:8 a=ma-aqeDJPWfhF71J90wA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=rgn2_BMLILUA:10 a=DvnSUQUdWHYA:10 a=lZB815dzVv] X-AnalysisOut: [QA:10 a=yTgjCclkZ2hq9t63:21 a=UxG5oP_PI9hwV9DE:21 a=yMhMjl] X-AnalysisOut: [ubAAAA:8 a=SSmOFEACAAAA:8 a=wsg_gzh6vnjMKvWPgVUA:9 a=gKO2H] X-AnalysisOut: [q4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-] X-AnalysisOut: [hUA:10 a=7VUKDj3FRjwmZIHY:21 a=3gOHuavKbpDrUikz:21 a=z4VAb] X-AnalysisOut: [E6AnX0FkjHa:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] X-Mailman-Approved-At: Sun, 03 Mar 2013 01:33:34 -0800 Cc: ippm Subject: Re: [ippm] FW: New Version Notification for draft-ko-ippm-streaming-performance-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 19:06:13 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB7045E3D52exmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for this comment. I agree that VBR encoding is typically used and th= at is frequently reflected in the short-term average rate of the video stre= am. There are also a couple of differences between the model and actual streams= that you didn't mention but are probably aware of. First, most protocols u= sed for streaming result in the stream being delivered in bursts rather tha= n as individually spaced packets. Second, many streams are available at mul= tiple encoded rates and support adaptive switching between the rates based = on the receiver's determination of variable performance in the network chan= nel. I alluded to some of the above items in the "Additional Topics" sectio= n. With regard to VBR - the variation in encoded rate would cause correspondin= g variation in the rate at which the dejitter buffer is drained, which woul= d in turn affect the Dejitter-Buffer-Fill sample metric. Whether this chang= e would better reflect actual performance depends on how well a change in t= he model represents actual VBR behavior. The current proposal uses the long= term average (essentially a CBR model) as what seems to be a necessary sim= plification, since modeling the variation in VBR strikes me as a somewhat d= aunting task, but if a model enhancement could be shown to be both represen= tative and manageable I would welcome it. With regard to bursting - I have captured many actual streams and when ther= e the network performance is significantly higher than that required to del= iver the video stream, this bursting deviates significantly from the model.= However, when the network performance is close to the required performance= to support the video, the bursts are spread over time by the network. When= network performance equals required performance, the bursts merge into eac= h other and appear as a continuous stream at the destination. So the less m= argin there is in network performance (meaning, usually, the more interesti= ng the test case), the closer the model approximates actual streaming behav= ior. With regard to adaptive streaming, the model could be enhanced to simulate = this, but this probably requires discussion with regard to whether it is ap= propriate. As it is, the metrics generated by the methodology can be descri= bed in terms of a small set of parameters including a "streaming rate." Onc= e adaptive streaming is modeled, I think it may become more difficult to ex= press the resulting metrics in intuitive terms. I'll have a brief presentation in Orlando that will touch on these topics. = Will you be there? Best regards, Ken From: Guangqing Deng [mailto:dengguangqing@cnnic.cn] Sent: Thursday, February 28, 2013 10:46 AM To: KEN KO Cc: ippm Subject: Re: [ippm] FW: New Version Notification for draft-ko-ippm-streamin= g-performance-00.txt Hi, Ken, I am also interested in the modeling of streaming performance and = have you ever done any actual network measurement to verify the accuracy of= the streaming performance model in this draft? Usually, to ensure constant= image quality, the VBR (Variable Bit Rate) coding method is used and then = the streaming rate is always time-varying. Then is it necessary to take the= dynamics of streaming rate into consideration for the streaming performanc= e model? ________________________________ Guangqing Deng cnnic From: KEN KO Date: 2013-02-19 09:30 To: ippm@ietf.org Subject: [ippm] FW: New Version Notification for draft-ko-ippm-streaming-pe= rformance-00.txt IPPM, Here is a new I-D relating to testing for streaming performance. Instead of= sending a stream to directly test one condition, it applies a streaming mo= del to metrics from TCP throughput testing to estimate performance for any = number of conditions. Comments are welcome. Regards, Ken Ko -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Monday, February 18, 2013 1:50 PM To: KEN KO Subject: New Version Notification for draft-ko-ippm-streaming-performance-0= 0.txt A new version of I-D, draft-ko-ippm-streaming-performance-00.txt has been successfully submitted by Ken Ko and posted to the IETF repository= . Filename: draft-ko-ippm-streaming-performance Revision: 00 Title: Model-Based Estimation of Streaming Performance Creation date: 2013-02-18 Group: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-ko-ippm-streamin= g-performance-00.txt Status: http://datatracker.ietf.org/doc/draft-ko-ippm-streaming-pe= rformance Htmlized: http://tools.ietf.org/html/draft-ko-ippm-streaming-perform= ance-00 Abstract: This memo defines metrics plus a methodology for post-measurement processing of sample metrics to evaluate network path performance relative to streaming video traffic. The metrics are based on established methodologies for TCP throughput testing. The post- processing methodology is based on a model of streaming traffic that allows a given sample metric to be evaluated against multiple sets of parameters representing different streaming rates, delays and buffering values. The results of the post-processing methodology are derived metrics that are suitable for statistical analysis. The IETF Secretariat _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_D14B7E40AEBFD54EA3AD964902DD7CB7045E3D52exmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for this comment. = I agree that VBR encoding is typically used and that is frequently reflecte= d in the short-term average rate of the video stream.

There are also a couple o= f differences between the model and actual streams that you didn’t me= ntion but are probably aware of. First, most protocols used for streaming result in the stream being delivered in bursts rather than as in= dividually spaced packets. Second, many streams are available at multiple e= ncoded rates and support adaptive switching between the rates based on the = receiver’s determination of variable performance in the network channel. I alluded to some of the above items i= n the “Additional Topics” section.

With regard to VBR –= ; the variation in encoded rate would cause corresponding variation in the = rate at which the dejitter buffer is drained, which would in turn affect the Dejitter-Buffer-Fill sample metric. Whether this change would b= etter reflect actual performance depends on how well a change in the model = represents actual VBR behavior. The current proposal uses the long term ave= rage (essentially a CBR model) as what seems to be a necessary simplification, since modeling the variation = in VBR strikes me as a somewhat daunting task, but if a model enhancement c= ould be shown to be both representative and manageable I would welcome it.

With regard to bursting &= #8211; I have captured many actual streams and when there the network perfo= rmance is significantly higher than that required to deliver the video stream, this bursting deviates significantly from the model. However= , when the network performance is close to the required performance to supp= ort the video, the bursts are spread over time by the network. When network= performance equals required performance, the bursts merge into each other and appear as a continuous stream at the = destination. So the less margin there is in network performance (meaning, u= sually, the more interesting the test case), the closer the model approxima= tes actual streaming behavior.

With regard to adaptive s= treaming, the model could be enhanced to simulate this, but this probably r= equires discussion with regard to whether it is appropriate. As it is, the metrics generated by the methodology can be described in ter= ms of a small set of parameters including a “streaming rate.” O= nce adaptive streaming is modeled, I think it may become more difficult to = express the resulting metrics in intuitive terms.

I’ll have a brief p= resentation in Orlando that will touch on these topics. Will you be there?<= o:p>

Best regards,<= /span>

Ken

From: Guangqing Deng [mailto:dengguangqing@cnn= ic.cn]
Sent: Thursday, February 28, 2013 10:46 AM
To: KEN KO
Cc: ippm
Subject: Re: [ippm] FW: New Version Notification for draft-ko-ippm-s= treaming-performance-00.txt

 

Ken, I am also interes= ted in the modeling of streaming performance and have you ever done any act= ual network measurement to verify the accuracy of the streaming performance mo= del in this draft? Usually, to ensure constant image quality, the VBR (Vari= able Bit Rate) coding method is used and then the streaming rate is always = time-varying. Then is it necessary to take the dynamics of streaming rate into consideration for the streamin= g performance model?

 

Guangqing Deng
cnnic 

 

From:&n= bsp;= KEN KO

Date:&n= bsp;2013-02-19 09:30

To:&nbs= p;ippm@i= etf.org

Subject: [ippm] FW: New Version Notification for draft-ko-ippm-streaming-performance-00.tx= t

IPPM, 

 

Here is a new I-D <= span style=3D"font-size:10.5pt;font-family:"Microsoft YaHei",&quo= t;serif";color:navy">relating <= /span>to = testing=  forstreaming performance. Instead=  of sending=  a=  s= tream to directly test one condition, = it applies = a = streamingmodel to metrics from TCP throughput=  testing<= /span> to=  e= stimate performance for any number of <= span style=3D"font-size:10.5pt;font-family:"Microsoft YaHei",&quo= t;serif";color:navy">conditions.&nbs= p;Comments are welcome.

 

Regards,

Ken Ko

 

-----Original Message-----

Sent: Monday, February = ;18,&nb= sp;2013=  1:50 PM

To: KEN KO

Subject: New = Version <= /span>Notification for draft-ko-ippm-streaming-perfo= rmance-00.txt

 

 

A new version <= span style=3D"font-size:10.5pt;font-family:"Microsoft YaHei",&quo= t;serif";color:navy">of = I-D, draft-ko-ippm-streaming-performance-00.txt

has been successfully = submittedby Ken Ko and posted to the IETF repository.

 

Filename:  d= raft-ko-ippm-streaming-performance

Revision:  0= 0

Title:  M= odel-Based Estimation of Streaming = Performance

Creation date:  2= 013-02-18

Group:  I= ndividual Submission

Number of pages: 18

 

 

Abstract:

   This<= /span> me= mo defines metrics plus a methodology <= span style=3D"font-size:10.5pt;font-family:"Microsoft YaHei",&quo= t;serif";color:navy">for post-measurement

   proce= ssing of sample metrics to evaluate network path <= /span>performance

   relat= ive  streaming video traffic. The metrics are <= /span>based&nb= sp;on

   estab= lished methodologies for TCP throughput testing.&nb= sp;The&= nbsp;post-

   proce= ssing methodology is based on a model <= span style=3D"font-size:10.5pt;font-family:"Microsoft YaHei",&quo= t;serif";color:navy">of = streaming = ;traffic that

   allow= s = a = given sample metric to be evaluated <= span style=3D"font-size:10.5pt;font-family:"Microsoft YaHei",&quo= t;serif";color:navy">against multiple&= nbsp;sets

   of para= meters representing different streaming rates,&nb= sp;delaysand

   buffe= ring values. The results of the post-processing = methodology are

   deriv= ed metrics that are suitable for statistical analysis.

 

         &nb= sp;            =             &nb= sp;            =             &nb= sp;            =           

 

 

The IETF Secretariat

 

_______________________________________________

ippm mailing = list

--_000_D14B7E40AEBFD54EA3AD964902DD7CB7045E3D52exmb1corpadtran_-- From mach.chen@huawei.com Mon Mar 4 01:54:18 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D29221F8626 for ; Mon, 4 Mar 2013 01:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CznNJavnj00t for ; Mon, 4 Mar 2013 01:54:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 584BC21F8613 for ; Mon, 4 Mar 2013 01:54:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APA10193; Mon, 04 Mar 2013 09:54:16 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 09:54:11 +0000 Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 09:54:15 +0000 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.4]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.01.0323.007; Mon, 4 Mar 2013 17:54:05 +0800 From: Mach Chen To: "ippm@ietf.org" Thread-Topic: New Version Notification for draft-chen-coloring-based-ipfpm-framework-01.txt Thread-Index: AQHOEyqM5cwJIBFoaEq5pHJyRPHrIpiVVWzA Date: Mon, 4 Mar 2013 09:54:05 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Liuhongming , Yinyuanbin Subject: [ippm] FW: New Version Notification for draft-chen-coloring-based-ipfpm-framework-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 09:54:18 -0000 SGkgRm9ya3MsDQoNCldlIHVwbG9hZGVkIGEgZHJhZnQgdGhhdCBkZXNjcmliZXMgYSBmcmFtZXdv cmsgZm9yICJjb2xvcmluZyIgYmFzZWQgSVAgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQuDQoNClRo ZSBjb25jZXB0IG9mICJjb2xvcmluZyIgSVAgcGFja2V0cyBmb3IgcGVyZm9ybWFuY2UgbWVhc3Vy ZW1lbnQgaXMgZGVzY3JpYmVkIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRl bXBpYS1vcHNhd2ctcDNtLTAyIC4gQnkgImNvbG9yaW5nIiB0aGUgcGFja2V0cyBvZiBhIHNwZWNp ZmljIElQIGZsb3cgdG8gZGlmZmVyZW50IGNvbG9ycywgaXQgbmF0dXJhbGx5IHNwbGl0cyB0aGUg SVAgZmxvdyBpbnRvIGRlZmVyZW50IGNvbnNlY3V0aXZlIGJsb2NrcyBhbmQgZ2l2ZXMgYSB3YXkg dG8gbWVhc3VyZSB0aGUgcmVhbCBwYWNrZXQgbG9zcyBhbmQgZGVsYXkgd2l0aG91dCBpbnNlcnRp bmcgYW55IGV4dHJhIE9BTSBwYWNrZXRzLg0KDQpBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIGl0LCB0 aGlzIGlzIG91dCBvZiBzY29wZSBmb3IgdGhlIGN1cnJlbnQgY2hhcnRlci4gSSB3b3VsZCBsaWtl IHlvdXIgb3BpbmlvbnMgb2YgdGhlIGRyYWZ0LCBhbmQgaWYgeW91IHRoaW5rIHlvdSB3b3VsZCBs aWtlIHRvIHJlY2hhcnRlciB0byBpbmNsdWRlIHRoaXMgd29yayBJIHdvdWxkIGJlIGhhcHB5IHRv IGhlYXIgaXQuDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDEzIDM6MzQgUE0N ClRvOiBNYWNoIENoZW4NCkNjOiBMaXVob25nbWluZzsgWWlueXVhbmJpbg0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1jaGVuLWNvbG9yaW5nLWJhc2VkLWlwZnBt LWZyYW1ld29yay0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY2hlbi1j b2xvcmluZy1iYXNlZC1pcGZwbS1mcmFtZXdvcmstMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IE1hY2goR3VveWkpIENoZW4gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYg cmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1jaGVuLWNvbG9yaW5nLWJhc2VkLWlwZnBt LWZyYW1ld29yaw0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgQ29sb3JpbmcgYmFzZWQgSVAgRmxv dyBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBGcmFtZXdvcmsNCkNyZWF0aW9uIGRhdGU6CSAyMDEz LTAyLTI1DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczog MTcNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtY2hlbi1jb2xvcmluZy1iYXNlZC1pcGZwbS1mcmFtZXdvcmstMDEudHh0DQpTdGF0dXM6 ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hlbi1jb2xv cmluZy1iYXNlZC1pcGZwbS1mcmFtZXdvcmsNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1jb2xvcmluZy1iYXNlZC1pcGZwbS1mcmFtZXdvcmst MDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtY2hlbi1jb2xvcmluZy1iYXNlZC1pcGZwbS1mcmFtZXdvcmstMDENCg0KQWJzdHJhY3Q6DQog ICBCeSBzZXR0aW5nIG9uZSB1bnVzZWQgYml0IG9mIHRoZSBJUCBoZWFkZXIgb2YgcGFja2V0cyB0 byAiY29sb3IiIHRoZQ0KICAgcGFja2V0cyBpbnRvIGRpZmZlcmVudCBjb2xvciBibG9ja3MsIGl0 IG5hdHVyYWxseSBnaXZlcyBhIHdheSB0bw0KICAgbWVhc3VyZSB0aGUgcmVhbCBwYWNrZXQgbG9z cyBhbmQgZGVsYXkgd2l0aG91dCBpbnNlcnRpbmcgYW55IGV4dHJhDQogICBPQU0gcGFja2V0cy4g IFRoaXMgaXMgY2FsbGVkICJjb2xvcmluZyIgYmFzZWQgSVAgRmxvdyBQZXJmb3JtYW5jZQ0KICAg TWVhc3VyZW1lbnQgKElQRlBNKS4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgZnJhbWV3b3Jr IGFuZA0KICAgcHJvdG9jb2wgZm9yIHRoaXMgImNvbG9yaW5nIiBiYXNlZCBJUEZQTS4NCg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From steve.baillargeon@ericsson.com Wed Mar 6 06:08:17 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B8E21F887D for ; Wed, 6 Mar 2013 06:08:17 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZD+cimoHawg for ; Wed, 6 Mar 2013 06:08:16 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id CDF2721F88A2 for ; Wed, 6 Mar 2013 06:08:15 -0800 (PST) X-AuditID: c6180641-b7faf6d00000096b-f6-51374dcfa56a Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5E.D1.02411.FCD47315; Wed, 6 Mar 2013 15:08:15 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 09:08:14 -0500 From: Steve Baillargeon To: "MORTON JR., ALFRED (AL)" Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt Thread-Index: AQHOAMfan+4IuK/3AEOHNpEUAjz0YZiY4MOA Date: Wed, 6 Mar 2013 14:08:13 +0000 Message-ID: References: <20130201220204.18218.91881.idtracker@ietfa.amsl.com> In-Reply-To: <20130201220204.18218.91881.idtracker@ietfa.amsl.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXRPgu55X/NAgzcTpSy2HpvIaNHz4B2z A5PHy/45jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4dKyVtWC+fMXsQ9+YGxg3SnYxcnJICJhI NB7fywJhi0lcuLeerYuRi0NI4AijxKw5l5khnGWMEuseHQerYhOwkFg/dxlQgoNDRMBQ4ukq D5Aws4CyxN5X8xlBbGEBZ4nJp/8wg9giAi4SZ7e8Y4ewjSRuPXzNCmKzCKhIHJi+B2gkOwev gK/EpAqQqJCAo8TWBSuZQIZzCjhJHF0hBhJmFJCV2H32OhPEInGJW0/mM0FcLCCxZM95Zghb VOLl43+sELayxJIn+1kg6nUkFuz+xAZha0ssW/garJ5XQFDi5MwnLBMYxWYhGTsLScssJC2z kLQsYGRZxchRWpxalptuZLiJERgfxyTYHHcwLvhkeYhRmoNFSZw31PVCgJBAemJJanZqakFq UXxRaU5q8SFGJg5OqQbG1cuOneV/8uX53S/1wfwdlw8febwtbmu53pT9wdevMFxqjGeMffgm rb1128t19+K27r6buM9s3efguitO3okFr+dmCC9q2MQ16enLxReCMw12Kr2u367nclyLX/xi vpNE398Anx8phuHPizgllJv7lOufsDOoSDz9s63bR8hlWZwlv5xZ/eMPSizFGYmGWsxFxYkA Dg6XWV0CAAA= Cc: "ippm@ietf.org" Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:08:17 -0000 Hi Al I am resending with the correct draft name! I also added one more comment a= nd put them in chronological order. Here are my comments about draft-morton-ippm-twamp-rate-problem-02.txt. - Section 3) You indicate the two-way measurement architecture is favored = and I agree. You also indicate that each direction of transmission must be = evaluated separately and I agree. However this paragraph does not clarify t= he meaning of test streams vs test sessions. If you imply that each test st= ream requires its own test session, then I don't agree this is a good archi= tectural decision since in many access networks following a hub-and-spoke t= opology, I expect the spoke to be the low complexity device (as you have in= dicated) and the hub to be the controller where the test sessions are confi= gured, activated/deactivated and where data is probably collected. With In-= Service testing including 24/7 monitoring, one challenge is the number of c= oncurrent test sessions supported at the hub/controller. It is often the li= miting factor for scaling the measurement system. Therefore it is desirable= to include the case where a single test session (e.g. TWAMP) can measure b= oth the forward and reverse rates for a given Type-P packet. If you don't, = you could end-up with twice as many test sessions than actually needed.=20 - Section 4) You are missing variable intra-packet spacing in the pair, ens= emble or train where you are listing the MUST for the test protocol. - Section 5) I would like to see a requirement on the test protocol for th= e two-way architecture where it can measure the rate in a specific transmis= sion direction using a single Type-P test session where the test session ha= s its own test data stream and also measure rates in both forward and rever= se transmission directions using a single Type-P test session where the for= ward direction data stream is also used to measure the reverse direction ra= te. - Section 5) Why is it so important to specify ALL variables to the Receiv= er in the one-way architecture. As far as I know it is possible today to me= asure rate in a given direction with the existing OWAMP protocol without an= y changes to it. Regards Steve B -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: February-01-13 5:02 PM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : Rate Measurement Test Protocol Problem Statement Author(s) : Al Morton Filename : draft-ietf-ippm-rate-problem-02.txt Pages : 11 Date : 2013-02-01 Abstract: There is a rate measurement scenario which has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From steve.baillargeon@ericsson.com Wed Mar 6 10:15:27 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6AE21F8A42 for ; Wed, 6 Mar 2013 10:15:27 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqAROXxXVO4e for ; Wed, 6 Mar 2013 10:15:23 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9E21F8A35 for ; Wed, 6 Mar 2013 10:15:20 -0800 (PST) X-AuditID: c618062d-b7f0d6d00000097e-9d-513787b73b7a Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 28.40.02430.7B787315; Wed, 6 Mar 2013 19:15:20 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 13:15:19 -0500 From: Steve Baillargeon To: "MORTON JR., ALFRED (AL)" Thread-Topic: : [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt Thread-Index: Ac4alo5iFURQBOK9TKaVlvb2oe7qEQ== Date: Wed, 6 Mar 2013 18:15:18 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyuXRPiO6OdvNAg1mfWCy2HpvIaNHz4B2z A5PHy/45jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4t+ESS8Fp5YqTu+YxNzD+keli5OSQEDCR uHe2mRnCFpO4cG89WxcjF4eQwBFGiXftq1kgnGWMEh373rGDVLEJWEisn7sMqIODQ0TAUOLp Kg+QMLOAssTeV/MZQWxhAReJc/vWMYHYIgJuErOObWCHsPUkjp9bzQpiswioSJw6sQRsMa+A r8T5J3PAehkFZCV2n73OBDFTXOLWk/lMEMcJSCzZcx7qUFGJl4//sULYyhJLnuxngajXkViw +xMbhK0tsWzha6j5ghInZz5hmcAoMgvJ2FlIWmYhaZmFpGUBI8sqRo7S4tSy3HQjg02MwKA/ JsGmu4Nxz0vLQ4zSHCxK4rxBrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDaa3w6q3Uj 7L8Np4Pehdqrzy/Oy07VnrTOLSvMXWm1pknbkoj3bmcTfY1vTHHq8fBz2BS8zWqCuIiab8Hr f9du57rvOvAlcXHGEgv25+fcnrZNSm0uv/LwvZHd7mhT7pWi4l+flK26n73k6OYUE7/NC7tk Mu/9MA+Xnnj4hcVW1tA9+9ay+3sqsRRnJBpqMRcVJwIAwpUgn0gCAAA= Cc: "ippm@ietf.org" Subject: Re: [ippm] : I-D Action: draft-ietf-ippm-rate-problem-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:15:27 -0000 Hi Al Do you have any problems with your email server (if you can get this messag= e)? I got the following message: Delivery is delayed to acmorton@att.com . Subj= ect: RE: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt. This messa= ge hasn't been delivered yet. Delivery will continue to be attempted. See comments below. -Steve -----Original Message----- From: Steve Baillargeon=20 Sent: March-06-13 9:08 AM To: 'MORTON JR., ALFRED (AL)' Cc: ippm@ietf.org Subject: RE: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt Hi Al I am resending with the correct draft name! I also added one more comment a= nd put them in chronological order. Here are my comments about draft-morton-ippm-twamp-rate-problem-02.txt. - Section 3) You indicate the two-way measurement architecture is favored = and I agree. You also indicate that each direction of transmission must be = evaluated separately and I agree. However this paragraph does not clarify t= he meaning of test streams vs test sessions. If you imply that each test st= ream requires its own test session, then I don't agree this is a good archi= tectural decision since in many access networks following a hub-and-spoke t= opology, I expect the spoke to be the low complexity device (as you have in= dicated) and the hub to be the controller where the test sessions are confi= gured, activated/deactivated and where data is probably collected. With In-= Service testing including 24/7 monitoring, one challenge is the number of c= oncurrent test sessions supported at the hub/controller. It is often the li= miting factor for scaling the measurement system. Therefore it is desirable= to include the case where a single test session (e.g. TWAMP) can measure b= oth the forward and reverse rates for a given Type-P packet. If you don't, = you could end-up with twice as many test sessions than actually needed.=20 - Section 4) You are missing variable intra-packet spacing in the pair, ens= emble or train where you are listing the MUST for the test protocol. - Section 5) I would like to see a requirement on the test protocol for th= e two-way architecture where it can measure the rate in a specific transmis= sion direction using a single Type-P test session where the test session ha= s its own test data stream and also measure rates in both forward and rever= se transmission directions using a single Type-P test session where the for= ward direction data stream is also used to measure the reverse direction ra= te. - Section 5) Why is it so important to specify ALL variables to the Receiv= er in the one-way architecture. As far as I know it is possible today to me= asure rate in a given direction with the existing OWAMP protocol without an= y changes to it. Regards Steve B -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: February-01-13 5:02 PM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : Rate Measurement Test Protocol Problem Statement Author(s) : Al Morton Filename : draft-ietf-ippm-rate-problem-02.txt Pages : 11 Date : 2013-02-01 Abstract: There is a rate measurement scenario which has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From andreas.a.johnsson@ericsson.com Fri Mar 8 00:51:48 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C975421F8696 for ; Fri, 8 Mar 2013 00:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-Pg-xXZEAWb for ; Fri, 8 Mar 2013 00:51:46 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4295121F8691 for ; Fri, 8 Mar 2013 00:51:45 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-f8-5139a6a0169b Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E4.1F.32353.0A6A9315; Fri, 8 Mar 2013 09:51:44 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.124]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 09:51:43 +0100 From: Andreas Johnsson A To: "Al Morton (acmorton@att.com)" , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt Thread-Index: Ac4b2S5UXzh1IGQgRP6juDcnd/D+JA== Date: Fri, 8 Mar 2013 08:51:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D26039A349A82849AC399E2B92A05EF61A1F5DA4ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje6CZZaBBtsXi1hsPTaR0aLnwTtm ByaPl/1zGD2WLPnJFMAUxWWTkpqTWZZapG+XwJWx7WRlwefpjBWXvncwNjC2tjF2MXJySAiY SCzteccOYYtJXLi3ng3EFhI4xCjx/qlSFyMXkL2YUWLu79WsIAk2ASuJ9V3bmEFsEYF0iY4p v8GahQWcJd7eeANkcwDFPSSOnC+EKNGT+NALUcIioCLx6t8eJhCbV8BX4v7Mf2BxRqC930+t AYszC4hL3HoynwniHgGJJXvOM0PYohIvH/9jhbAVJa5OXw5Vny8x+8QdqJmCEidnPmGZwCg0 C8moWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsY2XMTM3PSy803MQJj4eCW 3wY7GDfdFzvEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY7XOjEMMYVW3 +uboXT6VsL/uv51NvpSDn1hSTem9pf7SapOXusRJ8D3YlrCgbFmVsrBMacrfj8++H9+y7mDW Kl4P3bT4t/fNra/GuzRuXvRF8Qq798kktrBLD5TvX/RP8Sg9tnm7G8sGCUWB+ZZFexT2xZRs 5373TGXnU93bCdc+50zfF9FyWImlOCPRUIu5qDgRAMVrOgdTAgAA Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 08:51:48 -0000 --_000_D26039A349A82849AC399E2B92A05EF61A1F5DA4ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Al, IPPM, Please see my comments on draft-ietf-ippm-twamp-rate-problem-02.txt: In Section 5 there is a requirement on variable packet size testing for eac= h measurement direction in a two-way architecture. I think this requirement= is too strong. I suggest changing REQUIRED to OPTIONAL. The reasons for this are - There is already one RFC in IETF that describes how rate measure= ments using TWAMP could be performed (RFC 6802). This solution does not, in= its current form, allow for variable packet sizes in each direction of mea= surement. However, a two-way architecture can always setup two test session= s with two different packet sizes. A problem statement in the area of rate = measurements should of course allow for both current (RFC 6802) and future = solutions (e.g. I.D. draft-morton-ippm-twamp-rate) to co-exist. - There has been quite some effort in IETF IPPM defining a symmetr= ical size mode for TWAMP. This is how you normally do tests, i.e. the test = session should do similar tests with equal packet sizes in both direction. = The text in the rate problem draft is a step away from this. Best regards, Andreas Johnsson -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-boun= ces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: February-01-13 5:02 PM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of th= e IETF. Title : Rate Measurement Test Protoc= ol Problem Statement Author(s) : Al Morton Filename : draft-ietf-ippm-rate-problem= -02.txt Pages : 11 Date : 2013-02-01 Abstract: There is a rate measurement scenario which has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_D26039A349A82849AC399E2B92A05EF61A1F5DA4ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Al, IPPM,

 

Please see my comments on dr= aft-ietf-ippm-twamp-rate-problem-02.txt:

 

In Section 5 there is a requ= irement on variable packet size testing for each measurement direction in a= two-way architecture. I think this requirement is too strong. I suggest ch= anging REQUIRED to OPTIONAL.

 

The reasons for this are

-=    &n= bsp;      There is already one RF= C in IETF that describes how rate measurements using TWAMP could be perform= ed (RFC 6802). This solution does not, in its current form, allow for varia= ble packet sizes in each direction of measurement. However, a two-way architecture can always setup two test = sessions with two different packet sizes. A problem statement in the area o= f rate measurements should of course allow for both current (RFC 6802) and = future solutions (e.g. I.D. draft-morton-ippm-twamp-rate) to co-exist.

-=    &n= bsp;      There has been quite so= me effort in IETF IPPM defining a symmetrical size mode for TWAMP. This is = how you normally do tests, i.e. the test session should do similar tests wi= th equal packet sizes in both direction. The text in the rate problem draft is a step away from this.

 

 

Best regards,

Andreas Johnsson<= /span>

 

 

 

 

 

-----Original Message-----

From: ippm-bounces@ietf.org= [= mailto:ippm-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org

Sent: February-01-13 5:02 PM=

To: i-d-announce@ietf.org

Cc: ippm@ietf.org

Subject: [ippm] I-D Action: = draft-ietf-ippm-rate-problem-02.txt

 

 

A New Internet-Draft is avai= lable from the on-line Internet-Drafts directories.

This draft is a work item of= the IP Performance Metrics Working Group of the IETF.

 

    &nbs= p;            &= nbsp;           Title&nbs= p;          : Rate Measurement= Test Protocol Problem Statement

    &nbs= p;            &= nbsp;           Author(s)=        : Al Morton

    &nbs= p;            &= nbsp;           Filename&= nbsp;       : draft-ietf-ippm-rate-problem-02= .txt

    &nbs= p;            &= nbsp;           Pages&nbs= p;          : 11

    &nbs= p;            &= nbsp;           Date = ;           : 2013-02-01<= o:p>

 

Abstract:<= /p>

   There is a rate= measurement scenario which has wide-spread attention

   of Internet acc= ess subscribers and seemingly all industry players,

   including regul= ators.  This memo presents an access rate-measurement

   problem stateme= nt for test protocols to measure IP Performance

   Metrics.  = Key test protocol aspects require the ability to control<= /p>

   packet size on = the tested path and enable asymmetrical packet size

   testing in a co= ntroller-responder architecture.

 

 

 

The IETF datatracker status = page for this draft is:

https://datatracker.ietf.org/= doc/draft-ietf-ippm-rate-problem=

 

There's also a htmlized vers= ion available at:

http://tools.ietf.org/html/draft= -ietf-ippm-rate-problem-02

 

A diff from the previous ver= sion is available at:

http://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-ippm-rate-problem-02<= o:p>

 

 

Internet-Drafts are also ava= ilable by anonymous FTP at:

f= tp://ftp.ietf.org/internet-drafts/

 

____________________________= ___________________

ippm mailing list=

ippm@ietf.org

https://www.ietf.org/mailman/listinfo/ippm

____________________________= ___________________

ippm mailing list=

ippm@ietf.org

https://www.ietf.org/mailman/listinfo/ippm

 

--_000_D26039A349A82849AC399E2B92A05EF61A1F5DA4ESESSMB105erics_-- From wwwrun@rfc-editor.org Fri Mar 8 06:16:14 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D33F21F85E7 for ; Fri, 8 Mar 2013 06:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVcqn2XIdsgf for ; Fri, 8 Mar 2013 06:16:09 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 979DD21F85C9 for ; Fri, 8 Mar 2013 06:16:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3D67AB1E002; Fri, 8 Mar 2013 06:02:15 -0800 (PST) To: khedayat@brixnet.com, roman.krzanowski@verizon.com, acmorton@att.com, kyum@juniper.net, babiarz@nortel.com, wes@mti-systems.com, martin.stiemerling@neclab.eu, trammell@tik.ee.ethz.ch, bill@wjcerveny.com From: RFC Errata System Message-Id: <20130308140215.3D67AB1E002@rfc-editor.org> Date: Fri, 8 Mar 2013 06:02:15 -0800 (PST) X-Mailman-Approved-At: Fri, 08 Mar 2013 16:41:52 -0800 Cc: rfc-editor@rfc-editor.org, ippm@ietf.org Subject: [ippm] [Editorial Errata Reported] RFC5357 (3511) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 14:16:14 -0000 The following errata report has been submitted for RFC5357, "A Two-Way Active Measurement Protocol (TWAMP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5357&eid=3511 -------------------------------------- Type: Editorial Reported by: Steve Baillargeon Section: Appendix Original Text ------------- controller responder +-----------------+ +-------------------+ | Server |<----------------->| | | Control-Client | | Session-Reflector | | Session-Sender |<--TWAMP-Test----->| | +-----------------+ +-------------------+ This example provides a simple architecture for responders where their role will be to simply act as light test points in the network. The controller establishes the test session with the Server through non-standard means. After the session is established, the controller transmits test packets to the responder. The responder follows the Session-Reflector behavior of TWAMP as described in section 4.2 with the following exceptions. In the case of TWAMP Light, the Session-Reflector does not necessarily have knowledge of the session state. IF the Session- Reflector does not have knowledge of the session state, THEN the Session-Reflector MUST copy the Sequence Number of the received packet to the Sequence Number field of the reflected packet. The controller receives the reflected test packets and collects two-way metrics. This architecture allows for collection of two-way metrics. Corrected Text -------------- controller responder +-----------------+ +-------------------+ | Server | | | | Control-Client | | Session-Reflector | | Session-Sender |<--TWAMP-Test----->| | +-----------------+ +-------------------+ This example provides a simple architecture for responders where their role will be to simply act as light test points in the network. The controller establishes the test session with the Server through non-standard means. After the session is established, the controller transmits test packets to the responder. Other examples are also possible. For instance, the responder may include a light Server responsible to instantiate the test session states based on the received test packets. The responder follows the Session-Reflector behavior of TWAMP as described in section 4.2 with the following exceptions. In the case of TWAMP Light, the Session-Reflector does not necessarily have knowledge of the session state. IF the Session- Reflector does not have knowledge of the session state, THEN the Session-Reflector MUST copy the Sequence Number of the received packet to the Sequence Number field of the reflected packet. The controller receives the reflected test packets and collects two-way metrics. This architecture allows for collection of two-way metrics. Otherwise IF the Session- Reflector has knowledge of the session state (using inspection of the received test packets for instance), THEN the Session-Reflector MUST generate it is own sequence number for each reflected packet. The controller receives the reflected test packets and collects two-way and one-way metrics. This alternative allows for collection of two-way and one-way metrics with TWAMP Light. Notes ----- Many readers of the appendix don't understand the meaning of informative and try to interpret the TWAMP light description as a specification. To correct this problem, it is recommended to add a few more lines explaning other TWAMP light architectures are possible. The original text describes a single TWAMP light architecture and this is misleading. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5357 (draft-ietf-ippm-twamp-09) -------------------------------------- Title : A Two-Way Active Measurement Protocol (TWAMP) Publication Date : October 2008 Author(s) : K. Hedayat, R. Krzanowski, A. Morton, K. Yum, J. Babiarz Category : PROPOSED STANDARD Source : IP Performance Metrics Area : Transport Stream : IETF Verifying Party : IESG From ippm@wjcerveny.com Mon Mar 11 12:55:56 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5F421F8DD5 for ; Mon, 11 Mar 2013 12:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqGwIxt87ktl for ; Mon, 11 Mar 2013 12:55:55 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7F00921F8DC5 for ; Mon, 11 Mar 2013 12:55:55 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AC7EC20B4D for ; Mon, 11 Mar 2013 15:55:54 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute5.internal (MEProxy); Mon, 11 Mar 2013 15:55:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=gFzcYo/JHdtYom8FEUzzVGauVbA=; b=tb30Vl8OPg7PcL0FnLhCJ8Xli3eW zyDuXNdSU6zblYy3EOYi68DInaiI+fMWPpKKZodJB4s2nundKVPI599ok6UH6euc EWocSHi1GtDr1K9l2vx+FYyAskwh+bFQ+N/2GmIrWa9ZdnNz/lqeTNyOqGnk34OR LPIILG1/8vS8/BU= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 87AD4B80E8A; Mon, 11 Mar 2013 15:55:54 -0400 (EDT) Message-Id: <1363031754.22213.140661202964369.0786320D@webmail.messagingengine.com> X-Sasl-Enc: YPhHmwEt/yoXy6Eav27dLxsZp2Y5G+TnM1HUhbm3XnPl 1363031754 From: William Cerveny To: ippm@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-d7ce2893 Date: Mon, 11 Mar 2013 15:55:54 -0400 Subject: [ippm] Slides for Thursday's (March 14, 2013) IPPM WG meeting X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 19:55:56 -0000 Dear IPPM WG Meeting Presenters, Please send me your slides for this Thursday's (March 14) IPPM WG meeting and I'll get them posted on the IETF meeting materials pages. Thanks, Bill Cerveny IPPM WG co-chair From trammell@tik.ee.ethz.ch Mon Mar 11 15:54:37 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EC821F903C for ; Mon, 11 Mar 2013 15:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYDwJnrb-89G for ; Mon, 11 Mar 2013 15:54:36 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0794E21F900C for ; Mon, 11 Mar 2013 15:54:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id AA672D9305 for ; Mon, 11 Mar 2013 23:54:21 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yfWPWU0gwB5G for ; Mon, 11 Mar 2013 23:54:21 +0100 (MET) Received: from dhcp-5213.meeting.ietf.org (dhcp-5213.meeting.ietf.org [130.129.82.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 30F71D9304 for ; Mon, 11 Mar 2013 23:54:21 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4D9A7961-A331-4090-8365-49C25ECBDEF7@tik.ee.ethz.ch> Date: Mon, 11 Mar 2013 18:54:19 -0400 To: "ippm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [ippm] Minutes and Jabber Scribes: Please Volunteer! X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:54:37 -0000 Greetings, all, If anyone attending the IPPM meetings Thursday and Friday in Orlando = would like to volunteer to serve as note-takers for minutes or Jabber = scribing for remote audio participants, please contact the chairs at = ippm-chairs@tools.ietf.org. It would be very much appreciated. :) Many thanks, best regards, Brian= From Maha.Abdallah@lip6.fr Mon Mar 11 21:53:17 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3599021F8742 for ; Mon, 11 Mar 2013 21:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvXmLyJJnrku for ; Mon, 11 Mar 2013 21:53:16 -0700 (PDT) Received: from isis.lip6.fr (isis.lip6.fr [IPv6:2001:660:3302:283c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9C721F86E4 for ; Mon, 11 Mar 2013 21:53:15 -0700 (PDT) Received: from poleia.lip6.fr (mailtwo.desir.lip6.fr [132.227.205.24]) by isis.lip6.fr (8.14.5/lip6) with ESMTP id r2C4r9AT010941 for ; Tue, 12 Mar 2013 05:53:11 +0100 (CET) X-pt: isis.lip6.fr Received: by poleia.lip6.fr (Postfix, from userid 33) id 3C745147CE6; Tue, 12 Mar 2013 05:53:04 +0100 (CET) Received: from 66.44.49.79 (SquirrelMail authenticated user abdallah) by mailtwo.lip6.fr with HTTP; Tue, 12 Mar 2013 05:53:04 +0100 Message-ID: <9322de9b807654578f80dccb7af48fc8.squirrel@mailtwo.lip6.fr> Date: Tue, 12 Mar 2013 05:53:04 +0100 From: "Maha Abdallah" To: ippm@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (isis.lip6.fr [132.227.60.2]); Tue, 12 Mar 2013 05:53:12 +0100 (CET) X-Scanned-By: MIMEDefang 2.73 on 132.227.60.2 Subject: [ippm] Springer's MMSJ - Special Issue on Network and Systems Support for Games X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 04:53:17 -0000 Springer’s Multimedia Systems Journal (MMSJ) Special Issue on Network and Systems Support for Games http://netgames2012.lip6.fr/MMSJ-SI ====================================================================== The market for networked video games is now worth more than $1 billion in western countries. The inherent social and community-building aspects of networked video games are widening the sector's influence on other markets, making their worldwide potential growth tremendous. Virtual economies are also exploding and becoming a growing economic force to be reckoned with. We are already seeing evidence that virtual and real world economies are starting to merge, where users/avatars can exchange real goods along with virtual goods in virtual market places. Another important facet of networked games’ success is that they are allowing not only economic factors to seep through, but social and cultural ones as well. Significant efforts are put into leveraging networked games technologies beyond entertainment, and toward educational, cultural, social, environmental, humanitarian, or learning and training ends. Serious games applications in these domains will clearly continue to grow. This growth clearly poses new challenges on the underlying network and system architectures, and introduces new research questions that require synthesis of a variety of research areas. This special issue focuses on network and systems aspects of games, and covers research and engineering topics that help understand networked games of today and enable the next generation of future networked games. Submissions are solicited on all aspects of networked games, including (but not limited to): - Novel system architectures for networked games (e.g., P2P, cloud gaming) - Efficient message distribution and network protocol design - State synchronization and lag compensation techniques - Network traffic modeling, measurement, and impact on network infrastructure - System benchmarking, performance evaluation, and provisioning - Operating system enhancements, service platforms, and middleware - Scalability issues for massively multiplayer online games (MMOG) - Multiplayer usability and user behavior studies - Personal communications and conferencing in games - Games on mobile devices and other resource-constrained systems - Networks of sensors and actuators, networked haptics - Quality of service and quality of experience - Dynamic and user-generated content authoring, management and adaptation - Content creation: non-linear storytelling, object capturing, algorithmic creation - Security, authentication, accounting and digital rights management - Cheat detection and prevention - Social networking in multiplayer games - Collaborative learning and training in multiplayer serious games IMPORTANT DATES ================ Submission Deadline: March 31, 2013 (23:59 EDT) First Round Notification: May 20, 2013 Revised Paper Due: July 15, 2013 Final Decision: August 26, 2013 SUBMISSION INSTRUCTIONS ======================== Prospective authors should prepare their manuscripts in accordance with the formatting and submission instructions of Springer’s Multimedia Systems Journal. Detailed submission instructions can be found at http://netgames2012.lip6.fr/MMSJ-SI Submitted articles should report original research results, and must not be under consideration for publication elsewhere. Submissions that are extended versions of previously published conference/workshop papers must technically extend the published version by at least 30%, must explain in the accompanying cover letter the novel and significant contribution of the extended work, and must explicitly cite the published conference/workshop version. GUEST EDITORS ============== Maha Abdallah, Pierre and Marie Curie University, France Khaled Boussetta, University of Paris 13, France Wei Tsang Ooi, National University of Singapore, Singapore From steve.baillargeon@ericsson.com Thu Mar 14 11:41:34 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42A911E81A1 for ; Thu, 14 Mar 2013 11:41:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HT8GAj23Yky for ; Thu, 14 Mar 2013 11:41:33 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 262F511E8144 for ; Thu, 14 Mar 2013 11:41:33 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-66-514219dc265d Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DD.48.02430.CD912415; Thu, 14 Mar 2013 19:41:32 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 14:41:32 -0400 From: Steve Baillargeon To: "MORTON JR., ALFRED (AL)" , "ippm@ietf.org" Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt Thread-Index: AQHOAMfan+4IuK/3AEOHNpEUAjz0YZiY4MOAgAzQzgA= Date: Thu, 14 Mar 2013 18:41:30 +0000 Message-ID: References: <20130201220204.18218.91881.idtracker@ietfa.amsl.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyuXRPlO4dSadAg2/v9S22HpvIaNHz4B2z A5PHy/45jB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY9fYCe8Fj1YpP3SvYGhgvyXUxcnBICJhI tHwM7GLkBDLFJC7cW8/WxcjFISRwhFFi0elv7BDOckaJ7unv2UGq2AQsJNbPXcYM0iwiECLx +7YNSFhYwFli8uk/zCC2iICLxNkt79ghbCuJvo6frCA2i4CqxId13xhBbF4BX4lTOx6C1QgJ OEn82L8MzGYUkJXYffY6E4jNLCAucevJfCaI4wQkluw5zwxhi0q8fPyPFcJWlljyZD8LRL2O xILdn9ggbG2JZQtfM0PsEpQ4OfMJywRGkVlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGWxi BIb8MQk23R2Me15aHmKU5mBREucNcr0QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGRd+P8 APXzttfOnFw4fdKVFaVRJv528+/uuf56aqr9rKOc9yZ/Pa2l4xDJG8h8/HSd5YVL+84LXuJi v/O+gc3i1aNJP97dtyre5Z2t73vLkH17yEeXPc+CqvOaE82fs9z+od7FxXVs9azWoALDlVpO 7i1vLXepCv17KiNhm6X65a32qZoJXZEvlFiKMxINtZiLihMBv8vIGEcCAAA= Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:41:34 -0000 Hi I would like to follow-up on the rate problem. Based on what I understood at the WG meeting , the main objective of the r= ate problem statement is to establish requirements on test protocols for me= asuring the bulk transfer capacity. If so, the title and abstract should cl= early state this aspect. Is it for UDP or TCP or both TCP and UDP bulk transfer capacity measurement= s?=20 The title and abstract should also clarify this aspect and the requirements= should highlight the differences. Should we reset/re-align the problem statement to align with Why is BTC so = hard? by Matt Mathis? -Steve -----Original Message----- From: Steve Baillargeon=20 Sent: March-06-13 9:08 AM To: 'MORTON JR., ALFRED (AL)' Cc: ippm@ietf.org Subject: RE: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt Hi Al I am resending with the correct draft name! I also added one more comment a= nd put them in chronological order. Here are my comments about draft-morton-ippm-twamp-rate-problem-02.txt. - Section 3) You indicate the two-way measurement architecture is favored = and I agree. You also indicate that each direction of transmission must be = evaluated separately and I agree. However this paragraph does not clarify t= he meaning of test streams vs test sessions. If you imply that each test st= ream requires its own test session, then I don't agree this is a good archi= tectural decision since in many access networks following a hub-and-spoke t= opology, I expect the spoke to be the low complexity device (as you have in= dicated) and the hub to be the controller where the test sessions are confi= gured, activated/deactivated and where data is probably collected. With In-= Service testing including 24/7 monitoring, one challenge is the number of c= oncurrent test sessions supported at the hub/controller. It is often the li= miting factor for scaling the measurement system. Therefore it is desirable= to include the case where a single test session (e.g. TWAMP) can measure b= oth the forward and reverse rates for a given Type-P packet. If you don't, = you could end-up with twice as many test sessions than actually needed.=20 - Section 4) You are missing variable intra-packet spacing in the pair, ens= emble or train where you are listing the MUST for the test protocol. - Section 5) I would like to see a requirement on the test protocol for th= e two-way architecture where it can measure the rate in a specific transmis= sion direction using a single Type-P test session where the test session ha= s its own test data stream and also measure rates in both forward and rever= se transmission directions using a single Type-P test session where the for= ward direction data stream is also used to measure the reverse direction ra= te. - Section 5) Why is it so important to specify ALL variables to the Receiv= er in the one-way architecture. As far as I know it is possible today to me= asure rate in a given direction with the existing OWAMP protocol without an= y changes to it. Regards Steve B -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: February-01-13 5:02 PM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : Rate Measurement Test Protocol Problem Statement Author(s) : Al Morton Filename : draft-ietf-ippm-rate-problem-02.txt Pages : 11 Date : 2013-02-01 Abstract: There is a rate measurement scenario which has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From trammell@tik.ee.ethz.ch Thu Mar 14 15:13:47 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478CF21F8E5C for ; Thu, 14 Mar 2013 15:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GxEfJlqcGKm for ; Thu, 14 Mar 2013 15:13:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DCFEB21F8D85 for ; Thu, 14 Mar 2013 15:13:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B302DD9310 for ; Thu, 14 Mar 2013 23:13:41 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id e8mRg5AljpgD for ; Thu, 14 Mar 2013 23:13:41 +0100 (MET) Received: from dhcp-5213.meeting.ietf.org (dhcp-5213.meeting.ietf.org [130.129.82.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4463AD9305 for ; Thu, 14 Mar 2013 23:13:41 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <518DF324-A8CE-44AB-8B50-4F9A2AC018DE@tik.ee.ethz.ch> Date: Thu, 14 Mar 2013 18:13:38 -0400 To: "ippm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [ippm] Raw material for tomorrow's charter discussion X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:13:47 -0000 Greetings, all, We've worked on editing the text of the IPPM charter to reflect what we = see as the union of work items which could fit under the new charter of = the working group, based on today's meeting=05, as well as past = discussions both on- and off-list. This is NOT a proposed new charter; = rather, it's a starting point for tomorrow's charter text discussion, = presented to allow participants to prepare. A proposed charter resulting from tomorrow's meeting will be circulated = thereafter. Cheers, Bill and Brian [begin charter discussion text] The IP Performance Metrics (IPPM) Working Group develops and maintains = standard metrics that can be applied to the quality, performance, and = reliability of Internet data delivery services and applications. It also = develops and maintains protocols for the measurement of these metrics. = These metrics are designed such that they can be performed by network = operators, end users, or independent testing groups. Metrics developed = by the IPPM WG are intended to provide unbiased quantitative performance = measurements and not a value judgement, such as =93good=94 or =93bad=94 = performance. The IPPM WG has produced documents that define specific metrics and = procedures for accurately measuring and documenting these metrics. The = working group will continue advancing these metrics along the standards = track, along the guidelines stated in RFC 6576. In addition, the WG will develop new metrics which more accurately model = the network path(s) under test and/or the behavior of transport and = application layer protocols on these path(s), whether based on = previously-defined or newly-defined fundamental metrics. In addition, = the WG will define methods for the composition and comparison of these = metrics, as well as passive and hybrid measurement methods for these = metrics, as appropriate. The WG may update its core framework RFC 2330 = as necessary to accommodate these activities. The WG has produced protocols to enable communication among test = equipment that implements the one- and two-way metrics (OWAMP and TWAMP = respectively). OWAMP and TWAMP will be advanced along the standards = track. Further development of these protocols will also be done inside = the WG. The interoperability of metric definitions is crucial to accurate, = comparable measurement. The WG will define and maintain a registry of = metric definitions to this end. The WG encourages work which compares = IPPM metrics with metrics developed elsewhere, particularly in regards = to interoperability, similarity and functionality. The WG also = encourages work which improves interoperability of IPPM protocols with = other protocols for measuring similar metrics. The IPPM WG seeks cooperation with other appropriate standards bodies = and forums (such as ATIS IIF, ITU-T SG 12, 13 and 15, MEF, BBF, etc.) to = promote consistent approaches and metrics. Within the IETF process, IPPM = metrics definitions will be subject to as rigorous a scrutiny for = usefulness, clarity, and accuracy as other protocol standards. The IPPM = WG will interact with other areas of IETF activity whose scope = intersects with the requirement of these specific metrics. The WG will, = on request, provide input to other IETF working groups on the use and = implementation of these metrics. [end charter discussion text] From gregimirsky@gmail.com Fri Mar 15 09:19:49 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDE521F87FF for ; Fri, 15 Mar 2013 09:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04+J8YXAbtwD for ; Fri, 15 Mar 2013 09:19:48 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3E21A21F87FB for ; Fri, 15 Mar 2013 09:19:48 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id cz10so2753150veb.35 for ; Fri, 15 Mar 2013 09:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NtVi23nr86MSHOguvgHrBtNLVqmzu4Mzw75PrY7r12U=; b=MXdLHZcHm3ZFagG/sOokChgQJW/BuuvA2oW0EcxUOcImnbSs4+i1O7PcAIHgFyarog 5BVkp+ySoqOQlJGdQuudjtxZ0AsLDrGrNa7L9saoN/He0WyIDBJtz/QPXVAFsvw/QsDa uBKCjJeZrG5r1SXJolpCN/tnJ1gY1CU0PPJEcAp9Bdp5JXYf8D2SZnmfkiu/jrSBuZRK 4dGFuxlBZLZGhB+yUZulK6ESsrMR8hUmQzWVdGqiZrnEI+i9uZ9WhUd8Yk+RvNpEnLMc 4QfyxwqMgL0a90Ci3vH/UKCwn8k7jm7K+gj7yNIUbyidDByBlMWGXnoxwJ4FtiUEo7r8 1WaA== MIME-Version: 1.0 X-Received: by 10.52.33.138 with SMTP id r10mr6629193vdi.34.1363364387598; Fri, 15 Mar 2013 09:19:47 -0700 (PDT) Received: by 10.220.217.73 with HTTP; Fri, 15 Mar 2013 09:19:47 -0700 (PDT) In-Reply-To: <518DF324-A8CE-44AB-8B50-4F9A2AC018DE@tik.ee.ethz.ch> References: <518DF324-A8CE-44AB-8B50-4F9A2AC018DE@tik.ee.ethz.ch> Date: Fri, 15 Mar 2013 09:19:47 -0700 Message-ID: From: Greg Mirsky To: Brian Trammell Content-Type: multipart/alternative; boundary=20cf307c9aae0632a404d7f902af Cc: "ippm@ietf.org" Subject: Re: [ippm] Raw material for tomorrow's charter discussion X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:19:49 -0000 --20cf307c9aae0632a404d7f902af Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Brian, et al., I think that the following phrase "In addition, the WG will define methods for the composition and comparison of these metrics, as well as passive and hybrid measurement methods for these metrics, as appropriate." implies that active measurement method is the main technique being considered and researched at IPPM WG. I think that all measurement methods are equally in scope of the WG and propose the following change: "In addition, the WG will define methods for the composition, comparison of these metrics, as well as active, passive, and hybrid measurement methods for these metrics, as appropriate." Regards, Greg On Thu, Mar 14, 2013 at 3:13 PM, Brian Trammell wr= ote: > Greetings, all, > > We've worked on editing the text of the IPPM charter to reflect what we > see as the union of work items which could fit under the new charter of t= he > working group, based on today's meeting , as well as past discussions bot= h > on- and off-list. This is NOT a proposed new charter; rather, it's a > starting point for tomorrow's charter text discussion, presented to allow > participants to prepare. > > A proposed charter resulting from tomorrow's meeting will be circulated > thereafter. > > Cheers, > > Bill and Brian > > [begin charter discussion text] > > The IP Performance Metrics (IPPM) Working Group develops and maintains > standard metrics that can be applied to the quality, performance, and > reliability of Internet data delivery services and applications. It also > develops and maintains protocols for the measurement of these metrics. > These metrics are designed such that they can be performed by network > operators, end users, or independent testing groups. Metrics developed by > the IPPM WG are intended to provide unbiased quantitative performance > measurements and not a value judgement, such as =93good=94 or =93bad=94 p= erformance. > > The IPPM WG has produced documents that define specific metrics and > procedures for accurately measuring and documenting these metrics. The > working group will continue advancing these metrics along the standards > track, along the guidelines stated in RFC 6576. > > In addition, the WG will develop new metrics which more accurately model > the network path(s) under test and/or the behavior of transport and > application layer protocols on these path(s), whether based on > previously-defined or newly-defined fundamental metrics. In addition, the > WG will define methods for the composition and comparison of these metric= s, > as well as passive and hybrid measurement methods for these metrics, as > appropriate. The WG may update its core framework RFC 2330 as necessary t= o > accommodate these activities. > > The WG has produced protocols to enable communication among test equipmen= t > that implements the one- and two-way metrics (OWAMP and TWAMP > respectively). OWAMP and TWAMP will be advanced along the standards track= . > Further development of these protocols will also be done inside the WG. > > The interoperability of metric definitions is crucial to accurate, > comparable measurement. The WG will define and maintain a registry of > metric definitions to this end. The WG encourages work which compares IPP= M > metrics with metrics developed elsewhere, particularly in regards to > interoperability, similarity and functionality. The WG also encourages wo= rk > which improves interoperability of IPPM protocols with other protocols fo= r > measuring similar metrics. > > The IPPM WG seeks cooperation with other appropriate standards bodies and > forums (such as ATIS IIF, ITU-T SG 12, 13 and 15, MEF, BBF, etc.) to > promote consistent approaches and metrics. Within the IETF process, IPPM > metrics definitions will be subject to as rigorous a scrutiny for > usefulness, clarity, and accuracy as other protocol standards. The IPPM W= G > will interact with other areas of IETF activity whose scope intersects wi= th > the requirement of these specific metrics. The WG will, on request, provi= de > input to other IETF working groups on the use and implementation of these > metrics. > > [end charter discussion text] > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --20cf307c9aae0632a404d7f902af Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Brian, et al.,
I think that the following phrase
"In addit= ion, the WG will define methods for the composition and=20 comparison of these metrics, as well as passive and hybrid measurement=20 methods for these metrics, as appropriate."
implies that active mea= surement method is the main technique being considered and researched at IP= PM WG. I think that all measurement methods are equally in scope of the WG = and propose the following change:
"In addition, the WG will define methods for the composition,=20 comparison of these metrics, as well as active, passive, and hybrid measure= ment=20 methods for these metrics, as appropriate."

Regards,
Greg
On Thu, Mar 14, 2013 at 3:13 PM, Brian Tram= mell <trammell@tik.ee.ethz.ch> wrote:
Greetings, all,

We've worked on editing the text of the IPPM charter to reflect what we= see as the union of work items which could fit under the new charter of th= e working group, based on today's meeting , as well as past discussions= both on- and off-list. This is NOT a proposed new charter; rather, it'= s a starting point for tomorrow's charter text discussion, presented to= allow participants to prepare.

A proposed charter resulting from tomorrow's meeting will be circulated= thereafter.

Cheers,

Bill and Brian

[begin charter discussion text]

The IP Performance Metrics (IPPM) Working Group develops and maintains stan= dard metrics that can be applied to the quality, performance, and reliabili= ty of Internet data delivery services and applications. It also develops an= d maintains protocols for the measurement of these metrics. These metrics a= re designed such that they can be performed by network operators, end users= , or independent testing groups. Metrics developed by the IPPM WG are inten= ded to provide unbiased quantitative performance measurements and not a val= ue judgement, such as =93good=94 or =93bad=94 performance.

The IPPM WG has produced documents that define specific metrics and procedu= res for accurately measuring and documenting these metrics. The working gro= up will continue advancing these metrics along the standards track, along t= he guidelines stated in RFC 6576.

In addition, the WG will develop new metrics which more accurately model th= e network path(s) under test and/or the behavior of transport and applicati= on layer protocols on these path(s), whether based on previously-defined or= newly-defined fundamental metrics. In addition, the WG will define methods= for the composition and comparison of these metrics, as well as passive an= d hybrid measurement methods for these metrics, as appropriate. The WG may = update its core framework RFC 2330 as necessary to accommodate these activi= ties.

The WG has produced protocols to enable communication among test equipment = that implements the one- and two-way metrics (OWAMP and TWAMP respectively)= . OWAMP and TWAMP will be advanced along the standards track. Further devel= opment of these protocols will also be done inside the WG.

The interoperability of metric definitions is crucial to accurate, comparab= le measurement. The WG will define and maintain a registry of metric defini= tions to this end. The WG encourages work which compares IPPM metrics with = metrics developed elsewhere, particularly in regards to interoperability, s= imilarity and functionality. The WG also encourages work which improves int= eroperability of IPPM protocols with other protocols for measuring similar = metrics.

The IPPM WG seeks cooperation with other appropriate standards bodies and f= orums (such as ATIS IIF, ITU-T SG 12, 13 and 15, MEF, BBF, etc.) to promote= consistent approaches and metrics. Within the IETF process, IPPM metrics d= efinitions will be subject to as rigorous a scrutiny for usefulness, clarit= y, and accuracy as other protocol standards. The IPPM WG will interact with= other areas of IETF activity whose scope intersects with the requirement o= f these specific metrics. The WG will, on request, provide input to other I= ETF working groups on the use and implementation of these metrics.

[end charter discussion text]


_______________________________________________
ippm mailing list
ippm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ippm

--20cf307c9aae0632a404d7f902af-- From matt.mathis@gmail.com Fri Mar 15 14:50:16 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9FA21F8A11 for ; Fri, 15 Mar 2013 14:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtdPgTZSzbJ8 for ; Fri, 15 Mar 2013 14:50:15 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6486921F89E9 for ; Fri, 15 Mar 2013 14:50:15 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so3980476oag.15 for ; Fri, 15 Mar 2013 14:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=ZrEwy14SpklfDCkT4sPgbbTuj1SBWz1S5ZkcdFXMomc=; b=mdiX98jtsYJfea8a182nl7q/pUa3RtnHpxhX8JBCLe5h+oG2DbKt8gxJQYoV2Dv1V3 y+ES8BNObv4NI1ObMYDQ8n+RDfs3ZVBiyqDxBe1sGlk8IuaOWEbuc63EcQ8C1bt0IQFB U1e/F4fK7oHKfPCSEpc5dLl3g5Ahi0D9ZviWz5oQ1M+aM5F1dpBYEmjVmKL8FWRrPGHz YMFKQih+BNBbngy6Ndf4sTXEzWYvsePoR+XAFjuoCRMEEM0PBNtJZdv4im3r/O8pV3s9 TR1M6Pepu3spucmAQOdJL4Ax+RBAoinLyxtUAK/CBdquNsW29Uhlk7v4pDEvy+0mGcRf myvw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=ZrEwy14SpklfDCkT4sPgbbTuj1SBWz1S5ZkcdFXMomc=; b=pVY/uMWs3V5LEkSDohjZ0F8slypJ69x7GAvHV7kwCBEO9sB5uMqqytyTY33uFjy3Dm MqD64Gd8JaIe3RWpJojWMkQLsqOeiKTrwKJGM8w2TRnXkdRyDl5mx+DigGAQs8Krpwb8 Ioki6ZGNqVFCADrX1m35AAtp/Vf8iOSNECAsRKurIiJ210qM/UIIKewZelhlILZdYtay Lv4rP+W621sholTdxKxrbUWZJijy2xM13WnzADMRGI8Iu5bVX06n3LV72RfkZBE54B36 JuKMVqM2Ss0CyKmuwGfVvvtiw9qNqGu8F/6eT+M2DFqoWM+qowLG/unNvAf9/MNCjvTB 2tFw== MIME-Version: 1.0 X-Received: by 10.60.3.233 with SMTP id f9mr3721120oef.32.1363384214988; Fri, 15 Mar 2013 14:50:14 -0700 (PDT) Sender: matt.mathis@gmail.com Received: by 10.76.71.198 with HTTP; Fri, 15 Mar 2013 14:50:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Mar 2013 14:50:14 -0700 X-Google-Sender-Auth: K_lDkMWebJYl1BsJrfUOwTbuOTs Message-ID: From: Matt Mathis To: ippm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [ippm] URL for draft charter X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 21:50:16 -0000 I have to apologize: my message sending the doc URL to the list bounced, and the error got filed so I did not see it. Sorry about that. The draft from today's session is still posted, so you can read the updated (still rough) draft. The chairs have already ported this back to traditional technology, and will be circulating it some time soon for comments from the list. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Fri, Mar 15, 2013 at 9:34 AM, Matt Mathis wrote: > This doc has public shared write.... > > https://docs.google.com/document/d/1npqPOEG1x2TJYVa8I0LotZ9t9jywhp4CPJvMMhd4McI/edit# > > Please be gentle. > > Thanks, > --MM-- > Matt Mathis Home/Cell:412.654.7529 > ------------------------------------------- > Evil is defined by mortals who think they know "The Truth" and use > force to apply it to others. From ippm@wjcerveny.com Mon Mar 18 09:17:51 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8B411E80E9 for ; Mon, 18 Mar 2013 09:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbQLkQblRTRe for ; Mon, 18 Mar 2013 09:17:43 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2C60711E80E8 for ; Mon, 18 Mar 2013 09:17:39 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B677320E00 for ; Mon, 18 Mar 2013 12:17:38 -0400 (EDT) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute6.internal (MEProxy); Mon, 18 Mar 2013 12:17:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=4JSIQYiPgc4M240ozChWx79L70A=; b=XEM C5RoXM8DoOePASUsyF8d90xN7n/KbR0MWx3RjRogzn0CU444LoaEXQ2Bj5OvK4im AUpKr5qt/yPSeMWi390fWMS+RvhnYq4icRoisVCliXDitk3OMeNJcbWoh3/w/ia1 NShLAWYk//RiqYCnrS4rPvMeQn5PogdGE/5YlHhA= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id 8C32A701F3F; Mon, 18 Mar 2013 12:17:38 -0400 (EDT) Message-Id: <1363623458.6393.140661205906597.14CCFBC0@webmail.messagingengine.com> X-Sasl-Enc: u0HCxBMrP2GYhqLYqL/EQ9fkKKagAyVuPYim1pbj04rR 1363623458 From: William Cerveny To: ippm@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-911fcbf3 In-Reply-To: <1363623324.5716.140661205903585.5E4C152A@webmail.messagingengine.com> References: <1363623324.5716.140661205903585.5E4C152A@webmail.messagingengine.com> Date: Mon, 18 Mar 2013 12:17:38 -0400 Subject: Re: [ippm] IPPM minutes available for IETF 86 meetings X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:17:51 -0000 The minutes can be viewed at http://www.ietf.org/proceedings/86/minutes/minutes-86-ippm by the way. Bill Cerveny On Mon, Mar 18, 2013, at 12:15 PM, William Cerveny wrote: > I'm uploaded the minutes for the IETF 86 IPPM meetings. For the first > session, I combined minutes recorded by Nevil Brownlee and Al Morton > (Thanks Nevil and Al!). For the rechartering discussion in the second > session, I included notes (who said or suggested what) that were > recorded in the collaborative / shared charter document on Google Docs. > > If you have any updates to the minutes, please let me know. > > Thanks, > > Bill Cerveny From ippm@wjcerveny.com Mon Mar 18 09:31:01 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D2921F8F1C for ; Mon, 18 Mar 2013 09:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-G1JWKGr-O5 for ; Mon, 18 Mar 2013 09:30:53 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0F55F11E80D9 for ; Mon, 18 Mar 2013 09:15:30 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2E56620CCA for ; Mon, 18 Mar 2013 12:15:25 -0400 (EDT) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute1.internal (MEProxy); Mon, 18 Mar 2013 12:15:25 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=ZCbnCN6vihTh2Hmw3tSOeV7scAA=; b=oqeUAw+2FtVbyntP02VB/PM72uA8 Rp0PRVOGLicist3rglZQSCkMS6GEStLjL63EFJsnDOz/Q1ny6U0sAVVL02DHKQpv eDMMeL91WK0klKywZrww9ml0XPUBJQHvRPh+xYnZGK+yIi/MbKxz0R3Vy+FoPRtY KojURUiaFxiY3Qc= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id 09C7F701F40; Mon, 18 Mar 2013 12:15:25 -0400 (EDT) Message-Id: <1363623324.5716.140661205903585.5E4C152A@webmail.messagingengine.com> X-Sasl-Enc: HLA/0plPp6fpF7/lmI0V3vLkKK8J1txLpcHgiS0NDQjP 1363623324 From: William Cerveny To: ippm@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-911fcbf3 Date: Mon, 18 Mar 2013 12:15:24 -0400 Subject: [ippm] IPPM minutes available for IETF 86 meetings X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:31:01 -0000 I'm uploaded the minutes for the IETF 86 IPPM meetings. For the first session, I combined minutes recorded by Nevil Brownlee and Al Morton (Thanks Nevil and Al!). For the rechartering discussion in the second session, I included notes (who said or suggested what) that were recorded in the collaborative / shared charter document on Google Docs. If you have any updates to the minutes, please let me know. Thanks, Bill Cerveny From trammell@tik.ee.ethz.ch Mon Mar 18 19:34:19 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D44D21F84E2 for ; Mon, 18 Mar 2013 19:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkrrCSQL+RT4 for ; Mon, 18 Mar 2013 19:34:16 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9121F84E0 for ; Mon, 18 Mar 2013 19:34:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 96D28D930B for ; Tue, 19 Mar 2013 03:34:15 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id upZQ6gfXkPra for ; Tue, 19 Mar 2013 03:34:15 +0100 (MET) Received: from [175.159.194.189] (unknown [175.159.194.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A5F43D9308 for ; Tue, 19 Mar 2013 03:34:14 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Mar 2013 10:34:11 +0800 Message-Id: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> To: "ippm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "" List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 02:34:19 -0000 Greetings, all, We have updated the draft charter based on discussion during our meeting = in Orlando last Friday. We believe the draft charter below addresses all = comments received, and would like to issue a call for WG consensus on = the charter text. We'll be issuing separate calls for each of the = documents under consideration for adoption as WG items under this = charter. If you support the adoption of this charter for IPPM, please reply to = this message and/or to the list stating so.=20 If you do not support the adoption of this charter, please reply to the = list, with your suggestions for improvement and further discussion. Please reply by Monday 25 March 2013; absent continuing discussion, we = intend to evaluate consensus then, and send the charter to the IESG for = approval. Many thanks, best regards, Brian IP Performance Metrics (ippm) ----------------------------- Charter Current Status: Active Chairs: Brian Trammell=20 Bill Cerveny =20 Transport Area Directors: Martin Stiemerling Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: http://www.ietf.org/mail-archive/web/ippm Description of Working Group: The IP Performance Metrics (IPPM) Working Group develops and maintains = standard metrics that can be applied to the quality, performance, and reliability = of Internet data delivery services and applications. It also develops and maintains protocols for the measurement of these metrics. These metrics = are designed such that they can be performed by network operators, end = users, or independent testing groups. Metrics developed by the IPPM WG are = intended to provide unbiased quantitative performance measurements and not a value judgement. The IPPM WG has produced documents that define specific metrics and = procedures for accurately measuring and documenting these metrics. The working = group will continue advancing these metrics along the standards track, using the guidelines stated in RFC 6576. To the extent possible, these metrics = will be used as the basis for future work on metrics in the WG. The WG will develop the minimum number of new metrics and models needed = to more accurately quantitatively characterize the network path(s) under test = and/or the behavior of transport and application layer protocols on these = path(s). New metric definitions will state how the definition improves on an existing = metric definition, or encompasses a metric not previously defined. Additional methods will be defined for the composition and calibration = of IPPM-defined metrics, as well as active, passive and hybrid measurement = methods for these metrics. In addition, WG encourages work which describes the applicability of metrics and measurement methods, especially to improve understanding of the tradeoffs involved among active, passive, and = hybrid methods. The WG may update its core framework RFC 2330 as necessary to = accommodate these activities. The WG has produced protocols for communication among test equipment to = enable the measurement of the one- and two-way metrics (OWAMP and TWAMP = respectively). These protocols will be advanced along the standards track. The WG will = further develop and improve these protocols. The WG may develop new measurement protocols as necessary to support new metrics. New metric and protocol development will focus on the automatability of measurements in order to support large-scale measurement efforts. The equivalency of metric definitions is crucial to accurate, comparable = and reproducible measurement. The WG will define and maintain a registry of = metric definitions to this end. The WG encourages work which compares IPPM = metrics with metrics developed elsewhere, particularly in regards to = equivalency, similarity and functionality. The WG also encourages work which improves = the availability of information about the context in which measurements were = taken. The IPPM WG seeks cooperation with other appropriate standards bodies = and forums to promote consistent approaches and metrics. Within the IETF = process, IPPM metric definitions will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM = WG will interact with other areas of IETF activity whose scope intersects with = the requirement of these specific metrics. The WG will, on request, provide = input to other IETF working groups on the use and implementation of these = metrics. Milestones: TBD - Submit draft on access rate measurement protocol problem = statement to IESG as Informational TBD - Submit draft on RFC 2680 standards-track advancement testing to IESG as Informational =20 Additional milestones TBD= From mattmathis@google.com Mon Mar 18 22:47:31 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCEA21F8A51 for ; Mon, 18 Mar 2013 22:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7+vkfJ-Lt3A for ; Mon, 18 Mar 2013 22:47:30 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A446A21F8556 for ; Mon, 18 Mar 2013 22:47:30 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id c10so124863ieb.31 for ; Mon, 18 Mar 2013 22:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Zik6hwXWyIvDRPv/btgjtKuPKsNEQeTeiZu1/xEo8ss=; b=WDLPZFLLT4BMCrxlK1BHxrPTGcQa/LN0XCx+HOQkyGSGu2daVv05yF7x6OUjUvtTR0 I96aSOxYuglaWOEXYPvuu0JSjHWUDQWHK5tpGBZg+o9k47rshcuQXhZj7sIdYM0te8I1 OE5wJ1tjAMvgQEoGKLbflnnvccmMdMXrWLdnysC6Kde84aUiMnU659Q9Gb/iDG0yFiS6 YriQB6BrOPBdd3IY5lHUIkds56byGR1Z4xjMLMF/SujmzgDw2Q+BRXjV/Y/xPLsUHysM vB0xfmO7peOB7xkVFS+K9D5KCoZZFExtJefL1Ifb3lHioJz2m4SLR8MM5EmZlYrzBhL3 eqGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Zik6hwXWyIvDRPv/btgjtKuPKsNEQeTeiZu1/xEo8ss=; b=hu85FOrEjTbh9Qkkt6BAdlgWMEkBbfUJVSvP3/OOIEidvcPLNkMIBcgrE72dWkJsea MSkTUTaCiwvKFjNMa3kc2aLPfafuKgaxx/I9hcgQatOFim3zOnyaISY77wtUj5lfAXTZ 77fGfAefhTOPJ2nl2/F4gs1SGadKXMSeCXtFiIlpoznezTubFjZNNMoN22ltLEQHAKYx 16HFaz+3jqxWtHZG7behOeTHY243RiftDJfChTpFq6vCWN1JJp1NjjEbtJNBUyIDTVKA Rsv3S2fu9miKs344hTAtzLbOj302xl2qoM1dnSonNx+mxk7zTTsa++6qrVuKXPzoLzb6 Mq2A== MIME-Version: 1.0 X-Received: by 10.50.135.100 with SMTP id pr4mr944226igb.37.1363672042501; Mon, 18 Mar 2013 22:47:22 -0700 (PDT) Received: by 10.64.77.106 with HTTP; Mon, 18 Mar 2013 22:47:22 -0700 (PDT) In-Reply-To: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> Date: Mon, 18 Mar 2013 22:47:22 -0700 Message-ID: From: Matt Mathis To: "" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmjHhO8Cbf7GAU5ARBchFdE1/LffWaiSI6d0b572rriHHAF9nq8de/t7IjQPZNy+Isogkpqp8tT4qxSFblKPirWPBsb8ufMh2E6auFTOpOLYRdll1obfjiDtfZkTo+Eap3iua5CveUhl2JUEWMQxcsjSFvBhMD61cMeHe630WugxvBmU7Z3nVqGusX3N6NLAUQt0GPC Cc: "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 05:47:31 -0000 Look Good to Me (LGTM) One minor issue: > "To the extent possible, these metrics will be used as the basis for futu= re work on metrics in the WG." I don't understand the point here. Perhaps s/metrics/guidelines/ (first time only)? Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, Mar 18, 2013 at 7:34 PM, Brian Trammell w= rote: > Greetings, all, > > We have updated the draft charter based on discussion during our meeting = in Orlando last Friday. We believe the draft charter below addresses all co= mments received, and would like to issue a call for WG consensus on the cha= rter text. We'll be issuing separate calls for each of the documents under = consideration for adoption as WG items under this charter. > > If you support the adoption of this charter for IPPM, please reply to thi= s message and/or to the list stating so. > > If you do not support the adoption of this charter, please reply to the l= ist, with your suggestions for improvement and further discussion. > > Please reply by Monday 25 March 2013; absent continuing discussion, we in= tend to evaluate consensus then, and send the charter to the IESG for appro= val. > > Many thanks, best regards, > > Brian > > > IP Performance Metrics (ippm) > ----------------------------- > > Charter > > Current Status: Active > > Chairs: > Brian Trammell > Bill Cerveny > > Transport Area Directors: > Martin Stiemerling > Martin Stiemerling > > Transport Area Advisor: > Martin Stiemerling > > Mailing Lists: > General Discussion: ippm@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ippm > Archive: http://www.ietf.org/mail-archive/web/ippm > > Description of Working Group: > > The IP Performance Metrics (IPPM) Working Group develops and maintains st= andard > metrics that can be applied to the quality, performance, and reliability = of > Internet data delivery services and applications. It also develops and > maintains protocols for the measurement of these metrics. These metrics a= re > designed such that they can be performed by network operators, end users,= or > independent testing groups. Metrics developed by the IPPM WG are intended= to > provide unbiased quantitative performance measurements and not a value > judgement. > > The IPPM WG has produced documents that define specific metrics and proce= dures > for accurately measuring and documenting these metrics. The working group= will > continue advancing these metrics along the standards track, using the > guidelines stated in RFC 6576. To the extent possible, these metrics will= be > used as the basis for future work on metrics in the WG. > > The WG will develop the minimum number of new metrics and models needed t= o more > accurately quantitatively characterize the network path(s) under test and= /or > the behavior of transport and application layer protocols on these path(s= ). New > metric definitions will state how the definition improves on an existing = metric > definition, or encompasses a metric not previously defined. > > Additional methods will be defined for the composition and calibration of > IPPM-defined metrics, as well as active, passive and hybrid measurement m= ethods > for these metrics. In addition, WG encourages work which describes the > applicability of metrics and measurement methods, especially to improve > understanding of the tradeoffs involved among active, passive, and hybrid > methods. > > The WG may update its core framework RFC 2330 as necessary to accommodate= these > activities. > > The WG has produced protocols for communication among test equipment to e= nable > the measurement of the one- and two-way metrics (OWAMP and TWAMP respecti= vely). > These protocols will be advanced along the standards track. The WG will f= urther > develop and improve these protocols. The WG may develop new measurement > protocols as necessary to support new metrics. New metric and protocol > development will focus on the automatability of measurements in order to > support large-scale measurement efforts. > > The equivalency of metric definitions is crucial to accurate, comparable = and > reproducible measurement. The WG will define and maintain a registry of m= etric > definitions to this end. The WG encourages work which compares IPPM metri= cs > with metrics developed elsewhere, particularly in regards to equivalency, > similarity and functionality. The WG also encourages work which improves = the > availability of information about the context in which measurements were = taken. > > The IPPM WG seeks cooperation with other appropriate standards bodies and > forums to promote consistent approaches and metrics. Within the IETF proc= ess, > IPPM metric definitions will be subject to as rigorous a scrutiny for > usefulness, clarity, and accuracy as other protocol standards. The IPPM W= G will > interact with other areas of IETF activity whose scope intersects with th= e > requirement of these specific metrics. The WG will, on request, provide i= nput > to other IETF working groups on the use and implementation of these metri= cs. > > Milestones: > > TBD - Submit draft on access rate measurement protocol problem state= ment > to IESG as Informational > TBD - Submit draft on RFC 2680 standards-track advancement testing > to IESG as Informational > > Additional milestones TBD > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From marcelo@it.uc3m.es Tue Mar 19 04:51:06 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27BC21F8622 for ; Tue, 19 Mar 2013 04:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2ObFVC9BRDG for ; Tue, 19 Mar 2013 04:51:05 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id CB41121F86B2 for ; Tue, 19 Mar 2013 04:51:04 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 97B0B9D70B0 for ; Tue, 19 Mar 2013 12:51:03 +0100 (CET) X-uc3m-safe: yes Received: from [163.117.203.239] (unknown [163.117.203.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 05B1C10D83C7 for ; Tue, 19 Mar 2013 12:51:01 +0100 (CET) Message-ID: <51485126.9060707@it.uc3m.es> Date: Tue, 19 Mar 2013 12:51:02 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: ippm@ietf.org References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> In-Reply-To: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Tue, 19 Mar 2013 12:51:03 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19730.003 X-TM-AS-Result: No--34.142-7.0-31-1 X-imss-scan-details: No--34.142-7.0-31-1 Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 11:51:06 -0000 Hi, Thanks for the work on the charter text. I support it. Regards, marcelo El 19/03/13 03:34, Brian Trammell escribió: > Greetings, all, > > We have updated the draft charter based on discussion during our meeting in Orlando last Friday. We believe the draft charter below addresses all comments received, and would like to issue a call for WG consensus on the charter text. We'll be issuing separate calls for each of the documents under consideration for adoption as WG items under this charter. > > If you support the adoption of this charter for IPPM, please reply to this message and/or to the list stating so. > > If you do not support the adoption of this charter, please reply to the list, with your suggestions for improvement and further discussion. > > Please reply by Monday 25 March 2013; absent continuing discussion, we intend to evaluate consensus then, and send the charter to the IESG for approval. > > Many thanks, best regards, > > Brian > > > IP Performance Metrics (ippm) > ----------------------------- > > Charter > > Current Status: Active > > Chairs: > Brian Trammell > Bill Cerveny > > Transport Area Directors: > Martin Stiemerling > Martin Stiemerling > > Transport Area Advisor: > Martin Stiemerling > > Mailing Lists: > General Discussion: ippm@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ippm > Archive: http://www.ietf.org/mail-archive/web/ippm > > Description of Working Group: > > The IP Performance Metrics (IPPM) Working Group develops and maintains standard > metrics that can be applied to the quality, performance, and reliability of > Internet data delivery services and applications. It also develops and > maintains protocols for the measurement of these metrics. These metrics are > designed such that they can be performed by network operators, end users, or > independent testing groups. Metrics developed by the IPPM WG are intended to > provide unbiased quantitative performance measurements and not a value > judgement. > > The IPPM WG has produced documents that define specific metrics and procedures > for accurately measuring and documenting these metrics. The working group will > continue advancing these metrics along the standards track, using the > guidelines stated in RFC 6576. To the extent possible, these metrics will be > used as the basis for future work on metrics in the WG. > > The WG will develop the minimum number of new metrics and models needed to more > accurately quantitatively characterize the network path(s) under test and/or > the behavior of transport and application layer protocols on these path(s). New > metric definitions will state how the definition improves on an existing metric > definition, or encompasses a metric not previously defined. > > Additional methods will be defined for the composition and calibration of > IPPM-defined metrics, as well as active, passive and hybrid measurement methods > for these metrics. In addition, WG encourages work which describes the > applicability of metrics and measurement methods, especially to improve > understanding of the tradeoffs involved among active, passive, and hybrid > methods. > > The WG may update its core framework RFC 2330 as necessary to accommodate these > activities. > > The WG has produced protocols for communication among test equipment to enable > the measurement of the one- and two-way metrics (OWAMP and TWAMP respectively). > These protocols will be advanced along the standards track. The WG will further > develop and improve these protocols. The WG may develop new measurement > protocols as necessary to support new metrics. New metric and protocol > development will focus on the automatability of measurements in order to > support large-scale measurement efforts. > > The equivalency of metric definitions is crucial to accurate, comparable and > reproducible measurement. The WG will define and maintain a registry of metric > definitions to this end. The WG encourages work which compares IPPM metrics > with metrics developed elsewhere, particularly in regards to equivalency, > similarity and functionality. The WG also encourages work which improves the > availability of information about the context in which measurements were taken. > > The IPPM WG seeks cooperation with other appropriate standards bodies and > forums to promote consistent approaches and metrics. Within the IETF process, > IPPM metric definitions will be subject to as rigorous a scrutiny for > usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will > interact with other areas of IETF activity whose scope intersects with the > requirement of these specific metrics. The WG will, on request, provide input > to other IETF working groups on the use and implementation of these metrics. > > Milestones: > > TBD - Submit draft on access rate measurement protocol problem statement > to IESG as Informational > TBD - Submit draft on RFC 2680 standards-track advancement testing > to IESG as Informational > > Additional milestones TBD > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From steve.baillargeon@ericsson.com Tue Mar 19 05:50:16 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1990721F8A11 for ; Tue, 19 Mar 2013 05:50:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kLIgX+PKNJQ for ; Tue, 19 Mar 2013 05:50:15 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B74A21F869A for ; Tue, 19 Mar 2013 05:50:14 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-7f-51485f05e850 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 89.38.02430.50F58415; Tue, 19 Mar 2013 13:50:14 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 08:50:13 -0400 From: Steve Baillargeon To: "" , "ippm@ietf.org" Thread-Topic: [ippm] Call for Consensus on new charter for IPPM Thread-Index: AQHOJEpFnIinYFOjE0+InTcVm2jt2Zis95Ug Date: Tue, 19 Mar 2013 12:50:12 +0000 Message-ID: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> In-Reply-To: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPlC5bvEegwc+/fBYdD96xW/Q8eMfs wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGVcmhxZcFiromfCIqYGxjVKXYycHBICJhIH N65kh7DFJC7cW8/WxcjFISRwhFHi5uTF7BDOckaJQ8tns4BUsQlYSKyfu4wZxBYRSJJoevGI CcQWFrCT6J21kAkibi/x8Ms9KNtI4snCNrANLAKqEn9P3QCL8wr4SpxfsZwRxBYScJRYem09 WJxTwElizcRVYPWMArISu89eB4szC4hL3HoynwniUgGJJXvOM0PYohIvH/9jhbCVJb7PecQC Ua8jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjBylxalluelG BpsYgdFwTIJNdwfjnpeWhxilOViUxHmDXC8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCM cisNV68Nzj5S37lse6HmMu41W/U73NTvTJ27n1NL/8qp601fPBzcdzTZa3onfFApevxadN0x 4f8t8pUvYw5UTbr8dNmDbPVpzxxnHRZ6qPkoYZH4iysWUna53PcUTpw6zF58dK2R9weXG0eu J6hZmYbVriu5Lum7YuYXe7t8LXHuT4nvT61TYinOSDTUYi4qTgQAGcsvMlQCAAA= Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 12:50:16 -0000 I support. -Steve -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: March-18-13 10:34 PM To: ippm@ietf.org Subject: [ippm] Call for Consensus on new charter for IPPM Greetings, all, We have updated the draft charter based on discussion during our meeting in= Orlando last Friday. We believe the draft charter below addresses all comm= ents received, and would like to issue a call for WG consensus on the chart= er text. We'll be issuing separate calls for each of the documents under co= nsideration for adoption as WG items under this charter. If you support the adoption of this charter for IPPM, please reply to this = message and/or to the list stating so.=20 If you do not support the adoption of this charter, please reply to the lis= t, with your suggestions for improvement and further discussion. Please reply by Monday 25 March 2013; absent continuing discussion, we inte= nd to evaluate consensus then, and send the charter to the IESG for approva= l. Many thanks, best regards, Brian IP Performance Metrics (ippm) ----------------------------- Charter Current Status: Active Chairs: Brian Trammell=20 Bill Cerveny =20 Transport Area Directors: Martin Stiemerling Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: http://www.ietf.org/mail-archive/web/ippm Description of Working Group: The IP Performance Metrics (IPPM) Working Group develops and maintains stan= dard metrics that can be applied to the quality, performance, and reliabili= ty of Internet data delivery services and applications. It also develops an= d maintains protocols for the measurement of these metrics. These metrics a= re designed such that they can be performed by network operators, end users= , or independent testing groups. Metrics developed by the IPPM WG are inten= ded to provide unbiased quantitative performance measurements and not a val= ue judgement. The IPPM WG has produced documents that define specific metrics and procedu= res for accurately measuring and documenting these metrics. The working gro= up will continue advancing these metrics along the standards track, using t= he guidelines stated in RFC 6576. To the extent possible, these metrics wil= l be used as the basis for future work on metrics in the WG. The WG will develop the minimum number of new metrics and models needed to = more accurately quantitatively characterize the network path(s) under test = and/or the behavior of transport and application layer protocols on these p= ath(s). New metric definitions will state how the definition improves on an= existing metric definition, or encompasses a metric not previously defined= . Additional methods will be defined for the composition and calibration of I= PPM-defined metrics, as well as active, passive and hybrid measurement meth= ods for these metrics. In addition, WG encourages work which describes the = applicability of metrics and measurement methods, especially to improve und= erstanding of the tradeoffs involved among active, passive, and hybrid meth= ods. The WG may update its core framework RFC 2330 as necessary to accommodate t= hese activities. The WG has produced protocols for communication among test equipment to ena= ble the measurement of the one- and two-way metrics (OWAMP and TWAMP respec= tively). These protocols will be advanced along the standards track. The WG will fur= ther develop and improve these protocols. The WG may develop new measuremen= t protocols as necessary to support new metrics. New metric and protocol de= velopment will focus on the automatability of measurements in order to supp= ort large-scale measurement efforts. The equivalency of metric definitions is crucial to accurate, comparable an= d reproducible measurement. The WG will define and maintain a registry of m= etric definitions to this end. The WG encourages work which compares IPPM m= etrics with metrics developed elsewhere, particularly in regards to equival= ency, similarity and functionality. The WG also encourages work which impro= ves the availability of information about the context in which measurements= were taken. The IPPM WG seeks cooperation with other appropriate standards bodies and f= orums to promote consistent approaches and metrics. Within the IETF process= , IPPM metric definitions will be subject to as rigorous a scrutiny for use= fulness, clarity, and accuracy as other protocol standards. The IPPM WG wil= l interact with other areas of IETF activity whose scope intersects with th= e requirement of these specific metrics. The WG will, on request, provide i= nput to other IETF working groups on the use and implementation of these me= trics. Milestones: TBD - Submit draft on access rate measurement protocol problem stateme= nt to IESG as Informational TBD - Submit draft on RFC 2680 standards-track advancement testing to IESG as Informational =20 Additional milestones TBD _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From samita.chakrabarti@ericsson.com Tue Mar 19 09:05:41 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5311E11E80A5 for ; Tue, 19 Mar 2013 09:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvDpD5Osi0hj for ; Tue, 19 Mar 2013 09:05:40 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 774C411E80A4 for ; Tue, 19 Mar 2013 09:05:40 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-4c-51488cd31596 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 66.E4.02430.3DC88415; Tue, 19 Mar 2013 17:05:39 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 12:05:39 -0400 From: Samita Chakrabarti To: "" , "ippm@ietf.org" Thread-Topic: [ippm] Call for Consensus on new charter for IPPM Thread-Index: AQHOJEpFKTGk1X2GfEGcUeer93w4cZitLmBw Date: Tue, 19 Mar 2013 16:05:37 +0000 Message-ID: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> In-Reply-To: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyuXRPoO7lHo9Ag551lhYdD96xW/Q8eMfs wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGW8v/SdueCVVsXWo9tYGhjPKXUxcnJICJhI 3Jm4lgXCFpO4cG89WxcjF4eQwBFGiXVbp7CBJIQEljNK7LpQDGKzCVhJdPTuYQexRQSSJJpe PGICsYUF7CR6Zy1kgojbSzz8cg/KNpL4fOQDkM3BwSKgKvGjlxskzCvgLbHjZTczxHhHiaXX 1oOVcwo4SayZuApsPCPQPd9PrQGLMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4WwlSWWPNnP AlGvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYwcpcWpZbnp RgabGIGxcEyCTXcH456XlocYpTlYlMR5g1wvBAgJpCeWpGanphakFsUXleakFh9iZOLglGpg 7DmlxWWV1hEvWRLGveZu284qhmm2yx6fr1pbnhDSyh43k+vH9FO6T4yE7C9e0FohODPv9t64 /g550Q8L/Fu4I1vfnJt53/7N5U03Lm1q4dbu7ri+9N02Nx81ARXdfTZiMTab1qctUX/okxA2 yfRQgLbthvWXzJ3u/JTTD+1W1Y3+UNlpL8SlxFKckWioxVxUnAgA7FZXYlMCAAA= Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:05:41 -0000 I support the charter update. Thanks. -Samita=20 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Monday, March 18, 2013 7:34 PM To: ippm@ietf.org Subject: [ippm] Call for Consensus on new charter for IPPM Greetings, all, We have updated the draft charter based on discussion during our meeting in= Orlando last Friday. We believe the draft charter below addresses all comm= ents received, and would like to issue a call for WG consensus on the chart= er text. We'll be issuing separate calls for each of the documents under co= nsideration for adoption as WG items under this charter. If you support the adoption of this charter for IPPM, please reply to this = message and/or to the list stating so.=20 If you do not support the adoption of this charter, please reply to the lis= t, with your suggestions for improvement and further discussion. Please reply by Monday 25 March 2013; absent continuing discussion, we inte= nd to evaluate consensus then, and send the charter to the IESG for approva= l. Many thanks, best regards, Brian IP Performance Metrics (ippm) ----------------------------- Charter Current Status: Active Chairs: Brian Trammell=20 Bill Cerveny =20 Transport Area Directors: Martin Stiemerling Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: http://www.ietf.org/mail-archive/web/ippm Description of Working Group: The IP Performance Metrics (IPPM) Working Group develops and maintains stan= dard metrics that can be applied to the quality, performance, and reliabili= ty of Internet data delivery services and applications. It also develops an= d maintains protocols for the measurement of these metrics. These metrics a= re designed such that they can be performed by network operators, end users= , or independent testing groups. Metrics developed by the IPPM WG are inten= ded to provide unbiased quantitative performance measurements and not a val= ue judgement. The IPPM WG has produced documents that define specific metrics and procedu= res for accurately measuring and documenting these metrics. The working gro= up will continue advancing these metrics along the standards track, using t= he guidelines stated in RFC 6576. To the extent possible, these metrics wil= l be used as the basis for future work on metrics in the WG. The WG will develop the minimum number of new metrics and models needed to = more accurately quantitatively characterize the network path(s) under test = and/or the behavior of transport and application layer protocols on these p= ath(s). New metric definitions will state how the definition improves on an= existing metric definition, or encompasses a metric not previously defined= . Additional methods will be defined for the composition and calibration of I= PPM-defined metrics, as well as active, passive and hybrid measurement meth= ods for these metrics. In addition, WG encourages work which describes the = applicability of metrics and measurement methods, especially to improve und= erstanding of the tradeoffs involved among active, passive, and hybrid meth= ods. The WG may update its core framework RFC 2330 as necessary to accommodate t= hese activities. The WG has produced protocols for communication among test equipment to ena= ble the measurement of the one- and two-way metrics (OWAMP and TWAMP respec= tively). These protocols will be advanced along the standards track. The WG will fur= ther develop and improve these protocols. The WG may develop new measuremen= t protocols as necessary to support new metrics. New metric and protocol de= velopment will focus on the automatability of measurements in order to supp= ort large-scale measurement efforts. The equivalency of metric definitions is crucial to accurate, comparable an= d reproducible measurement. The WG will define and maintain a registry of m= etric definitions to this end. The WG encourages work which compares IPPM m= etrics with metrics developed elsewhere, particularly in regards to equival= ency, similarity and functionality. The WG also encourages work which impro= ves the availability of information about the context in which measurements= were taken. The IPPM WG seeks cooperation with other appropriate standards bodies and f= orums to promote consistent approaches and metrics. Within the IETF process= , IPPM metric definitions will be subject to as rigorous a scrutiny for use= fulness, clarity, and accuracy as other protocol standards. The IPPM WG wil= l interact with other areas of IETF activity whose scope intersects with th= e requirement of these specific metrics. The WG will, on request, provide i= nput to other IETF working groups on the use and implementation of these me= trics. Milestones: TBD - Submit draft on access rate measurement protocol problem stateme= nt to IESG as Informational TBD - Submit draft on RFC 2680 standards-track advancement testing to IESG as Informational =20 Additional milestones TBD _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From yaojk@cnnic.cn Wed Mar 20 17:47:59 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C1621F8DD6 for ; Wed, 20 Mar 2013 17:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.295 X-Spam-Level: X-Spam-Status: No, score=-99.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARcBSax1PTAF for ; Wed, 20 Mar 2013 17:47:54 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id A88C921F8DD0 for ; Wed, 20 Mar 2013 17:47:52 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 21 Mar 2013 08:47:44 +0800 Message-ID: From: "Jiankang YAO" To: , References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> Date: Thu, 21 Mar 2013 08:47:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 00:47:59 -0000 VGhlIGNoYXJ0ZXIgaXMgZmluZSB0byBtZS4NCg0KSmlhbmthbmcgWWFvDQotLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkJyaWFuIFRyYW1tZWxsIiA8dHJhbW1lbGxAdGlrLmVl LmV0aHouY2g+DQpUbzogPGlwcG1AaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxOSwg MjAxMyAxMDozNCBBTQ0KU3ViamVjdDogW2lwcG1dIENhbGwgZm9yIENvbnNlbnN1cyBvbiBuZXcg Y2hhcnRlciBmb3IgSVBQTQ0KDQoNCj4gR3JlZXRpbmdzLCBhbGwsDQo+IA0KPiBXZSBoYXZlIHVw ZGF0ZWQgdGhlIGRyYWZ0IGNoYXJ0ZXIgYmFzZWQgb24gZGlzY3Vzc2lvbiBkdXJpbmcgb3VyIG1l ZXRpbmcgaW4gT3JsYW5kbyBsYXN0IEZyaWRheS4gV2UgYmVsaWV2ZSB0aGUgZHJhZnQgY2hhcnRl ciBiZWxvdyBhZGRyZXNzZXMgYWxsIGNvbW1lbnRzIHJlY2VpdmVkLCBhbmQgd291bGQgbGlrZSB0 byBpc3N1ZSBhIGNhbGwgZm9yIFdHIGNvbnNlbnN1cyBvbiB0aGUgY2hhcnRlciB0ZXh0LiBXZSds bCBiZSBpc3N1aW5nIHNlcGFyYXRlIGNhbGxzIGZvciBlYWNoIG9mIHRoZSBkb2N1bWVudHMgdW5k ZXIgY29uc2lkZXJhdGlvbiBmb3IgYWRvcHRpb24gYXMgV0cgaXRlbXMgdW5kZXIgdGhpcyBjaGFy dGVyLg0KPiANCj4gSWYgeW91IHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgY2hhcnRlciBm b3IgSVBQTSwgcGxlYXNlIHJlcGx5IHRvIHRoaXMgbWVzc2FnZSBhbmQvb3IgdG8gdGhlIGxpc3Qg c3RhdGluZyBzby4gDQo+IA0KPiBJZiB5b3UgZG8gbm90IHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9m IHRoaXMgY2hhcnRlciwgcGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0LCB3aXRoIHlvdXIgc3VnZ2Vz dGlvbnMgZm9yIGltcHJvdmVtZW50IGFuZCBmdXJ0aGVyIGRpc2N1c3Npb24uDQo+IA0KPiBQbGVh c2UgcmVwbHkgYnkgTW9uZGF5IDI1IE1hcmNoIDIwMTM7IGFic2VudCBjb250aW51aW5nIGRpc2N1 c3Npb24sIHdlIGludGVuZCB0byBldmFsdWF0ZSBjb25zZW5zdXMgdGhlbiwgYW5kIHNlbmQgdGhl IGNoYXJ0ZXIgdG8gdGhlIElFU0cgZm9yIGFwcHJvdmFsLg0KPiANCj4gTWFueSB0aGFua3MsIGJl c3QgcmVnYXJkcywNCj4gDQo+IEJyaWFuDQo+IA0KPiANCj4gSVAgUGVyZm9ybWFuY2UgTWV0cmlj cyAoaXBwbSkNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IENoYXJ0ZXIN Cj4gDQo+IEN1cnJlbnQgU3RhdHVzOiBBY3RpdmUNCj4gDQo+IENoYWlyczoNCj4gICAgIEJyaWFu IFRyYW1tZWxsIA0KPiAgICAgQmlsbCBDZXJ2ZW55DQo+ICAgICANCj4gVHJhbnNwb3J0IEFyZWEg RGlyZWN0b3JzOg0KPiAgICAgTWFydGluIFN0aWVtZXJsaW5nDQo+ICAgICBNYXJ0aW4gU3RpZW1l cmxpbmcNCj4gDQo+IFRyYW5zcG9ydCBBcmVhIEFkdmlzb3I6DQo+ICAgICBNYXJ0aW4gU3RpZW1l cmxpbmcNCj4gDQo+IE1haWxpbmcgTGlzdHM6DQo+ICAgICBHZW5lcmFsIERpc2N1c3Npb246IGlw cG1AaWV0Zi5vcmcNCj4gICAgIFRvIFN1YnNjcmliZTogICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQo+ICAgICBBcmNoaXZlOiAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pcHBtDQo+IA0KPiBEZXNjcmlwdGlvbiBv ZiBXb3JraW5nIEdyb3VwOg0KPiANCj4gVGhlIElQIFBlcmZvcm1hbmNlIE1ldHJpY3MgKElQUE0p IFdvcmtpbmcgR3JvdXAgZGV2ZWxvcHMgYW5kIG1haW50YWlucyBzdGFuZGFyZA0KPiBtZXRyaWNz IHRoYXQgY2FuIGJlIGFwcGxpZWQgdG8gdGhlIHF1YWxpdHksIHBlcmZvcm1hbmNlLCBhbmQgcmVs aWFiaWxpdHkgb2YNCj4gSW50ZXJuZXQgZGF0YSBkZWxpdmVyeSBzZXJ2aWNlcyBhbmQgYXBwbGlj YXRpb25zLiBJdCBhbHNvIGRldmVsb3BzIGFuZA0KPiBtYWludGFpbnMgcHJvdG9jb2xzIGZvciB0 aGUgbWVhc3VyZW1lbnQgb2YgdGhlc2UgbWV0cmljcy4gVGhlc2UgbWV0cmljcyBhcmUNCj4gZGVz aWduZWQgc3VjaCB0aGF0IHRoZXkgY2FuIGJlIHBlcmZvcm1lZCBieSBuZXR3b3JrIG9wZXJhdG9y cywgZW5kIHVzZXJzLCBvcg0KPiBpbmRlcGVuZGVudCB0ZXN0aW5nIGdyb3Vwcy4gTWV0cmljcyBk ZXZlbG9wZWQgYnkgdGhlIElQUE0gV0cgYXJlIGludGVuZGVkIHRvDQo+IHByb3ZpZGUgdW5iaWFz ZWQgcXVhbnRpdGF0aXZlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50cyBhbmQgbm90IGEgdmFsdWUN Cj4ganVkZ2VtZW50Lg0KPiANCj4gVGhlIElQUE0gV0cgaGFzIHByb2R1Y2VkIGRvY3VtZW50cyB0 aGF0IGRlZmluZSBzcGVjaWZpYyBtZXRyaWNzIGFuZCBwcm9jZWR1cmVzDQo+IGZvciBhY2N1cmF0 ZWx5IG1lYXN1cmluZyBhbmQgZG9jdW1lbnRpbmcgdGhlc2UgbWV0cmljcy4gVGhlIHdvcmtpbmcg Z3JvdXAgd2lsbA0KPiBjb250aW51ZSBhZHZhbmNpbmcgdGhlc2UgbWV0cmljcyBhbG9uZyB0aGUg c3RhbmRhcmRzIHRyYWNrLCB1c2luZyB0aGUNCj4gZ3VpZGVsaW5lcyBzdGF0ZWQgaW4gUkZDIDY1 NzYuIFRvIHRoZSBleHRlbnQgcG9zc2libGUsIHRoZXNlIG1ldHJpY3Mgd2lsbCBiZQ0KPiB1c2Vk IGFzIHRoZSBiYXNpcyBmb3IgZnV0dXJlIHdvcmsgb24gbWV0cmljcyBpbiB0aGUgV0cuDQo+IA0K PiBUaGUgV0cgd2lsbCBkZXZlbG9wIHRoZSBtaW5pbXVtIG51bWJlciBvZiBuZXcgbWV0cmljcyBh bmQgbW9kZWxzIG5lZWRlZCB0byBtb3JlDQo+IGFjY3VyYXRlbHkgcXVhbnRpdGF0aXZlbHkgY2hh cmFjdGVyaXplIHRoZSBuZXR3b3JrIHBhdGgocykgdW5kZXIgdGVzdCBhbmQvb3INCj4gdGhlIGJl aGF2aW9yIG9mIHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2xzIG9uIHRo ZXNlIHBhdGgocykuIE5ldw0KPiBtZXRyaWMgZGVmaW5pdGlvbnMgd2lsbCBzdGF0ZSBob3cgdGhl IGRlZmluaXRpb24gaW1wcm92ZXMgb24gYW4gZXhpc3RpbmcgbWV0cmljDQo+IGRlZmluaXRpb24s IG9yIGVuY29tcGFzc2VzIGEgbWV0cmljIG5vdCBwcmV2aW91c2x5IGRlZmluZWQuDQo+IA0KPiBB ZGRpdGlvbmFsIG1ldGhvZHMgd2lsbCBiZSBkZWZpbmVkIGZvciB0aGUgY29tcG9zaXRpb24gYW5k IGNhbGlicmF0aW9uIG9mDQo+IElQUE0tZGVmaW5lZCBtZXRyaWNzLCBhcyB3ZWxsIGFzIGFjdGl2 ZSwgcGFzc2l2ZSBhbmQgaHlicmlkIG1lYXN1cmVtZW50IG1ldGhvZHMNCj4gZm9yIHRoZXNlIG1l dHJpY3MuIEluIGFkZGl0aW9uLCBXRyBlbmNvdXJhZ2VzIHdvcmsgd2hpY2ggZGVzY3JpYmVzIHRo ZQ0KPiBhcHBsaWNhYmlsaXR5IG9mIG1ldHJpY3MgYW5kIG1lYXN1cmVtZW50IG1ldGhvZHMsIGVz cGVjaWFsbHkgdG8gaW1wcm92ZQ0KPiB1bmRlcnN0YW5kaW5nIG9mIHRoZSB0cmFkZW9mZnMgaW52 b2x2ZWQgYW1vbmcgYWN0aXZlLCBwYXNzaXZlLCBhbmQgaHlicmlkDQo+IG1ldGhvZHMuDQo+IA0K PiBUaGUgV0cgbWF5IHVwZGF0ZSBpdHMgY29yZSBmcmFtZXdvcmsgUkZDIDIzMzAgYXMgbmVjZXNz YXJ5IHRvIGFjY29tbW9kYXRlIHRoZXNlDQo+IGFjdGl2aXRpZXMuDQo+IA0KPiBUaGUgV0cgaGFz IHByb2R1Y2VkIHByb3RvY29scyBmb3IgY29tbXVuaWNhdGlvbiBhbW9uZyB0ZXN0IGVxdWlwbWVu dCB0byBlbmFibGUNCj4gdGhlIG1lYXN1cmVtZW50IG9mIHRoZSBvbmUtIGFuZCB0d28td2F5IG1l dHJpY3MgKE9XQU1QIGFuZCBUV0FNUCByZXNwZWN0aXZlbHkpLg0KPiBUaGVzZSBwcm90b2NvbHMg d2lsbCBiZSBhZHZhbmNlZCBhbG9uZyB0aGUgc3RhbmRhcmRzIHRyYWNrLiBUaGUgV0cgd2lsbCBm dXJ0aGVyDQo+IGRldmVsb3AgYW5kIGltcHJvdmUgdGhlc2UgcHJvdG9jb2xzLiBUaGUgV0cgbWF5 IGRldmVsb3AgbmV3IG1lYXN1cmVtZW50DQo+IHByb3RvY29scyBhcyBuZWNlc3NhcnkgdG8gc3Vw cG9ydCBuZXcgbWV0cmljcy4gTmV3IG1ldHJpYyBhbmQgcHJvdG9jb2wNCj4gZGV2ZWxvcG1lbnQg d2lsbCBmb2N1cyBvbiB0aGUgYXV0b21hdGFiaWxpdHkgb2YgbWVhc3VyZW1lbnRzIGluIG9yZGVy IHRvDQo+IHN1cHBvcnQgbGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnQgZWZmb3J0cy4NCj4gDQo+IFRo ZSBlcXVpdmFsZW5jeSBvZiBtZXRyaWMgZGVmaW5pdGlvbnMgaXMgY3J1Y2lhbCB0byBhY2N1cmF0 ZSwgY29tcGFyYWJsZSBhbmQNCj4gcmVwcm9kdWNpYmxlIG1lYXN1cmVtZW50LiBUaGUgV0cgd2ls bCBkZWZpbmUgYW5kIG1haW50YWluIGEgcmVnaXN0cnkgb2YgbWV0cmljDQo+IGRlZmluaXRpb25z IHRvIHRoaXMgZW5kLiBUaGUgV0cgZW5jb3VyYWdlcyB3b3JrIHdoaWNoIGNvbXBhcmVzIElQUE0g bWV0cmljcw0KPiB3aXRoIG1ldHJpY3MgZGV2ZWxvcGVkIGVsc2V3aGVyZSwgcGFydGljdWxhcmx5 IGluIHJlZ2FyZHMgdG8gZXF1aXZhbGVuY3ksDQo+IHNpbWlsYXJpdHkgYW5kIGZ1bmN0aW9uYWxp dHkuIFRoZSBXRyBhbHNvIGVuY291cmFnZXMgd29yayB3aGljaCBpbXByb3ZlcyB0aGUNCj4gYXZh aWxhYmlsaXR5IG9mIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IGluIHdoaWNoIG1lYXN1 cmVtZW50cyB3ZXJlIHRha2VuLg0KPiANCj4gVGhlIElQUE0gV0cgc2Vla3MgY29vcGVyYXRpb24g d2l0aCBvdGhlciBhcHByb3ByaWF0ZSBzdGFuZGFyZHMgYm9kaWVzIGFuZA0KPiBmb3J1bXMgdG8g cHJvbW90ZSBjb25zaXN0ZW50IGFwcHJvYWNoZXMgYW5kIG1ldHJpY3MuIFdpdGhpbiB0aGUgSUVU RiBwcm9jZXNzLA0KPiBJUFBNIG1ldHJpYyBkZWZpbml0aW9ucyB3aWxsIGJlIHN1YmplY3QgdG8g YXMgcmlnb3JvdXMgYSBzY3J1dGlueSBmb3INCj4gdXNlZnVsbmVzcywgY2xhcml0eSwgYW5kIGFj Y3VyYWN5IGFzIG90aGVyIHByb3RvY29sIHN0YW5kYXJkcy4gVGhlIElQUE0gV0cgd2lsbA0KPiBp bnRlcmFjdCB3aXRoIG90aGVyIGFyZWFzIG9mIElFVEYgYWN0aXZpdHkgd2hvc2Ugc2NvcGUgaW50 ZXJzZWN0cyB3aXRoIHRoZQ0KPiByZXF1aXJlbWVudCBvZiB0aGVzZSBzcGVjaWZpYyBtZXRyaWNz LiBUaGUgV0cgd2lsbCwgb24gcmVxdWVzdCwgcHJvdmlkZSBpbnB1dA0KPiB0byBvdGhlciBJRVRG IHdvcmtpbmcgZ3JvdXBzIG9uIHRoZSB1c2UgYW5kIGltcGxlbWVudGF0aW9uIG9mIHRoZXNlIG1l dHJpY3MuDQo+IA0KPiBNaWxlc3RvbmVzOg0KPiANCj4gVEJEICAgICAgLSBTdWJtaXQgZHJhZnQg b24gYWNjZXNzIHJhdGUgbWVhc3VyZW1lbnQgcHJvdG9jb2wgcHJvYmxlbSBzdGF0ZW1lbnQNCj4g ICAgICAgICAgIHRvIElFU0cgYXMgSW5mb3JtYXRpb25hbA0KPiBUQkQgICAgICAtIFN1Ym1pdCBk cmFmdCBvbiBSRkMgMjY4MCBzdGFuZGFyZHMtdHJhY2sgYWR2YW5jZW1lbnQgdGVzdGluZw0KPiAg ICAgICAgICAgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsDQo+ICAgICAgICAgICANCj4gQWRkaXRp b25hbCBtaWxlc3RvbmVzIFRCRA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBpcHBtIG1haWxpbmcgbGlzdA0KPiBpcHBtQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ== From acooper@cdt.org Wed Mar 20 18:22:28 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30EE21F8B65 for ; Wed, 20 Mar 2013 18:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUvGdRgp8SOI for ; Wed, 20 Mar 2013 18:22:27 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 18C4F21F8B35 for ; Wed, 20 Mar 2013 18:22:24 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 20 Mar 2013 21:22:22 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Alissa Cooper In-Reply-To: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> Date: Wed, 20 Mar 2013 21:22:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> To: "" X-Mailer: Apple Mail (2.1499) Cc: "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 01:22:28 -0000 Looks good. One nit below. On Mar 18, 2013, at 10:34 PM, Brian Trammell = wrote: > Additional methods will be defined for the composition and calibration = of > IPPM-defined metrics, as well as active, passive and hybrid = measurement methods > for these metrics. In addition, WG encourages work which describes the s/WG encourages/the WG encourages/ --Alissa > applicability of metrics and measurement methods, especially to = improve > understanding of the tradeoffs involved among active, passive, and = hybrid > methods. >=20 > The WG may update its core framework RFC 2330 as necessary to = accommodate these > activities. >=20 > The WG has produced protocols for communication among test equipment = to enable > the measurement of the one- and two-way metrics (OWAMP and TWAMP = respectively). > These protocols will be advanced along the standards track. The WG = will further > develop and improve these protocols. The WG may develop new = measurement > protocols as necessary to support new metrics. New metric and protocol > development will focus on the automatability of measurements in order = to > support large-scale measurement efforts. >=20 > The equivalency of metric definitions is crucial to accurate, = comparable and > reproducible measurement. The WG will define and maintain a registry = of metric > definitions to this end. The WG encourages work which compares IPPM = metrics > with metrics developed elsewhere, particularly in regards to = equivalency, > similarity and functionality. The WG also encourages work which = improves the > availability of information about the context in which measurements = were taken. >=20 > The IPPM WG seeks cooperation with other appropriate standards bodies = and > forums to promote consistent approaches and metrics. Within the IETF = process, > IPPM metric definitions will be subject to as rigorous a scrutiny for > usefulness, clarity, and accuracy as other protocol standards. The = IPPM WG will > interact with other areas of IETF activity whose scope intersects with = the > requirement of these specific metrics. The WG will, on request, = provide input > to other IETF working groups on the use and implementation of these = metrics. >=20 > Milestones: >=20 > TBD - Submit draft on access rate measurement protocol problem = statement > to IESG as Informational > TBD - Submit draft on RFC 2680 standards-track advancement = testing > to IESG as Informational >=20 > Additional milestones TBD > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >=20 From k.pentikousis@huawei.com Thu Mar 21 04:15:20 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2407F21F8F0B for ; Thu, 21 Mar 2013 04:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oStj05i5hwKs for ; Thu, 21 Mar 2013 04:15:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6218521F8F06 for ; Thu, 21 Mar 2013 04:15:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APP90325; Thu, 21 Mar 2013 11:15:17 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 11:14:21 +0000 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 11:15:16 +0000 Received: from SZXEML511-MBX.china.huawei.com ([169.254.5.69]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.007; Thu, 21 Mar 2013 19:15:08 +0800 From: Konstantinos Pentikousis To: "" , "ippm@ietf.org" Thread-Topic: [ippm] Call for Consensus on new charter for IPPM Thread-Index: AQHOJKBTb8UF4tu1S027EYX5g536S5iwARZw Date: Thu, 21 Mar 2013 11:15:07 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23AEC818D@szxeml511-mbx.china.huawei.com> References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> In-Reply-To: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.64.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 11:15:20 -0000 Dear Chairs, The charter looks good, many thanks for the effort! I support it as well. Best regards, Kostas |-----Original Message----- |From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] |Sent: Tuesday, March 19, 2013 3:34 AM |To: ippm@ietf.org |Subject: [ippm] Call for Consensus on new charter for IPPM | |Greetings, all, | |We have updated the draft charter based on discussion during our meeting |in Orlando last Friday. We believe the draft charter below addresses all |comments received, and would like to issue a call for WG consensus on |the charter text. We'll be issuing separate calls for each of the |documents under consideration for adoption as WG items under this |charter. | |If you support the adoption of this charter for IPPM, please reply to |this message and/or to the list stating so. | |If you do not support the adoption of this charter, please reply to the |list, with your suggestions for improvement and further discussion. | |Please reply by Monday 25 March 2013; absent continuing discussion, we |intend to evaluate consensus then, and send the charter to the IESG for |approval. | |Many thanks, best regards, | |Brian | | |IP Performance Metrics (ippm) |----------------------------- | | Charter | | Current Status: Active | | Chairs: | Brian Trammell | Bill Cerveny | | Transport Area Directors: | Martin Stiemerling | Martin Stiemerling | | Transport Area Advisor: | Martin Stiemerling | | Mailing Lists: | General Discussion: ippm@ietf.org | To Subscribe: https://www.ietf.org/mailman/listinfo/ippm | Archive: http://www.ietf.org/mail-archive/web/ippm | |Description of Working Group: | |The IP Performance Metrics (IPPM) Working Group develops and maintains |standard metrics that can be applied to the quality, performance, and |reliability of Internet data delivery services and applications. It also |develops and maintains protocols for the measurement of these metrics. |These metrics are designed such that they can be performed by network |operators, end users, or independent testing groups. Metrics developed |by the IPPM WG are intended to provide unbiased quantitative performance |measurements and not a value judgement. | |The IPPM WG has produced documents that define specific metrics and |procedures for accurately measuring and documenting these metrics. The |working group will continue advancing these metrics along the standards |track, using the guidelines stated in RFC 6576. To the extent possible, |these metrics will be used as the basis for future work on metrics in |the WG. | |The WG will develop the minimum number of new metrics and models needed |to more accurately quantitatively characterize the network path(s) under |test and/or the behavior of transport and application layer protocols on |these path(s). New metric definitions will state how the definition |improves on an existing metric definition, or encompasses a metric not |previously defined. | |Additional methods will be defined for the composition and calibration |of IPPM-defined metrics, as well as active, passive and hybrid |measurement methods for these metrics. In addition, WG encourages work |which describes the applicability of metrics and measurement methods, |especially to improve understanding of the tradeoffs involved among |active, passive, and hybrid methods. | |The WG may update its core framework RFC 2330 as necessary to |accommodate these activities. | |The WG has produced protocols for communication among test equipment to |enable the measurement of the one- and two-way metrics (OWAMP and TWAMP |respectively). |These protocols will be advanced along the standards track. The WG will |further develop and improve these protocols. The WG may develop new |measurement protocols as necessary to support new metrics. New metric |and protocol development will focus on the automatability of |measurements in order to support large-scale measurement efforts. | |The equivalency of metric definitions is crucial to accurate, comparable |and reproducible measurement. The WG will define and maintain a registry |of metric definitions to this end. The WG encourages work which compares |IPPM metrics with metrics developed elsewhere, particularly in regards |to equivalency, similarity and functionality. The WG also encourages |work which improves the availability of information about the context in |which measurements were taken. | |The IPPM WG seeks cooperation with other appropriate standards bodies |and forums to promote consistent approaches and metrics. Within the IETF |process, IPPM metric definitions will be subject to as rigorous a |scrutiny for usefulness, clarity, and accuracy as other protocol |standards. The IPPM WG will interact with other areas of IETF activity |whose scope intersects with the requirement of these specific metrics. |The WG will, on request, provide input to other IETF working groups on |the use and implementation of these metrics. | |Milestones: | |TBD - Submit draft on access rate measurement protocol problem |statement | to IESG as Informational |TBD - Submit draft on RFC 2680 standards-track advancement testing | to IESG as Informational | |Additional milestones TBD From ken.ko@adtran.com Thu Mar 21 05:09:49 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8DC21F8775 for ; Thu, 21 Mar 2013 05:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwUMxrSAgFvq for ; Thu, 21 Mar 2013 05:09:49 -0700 (PDT) Received: from p02c11o145.mxlogic.net (p02c11o145.mxlogic.net [208.65.144.78]) by ietfa.amsl.com (Postfix) with ESMTP id C6E0621F8DB9 for ; Thu, 21 Mar 2013 05:09:48 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO p02c11o145.mxlogic.net) by p02c11o145.mxlogic.net(mxl_mta-7.0.0-1) with ESMTP id c88fa415.2aaab8ff4940.44666.00-540.97645.p02c11o145.mxlogic.net (envelope-from ); Thu, 21 Mar 2013 06:09:48 -0600 (MDT) X-MXL-Hash: 514af88c0364c1f0-684cb71e7e455aa9247e97bcd3434ff357ec23b3 Received: from unknown [76.164.174.82] by p02c11o145.mxlogic.net(mxl_mta-7.0.0-1) with SMTP id 188fa415.0.44461.00-318.97575.p02c11o145.mxlogic.net (envelope-from ); Thu, 21 Mar 2013 06:09:47 -0600 (MDT) X-MXL-Hash: 514af88b41cb62b2-87de9194607f57e111ed940b2e035d51e38cebf4 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.01.0438.000; Thu, 21 Mar 2013 07:09:31 -0500 From: KEN KO To: Konstantinos Pentikousis Thread-Topic: [ippm] Call for Consensus on new charter for IPPM Thread-Index: AQHOJEpL625Utfat8UaRE0+tNEuZp5iwVeyA//+7YkI= Date: Thu, 21 Mar 2013 12:09:31 +0000 Message-ID: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch>, <8D38716F0C1A444BA0CD7E96454366C23AEC818D@szxeml511-mbx.china.huawei.com> In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23AEC818D@szxeml511-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=ItmphsDg c=1 sm=1 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a] X-AnalysisOut: [=XAL2D-GhROYA:10 a=qZHQZMT3apYA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=n8i27M1m] X-AnalysisOut: [AAAA:8 a=WNieO_kMZ1cA:10 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=g6GYTLO_4QsfUoQ3D_MA:9 a=CjuIK1q_8ugA:10 a=hPjdaMEvmhQA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=blA99687uylpjrms:21 a=khFtdWytV6vi] X-AnalysisOut: [7a4W:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Cc: "" , "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 12:09:50 -0000 It looks good to me as well. - Ken Ko ----- Original Message ----- From: Konstantinos Pentikousis To: "" , "ippm@ietf= .org" Sent: 3/21/2013 7:15 AM Subject: Re: [ippm] Call for Consensus on new charter for IPPM Dear Chairs, The charter looks good, many thanks for the effort! I support it as well. Best regards, Kostas |-----Original Message----- |From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] |Sent: Tuesday, March 19, 2013 3:34 AM |To: ippm@ietf.org |Subject: [ippm] Call for Consensus on new charter for IPPM | |Greetings, all, | |We have updated the draft charter based on discussion during our meeting |in Orlando last Friday. We believe the draft charter below addresses all |comments received, and would like to issue a call for WG consensus on |the charter text. We'll be issuing separate calls for each of the |documents under consideration for adoption as WG items under this |charter. | |If you support the adoption of this charter for IPPM, please reply to |this message and/or to the list stating so. | |If you do not support the adoption of this charter, please reply to the |list, with your suggestions for improvement and further discussion. | |Please reply by Monday 25 March 2013; absent continuing discussion, we |intend to evaluate consensus then, and send the charter to the IESG for |approval. | |Many thanks, best regards, | |Brian | | |IP Performance Metrics (ippm) |----------------------------- | | Charter | | Current Status: Active | | Chairs: | Brian Trammell | Bill Cerveny | | Transport Area Directors: | Martin Stiemerling | Martin Stiemerling | | Transport Area Advisor: | Martin Stiemerling | | Mailing Lists: | General Discussion: ippm@ietf.org | To Subscribe: https://www.ietf.org/mailman/listinfo/ippm | Archive: http://www.ietf.org/mail-archive/web/ippm | |Description of Working Group: | |The IP Performance Metrics (IPPM) Working Group develops and maintains |standard metrics that can be applied to the quality, performance, and |reliability of Internet data delivery services and applications. It also |develops and maintains protocols for the measurement of these metrics. |These metrics are designed such that they can be performed by network |operators, end users, or independent testing groups. Metrics developed |by the IPPM WG are intended to provide unbiased quantitative performance |measurements and not a value judgement. | |The IPPM WG has produced documents that define specific metrics and |procedures for accurately measuring and documenting these metrics. The |working group will continue advancing these metrics along the standards |track, using the guidelines stated in RFC 6576. To the extent possible, |these metrics will be used as the basis for future work on metrics in |the WG. | |The WG will develop the minimum number of new metrics and models needed |to more accurately quantitatively characterize the network path(s) under |test and/or the behavior of transport and application layer protocols on |these path(s). New metric definitions will state how the definition |improves on an existing metric definition, or encompasses a metric not |previously defined. | |Additional methods will be defined for the composition and calibration |of IPPM-defined metrics, as well as active, passive and hybrid |measurement methods for these metrics. In addition, WG encourages work |which describes the applicability of metrics and measurement methods, |especially to improve understanding of the tradeoffs involved among |active, passive, and hybrid methods. | |The WG may update its core framework RFC 2330 as necessary to |accommodate these activities. | |The WG has produced protocols for communication among test equipment to |enable the measurement of the one- and two-way metrics (OWAMP and TWAMP |respectively). |These protocols will be advanced along the standards track. The WG will |further develop and improve these protocols. The WG may develop new |measurement protocols as necessary to support new metrics. New metric |and protocol development will focus on the automatability of |measurements in order to support large-scale measurement efforts. | |The equivalency of metric definitions is crucial to accurate, comparable |and reproducible measurement. The WG will define and maintain a registry |of metric definitions to this end. The WG encourages work which compares |IPPM metrics with metrics developed elsewhere, particularly in regards |to equivalency, similarity and functionality. The WG also encourages |work which improves the availability of information about the context in |which measurements were taken. | |The IPPM WG seeks cooperation with other appropriate standards bodies |and forums to promote consistent approaches and metrics. Within the IETF |process, IPPM metric definitions will be subject to as rigorous a |scrutiny for usefulness, clarity, and accuracy as other protocol |standards. The IPPM WG will interact with other areas of IETF activity |whose scope intersects with the requirement of these specific metrics. |The WG will, on request, provide input to other IETF working groups on |the use and implementation of these metrics. | |Milestones: | |TBD - Submit draft on access rate measurement protocol problem |statement | to IESG as Informational |TBD - Submit draft on RFC 2680 standards-track advancement testing | to IESG as Informational | |Additional milestones TBD _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From christofer.flinta@ericsson.com Thu Mar 21 07:58:58 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993DE21F8771 for ; Thu, 21 Mar 2013 07:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU5MO2LbM4iS for ; Thu, 21 Mar 2013 07:58:57 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 51DFC21F875C for ; Thu, 21 Mar 2013 07:58:55 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-57-514b202e8f8c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F7.A5.19728.E202B415; Thu, 21 Mar 2013 15:58:54 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.176]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 15:58:53 +0100 From: Christofer Flinta To: "" , "ippm@ietf.org" Thread-Topic: [ippm] Call for Consensus on new charter for IPPM Thread-Index: AQHOJEpEPXmEQjYy80e9/GnCLXbA1JiwPgww Date: Thu, 21 Mar 2013 14:58:53 +0000 Message-ID: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> In-Reply-To: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvja6egnegwYOT1hYdD96xW/Q8eMfs wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGW8OZVVcEWrYuPRn2wNjDuUuhg5OSQETCR2 bv/JBGGLSVy4t56ti5GLQ0jgEKPEtH9vmSCcJYwSLSu6warYBCwkjvVNZQexRQSSJJpePAKL CwvYSfTOWsgEEbeXePjlHpDNAWQbSbS1eYCEWQRUJTp2rgNr5RXwleje85EVxBYScJRYem09 WCungJPEmomrwGoYBWQl7n+/xwJiMwuIS9x6Mh/qUAGJJXvOM0PYohIvH/9jhbAVJa5OX84E Ua8jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjOy5iZk56eVG mxiBkXBwy2/VHYx3zokcYpTmYFES5w13vRAgJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXFN 2DTFQzd+zz7rbRsfpfhl4yTOMwImERv7KlMXFTftZna1rbvnWPVh0flziwOifK7pxbGb+E++ lGTpopVulrEo86fnA12Fk/n/gw7rPb1xKVE/8oW12vX5HsyOkkdWGv1ZmMVzdmW5fOMVfr2J W4MNdpqx32GtjlIq157IFVF8z4Plx+2yJUosxRmJhlrMRcWJADbdux5SAgAA Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:58:58 -0000 It looks good to me. /Christofer -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: den 19 mars 2013 03:34 To: ippm@ietf.org Subject: [ippm] Call for Consensus on new charter for IPPM Greetings, all, We have updated the draft charter based on discussion during our meeting in= Orlando last Friday. We believe the draft charter below addresses all comm= ents received, and would like to issue a call for WG consensus on the chart= er text. We'll be issuing separate calls for each of the documents under co= nsideration for adoption as WG items under this charter. If you support the adoption of this charter for IPPM, please reply to this = message and/or to the list stating so.=20 If you do not support the adoption of this charter, please reply to the lis= t, with your suggestions for improvement and further discussion. Please reply by Monday 25 March 2013; absent continuing discussion, we inte= nd to evaluate consensus then, and send the charter to the IESG for approva= l. Many thanks, best regards, Brian IP Performance Metrics (ippm) ----------------------------- Charter Current Status: Active Chairs: Brian Trammell=20 Bill Cerveny =20 Transport Area Directors: Martin Stiemerling Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: http://www.ietf.org/mail-archive/web/ippm Description of Working Group: The IP Performance Metrics (IPPM) Working Group develops and maintains stan= dard metrics that can be applied to the quality, performance, and reliabili= ty of Internet data delivery services and applications. It also develops an= d maintains protocols for the measurement of these metrics. These metrics a= re designed such that they can be performed by network operators, end users= , or independent testing groups. Metrics developed by the IPPM WG are inten= ded to provide unbiased quantitative performance measurements and not a val= ue judgement. The IPPM WG has produced documents that define specific metrics and procedu= res for accurately measuring and documenting these metrics. The working gro= up will continue advancing these metrics along the standards track, using t= he guidelines stated in RFC 6576. To the extent possible, these metrics wil= l be used as the basis for future work on metrics in the WG. The WG will develop the minimum number of new metrics and models needed to = more accurately quantitatively characterize the network path(s) under test = and/or the behavior of transport and application layer protocols on these p= ath(s). New metric definitions will state how the definition improves on an= existing metric definition, or encompasses a metric not previously defined= . Additional methods will be defined for the composition and calibration of I= PPM-defined metrics, as well as active, passive and hybrid measurement meth= ods for these metrics. In addition, WG encourages work which describes the = applicability of metrics and measurement methods, especially to improve und= erstanding of the tradeoffs involved among active, passive, and hybrid meth= ods. The WG may update its core framework RFC 2330 as necessary to accommodate t= hese activities. The WG has produced protocols for communication among test equipment to ena= ble the measurement of the one- and two-way metrics (OWAMP and TWAMP respec= tively). These protocols will be advanced along the standards track. The WG will fur= ther develop and improve these protocols. The WG may develop new measuremen= t protocols as necessary to support new metrics. New metric and protocol de= velopment will focus on the automatability of measurements in order to supp= ort large-scale measurement efforts. The equivalency of metric definitions is crucial to accurate, comparable an= d reproducible measurement. The WG will define and maintain a registry of m= etric definitions to this end. The WG encourages work which compares IPPM m= etrics with metrics developed elsewhere, particularly in regards to equival= ency, similarity and functionality. The WG also encourages work which impro= ves the availability of information about the context in which measurements= were taken. The IPPM WG seeks cooperation with other appropriate standards bodies and f= orums to promote consistent approaches and metrics. Within the IETF process= , IPPM metric definitions will be subject to as rigorous a scrutiny for use= fulness, clarity, and accuracy as other protocol standards. The IPPM WG wil= l interact with other areas of IETF activity whose scope intersects with th= e requirement of these specific metrics. The WG will, on request, provide i= nput to other IETF working groups on the use and implementation of these me= trics. Milestones: TBD - Submit draft on access rate measurement protocol problem stateme= nt to IESG as Informational TBD - Submit draft on RFC 2680 standards-track advancement testing to IESG as Informational =20 Additional milestones TBD _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From dengguangqing@cnnic.cn Thu Mar 21 18:27:30 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63FF21F86D3 for ; Thu, 21 Mar 2013 18:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.706 X-Spam-Level: X-Spam-Status: No, score=0.706 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z451NNIKFSzf for ; Thu, 21 Mar 2013 18:27:29 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 0467821F86CB for ; Thu, 21 Mar 2013 18:27:27 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 22 Mar 2013 09:27:20 +0800 Date: Fri, 22 Mar 2013 09:27:18 +0800 From: "Guangqing Deng" To: =?gb2312?B?PGlwcG0tY2hhaXJzQHRvb2xzLmlldGYub3JnPg==?= References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201303220927178418421@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart268527350103_=----" Cc: "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 01:27:30 -0000 This is a multi-part message in MIME format. ------=_001_NextPart268527350103_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 dGhlIGNoYXJ0ZXIgbG9va3MgZ29vZCB0byBtZS4NCg0KDQoNCg0KR3VhbmdxaW5nIERlbmcNCkNO TklDIA0KDQpGcm9tOiBCcmlhbiBUcmFtbWVsbA0KRGF0ZTogMjAxMy0wMy0xOSAxMDozNA0KVG86 IGlwcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFtpcHBtXSBDYWxsIGZvciBDb25zZW5zdXMgb24gbmV3 IGNoYXJ0ZXIgZm9yIElQUE0NCkdyZWV0aW5ncywgYWxsLA0KDQpXZSBoYXZlIHVwZGF0ZWQgdGhl IGRyYWZ0IGNoYXJ0ZXIgYmFzZWQgb24gZGlzY3Vzc2lvbiBkdXJpbmcgb3VyIG1lZXRpbmcgaW4g T3JsYW5kbyBsYXN0IEZyaWRheS4gV2UgYmVsaWV2ZSB0aGUgZHJhZnQgY2hhcnRlciBiZWxvdyBh ZGRyZXNzZXMgYWxsIGNvbW1lbnRzIHJlY2VpdmVkLCBhbmQgd291bGQgbGlrZSB0byBpc3N1ZSBh IGNhbGwgZm9yIFdHIGNvbnNlbnN1cyBvbiB0aGUgY2hhcnRlciB0ZXh0LiBXZSdsbCBiZSBpc3N1 aW5nIHNlcGFyYXRlIGNhbGxzIGZvciBlYWNoIG9mIHRoZSBkb2N1bWVudHMgdW5kZXIgY29uc2lk ZXJhdGlvbiBmb3IgYWRvcHRpb24gYXMgV0cgaXRlbXMgdW5kZXIgdGhpcyBjaGFydGVyLg0KDQpJ ZiB5b3Ugc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBjaGFydGVyIGZvciBJUFBNLCBwbGVh c2UgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIGFuZC9vciB0byB0aGUgbGlzdCBzdGF0aW5nIHNvLiAN Cg0KSWYgeW91IGRvIG5vdCBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGNoYXJ0ZXIsIHBs ZWFzZSByZXBseSB0byB0aGUgbGlzdCwgd2l0aCB5b3VyIHN1Z2dlc3Rpb25zIGZvciBpbXByb3Zl bWVudCBhbmQgZnVydGhlciBkaXNjdXNzaW9uLg0KDQpQbGVhc2UgcmVwbHkgYnkgTW9uZGF5IDI1 IE1hcmNoIDIwMTM7IGFic2VudCBjb250aW51aW5nIGRpc2N1c3Npb24sIHdlIGludGVuZCB0byBl dmFsdWF0ZSBjb25zZW5zdXMgdGhlbiwgYW5kIHNlbmQgdGhlIGNoYXJ0ZXIgdG8gdGhlIElFU0cg Zm9yIGFwcHJvdmFsLg0KDQpNYW55IHRoYW5rcywgYmVzdCByZWdhcmRzLA0KDQpCcmlhbg0KDQoN CklQIFBlcmZvcm1hbmNlIE1ldHJpY3MgKGlwcG0pDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQogQ2hhcnRlcg0KDQogQ3VycmVudCBTdGF0dXM6IEFjdGl2ZQ0KDQogQ2hhaXJzOg0K ICAgICBCcmlhbiBUcmFtbWVsbCANCiAgICAgQmlsbCBDZXJ2ZW55DQogICAgIA0KIFRyYW5zcG9y dCBBcmVhIERpcmVjdG9yczoNCiAgICAgTWFydGluIFN0aWVtZXJsaW5nDQogICAgIE1hcnRpbiBT dGllbWVybGluZw0KDQogVHJhbnNwb3J0IEFyZWEgQWR2aXNvcjoNCiAgICAgTWFydGluIFN0aWVt ZXJsaW5nDQoNCiBNYWlsaW5nIExpc3RzOg0KICAgICBHZW5lcmFsIERpc2N1c3Npb246IGlwcG1A aWV0Zi5vcmcNCiAgICAgVG8gU3Vic2NyaWJlOiAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lwcG0NCiAgICAgQXJjaGl2ZTogICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaXBwbQ0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5n IEdyb3VwOg0KDQpUaGUgSVAgUGVyZm9ybWFuY2UgTWV0cmljcyAoSVBQTSkgV29ya2luZyBHcm91 cCBkZXZlbG9wcyBhbmQgbWFpbnRhaW5zIHN0YW5kYXJkDQptZXRyaWNzIHRoYXQgY2FuIGJlIGFw cGxpZWQgdG8gdGhlIHF1YWxpdHksIHBlcmZvcm1hbmNlLCBhbmQgcmVsaWFiaWxpdHkgb2YNCklu dGVybmV0IGRhdGEgZGVsaXZlcnkgc2VydmljZXMgYW5kIGFwcGxpY2F0aW9ucy4gSXQgYWxzbyBk ZXZlbG9wcyBhbmQNCm1haW50YWlucyBwcm90b2NvbHMgZm9yIHRoZSBtZWFzdXJlbWVudCBvZiB0 aGVzZSBtZXRyaWNzLiBUaGVzZSBtZXRyaWNzIGFyZQ0KZGVzaWduZWQgc3VjaCB0aGF0IHRoZXkg Y2FuIGJlIHBlcmZvcm1lZCBieSBuZXR3b3JrIG9wZXJhdG9ycywgZW5kIHVzZXJzLCBvcg0KaW5k ZXBlbmRlbnQgdGVzdGluZyBncm91cHMuIE1ldHJpY3MgZGV2ZWxvcGVkIGJ5IHRoZSBJUFBNIFdH IGFyZSBpbnRlbmRlZCB0bw0KcHJvdmlkZSB1bmJpYXNlZCBxdWFudGl0YXRpdmUgcGVyZm9ybWFu Y2UgbWVhc3VyZW1lbnRzIGFuZCBub3QgYSB2YWx1ZQ0KanVkZ2VtZW50Lg0KDQpUaGUgSVBQTSBX RyBoYXMgcHJvZHVjZWQgZG9jdW1lbnRzIHRoYXQgZGVmaW5lIHNwZWNpZmljIG1ldHJpY3MgYW5k IHByb2NlZHVyZXMNCmZvciBhY2N1cmF0ZWx5IG1lYXN1cmluZyBhbmQgZG9jdW1lbnRpbmcgdGhl c2UgbWV0cmljcy4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbA0KY29udGludWUgYWR2YW5jaW5nIHRo ZXNlIG1ldHJpY3MgYWxvbmcgdGhlIHN0YW5kYXJkcyB0cmFjaywgdXNpbmcgdGhlDQpndWlkZWxp bmVzIHN0YXRlZCBpbiBSRkMgNjU3Ni4gVG8gdGhlIGV4dGVudCBwb3NzaWJsZSwgdGhlc2UgbWV0 cmljcyB3aWxsIGJlDQp1c2VkIGFzIHRoZSBiYXNpcyBmb3IgZnV0dXJlIHdvcmsgb24gbWV0cmlj cyBpbiB0aGUgV0cuDQoNClRoZSBXRyB3aWxsIGRldmVsb3AgdGhlIG1pbmltdW0gbnVtYmVyIG9m IG5ldyBtZXRyaWNzIGFuZCBtb2RlbHMgbmVlZGVkIHRvIG1vcmUNCmFjY3VyYXRlbHkgcXVhbnRp dGF0aXZlbHkgY2hhcmFjdGVyaXplIHRoZSBuZXR3b3JrIHBhdGgocykgdW5kZXIgdGVzdCBhbmQv b3INCnRoZSBiZWhhdmlvciBvZiB0cmFuc3BvcnQgYW5kIGFwcGxpY2F0aW9uIGxheWVyIHByb3Rv Y29scyBvbiB0aGVzZSBwYXRoKHMpLiBOZXcNCm1ldHJpYyBkZWZpbml0aW9ucyB3aWxsIHN0YXRl IGhvdyB0aGUgZGVmaW5pdGlvbiBpbXByb3ZlcyBvbiBhbiBleGlzdGluZyBtZXRyaWMNCmRlZmlu aXRpb24sIG9yIGVuY29tcGFzc2VzIGEgbWV0cmljIG5vdCBwcmV2aW91c2x5IGRlZmluZWQuDQoN CkFkZGl0aW9uYWwgbWV0aG9kcyB3aWxsIGJlIGRlZmluZWQgZm9yIHRoZSBjb21wb3NpdGlvbiBh bmQgY2FsaWJyYXRpb24gb2YNCklQUE0tZGVmaW5lZCBtZXRyaWNzLCBhcyB3ZWxsIGFzIGFjdGl2 ZSwgcGFzc2l2ZSBhbmQgaHlicmlkIG1lYXN1cmVtZW50IG1ldGhvZHMNCmZvciB0aGVzZSBtZXRy aWNzLiBJbiBhZGRpdGlvbiwgV0cgZW5jb3VyYWdlcyB3b3JrIHdoaWNoIGRlc2NyaWJlcyB0aGUN CmFwcGxpY2FiaWxpdHkgb2YgbWV0cmljcyBhbmQgbWVhc3VyZW1lbnQgbWV0aG9kcywgZXNwZWNp YWxseSB0byBpbXByb3ZlDQp1bmRlcnN0YW5kaW5nIG9mIHRoZSB0cmFkZW9mZnMgaW52b2x2ZWQg YW1vbmcgYWN0aXZlLCBwYXNzaXZlLCBhbmQgaHlicmlkDQptZXRob2RzLg0KDQpUaGUgV0cgbWF5 IHVwZGF0ZSBpdHMgY29yZSBmcmFtZXdvcmsgUkZDIDIzMzAgYXMgbmVjZXNzYXJ5IHRvIGFjY29t bW9kYXRlIHRoZXNlDQphY3Rpdml0aWVzLg0KDQpUaGUgV0cgaGFzIHByb2R1Y2VkIHByb3RvY29s cyBmb3IgY29tbXVuaWNhdGlvbiBhbW9uZyB0ZXN0IGVxdWlwbWVudCB0byBlbmFibGUNCnRoZSBt ZWFzdXJlbWVudCBvZiB0aGUgb25lLSBhbmQgdHdvLXdheSBtZXRyaWNzIChPV0FNUCBhbmQgVFdB TVAgcmVzcGVjdGl2ZWx5KS4NClRoZXNlIHByb3RvY29scyB3aWxsIGJlIGFkdmFuY2VkIGFsb25n IHRoZSBzdGFuZGFyZHMgdHJhY2suIFRoZSBXRyB3aWxsIGZ1cnRoZXINCmRldmVsb3AgYW5kIGlt cHJvdmUgdGhlc2UgcHJvdG9jb2xzLiBUaGUgV0cgbWF5IGRldmVsb3AgbmV3IG1lYXN1cmVtZW50 DQpwcm90b2NvbHMgYXMgbmVjZXNzYXJ5IHRvIHN1cHBvcnQgbmV3IG1ldHJpY3MuIE5ldyBtZXRy aWMgYW5kIHByb3RvY29sDQpkZXZlbG9wbWVudCB3aWxsIGZvY3VzIG9uIHRoZSBhdXRvbWF0YWJp bGl0eSBvZiBtZWFzdXJlbWVudHMgaW4gb3JkZXIgdG8NCnN1cHBvcnQgbGFyZ2Utc2NhbGUgbWVh c3VyZW1lbnQgZWZmb3J0cy4NCg0KVGhlIGVxdWl2YWxlbmN5IG9mIG1ldHJpYyBkZWZpbml0aW9u cyBpcyBjcnVjaWFsIHRvIGFjY3VyYXRlLCBjb21wYXJhYmxlIGFuZA0KcmVwcm9kdWNpYmxlIG1l YXN1cmVtZW50LiBUaGUgV0cgd2lsbCBkZWZpbmUgYW5kIG1haW50YWluIGEgcmVnaXN0cnkgb2Yg bWV0cmljDQpkZWZpbml0aW9ucyB0byB0aGlzIGVuZC4gVGhlIFdHIGVuY291cmFnZXMgd29yayB3 aGljaCBjb21wYXJlcyBJUFBNIG1ldHJpY3MNCndpdGggbWV0cmljcyBkZXZlbG9wZWQgZWxzZXdo ZXJlLCBwYXJ0aWN1bGFybHkgaW4gcmVnYXJkcyB0byBlcXVpdmFsZW5jeSwNCnNpbWlsYXJpdHkg YW5kIGZ1bmN0aW9uYWxpdHkuIFRoZSBXRyBhbHNvIGVuY291cmFnZXMgd29yayB3aGljaCBpbXBy b3ZlcyB0aGUNCmF2YWlsYWJpbGl0eSBvZiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4dCBp biB3aGljaCBtZWFzdXJlbWVudHMgd2VyZSB0YWtlbi4NCg0KVGhlIElQUE0gV0cgc2Vla3MgY29v cGVyYXRpb24gd2l0aCBvdGhlciBhcHByb3ByaWF0ZSBzdGFuZGFyZHMgYm9kaWVzIGFuZA0KZm9y dW1zIHRvIHByb21vdGUgY29uc2lzdGVudCBhcHByb2FjaGVzIGFuZCBtZXRyaWNzLiBXaXRoaW4g dGhlIElFVEYgcHJvY2VzcywNCklQUE0gbWV0cmljIGRlZmluaXRpb25zIHdpbGwgYmUgc3ViamVj dCB0byBhcyByaWdvcm91cyBhIHNjcnV0aW55IGZvcg0KdXNlZnVsbmVzcywgY2xhcml0eSwgYW5k IGFjY3VyYWN5IGFzIG90aGVyIHByb3RvY29sIHN0YW5kYXJkcy4gVGhlIElQUE0gV0cgd2lsbA0K aW50ZXJhY3Qgd2l0aCBvdGhlciBhcmVhcyBvZiBJRVRGIGFjdGl2aXR5IHdob3NlIHNjb3BlIGlu dGVyc2VjdHMgd2l0aCB0aGUNCnJlcXVpcmVtZW50IG9mIHRoZXNlIHNwZWNpZmljIG1ldHJpY3Mu IFRoZSBXRyB3aWxsLCBvbiByZXF1ZXN0LCBwcm92aWRlIGlucHV0DQp0byBvdGhlciBJRVRGIHdv cmtpbmcgZ3JvdXBzIG9uIHRoZSB1c2UgYW5kIGltcGxlbWVudGF0aW9uIG9mIHRoZXNlIG1ldHJp Y3MuDQoNCk1pbGVzdG9uZXM6DQoNClRCRCAgICAgIC0gU3VibWl0IGRyYWZ0IG9uIGFjY2VzcyBy YXRlIG1lYXN1cmVtZW50IHByb3RvY29sIHByb2JsZW0gc3RhdGVtZW50DQogICAgICAgICAgIHRv IElFU0cgYXMgSW5mb3JtYXRpb25hbA0KVEJEICAgICAgLSBTdWJtaXQgZHJhZnQgb24gUkZDIDI2 ODAgc3RhbmRhcmRzLXRyYWNrIGFkdmFuY2VtZW50IHRlc3RpbmcNCiAgICAgICAgICAgdG8gSUVT RyBhcyBJbmZvcm1hdGlvbmFsDQogICAgICAgICAgIA0KQWRkaXRpb25hbCBtaWxlc3RvbmVzIFRC RA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0g bWFpbGluZyBsaXN0DQppcHBtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwcG0= ------=_001_NextPart268527350103_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
the charter looks good to me.
 
Guangqing=20 Deng
CNN= IC 
 
Date: 2013-03-19 10:34
To: ippm@ietf.org
Subject: [ippm] Call for Consensus on new charter for=20 IPPM
Greetings, all,
 
We have updated the draft charter based=  on discussion during our meeting in Or= lando last Friday. We believe the draft = ;charter below addresses all comments received,&n= bsp;and would like to issue a call for&= nbsp;WG consensus on the charter text. We'll=  be issuing separate calls for each of&= nbsp;the documents under consideration for adopti= on as WG items under this charter.
 
If you support the adoption of this&nbs= p;charter for IPPM, please reply to this&nbs= p;message and/or to the list stating so.&nbs= p;
 
If you do not support the adoption = ;of this charter, please reply to the l= ist, with your suggestions for improvement a= nd further discussion.
 
Please reply by Monday 25 March 2013;&n= bsp;absent continuing discussion, we intend to&nb= sp;evaluate consensus then, and send the cha= rter to the IESG for approval.
 
Many thanks, best regards,
 
Brian
 
 
IP Performance Metrics (ippm)
-----------------------------
 
 Charter
 
 Current Status: Active
 
 Chairs:
     Brian Trammell 
     Bill Cerveny
     
 Transport Area Directors:
     Martin Stiemerling
     Martin Stiemerling
 
 Transport Area Advisor:
     Martin Stiemerling
 
 Mailing Lists:
     General Discussion: ippm@ietf= .org
     To Subscribe:   &nb= sp;   https://www.ietf.org/mailman/listinfo/ippm
     Archive:     &= nbsp;      http://www.ietf.org/mail-archive/= web/ippm
 
Description of Working Group:
 
The IP Performance Metrics (IPPM) Working&nb= sp;Group develops and maintains standard
metrics that can be applied to the = ;quality, performance, and reliability of
Internet data delivery services and applicat= ions. It also develops and
maintains protocols for the measurement of&n= bsp;these metrics. These metrics are
designed such that they can be performe= d by network operators, end users, or
independent testing groups. Metrics developed&nbs= p;by the IPPM WG are intended to
provide unbiased quantitative performance measure= ments and not a value
judgement.
 
The IPPM WG has produced documents that=  define specific metrics and procedures
for accurately measuring and documenting the= se metrics. The working group will
continue advancing these metrics along the&n= bsp;standards track, using the
guidelines stated in RFC 6576. To the&n= bsp;extent possible, these metrics will be
used as the basis for future work = on metrics in the WG.
 
The WG will develop the minimum number&= nbsp;of new metrics and models needed to&nbs= p;more
accurately quantitatively characterize the networ= k path(s) under test and/or
the behavior of transport and application&nb= sp;layer protocols on these path(s). New
metric definitions will state how the d= efinition improves on an existing metric
definition, or encompasses a metric not = ;previously defined.
 
Additional methods will be defined for = the composition and calibration of
IPPM-defined metrics, as well as active,&nbs= p;passive and hybrid measurement methods
for these metrics. In addition, WG enco= urages work which describes the
applicability of metrics and measurement met= hods, especially to improve
understanding of the tradeoffs involved amon= g active, passive, and hybrid
methods.
 
The WG may update its core framework&nb= sp;RFC 2330 as necessary to accommodate thes= e
activities.
 
The WG has produced protocols for commu= nication among test equipment to enable
the measurement of the one- and two-way=  metrics (OWAMP and TWAMP respectively).
These protocols will be advanced along = the standards track. The WG will further
develop and improve these protocols. The&nbs= p;WG may develop new measurement
protocols as necessary to support new m= etrics. New metric and protocol
development will focus on the automatability=  of measurements in order to
support large-scale measurement efforts.
 
The equivalency of metric definitions is&nbs= p;crucial to accurate, comparable and
reproducible measurement. The WG will define=  and maintain a registry of metric
definitions to this end. The WG encoura= ges work which compares IPPM metrics
with metrics developed elsewhere, particularly&nb= sp;in regards to equivalency,
similarity and functionality. The WG also&nb= sp;encourages work which improves the
availability of information about the contex= t in which measurements were taken.
 
The IPPM WG seeks cooperation with othe= r appropriate standards bodies and
forums to promote consistent approaches and&= nbsp;metrics. Within the IETF process,
IPPM metric definitions will be subject = ;to as rigorous a scrutiny for
usefulness, clarity, and accuracy as other&n= bsp;protocol standards. The IPPM WG will
interact with other areas of IETF activ= ity whose scope intersects with the
requirement of these specific metrics. The&n= bsp;WG will, on request, provide input
to other IETF working groups on the&nbs= p;use and implementation of these metrics.
 
Milestones:
 
TBD      - Submit draft = on access rate measurement protocol problem = statement
           to&= nbsp;IESG as Informational
TBD      - Submit draft = on RFC 2680 standards-track advancement testing
           to&= nbsp;IESG as Informational
           
Additional milestones TBD
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
------=_001_NextPart268527350103_=------ From henk@uijterwaal.nl Fri Mar 22 00:02:58 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF7B11E80A4 for ; Fri, 22 Mar 2013 00:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG0KGIL9BhCn for ; Fri, 22 Mar 2013 00:02:57 -0700 (PDT) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by ietfa.amsl.com (Postfix) with ESMTP id C297311E809C for ; Fri, 22 Mar 2013 00:02:51 -0700 (PDT) Received: from geir.local ([88.128.80.6]) (authenticated bits=0) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id r2M72Kqd034666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Mar 2013 08:02:34 +0100 (CET) (envelope-from henk@uijterwaal.nl) Message-ID: <514BF38E.3040809@uijterwaal.nl> Date: Fri, 22 Mar 2013 07:00:46 +0100 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ippm@ietf.org References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> <201303220927178418421@cnnic.cn> In-Reply-To: <201303220927178418421@cnnic.cn> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 07:02:58 -0000 On 22/03/2013 02:27, Guangqing Deng wrote: > the charter looks good to me. I agree as well, Henk > > -------------------------------------------------------------------------------- > Guangqing Deng > CNNIC > > *From:* Brian Trammell > *Date:* 2013-03-19 10:34 > *To:* ippm@ietf.org > *Subject:* [ippm] Call for Consensus on new charter for IPPM > Greetings, all, > > We have updated the draft charter based on discussion during our meeting in Orlando last Friday. We believe the draft charter below addresses all comments received, and would like to issue a call for WG consensus on the charter text. We'll be issuing separate calls for each of the documents under consideration for adoption as WG items under this charter. > > If you support the adoption of this charter for IPPM, please reply to this message and/or to the list stating so. > > If you do not support the adoption of this charter, please reply to the list, with your suggestions for improvement and further discussion. > > Please reply by Monday 25 March 2013; absent continuing discussion, we intend to evaluate consensus then, and send the charter to the IESG for approval. > > Many thanks, best regards, > > Brian > > > IP Performance Metrics (ippm) > ----------------------------- > > Charter > > Current Status: Active > > Chairs: > Brian Trammell > Bill Cerveny > > Transport Area Directors: > Martin Stiemerling > Martin Stiemerling > > Transport Area Advisor: > Martin Stiemerling > > Mailing Lists: > General Discussion: ippm@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ippm > Archive: http://www.ietf.org/mail-archive/web/ippm > > Description of Working Group: > > The IP Performance Metrics (IPPM) Working Group develops and maintains standard > metrics that can be applied to the quality, performance, and reliability of > Internet data delivery services and applications. It also develops and > maintains protocols for the measurement of these metrics. These metrics are > designed such that they can be performed by network operators, end users, or > independent testing groups. Metrics developed by the IPPM WG are intended to > provide unbiased quantitative performance measurements and not a value > judgement. > > The IPPM WG has produced documents that define specific metrics and procedures > for accurately measuring and documenting these metrics. The working group will > continue advancing these metrics along the standards track, using the > guidelines stated in RFC 6576. To the extent possible, these metrics will be > used as the basis for future work on metrics in the WG. > > The WG will develop the minimum number of new metrics and models needed to more > accurately quantitatively characterize the network path(s) under test and/or > the behavior of transport and application layer protocols on these path(s). New > metric definitions will state how the definition improves on an existing metric > definition, or encompasses a metric not previously defined. > > Additional methods will be defined for the composition and calibration of > IPPM-defined metrics, as well as active, passive and hybrid measurement methods > for these metrics. In addition, WG encourages work which describes the > applicability of metrics and measurement methods, especially to improve > understanding of the tradeoffs involved among active, passive, and hybrid > methods. > > The WG may update its core framework RFC 2330 as necessary to accommodate these > activities. > > The WG has produced protocols for communication among test equipment to enable > the measurement of the one- and two-way metrics (OWAMP and TWAMP respectively). > These protocols will be advanced along the standards track. The WG will further > develop and improve these protocols. The WG may develop new measurement > protocols as necessary to support new metrics. New metric and protocol > development will focus on the automatability of measurements in order to > support large-scale measurement efforts. > > The equivalency of metric definitions is crucial to accurate, comparable and > reproducible measurement. The WG will define and maintain a registry of metric > definitions to this end. The WG encourages work which compares IPPM metrics > with metrics developed elsewhere, particularly in regards to equivalency, > similarity and functionality. The WG also encourages work which improves the > availability of information about the context in which measurements were taken. > > The IPPM WG seeks cooperation with other appropriate standards bodies and > forums to promote consistent approaches and metrics. Within the IETF process, > IPPM metric definitions will be subject to as rigorous a scrutiny for > usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will > interact with other areas of IETF activity whose scope intersects with the > requirement of these specific metrics. The WG will, on request, provide input > to other IETF working groups on the use and implementation of these metrics. > > Milestones: > > TBD - Submit draft on access rate measurement protocol problem statement > to IESG as Informational > TBD - Submit draft on RFC 2680 standards-track advancement testing > to IESG as Informational > > Additional milestones TBD > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ Read my blog at http://www.uijterwaal.nl/henks_hands.html From mach.chen@huawei.com Fri Mar 22 01:48:58 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371E921F901E for ; Fri, 22 Mar 2013 01:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6E4piPz0ZdB for ; Fri, 22 Mar 2013 01:48:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4477921F9037 for ; Fri, 22 Mar 2013 01:48:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQZ50778; Fri, 22 Mar 2013 08:48:54 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 22 Mar 2013 08:47:54 +0000 Received: from SZXEML452-HUB.china.huawei.com (10.82.67.195) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 22 Mar 2013 08:48:52 +0000 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.4]) by szxeml452-hub.china.huawei.com ([10.82.67.195]) with mapi id 14.01.0323.007; Fri, 22 Mar 2013 16:48:33 +0800 From: Mach Chen To: "" , "ippm@ietf.org" Thread-Topic: [ippm] Call for Consensus on new charter for IPPM Thread-Index: AQHOJEpI5c8vjoiC30+Db/EYv+vIi5ixaKqA Date: Fri, 22 Mar 2013 08:48:33 +0000 Message-ID: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> In-Reply-To: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:48:58 -0000 Hi, The charter looks good to me, I support it! By the way, does it mean that this draft (http://tools.ietf.org/html/draft-= chen-coloring-based-ipfpm-framework-01 ) is in the new charter? So, please= take a look at this draft and give your comments! Many thanks Mach > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Tuesday, March 19, 2013 10:34 AM > To: ippm@ietf.org > Subject: [ippm] Call for Consensus on new charter for IPPM >=20 > Greetings, all, >=20 > We have updated the draft charter based on discussion during our meeting = in > Orlando last Friday. We believe the draft charter below addresses all com= ments > received, and would like to issue a call for WG consensus on the charter = text. > We'll be issuing separate calls for each of the documents under considera= tion for > adoption as WG items under this charter. >=20 > If you support the adoption of this charter for IPPM, please reply to thi= s message > and/or to the list stating so. >=20 > If you do not support the adoption of this charter, please reply to the l= ist, with > your suggestions for improvement and further discussion. >=20 > Please reply by Monday 25 March 2013; absent continuing discussion, we in= tend > to evaluate consensus then, and send the charter to the IESG for approval= . >=20 > Many thanks, best regards, >=20 > Brian >=20 >=20 > IP Performance Metrics (ippm) > ----------------------------- >=20 > Charter >=20 > Current Status: Active >=20 > Chairs: > Brian Trammell > Bill Cerveny >=20 > Transport Area Directors: > Martin Stiemerling > Martin Stiemerling >=20 > Transport Area Advisor: > Martin Stiemerling >=20 > Mailing Lists: > General Discussion: ippm@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ippm > Archive: http://www.ietf.org/mail-archive/web/ippm >=20 > Description of Working Group: >=20 > The IP Performance Metrics (IPPM) Working Group develops and maintains > standard > metrics that can be applied to the quality, performance, and reliability = of > Internet data delivery services and applications. It also develops and > maintains protocols for the measurement of these metrics. These metrics a= re > designed such that they can be performed by network operators, end users,= or > independent testing groups. Metrics developed by the IPPM WG are intended= to > provide unbiased quantitative performance measurements and not a value > judgement. >=20 > The IPPM WG has produced documents that define specific metrics and > procedures > for accurately measuring and documenting these metrics. The working group= will > continue advancing these metrics along the standards track, using the > guidelines stated in RFC 6576. To the extent possible, these metrics will= be > used as the basis for future work on metrics in the WG. >=20 > The WG will develop the minimum number of new metrics and models needed > to more > accurately quantitatively characterize the network path(s) under test and= /or > the behavior of transport and application layer protocols on these path(s= ). New > metric definitions will state how the definition improves on an existing = metric > definition, or encompasses a metric not previously defined. >=20 > Additional methods will be defined for the composition and calibration of > IPPM-defined metrics, as well as active, passive and hybrid measurement > methods > for these metrics. In addition, WG encourages work which describes the > applicability of metrics and measurement methods, especially to improve > understanding of the tradeoffs involved among active, passive, and hybrid > methods. >=20 > The WG may update its core framework RFC 2330 as necessary to accommodate > these > activities. >=20 > The WG has produced protocols for communication among test equipment to > enable > the measurement of the one- and two-way metrics (OWAMP and TWAMP > respectively). > These protocols will be advanced along the standards track. The WG will f= urther > develop and improve these protocols. The WG may develop new measurement > protocols as necessary to support new metrics. New metric and protocol > development will focus on the automatability of measurements in order to > support large-scale measurement efforts. >=20 > The equivalency of metric definitions is crucial to accurate, comparable = and > reproducible measurement. The WG will define and maintain a registry of m= etric > definitions to this end. The WG encourages work which compares IPPM metri= cs > with metrics developed elsewhere, particularly in regards to equivalency, > similarity and functionality. The WG also encourages work which improves = the > availability of information about the context in which measurements were = taken. >=20 > The IPPM WG seeks cooperation with other appropriate standards bodies and > forums to promote consistent approaches and metrics. Within the IETF proc= ess, > IPPM metric definitions will be subject to as rigorous a scrutiny for > usefulness, clarity, and accuracy as other protocol standards. The IPPM W= G will > interact with other areas of IETF activity whose scope intersects with th= e > requirement of these specific metrics. The WG will, on request, provide i= nput > to other IETF working groups on the use and implementation of these metri= cs. >=20 > Milestones: >=20 > TBD - Submit draft on access rate measurement protocol problem > statement > to IESG as Informational > TBD - Submit draft on RFC 2680 standards-track advancement testing > to IESG as Informational >=20 > Additional milestones TBD > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From philip.eardley@bt.com Fri Mar 22 09:19:40 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDA821F8B20 for ; Fri, 22 Mar 2013 09:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-n5EGtHf9PR for ; Fri, 22 Mar 2013 09:19:39 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id B7FAF21F8A27 for ; Fri, 22 Mar 2013 09:19:38 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 22 Mar 2013 16:19:36 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.154]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Fri, 22 Mar 2013 16:19:37 +0000 From: To: , Date: Fri, 22 Mar 2013 16:19:35 +0000 Thread-Topic: [ippm] Call for Consensus on new charter for IPPM Thread-Index: Ac4kSkSVUNBKJ3MaSzK6yE+H7PiHBgCzPEQQ Message-ID: <9510D26531EF184D9017DF24659BB87F3439750029@EMV65-UKRD.domain1.systemhost.net> References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> In-Reply-To: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 16:19:40 -0000 looks good, thanks could the reference path (measurement points) work be mentioned? or maybe s= ome note about TBD whether this is in ippm or lmap? possible re-phrasings: para 1 < These metrics are designed such that they can be performed by network ope= rators> maybe 'used' or 'measured' instead of 'performed'? para 2 -could this be merged with the later paragraph < The WG has produced= protocols ...> (four paragraphs later)> They say ~ same thing para 3 - < The WG will develop the minimum number of new metrics and models= needed to more accurately quantitatively characterize the network path(s) = under test and/or the behavior of transport and application layer> maybe 'performance' instead of 'behavior'? penultimate para < The equivalency of metric definitions is crucial to accu= rate, comparable and reproducible measurement. The WG will define and maint= ain a registry of metric definitions to this end. The WG encourages work wh= ich compares IPPM metrics with metrics developed elsewhere, particularly in= regards to equivalency, similarity and functionality.> are ' equivalency' and 'similarity' the same thing? I'm not sure what 'func= tionality' means in this context. suggest Agreement about the definitions of metrics enables them to be measured accu= rately, comparably and reproducibly. To this end, the WG will define and ma= intain a registry of metric definitions. The WG also encourages work which = assesses the comparability of measurements of IPPM metrics with metrics dev= eloped elsewhere.> best wishes phil -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: 19 March 2013 02:34 To: ippm@ietf.org Subject: [ippm] Call for Consensus on new charter for IPPM Greetings, all, We have updated the draft charter based on discussion during our meeting in= Orlando last Friday. We believe the draft charter below addresses all comm= ents received, and would like to issue a call for WG consensus on the chart= er text. We'll be issuing separate calls for each of the documents under co= nsideration for adoption as WG items under this charter. If you support the adoption of this charter for IPPM, please reply to this = message and/or to the list stating so.=20 If you do not support the adoption of this charter, please reply to the lis= t, with your suggestions for improvement and further discussion. Please reply by Monday 25 March 2013; absent continuing discussion, we inte= nd to evaluate consensus then, and send the charter to the IESG for approva= l. Many thanks, best regards, Brian IP Performance Metrics (ippm) ----------------------------- Charter Current Status: Active Chairs: Brian Trammell=20 Bill Cerveny =20 Transport Area Directors: Martin Stiemerling Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: http://www.ietf.org/mail-archive/web/ippm Description of Working Group: The IP Performance Metrics (IPPM) Working Group develops and maintains stan= dard metrics that can be applied to the quality, performance, and reliabili= ty of Internet data delivery services and applications. It also develops an= d maintains protocols for the measurement of these metrics. These metrics a= re designed such that they can be performed by network operators, end users= , or independent testing groups. Metrics developed by the IPPM WG are inten= ded to provide unbiased quantitative performance measurements and not a val= ue judgement. The IPPM WG has produced documents that define specific metrics and procedu= res for accurately measuring and documenting these metrics. The working gro= up will continue advancing these metrics along the standards track, using t= he guidelines stated in RFC 6576. To the extent possible, these metrics wil= l be used as the basis for future work on metrics in the WG. The WG will develop the minimum number of new metrics and models needed to = more accurately quantitatively characterize the network path(s) under test = and/or the behavior of transport and application layer protocols on these p= ath(s). New metric definitions will state how the definition improves on an= existing metric definition, or encompasses a metric not previously defined= . Additional methods will be defined for the composition and calibration of I= PPM-defined metrics, as well as active, passive and hybrid measurement meth= ods for these metrics. In addition, WG encourages work which describes the = applicability of metrics and measurement methods, especially to improve und= erstanding of the tradeoffs involved among active, passive, and hybrid meth= ods. The WG may update its core framework RFC 2330 as necessary to accommodate t= hese activities. The WG has produced protocols for communication among test equipment to ena= ble the measurement of the one- and two-way metrics (OWAMP and TWAMP respec= tively). These protocols will be advanced along the standards track. The WG will fur= ther develop and improve these protocols. The WG may develop new measuremen= t protocols as necessary to support new metrics. New metric and protocol de= velopment will focus on the automatability of measurements in order to supp= ort large-scale measurement efforts. The equivalency of metric definitions is crucial to accurate, comparable an= d reproducible measurement. The WG will define and maintain a registry of m= etric definitions to this end. The WG encourages work which compares IPPM m= etrics with metrics developed elsewhere, particularly in regards to equival= ency, similarity and functionality. The WG also encourages work which impro= ves the availability of information about the context in which measurements= were taken. The IPPM WG seeks cooperation with other appropriate standards bodies and f= orums to promote consistent approaches and metrics. Within the IETF process= , IPPM metric definitions will be subject to as rigorous a scrutiny for use= fulness, clarity, and accuracy as other protocol standards. The IPPM WG wil= l interact with other areas of IETF activity whose scope intersects with th= e requirement of these specific metrics. The WG will, on request, provide i= nput to other IETF working groups on the use and implementation of these me= trics. Milestones: TBD - Submit draft on access rate measurement protocol problem stateme= nt to IESG as Informational TBD - Submit draft on RFC 2680 standards-track advancement testing to IESG as Informational =20 Additional milestones TBD _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From mattmathis@google.com Sat Mar 23 12:13:23 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467A321F8CF4 for ; Sat, 23 Mar 2013 12:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISvXCPj0igqF for ; Sat, 23 Mar 2013 12:13:22 -0700 (PDT) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B3F1421F8CF0 for ; Sat, 23 Mar 2013 12:13:22 -0700 (PDT) Received: by mail-ia0-f170.google.com with SMTP id h8so4553703iaa.29 for ; Sat, 23 Mar 2013 12:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SA71Cpe3kI2xdF4sn1EVsUJEAClVFMtbQVt6KbWNsE4=; b=kk9YeJJcZTioVY8BsDpqciSgOHHKB4dIoSJGpXfqk9enEleu37g2sYPJGtsbVC+aSL tDH0aZ0DkR+NEz+l3S02pHfB8QitE/fwTpgkh7fQCsf1cZ5Yn7kFhwgQtGgXeH4cy2t2 NAxeVx8EFZK8V3X2CAV02A8dr4XgkS/tn5+FSfMNqnmR40u31+DYhDOSNeqRI0u9DGHZ NMLFvs1+HYijY0qM8NoaEXVqUwUsPv9izB9ypneSeN2/eMW1OagyMzdux8HGtVP1q3ED CX3JyMlqgiH3NyLGmGjbwAGmbnUVMFSl673S8xdeRlmUouZztQu6cjFlw2qxVoXRFpLD uKxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=SA71Cpe3kI2xdF4sn1EVsUJEAClVFMtbQVt6KbWNsE4=; b=EvQIJ/hVJ+3Ycs0hE8Q0T6JIPzOPgxmoqbfyXv4nC9gObGQvu1/HzlOI10CxHpNJaF 6CCKkWlmOXzYVzSwm24UzPjG4nQots++R3YuGBO5E7GN2QyjAVGKSacq8j6Sib6v5KTi Olh2bnrQ2cgg3WdpqtRQnvxKyeeAFSsLtcUqyapeVupYniQc0bWEJbml41mqCIALBcNG i9IPSZbY8JbMn0ZBVZD+N4KGBu8q/fG/O2UsnWxyZkeRo+o37qxjS6jk5rRynS+EsD7z X5eocZ/P3nQ5xMk5b4Q5QXf+yXmDiv2wPJsMsdXL2h0pCrI32RuwXkp5DU1Eoh2suVxz FZJQ== MIME-Version: 1.0 X-Received: by 10.50.154.129 with SMTP id vo1mr7494819igb.93.1364065999156; Sat, 23 Mar 2013 12:13:19 -0700 (PDT) Received: by 10.64.70.37 with HTTP; Sat, 23 Mar 2013 12:13:18 -0700 (PDT) In-Reply-To: <9510D26531EF184D9017DF24659BB87F3439750029@EMV65-UKRD.domain1.systemhost.net> References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> <9510D26531EF184D9017DF24659BB87F3439750029@EMV65-UKRD.domain1.systemhost.net> Date: Sat, 23 Mar 2013 12:13:18 -0700 Message-ID: From: Matt Mathis To: "EARDLEY, Phil" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm4T0QT5eHOZ80JjF2nAffmI43CFUez/xL31dKhMsP0MEDovL1GYQ13TJS71LcWwxsHWcMSaSVbvHuJcfpFpFL+0NBGY6bTA+ldCz3qsob925Ghc/o7hwEbrLQhcIX612P5ApmzdMttM03+ZFyJ75+Rr5sMfCV40qCX5tjdFo0dQBOaIls46q/lwvrVHzzedHnqkvfE Cc: IETF IPPM Chairs , "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 19:13:23 -0000 Oops On Fri, Mar 22, 2013 at 9:19 AM, wrote: > could the reference path (measurement points) work be mentioned? or maybe some note about TBD whether this is in ippm or lmap? This is a very good point. This should be in scope for IPPM, and it would be best if the charter said so explicitly. The dialog about reference paths (measurement points) has a venn diagram problem between LMAP and IPPM. LMAP is clearly focused on the last mile, so their reference path model contains no markers corresponding to interconnects, so it can not be used as a foundation for metrics that might characterize poor performance due to poorly placed or insufficient peering capacity. Although such metrics are not part of IPPM's traditional scope, "cloud metrics" would be a trivial extension to MBM. (e.g. Given a pool of content providers and a pool of users, what is the probability that a random user will receive random content at better than a specified performance?) Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. From trammell@tik.ee.ethz.ch Sun Mar 24 01:38:46 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBEB21F8AB8 for ; Sun, 24 Mar 2013 01:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co+a46z9tmfg for ; Sun, 24 Mar 2013 01:38:45 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1E20521F88A1 for ; Sun, 24 Mar 2013 01:38:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8B99AD9308; Sun, 24 Mar 2013 09:38:40 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j+rytL7plMfR; Sun, 24 Mar 2013 09:38:40 +0100 (MET) Received: from [192.168.0.5] (unknown [121.99.65.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4F98FD9305; Sun, 24 Mar 2013 09:38:37 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <9510D26531EF184D9017DF24659BB87F3439750029@EMV65-UKRD.domain1.systemhost.net> Date: Sun, 24 Mar 2013 21:38:33 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> <9510D26531EF184D9017DF24659BB87F3439750029@EMV65-UKRD.domain1.systemhost.net> To: philip.eardley@bt.com X-Mailer: Apple Mail (2.1499) Cc: ippm-chairs@tools.ietf.org, ippm@ietf.org Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 08:38:46 -0000 Hi, Phil, Thanks for the comments; comments and questions on comments inline. On 23 Mar 2013, at 5:19, philip.eardley@bt.com wrote: > looks good, thanks >=20 > could the reference path (measurement points) work be mentioned? or = maybe some note about TBD whether this is in ippm or lmap? I believe it's in IPPM, since it fits into metric definition, and the = reference path would be part of the metric definition for reproducible = deployment of observation points. (I also think it would be useful to = ensure that the reference path doesn't just address LMAP use cases, but = wider IPPM use cases, but that's a separate point.) I see the reference path work as covered in the penultimate paragraph: "The WG also encourages work which improves the availability of = information about the context in which measurements were taken." Does this not accurately characterize the aim of the reference path? > possible re-phrasings: >=20 > para 1 > < These metrics are designed such that they can be performed by = network operators> > maybe 'used' or 'measured' instead of 'performed'? 'used' sounds good; changed in working copy. > para 2 -could this be merged with the later paragraph < The WG has = produced protocols ...> (four paragraphs later)> They say ~ same thing I don't follow this comment... Para 2 discussed metrics, Para 5 = measurement protocols. We want to keep this work separate, I think. > para 3 - < The WG will develop the minimum number of new metrics and = models needed to more accurately quantitatively characterize the network = path(s) under test and/or the behavior of transport and application = layer> > maybe 'performance' instead of 'behavior'? Works for me; changed in working copy. > penultimate para < The equivalency of metric definitions is crucial to = accurate, comparable and reproducible measurement. The WG will define = and maintain a registry of metric definitions to this end. The WG = encourages work which compares IPPM metrics with metrics developed = elsewhere, particularly in regards to equivalency, similarity and = functionality.> > are ' equivalency' and 'similarity' the same thing? I'm not sure what = 'functionality' means in this context. >=20 > suggest > Agreement about the definitions of metrics enables them to be measured = accurately, comparably and reproducibly. To this end, the WG will define = and maintain a registry of metric definitions. The WG also encourages = work which assesses the comparability of measurements of IPPM metrics = with metrics developed elsewhere.> Good point, countersuggest: Agreement about the definitions of metrics enables accurate, comparable, = and reproducible measurement of those metrics. To this end, the WG will = define and maintain a registry of metric definitions. The WG encourages work which assesses the comparability of measurements of IPPM metrics with metrics developed elsewhere. The WG also encourages work which improves the availability of information about the context in which measurements were = taken. Cheers, Brian > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf = Of Brian Trammell > Sent: 19 March 2013 02:34 > To: ippm@ietf.org > Subject: [ippm] Call for Consensus on new charter for IPPM >=20 > Greetings, all, >=20 > We have updated the draft charter based on discussion during our = meeting in Orlando last Friday. We believe the draft charter below = addresses all comments received, and would like to issue a call for WG = consensus on the charter text. We'll be issuing separate calls for each = of the documents under consideration for adoption as WG items under this = charter. >=20 > If you support the adoption of this charter for IPPM, please reply to = this message and/or to the list stating so.=20 >=20 > If you do not support the adoption of this charter, please reply to = the list, with your suggestions for improvement and further discussion. >=20 > Please reply by Monday 25 March 2013; absent continuing discussion, we = intend to evaluate consensus then, and send the charter to the IESG for = approval. >=20 > Many thanks, best regards, >=20 > Brian >=20 >=20 > IP Performance Metrics (ippm) > ----------------------------- >=20 > Charter >=20 > Current Status: Active >=20 > Chairs: > Brian Trammell=20 > Bill Cerveny >=20 > Transport Area Directors: > Martin Stiemerling > Martin Stiemerling >=20 > Transport Area Advisor: > Martin Stiemerling >=20 > Mailing Lists: > General Discussion: ippm@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ippm > Archive: http://www.ietf.org/mail-archive/web/ippm >=20 > Description of Working Group: >=20 > The IP Performance Metrics (IPPM) Working Group develops and maintains = standard metrics that can be applied to the quality, performance, and = reliability of Internet data delivery services and applications. It also = develops and maintains protocols for the measurement of these metrics. = These metrics are designed such that they can be performed by network = operators, end users, or independent testing groups. Metrics developed = by the IPPM WG are intended to provide unbiased quantitative performance = measurements and not a value judgement. >=20 > The IPPM WG has produced documents that define specific metrics and = procedures for accurately measuring and documenting these metrics. The = working group will continue advancing these metrics along the standards = track, using the guidelines stated in RFC 6576. To the extent possible, = these metrics will be used as the basis for future work on metrics in = the WG. >=20 > The WG will develop the minimum number of new metrics and models = needed to more accurately quantitatively characterize the network = path(s) under test and/or the behavior of transport and application = layer protocols on these path(s). New metric definitions will state how = the definition improves on an existing metric definition, or encompasses = a metric not previously defined. >=20 > Additional methods will be defined for the composition and calibration = of IPPM-defined metrics, as well as active, passive and hybrid = measurement methods for these metrics. In addition, WG encourages work = which describes the applicability of metrics and measurement methods, = especially to improve understanding of the tradeoffs involved among = active, passive, and hybrid methods. >=20 > The WG may update its core framework RFC 2330 as necessary to = accommodate these activities. >=20 > The WG has produced protocols for communication among test equipment = to enable the measurement of the one- and two-way metrics (OWAMP and = TWAMP respectively). > These protocols will be advanced along the standards track. The WG = will further develop and improve these protocols. The WG may develop new = measurement protocols as necessary to support new metrics. New metric = and protocol development will focus on the automatability of = measurements in order to support large-scale measurement efforts. >=20 > The equivalency of metric definitions is crucial to accurate, = comparable and reproducible measurement. The WG will define and maintain = a registry of metric definitions to this end. The WG encourages work = which compares IPPM metrics with metrics developed elsewhere, = particularly in regards to equivalency, similarity and functionality. = The WG also encourages work which improves the availability of = information about the context in which measurements were taken. >=20 > The IPPM WG seeks cooperation with other appropriate standards bodies = and forums to promote consistent approaches and metrics. Within the IETF = process, IPPM metric definitions will be subject to as rigorous a = scrutiny for usefulness, clarity, and accuracy as other protocol = standards. The IPPM WG will interact with other areas of IETF activity = whose scope intersects with the requirement of these specific metrics. = The WG will, on request, provide input to other IETF working groups on = the use and implementation of these metrics. >=20 > Milestones: >=20 > TBD - Submit draft on access rate measurement protocol problem = statement > to IESG as Informational > TBD - Submit draft on RFC 2680 standards-track advancement = testing > to IESG as Informational >=20 > Additional milestones TBD > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From trammell@tik.ee.ethz.ch Sun Mar 24 01:38:47 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F8021F88A1 for ; Sun, 24 Mar 2013 01:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exHp25joU-PX for ; Sun, 24 Mar 2013 01:38:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 250BC21F89B5 for ; Sun, 24 Mar 2013 01:38:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 86B67D930B; Sun, 24 Mar 2013 09:38:45 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tY9gbvyVnTGY; Sun, 24 Mar 2013 09:38:45 +0100 (MET) Received: from [192.168.0.5] (unknown [121.99.65.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9E6A6D9305; Sun, 24 Mar 2013 09:38:43 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Sun, 24 Mar 2013 21:38:41 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <567D1CA6-2BCB-41DE-BB0D-121D261A7AFF@tik.ee.ethz.ch> References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> To: Alissa Cooper X-Mailer: Apple Mail (2.1499) Cc: "" , "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 08:38:47 -0000 Hi, Alissa, Thanks for the comment! Nit fixed in working copy of the charter. Cheers, Brian On 21 Mar 2013, at 14:22, Alissa Cooper wrote: > Looks good. One nit below. >=20 > On Mar 18, 2013, at 10:34 PM, Brian Trammell = wrote: >=20 >> Additional methods will be defined for the composition and = calibration of >> IPPM-defined metrics, as well as active, passive and hybrid = measurement methods >> for these metrics. In addition, WG encourages work which describes = the >=20 > s/WG encourages/the WG encourages/ >=20 > --Alissa >=20 >> applicability of metrics and measurement methods, especially to = improve >> understanding of the tradeoffs involved among active, passive, and = hybrid >> methods. >>=20 >> The WG may update its core framework RFC 2330 as necessary to = accommodate these >> activities. >>=20 >> The WG has produced protocols for communication among test equipment = to enable >> the measurement of the one- and two-way metrics (OWAMP and TWAMP = respectively). >> These protocols will be advanced along the standards track. The WG = will further >> develop and improve these protocols. The WG may develop new = measurement >> protocols as necessary to support new metrics. New metric and = protocol >> development will focus on the automatability of measurements in order = to >> support large-scale measurement efforts. >>=20 >> The equivalency of metric definitions is crucial to accurate, = comparable and >> reproducible measurement. The WG will define and maintain a registry = of metric >> definitions to this end. The WG encourages work which compares IPPM = metrics >> with metrics developed elsewhere, particularly in regards to = equivalency, >> similarity and functionality. The WG also encourages work which = improves the >> availability of information about the context in which measurements = were taken. >>=20 >> The IPPM WG seeks cooperation with other appropriate standards bodies = and >> forums to promote consistent approaches and metrics. Within the IETF = process, >> IPPM metric definitions will be subject to as rigorous a scrutiny for >> usefulness, clarity, and accuracy as other protocol standards. The = IPPM WG will >> interact with other areas of IETF activity whose scope intersects = with the >> requirement of these specific metrics. The WG will, on request, = provide input >> to other IETF working groups on the use and implementation of these = metrics. >>=20 >> Milestones: >>=20 >> TBD - Submit draft on access rate measurement protocol problem = statement >> to IESG as Informational >> TBD - Submit draft on RFC 2680 standards-track advancement = testing >> to IESG as Informational >>=20 >> Additional milestones TBD >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >>=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From trammell@tik.ee.ethz.ch Sun Mar 24 01:41:34 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD8C21F8AE6 for ; Sun, 24 Mar 2013 01:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Lh7HzVoBDzX for ; Sun, 24 Mar 2013 01:41:33 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED4021F8AD8 for ; Sun, 24 Mar 2013 01:41:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 97003D9308; Sun, 24 Mar 2013 09:41:32 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5Yc5HZ5XymK4; Sun, 24 Mar 2013 09:41:32 +0100 (MET) Received: from [192.168.0.5] (unknown [121.99.65.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 895EAD9305; Sun, 24 Mar 2013 09:41:30 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Sun, 24 Mar 2013 21:41:26 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> To: Mach Chen X-Mailer: Apple Mail (2.1499) Cc: "" , "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 08:41:34 -0000 Hi, Mach, On quick review, as the work described in the draft covers a hybrid = performance measurement approach, it would seem to be in scope of the = proposed charter. However, as we've had no discussion of the draft on = the list or in an IPPM meeting, it's premature to make a call for = adoption for the draft as a WG item at this time. (Others, if you have interest in the described work, please read the = draft and discuss with the authors.) Best regards, Brian On 22 Mar 2013, at 21:48, Mach Chen wrote: > Hi, >=20 > The charter looks good to me, I support it! >=20 > By the way, does it mean that this draft = (http://tools.ietf.org/html/draft-chen-coloring-based-ipfpm-framework-01 = ) is in the new charter? So, please take a look at this draft and give = your comments! >=20 > Many thanks > Mach >=20 >> -----Original Message----- >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf = Of >> Brian Trammell >> Sent: Tuesday, March 19, 2013 10:34 AM >> To: ippm@ietf.org >> Subject: [ippm] Call for Consensus on new charter for IPPM >>=20 >> Greetings, all, >>=20 >> We have updated the draft charter based on discussion during our = meeting in >> Orlando last Friday. We believe the draft charter below addresses all = comments >> received, and would like to issue a call for WG consensus on the = charter text. >> We'll be issuing separate calls for each of the documents under = consideration for >> adoption as WG items under this charter. >>=20 >> If you support the adoption of this charter for IPPM, please reply to = this message >> and/or to the list stating so. >>=20 >> If you do not support the adoption of this charter, please reply to = the list, with >> your suggestions for improvement and further discussion. >>=20 >> Please reply by Monday 25 March 2013; absent continuing discussion, = we intend >> to evaluate consensus then, and send the charter to the IESG for = approval. >>=20 >> Many thanks, best regards, >>=20 >> Brian >>=20 >>=20 >> IP Performance Metrics (ippm) >> ----------------------------- >>=20 >> Charter >>=20 >> Current Status: Active >>=20 >> Chairs: >> Brian Trammell >> Bill Cerveny >>=20 >> Transport Area Directors: >> Martin Stiemerling >> Martin Stiemerling >>=20 >> Transport Area Advisor: >> Martin Stiemerling >>=20 >> Mailing Lists: >> General Discussion: ippm@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/ippm >> Archive: http://www.ietf.org/mail-archive/web/ippm >>=20 >> Description of Working Group: >>=20 >> The IP Performance Metrics (IPPM) Working Group develops and = maintains >> standard >> metrics that can be applied to the quality, performance, and = reliability of >> Internet data delivery services and applications. It also develops = and >> maintains protocols for the measurement of these metrics. These = metrics are >> designed such that they can be performed by network operators, end = users, or >> independent testing groups. Metrics developed by the IPPM WG are = intended to >> provide unbiased quantitative performance measurements and not a = value >> judgement. >>=20 >> The IPPM WG has produced documents that define specific metrics and >> procedures >> for accurately measuring and documenting these metrics. The working = group will >> continue advancing these metrics along the standards track, using the >> guidelines stated in RFC 6576. To the extent possible, these metrics = will be >> used as the basis for future work on metrics in the WG. >>=20 >> The WG will develop the minimum number of new metrics and models = needed >> to more >> accurately quantitatively characterize the network path(s) under test = and/or >> the behavior of transport and application layer protocols on these = path(s). New >> metric definitions will state how the definition improves on an = existing metric >> definition, or encompasses a metric not previously defined. >>=20 >> Additional methods will be defined for the composition and = calibration of >> IPPM-defined metrics, as well as active, passive and hybrid = measurement >> methods >> for these metrics. In addition, WG encourages work which describes = the >> applicability of metrics and measurement methods, especially to = improve >> understanding of the tradeoffs involved among active, passive, and = hybrid >> methods. >>=20 >> The WG may update its core framework RFC 2330 as necessary to = accommodate >> these >> activities. >>=20 >> The WG has produced protocols for communication among test equipment = to >> enable >> the measurement of the one- and two-way metrics (OWAMP and TWAMP >> respectively). >> These protocols will be advanced along the standards track. The WG = will further >> develop and improve these protocols. The WG may develop new = measurement >> protocols as necessary to support new metrics. New metric and = protocol >> development will focus on the automatability of measurements in order = to >> support large-scale measurement efforts. >>=20 >> The equivalency of metric definitions is crucial to accurate, = comparable and >> reproducible measurement. The WG will define and maintain a registry = of metric >> definitions to this end. The WG encourages work which compares IPPM = metrics >> with metrics developed elsewhere, particularly in regards to = equivalency, >> similarity and functionality. The WG also encourages work which = improves the >> availability of information about the context in which measurements = were taken. >>=20 >> The IPPM WG seeks cooperation with other appropriate standards bodies = and >> forums to promote consistent approaches and metrics. Within the IETF = process, >> IPPM metric definitions will be subject to as rigorous a scrutiny for >> usefulness, clarity, and accuracy as other protocol standards. The = IPPM WG will >> interact with other areas of IETF activity whose scope intersects = with the >> requirement of these specific metrics. The WG will, on request, = provide input >> to other IETF working groups on the use and implementation of these = metrics. >>=20 >> Milestones: >>=20 >> TBD - Submit draft on access rate measurement protocol problem >> statement >> to IESG as Informational >> TBD - Submit draft on RFC 2680 standards-track advancement = testing >> to IESG as Informational >>=20 >> Additional milestones TBD >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Sun Mar 24 06:58:15 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E35121F8D06 for ; Sun, 24 Mar 2013 06:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKVCKZ+jaVzE for ; Sun, 24 Mar 2013 06:58:14 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id ED2F421F8C5B for ; Sun, 24 Mar 2013 06:58:13 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 853D812088F; Sun, 24 Mar 2013 10:01:42 -0400 (EDT) Received: from njfpsrvexg5.research.att.com (njfpsrvexg5.research.att.com [135.207.177.27]) by mail-green.research.att.com (Postfix) with ESMTP id 16CA2E36D2; Sun, 24 Mar 2013 09:50:24 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg5.research.att.com ([fe80::a501:da3:2345:4587%10]) with mapi; Sun, 24 Mar 2013 09:58:13 -0400 From: "MORTON JR., ALFRED C (AL)" To: Brian Trammell , "philip.eardley@bt.com" Date: Sun, 24 Mar 2013 09:58:11 -0400 Thread-Topic: [ippm] Call for Consensus on new charter for IPPM Thread-Index: Ac4oawuNGpiPSiWcS+C9klvXXjMA5wAJnoAQ Message-ID: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> <9510D26531EF184D9017DF24659BB87F3439750029@EMV65-UKRD.domain1.systemhost.net> 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 Cc: "ippm-chairs@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 13:58:15 -0000 Following changes others have proposed, I support the new charter with a few more suggestions, below: ...New metric definitions will state how the definition improves on an exi= sting metric definition, or encompasses a metric not previously defined. "encompass" would seem to refer to an existing metric instead of a new one: http://oxforddictionaries.com/definition/english/encompass I suggest: ... or assesses a property of packet transfer not previously defined. (just as an example, we have loss pattern and loss episode metrics, but nothing comparable for delay except delay variation...) -=3D-=3D-=3D-=3D-=3D- further on: ... New metric and protocol development will focus on the=20 automatability of measurements in order to support large-scale measurement = efforts. suggest: s/automatability/automation/=20 (it's more straightforward, and my spell-checker doesn't accept "automatabi= lity"=20 -=3D-=3D-=3D-=3D-=3D- 2nd to last para: The equivalency of metric definitions is crucial to accurate, comparable an= d reproducible measurement. I suggest: The clarity of metric definitions and methods of measurement is crucial to = accurate, reproducible, and equivalent results across implementations. (following approval RFC 6576, "equivalence" has a special meaning in IPPM, and the synonym for interoperability among results from implementations of = metrics and methods). ++++++++++++ OR, with the alternate text suggested by Brian and Phil: Agreement about the definitions of metrics enables accurate, comparable, a= nd reproducible measurement of those metrics. suggest: Agreement about the definitions of metrics and methods of measurement enabl= es accurate,=20 reproducible, and equivalent results across different implementations. -=3D-=3D-=3D-=3D-=3D- last para: ... Within the IETF process, IPPM metric definitions will be subject to as = rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol= standards. suggest: s/definitions/definitions and measurement protocols/ regards, Al > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Sunday, March 24, 2013 4:39 AM > To: philip.eardley@bt.com > Cc: ippm-chairs@tools.ietf.org; ippm@ietf.org > Subject: Re: [ippm] Call for Consensus on new charter for IPPM >=20 > Hi, Phil, >=20 > Thanks for the comments; comments and questions on comments inline. >=20 > On 23 Mar 2013, at 5:19, philip.eardley@bt.com wrote: >=20 > > looks good, thanks > > > > could the reference path (measurement points) work be mentioned? or > maybe some note about TBD whether this is in ippm or lmap? >=20 > I believe it's in IPPM, since it fits into metric definition, and the > reference path would be part of the metric definition for reproducible > deployment of observation points. (I also think it would be useful to > ensure that the reference path doesn't just address LMAP use cases, but > wider IPPM use cases, but that's a separate point.) >=20 > I see the reference path work as covered in the penultimate paragraph: >=20 > "The WG also encourages work which improves the availability of > information about the context in which measurements were taken." >=20 > Does this not accurately characterize the aim of the reference path? >=20 > > possible re-phrasings: > > > > para 1 > > < These metrics are designed such that they can be performed by network > operators> > > maybe 'used' or 'measured' instead of 'performed'? >=20 > 'used' sounds good; changed in working copy. >=20 > > para 2 -could this be merged with the later paragraph < The WG has > produced protocols ...> (four paragraphs later)> They say ~ same thing >=20 > I don't follow this comment... Para 2 discussed metrics, Para 5 > measurement protocols. We want to keep this work separate, I think. >=20 > > para 3 - < The WG will develop the minimum number of new metrics and > models needed to more accurately quantitatively characterize the network > path(s) under test and/or the behavior of transport and application layer= > > > maybe 'performance' instead of 'behavior'? >=20 > Works for me; changed in working copy. >=20 > > penultimate para < The equivalency of metric definitions is crucial to > accurate, comparable and reproducible measurement. The WG will define and > maintain a registry of metric definitions to this end. The WG encourages > work which compares IPPM metrics with metrics developed elsewhere, > particularly in regards to equivalency, similarity and functionality.> > > are ' equivalency' and 'similarity' the same thing? I'm not sure what > 'functionality' means in this context. > > > > suggest > > Agreement about the definitions of metrics enables them to be measured > accurately, comparably and reproducibly. To this end, the WG will define > and maintain a registry of metric definitions. The WG also encourages wor= k > which assesses the comparability of measurements of IPPM metrics with > metrics developed elsewhere.> >=20 > Good point, countersuggest: >=20 > Agreement about the definitions of metrics enables accurate, comparable, > and > reproducible measurement of those metrics. To this end, the WG will defin= e > and > maintain a registry of metric definitions. The WG encourages work which > assesses the comparability of measurements of IPPM metrics with metrics > developed elsewhere. The WG also encourages work which improves the > availability of information about the context in which measurements were > taken. >=20 > Cheers, >=20 > Brian >=20 >=20 > > -----Original Message----- > > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Brian Trammell > > Sent: 19 March 2013 02:34 > > To: ippm@ietf.org > > Subject: [ippm] Call for Consensus on new charter for IPPM > > > > Greetings, all, > > > > We have updated the draft charter based on discussion during our meetin= g > in Orlando last Friday. We believe the draft charter below addresses all > comments received, and would like to issue a call for WG consensus on the > charter text. We'll be issuing separate calls for each of the documents > under consideration for adoption as WG items under this charter. > > > > If you support the adoption of this charter for IPPM, please reply to > this message and/or to the list stating so. > > > > If you do not support the adoption of this charter, please reply to the > list, with your suggestions for improvement and further discussion. > > > > Please reply by Monday 25 March 2013; absent continuing discussion, we > intend to evaluate consensus then, and send the charter to the IESG for > approval. > > > > Many thanks, best regards, > > > > Brian > > > > > > IP Performance Metrics (ippm) > > ----------------------------- > > > > Charter > > > > Current Status: Active > > > > Chairs: > > Brian Trammell > > Bill Cerveny > > > > Transport Area Directors: > > Martin Stiemerling > > Martin Stiemerling > > > > Transport Area Advisor: > > Martin Stiemerling > > > > Mailing Lists: > > General Discussion: ippm@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/ippm > > Archive: http://www.ietf.org/mail-archive/web/ippm > > > > Description of Working Group: > > > > The IP Performance Metrics (IPPM) Working Group develops and maintains > standard metrics that can be applied to the quality, performance, and > reliability of Internet data delivery services and applications. It also > develops and maintains protocols for the measurement of these metrics. > These metrics are designed such that they can be performed by network > operators, end users, or independent testing groups. Metrics developed by > the IPPM WG are intended to provide unbiased quantitative performance > measurements and not a value judgement. > > > > The IPPM WG has produced documents that define specific metrics and > procedures for accurately measuring and documenting these metrics. The > working group will continue advancing these metrics along the standards > track, using the guidelines stated in RFC 6576. To the extent possible, > these metrics will be used as the basis for future work on metrics in the > WG. > > > > The WG will develop the minimum number of new metrics and models needed > to more accurately quantitatively characterize the network path(s) under > test and/or the behavior of transport and application layer protocols on > these path(s). New metric definitions will state how the definition > improves on an existing metric definition, or encompasses a metric not > previously defined. > > > > Additional methods will be defined for the composition and calibration > of IPPM-defined metrics, as well as active, passive and hybrid measuremen= t > methods for these metrics. In addition, WG encourages work which describe= s > the applicability of metrics and measurement methods, especially to > improve understanding of the tradeoffs involved among active, passive, an= d > hybrid methods. > > > > The WG may update its core framework RFC 2330 as necessary to > accommodate these activities. > > > > The WG has produced protocols for communication among test equipment to > enable the measurement of the one- and two-way metrics (OWAMP and TWAMP > respectively). > > These protocols will be advanced along the standards track. The WG will > further develop and improve these protocols. The WG may develop new > measurement protocols as necessary to support new metrics. New metric and > protocol development will focus on the automatability of measurements in > order to support large-scale measurement efforts. > > > > The equivalency of metric definitions is crucial to accurate, comparabl= e > and reproducible measurement. The WG will define and maintain a registry > of metric definitions to this end. The WG encourages work which compares > IPPM metrics with metrics developed elsewhere, particularly in regards to > equivalency, similarity and functionality. The WG also encourages work > which improves the availability of information about the context in which > measurements were taken. > > > > The IPPM WG seeks cooperation with other appropriate standards bodies > and forums to promote consistent approaches and metrics. Within the IETF > process, IPPM metric definitions will be subject to as rigorous a scrutin= y > for usefulness, clarity, and accuracy as other protocol standards. The > IPPM WG will interact with other areas of IETF activity whose scope > intersects with the requirement of these specific metrics. The WG will, o= n > request, provide input to other IETF working groups on the use and > implementation of these metrics. > > > > Milestones: > > > > TBD - Submit draft on access rate measurement protocol problem > statement > > to IESG as Informational > > TBD - Submit draft on RFC 2680 standards-track advancement testing > > to IESG as Informational > > > > Additional milestones TBD > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From trammell@tik.ee.ethz.ch Sun Mar 24 18:19:09 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D2821F8D13 for ; Sun, 24 Mar 2013 18:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnFSbqmt278z for ; Sun, 24 Mar 2013 18:19:08 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7599621F8C93 for ; Sun, 24 Mar 2013 18:19:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 28F6BD930B; Mon, 25 Mar 2013 02:19:07 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id B4FAWJvEVVlg; Mon, 25 Mar 2013 02:19:06 +0100 (MET) Received: from [130.216.155.121] (unknown [130.216.155.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 074CCD9304; Mon, 25 Mar 2013 02:19:04 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Mon, 25 Mar 2013 14:18:58 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> <9510D26531EF184D9017DF24659BB87F3439750029@EMV65-UKRD.domain1.systemhost.net> To: "MORTON JR., ALFRED C (AL)" X-Mailer: Apple Mail (2.1499) Cc: "ippm-chairs@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 01:19:09 -0000 hi, Al, all, (Taking my chair hat off, to discuss charter wordsmithing as a = contributor.) On 25 Mar 2013, at 2:58, "MORTON JR., ALFRED C (AL)" = wrote: > Following changes others have proposed, I support the new charter > with a few more suggestions, below: >=20 > ...New metric definitions will state how the definition improves = on an existing metric definition, or encompasses a metric not previously = defined. >=20 > "encompass" would seem to refer to an existing metric instead of a new = one: > http://oxforddictionaries.com/definition/english/encompass >=20 > I suggest: > ... or assesses a property of packet transfer not previously defined. >=20 > (just as an example, we have loss pattern and loss episode metrics, > but nothing comparable for delay except delay variation...) "a property of packet transfer" is, I think, too limiting. The behavior = of transport layer protocols or applications atop them are not really = packet transfer properties. Suggest "or assesses a property of network performance not previously = defined." > -=3D-=3D-=3D-=3D-=3D- >=20 > further on: > ... New metric and protocol development will focus on the=20 > automatability of measurements in order to support large-scale = measurement efforts. >=20 > suggest: > s/automatability/automation/=20 > (it's more straightforward, and my spell-checker doesn't accept = "automatability"=20 We're not specifically automating metrics, though, that gets into LMAP = territory IMO. How about "Suitability of measurements for automation?" Best regards, Brian (as contributor)= From trammell@tik.ee.ethz.ch Sun Mar 24 18:24:14 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7768021F8DD0 for ; Sun, 24 Mar 2013 18:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBpvhlb-v23C for ; Sun, 24 Mar 2013 18:24:13 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C5CC321F8DC1 for ; Sun, 24 Mar 2013 18:24:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E8045D9308; Mon, 25 Mar 2013 02:24:12 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BV-08I9d9o+g; Mon, 25 Mar 2013 02:24:12 +0100 (MET) Received: from [130.216.155.121] (unknown [130.216.155.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D2948D9304; Mon, 25 Mar 2013 02:24:10 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Mon, 25 Mar 2013 14:24:06 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <0A38BC66-72A7-4274-B48A-A59BC16D27B9@tik.ee.ethz.ch> References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> <9510D26531EF184D9017DF24659BB87F3439750029@EMV65-UKRD.domain1.systemhost.net> To: "MORTON JR., ALFRED C (AL)" X-Mailer: Apple Mail (2.1499) Cc: "ippm-chairs@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 01:24:14 -0000 Hi, Al, all, (And with my chair hat on...) On 25 Mar 2013, at 2:58, "MORTON JR., ALFRED C (AL)" = wrote: > -=3D-=3D-=3D-=3D-=3D- > 2nd to last para: > The equivalency of metric definitions is crucial to accurate, = comparable and reproducible measurement. >=20 > I suggest: > The clarity of metric definitions and methods of measurement is = crucial to accurate, reproducible, and equivalent results across = implementations. >=20 > (following approval RFC 6576, "equivalence" has a special meaning in = IPPM, > and the synonym for interoperability among results from = implementations of metrics and methods). >=20 > ++++++++++++ > OR, with the alternate text suggested by Brian and Phil: > Agreement about the definitions of metrics enables accurate, = comparable, and > reproducible measurement of those metrics. >=20 > suggest: > Agreement about the definitions of metrics and methods of measurement = enables accurate,=20 > reproducible, and equivalent results across different implementations. Looks good to me, changed in working copy. > -=3D-=3D-=3D-=3D-=3D- > last para: >=20 > ... Within the IETF process, IPPM metric definitions will be subject = to as rigorous a scrutiny for usefulness, clarity, and accuracy as other = protocol standards. >=20 > suggest: > s/definitions/definitions and measurement protocols/ Also changed in working copy. Best regards, Brian (as chair) From acmorton@att.com Mon Mar 25 00:15:15 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271B921F8E7B for ; Mon, 25 Mar 2013 00:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHrK9RoWoEtE for ; Mon, 25 Mar 2013 00:15:14 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4168521F8E6B for ; Mon, 25 Mar 2013 00:15:11 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id C8F08120778; Mon, 25 Mar 2013 03:18:41 -0400 (EDT) Received: from njfpsrvexg1.research.att.com (njfpsrvexg1.research.att.com [135.207.177.20]) by mail-blue.research.att.com (Postfix) with ESMTP id E967BEF747; Mon, 25 Mar 2013 03:15:10 -0400 (EDT) Received: from concierge.research.att.com (135.207.179.20) by njfpsrvexg1.research.att.com (135.207.177.20) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 25 Mar 2013 03:15:10 -0400 Received: from njfpsrvexg7.research.att.com ([fe80:0000:0000:0000:3598:75fe:180.0.146.153]) by concierge.research.att.com ([135.207.24.83]) with mapi; Mon, 25 Mar 2013 03:15:10 -0400 From: "MORTON JR., ALFRED C (AL)" To: Brian Trammell Date: Mon, 25 Mar 2013 03:15:07 -0400 Thread-Topic: [ippm] Call for Consensus on new charter for IPPM Thread-Index: Ac4o9sRTvImigI2HTfOWYIa3mtbM/QAMXj2w Message-ID: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> <9510D26531EF184D9017DF24659BB87F3439750029@EMV65-UKRD.domain1.systemhost.net> 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 Cc: "ippm-chairs@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 07:15:15 -0000 Hi Contributor Brian, Both of your alt.suggestions work for me, Al > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Sunday, March 24, 2013 9:19 PM > To: MORTON JR., ALFRED C (AL) > Cc: philip.eardley@bt.com; ippm-chairs@tools.ietf.org; ippm@ietf.org > Subject: Re: [ippm] Call for Consensus on new charter for IPPM >=20 > hi, Al, all, >=20 > (Taking my chair hat off, to discuss charter wordsmithing as a > contributor.) >=20 > On 25 Mar 2013, at 2:58, "MORTON JR., ALFRED C (AL)" > wrote: >=20 > > Following changes others have proposed, I support the new charter > > with a few more suggestions, below: > > > > ...New metric definitions will state how the definition improves on > an existing metric definition, or encompasses a metric not previously > defined. > > > > "encompass" would seem to refer to an existing metric instead of a new > one: > > http://oxforddictionaries.com/definition/english/encompass > > > > I suggest: > > ... or assesses a property of packet transfer not previously defined. > > > > (just as an example, we have loss pattern and loss episode metrics, > > but nothing comparable for delay except delay variation...) >=20 > "a property of packet transfer" is, I think, too limiting. The behavior o= f > transport layer protocols or applications atop them are not really packet > transfer properties. >=20 > Suggest "or assesses a property of network performance not previously > defined." >=20 > > -=3D-=3D-=3D-=3D-=3D- > > > > further on: > > ... New metric and protocol development will focus on the > > automatability of measurements in order to support large-scale > measurement efforts. > > > > suggest: > > s/automatability/automation/ > > (it's more straightforward, and my spell-checker doesn't accept > "automatability" >=20 > We're not specifically automating metrics, though, that gets into LMAP > territory IMO. How about "Suitability of measurements for automation?" >=20 > Best regards, >=20 > Brian (as contributor) From mach.chen@huawei.com Mon Mar 25 00:20:11 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A2A21E803A for ; Mon, 25 Mar 2013 00:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBGfWoRypEPt for ; Mon, 25 Mar 2013 00:20:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE6921E8034 for ; Mon, 25 Mar 2013 00:20:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARB38063; Mon, 25 Mar 2013 07:20:08 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Mar 2013 07:19:54 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Mar 2013 07:20:06 +0000 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.247]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Mon, 25 Mar 2013 15:20:04 +0800 From: Mach Chen To: Brian Trammell Thread-Topic: [ippm] Call for Consensus on new charter for IPPM Thread-Index: AQHOJEpI5c8vjoiC30+Db/EYv+vIi5ixaKqAgAKfYwCAAf7IsA== Date: Mon, 25 Mar 2013 07:20:03 +0000 Message-ID: References: <343A449B-6C5E-4391-B3A2-11E8A46E1C02@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "ippm@ietf.org" Subject: Re: [ippm] Call for Consensus on new charter for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 07:20:11 -0000 Hi Brian, Sure, thanks for your reply! As you said, we'd appreciate that the IPPMers can read and comment on the d= raft.=20 Best regards, Mach > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Sunday, March 24, 2013 4:41 PM > To: Mach Chen > Cc: ; ippm@ietf.org > Subject: Re: [ippm] Call for Consensus on new charter for IPPM >=20 > Hi, Mach, >=20 > On quick review, as the work described in the draft covers a hybrid perfo= rmance > measurement approach, it would seem to be in scope of the proposed charte= r. > However, as we've had no discussion of the draft on the list or in an IPP= M > meeting, it's premature to make a call for adoption for the draft as a WG= item at > this time. >=20 > (Others, if you have interest in the described work, please read the draf= t and > discuss with the authors.) >=20 > Best regards, >=20 > Brian >=20 > On 22 Mar 2013, at 21:48, Mach Chen wrote: >=20 > > Hi, > > > > The charter looks good to me, I support it! > > > > By the way, does it mean that this draft > (http://tools.ietf.org/html/draft-chen-coloring-based-ipfpm-framework-01 = ) is in > the new charter? So, please take a look at this draft and give your comm= ents! > > > > Many thanks > > Mach > > > >> -----Original Message----- > >> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf O= f > >> Brian Trammell > >> Sent: Tuesday, March 19, 2013 10:34 AM > >> To: ippm@ietf.org > >> Subject: [ippm] Call for Consensus on new charter for IPPM > >> > >> Greetings, all, > >> > >> We have updated the draft charter based on discussion during our meeti= ng in > >> Orlando last Friday. We believe the draft charter below addresses all > comments > >> received, and would like to issue a call for WG consensus on the chart= er text. > >> We'll be issuing separate calls for each of the documents under consid= eration > for > >> adoption as WG items under this charter. > >> > >> If you support the adoption of this charter for IPPM, please reply to = this > message > >> and/or to the list stating so. > >> > >> If you do not support the adoption of this charter, please reply to th= e list, with > >> your suggestions for improvement and further discussion. > >> > >> Please reply by Monday 25 March 2013; absent continuing discussion, we > intend > >> to evaluate consensus then, and send the charter to the IESG for appro= val. > >> > >> Many thanks, best regards, > >> > >> Brian > >> > >> > >> IP Performance Metrics (ippm) > >> ----------------------------- > >> > >> Charter > >> > >> Current Status: Active > >> > >> Chairs: > >> Brian Trammell > >> Bill Cerveny > >> > >> Transport Area Directors: > >> Martin Stiemerling > >> Martin Stiemerling > >> > >> Transport Area Advisor: > >> Martin Stiemerling > >> > >> Mailing Lists: > >> General Discussion: ippm@ietf.org > >> To Subscribe: https://www.ietf.org/mailman/listinfo/ippm > >> Archive: http://www.ietf.org/mail-archive/web/ippm > >> > >> Description of Working Group: > >> > >> The IP Performance Metrics (IPPM) Working Group develops and maintains > >> standard > >> metrics that can be applied to the quality, performance, and reliabili= ty of > >> Internet data delivery services and applications. It also develops and > >> maintains protocols for the measurement of these metrics. These metric= s are > >> designed such that they can be performed by network operators, end use= rs, > or > >> independent testing groups. Metrics developed by the IPPM WG are > intended to > >> provide unbiased quantitative performance measurements and not a value > >> judgement. > >> > >> The IPPM WG has produced documents that define specific metrics and > >> procedures > >> for accurately measuring and documenting these metrics. The working gr= oup > will > >> continue advancing these metrics along the standards track, using the > >> guidelines stated in RFC 6576. To the extent possible, these metrics w= ill be > >> used as the basis for future work on metrics in the WG. > >> > >> The WG will develop the minimum number of new metrics and models > needed > >> to more > >> accurately quantitatively characterize the network path(s) under test = and/or > >> the behavior of transport and application layer protocols on these pat= h(s). > New > >> metric definitions will state how the definition improves on an existi= ng metric > >> definition, or encompasses a metric not previously defined. > >> > >> Additional methods will be defined for the composition and calibration= of > >> IPPM-defined metrics, as well as active, passive and hybrid measuremen= t > >> methods > >> for these metrics. In addition, WG encourages work which describes the > >> applicability of metrics and measurement methods, especially to improv= e > >> understanding of the tradeoffs involved among active, passive, and hyb= rid > >> methods. > >> > >> The WG may update its core framework RFC 2330 as necessary to > accommodate > >> these > >> activities. > >> > >> The WG has produced protocols for communication among test equipment t= o > >> enable > >> the measurement of the one- and two-way metrics (OWAMP and TWAMP > >> respectively). > >> These protocols will be advanced along the standards track. The WG wil= l > further > >> develop and improve these protocols. The WG may develop new > measurement > >> protocols as necessary to support new metrics. New metric and protocol > >> development will focus on the automatability of measurements in order = to > >> support large-scale measurement efforts. > >> > >> The equivalency of metric definitions is crucial to accurate, comparab= le and > >> reproducible measurement. The WG will define and maintain a registry o= f > metric > >> definitions to this end. The WG encourages work which compares IPPM > metrics > >> with metrics developed elsewhere, particularly in regards to equivalen= cy, > >> similarity and functionality. The WG also encourages work which improv= es the > >> availability of information about the context in which measurements we= re > taken. > >> > >> The IPPM WG seeks cooperation with other appropriate standards bodies = and > >> forums to promote consistent approaches and metrics. Within the IETF > process, > >> IPPM metric definitions will be subject to as rigorous a scrutiny for > >> usefulness, clarity, and accuracy as other protocol standards. The IPP= M WG > will > >> interact with other areas of IETF activity whose scope intersects with= the > >> requirement of these specific metrics. The WG will, on request, provid= e input > >> to other IETF working groups on the use and implementation of these me= trics. > >> > >> Milestones: > >> > >> TBD - Submit draft on access rate measurement protocol problem > >> statement > >> to IESG as Informational > >> TBD - Submit draft on RFC 2680 standards-track advancement testin= g > >> to IESG as Informational > >> > >> Additional milestones TBD > >> _______________________________________________ > >> ippm mailing list > >> ippm@ietf.org > >> https://www.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From trammell@tik.ee.ethz.ch Tue Mar 26 01:12:42 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE9F21F84D6 for ; Tue, 26 Mar 2013 01:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRtWo9TYKOrx for ; Tue, 26 Mar 2013 01:12:42 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A495321F89BA for ; Tue, 26 Mar 2013 01:12:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9E61ED930C for ; Tue, 26 Mar 2013 09:12:39 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8EVkWgA+FIfe for ; Tue, 26 Mar 2013 09:12:39 +0100 (MET) Received: from [192.168.0.5] (unknown [121.99.65.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 34437D9308 for ; Tue, 26 Mar 2013 09:12:37 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> Date: Tue, 26 Mar 2013 21:12:33 +1300 To: "ippm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 08:12:43 -0000 Greetings, all, Having applied comments in this thread to the charter, we've arrived at = the draft charter text below this message. I've seen on the order of a dozen comments supporting adoption of the = charter, some with suggestions for improvement that have been applied to = the below. Seeing no comments not supporting adoption, it appears that = we have clear consensus for the adoption of the draft charter text. Many = thanks to all for your comments! The next step is to adopt drafts from those which have been presented at = the IPPM meeting in Orlando and/or discussed to date on the list, and to = determine the milestones for those drafts.=20 For the following drafts and milestones, please indicate: (a) whether you support the adoption of the draft as a working group = item for the associated milestone, and (b) whether you have reviewed the draft, and/or are willing to review it = as a working group item (1) draft-morton-ippm-2330-update-01 Mon Year - Submit draft of RFC 2330bis (Framework update) to IESG as Proposed Standard (2) draft-morton-ippm-2679-bis-01 Mon Year - Submit draft of RFC 2679bis (One-Way Delay update)=20 to IESG as Proposed Standard (3) draft-morton-ippm-2680-bis-00 Mon Year - Submit draft of RFC 2680bis (One-Way Loss update)=20 to IESG as Proposed Standard (4) draft-morton-ippm-lmap-path-01 Mon Year - Submit draft on reference path for measurement location to IESG as Proposed Standard (5) draft-mathis-ippm-model-based-metrics-01 Mon Year - Submit draft on model-based TCP bulk transfer capacity = metrics to IESG as Proposed Standard (6) draft-ko-ippm-streaming-performance-00 Mon Year - Submit draft on model-based streaming performance metrics=20 to IESG as Proposed Standard (7) draft-bi-ippm-ipsec-01 Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed = Standard With respect to the following milestone, there are two drafts, which we = would presume would be unified through the working group process; it's = not necessary at this time to indicate which approach you support. (8) draft-bagnulo-ippm-new-registry-00, = draft-bagnulo-ippm-new-registry-independent-00 Mon Year - Submit draft on metrics registry to IESG as Proposed Standard I'd like to try to evaluate consensus on adoption on each draft by next = Wednesday, April 3, absent continuing discussion. Many thanks, best regards, Brian [Charter text follows] IP Performance Metrics (ippm) ----------------------------- Charter Current Status: Active Chairs: Brian Trammell=20 Bill Cerveny =20 Transport Area Directors: Martin Stiemerling Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: http://www.ietf.org/mail-archive/web/ippm Description of Working Group: The IP Performance Metrics (IPPM) Working Group develops and maintains = standard metrics that can be applied to the quality, performance, and reliability = of Internet data delivery services and applications. It also develops and maintains protocols for the measurement of these metrics. These metrics = are designed such that they can be used by network operators, end users, or independent testing groups. Metrics developed by the IPPM WG are = intended to provide unbiased quantitative performance measurements and not a value judgement. The IPPM WG has produced documents that define specific metrics and = procedures for accurately measuring and documenting these metrics. The working = group will continue advancing these metrics along the standards track, using the guidelines stated in RFC 6576. To the extent possible, these metrics = will be used as the basis for future work on metrics in the WG. The WG will develop the minimum number of new metrics and models needed = to more accurately quantitatively characterize the network path(s) under test = and/or the performance of transport and application layer protocols on these = path(s). New metric definitions will state how the definition improves on an = existing metric definition, or assesses a property of network performance not = previously covered by a defined metric. Additional methods will be defined for the composition and calibration = of IPPM-defined metrics, as well as active, passive and hybrid measurement = methods for these metrics. In addition, the WG encourages work which describes = the applicability of metrics and measurement methods, especially to improve understanding of the tradeoffs involved among active, passive, and = hybrid methods. The WG may update its core framework RFC 2330 as necessary to = accommodate these activities. The WG has produced protocols for communication among test equipment to = enable the measurement of the one- and two-way metrics (OWAMP and TWAMP = respectively). These protocols will be advanced along the standards track. The WG will = further develop and improve these protocols. The WG may develop new measurement protocols as necessary to support new metrics. New metric and protocol development will focus on the suitability of measurements for = automation, in order to support large-scale measurement efforts. Agreement about the definitions of metrics and methods of measurement = enables accurate, reproducible, and equivalent results across different implementations. To this end, the WG will define and maintain a registry = of metric definitions. The WG encourages work which assesses the = comparability of measurements of IPPM metrics with metrics developed elsewhere. The WG = also encourages work which improves the availability of information about the context in which measurements were taken. The IPPM WG seeks cooperation with other appropriate standards bodies = and forums to promote consistent approaches and metrics. Within the IETF = process, IPPM metric definitions and measurement protocols will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other = protocol standards. The IPPM WG will interact with other areas of IETF activity = whose scope intersects with the requirement of these specific metrics. The WG = will, on request, provide input to other IETF working groups on the use and implementation of these metrics. Milestones: Mon Year - Submit draft on access rate measurement protocol problem = statement to IESG as Informational Mon Year - Submit draft on RFC 2680 standards-track advancement testing to IESG as Informational =20= From dromasca@avaya.com Thu Mar 28 01:17:56 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C5E21F9063; Thu, 28 Mar 2013 01:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtlzAOxzIYQz; Thu, 28 Mar 2013 01:17:54 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2324121F90F1; Thu, 28 Mar 2013 01:17:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALh+MVGHCzI1/2dsb2JhbABEgma/XoEAFnOCIQEBAxIoPxIBFRUUQiYBBAENDRqHcQELpBycPwSNdmIUMYJmYQOcXINPBIZ/gwiCJw X-IronPort-AV: E=Sophos;i="4.84,766,1355115600"; d="scan'208";a="4041313" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 28 Mar 2013 04:17:49 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Mar 2013 04:15:38 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Thu, 28 Mar 2013 04:17:46 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" , "ippm@ietf.org" Thread-Topic: incoming liaison statement from IEEE Project P802.16.3 Thread-Index: Ac4rjLnfWpFw/p7tS3i28o1yTrXHQw== Date: Thu, 28 Mar 2013 08:17:46 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Roger Marks , "ops-ads@tools.ietf.org" Subject: [ippm] incoming liaison statement from IEEE Project P802.16.3 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 08:17:57 -0000 Hi, Please note the following incoming liaison statement from IEEE Project P802= .16.3 concerning the LMAP activity.=20 https://datatracker.ietf.org/liaison/1244/ Comments and discussions are welcome.=20 Regards, Dan From mattmathis@google.com Thu Mar 28 15:57:35 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E060121F8F0D for ; Thu, 28 Mar 2013 15:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMzPJ-J4YnEu for ; Thu, 28 Mar 2013 15:57:35 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 51F0521F8F0B for ; Thu, 28 Mar 2013 15:57:32 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id c12so53949ieb.6 for ; Thu, 28 Mar 2013 15:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=xJYs910x6K4tMHyW4xX4mPZGavZRuO3ZXgqALUsV2lc=; b=ThVv61BkDedx5qwYQ72jTC9Dt+T3B4HcFG83Cn2daUtRRVbgTIzQclnIzEurcFqBvW H2rZ9Sx535rauTAdkueSz7mo09wxGJL5RU2iLRZpcgZsh+BattioQJSViCYs1StFk+E1 Lf3+jdBJMiIAc/PD8dlsn3Dj3s9A6yv2AE8AX+kSbZZa/PJN/VW/po+kcKMqAJW5RN7e wDHkttCVb+Ohrnn1if0WKIXH7VudZQ5rAx5fTt9btwfbbPPVFKQ/DGa8OKPpHKv9MSrw kRlrnPEHKBh9hteL2rzDy/+28diOuz5b/SSalQSh5XhH0qwKXRn5GVIxaTHThSPqXiIo mDLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=xJYs910x6K4tMHyW4xX4mPZGavZRuO3ZXgqALUsV2lc=; b=MAfnvOtMmtk6ZRw0aMCoj82ojPw+2q1TAQQpjazNnzW9gJ2anDZnow+H3cXM5gxYk1 MuXoXu2FBarc7FcLELFTJ9NxfHUnC0jApBLFNHUrrHA9F3//u0Fie9mElm5bgIKCVdeI n9SjPIjzs1PnzOUSpAwvFUXpHL+4oFZa8VD7SoAd8XYRxj3rBgs0WJk0ZwmrSYvOFG7w 9ZD1YOAkH+SeUeE48/PxFEsq0nHkicSFVTWARZo9zjoUpHpI6EMPBfQoakFZmpHLjoHo mXPvy1OxToCODRRwvmsvHQz8py0j/TfW5QtEBhSYFrCcp5XIOFF+OTOSr8e8eWgakxGn 9nvg== MIME-Version: 1.0 X-Received: by 10.50.13.228 with SMTP id k4mr8401438igc.30.1364511451849; Thu, 28 Mar 2013 15:57:31 -0700 (PDT) Received: by 10.64.92.194 with HTTP; Thu, 28 Mar 2013 15:57:31 -0700 (PDT) Date: Thu, 28 Mar 2013 15:57:31 -0700 Message-ID: From: Matt Mathis To: "ippm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlqsuKUHaLm33YlSIEXDA1yFIGXWrc6KXCbPAvVDDZ21oVSqo1kDXA2MqE4230eNbJUt405StpRMsuA8fg/bR9HYyP1oNq1O3LMWtIUh2T4OQdO3FW31dn0C2KJQfOMOXQnCo2DeUOLM3j8oLBhAXVpR7qEQaLsOioIb3tx48yYKfT2KVWrnv6A+yLVw0tPhGEnjMsE Subject: [ippm] Looking for better terminology for Model Based Metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 22:57:36 -0000 Model Based Metrics over uses the term "test", and I am having troubles finding an alternative that I am like. I am currently using "a single property test", which has a pass/fail/inconclusive result. In medicine a "diagnostic (test)" is generally for the presence of an adverse condition. e.g. you do not want to hear "your diabetes test was positive". Although it is binary, the sense is inverted. Using the same pattern for MBM would require that tests identified by the failure condition e.g. " a diagnostic test to detect insufficient buffer space," and a positive test result would indicate a failure... Further complicating the issue the word "diagnose" means to identify the underlying problem. This is generally true for communications and networking diagnostics: they indicate why something failed - the results are not binary. (In medicine diagnostics are generally used to eliminate possible causes of a symptom, and less likely to indicate why). Other phrases, such as acceptance tests, have specific (and clashing) meanings in some contexts. Suggestions anybody? Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. From ken.ko@adtran.com Fri Mar 29 05:47:27 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C8421F93FE for ; Fri, 29 Mar 2013 05:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrQd+BUN+xAA for ; Fri, 29 Mar 2013 05:47:23 -0700 (PDT) Received: from p02c12o145.mxlogic.net (p02c12o145.mxlogic.net [208.65.145.78]) by ietfa.amsl.com (Postfix) with ESMTP id C1A3B21F93FD for ; Fri, 29 Mar 2013 05:47:22 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c12o145.mxlogic.net(mxl_mta-7.0.0-1) with ESMTP id a5d85515.2aaac0a02940.35780.00-570.86533.p02c12o145.mxlogic.net (envelope-from ); Fri, 29 Mar 2013 06:47:22 -0600 (MDT) X-MXL-Hash: 51558d5a4870a827-98c275a60f4d30ebb8902861805f7b07e14fa16e Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c12o145.mxlogic.net(mxl_mta-7.0.0-1) over TLS secured channel with ESMTP id 13d85515.0.35584.00-373.86007.p02c12o145.mxlogic.net (envelope-from ); Fri, 29 Mar 2013 06:47:20 -0600 (MDT) X-MXL-Hash: 51558d580a5237e2-cca261619e14abcd919b9d8206a8be463c132fbb Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::d50f:ceda:4e38:ebf0%14]) with mapi id 14.01.0438.000; Fri, 29 Mar 2013 07:46:40 -0500 From: KEN KO To: Guangqing Deng Thread-Topic: RE: [ippm] FW: New Version Notification for draft-ko-ippm-streaming-performance-00.txt Thread-Index: Ac4OP6doC0aeTAg0QxucUfNonLQELgHix5f/BZjGuikAExga8A== Date: Fri, 29 Mar 2013 12:46:39 +0000 Message-ID: References: <201302282346248720930@cnnic.cn>, <201303291131077845893@cnnic.cn> In-Reply-To: <201303291131077845893@cnnic.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.115.99] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB70460DBDCexmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=Z55b6gtA c=1 sm=1 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a] X-AnalysisOut: [=dnTLtdYZaPoA:10 a=3S_EiGSXC3EA:10 a=qZHQZMT3apYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=XOpkfcTC] X-AnalysisOut: [HjIA:10 a=48vgC7mUAAAA:8 a=KUgvJI_x6FxlutphJ6UA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=rgn2_BMLILUA:10 a=lZB815dzVvQA:10 a=DvnSUQUdWH] X-AnalysisOut: [YA:10 a=MMgaouAc07iZzPUo:21 a=xwgvsz6WXPfO1M1J:21 a=yMhMjl] X-AnalysisOut: [ubAAAA:8 a=SSmOFEACAAAA:8 a=4VCPXKp343du4F1CAEoA:9 a=gKO2H] X-AnalysisOut: [q4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-] X-AnalysisOut: [hUA:10 a=84p_ck12gkSNnzv2:21 a=g9ZXNFJD4P4an0NA:21 a=D5NpH] X-AnalysisOut: [wG0-KH86dRQ:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Cc: "ippm@ietf.org" Subject: Re: [ippm] FW: New Version Notification for draft-ko-ippm-streaming-performance-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 12:47:27 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB70460DBDCexmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think what you suggest (which I agree with) is already reflected in the m= odel behavior. The initial model state is FILL_NOPLAY. In that state, recei= ved content is written to the buffer but nothing is played out until the st= ate transition to either FILL_PLAY or MAINTAIN. That initial state (FILL_NO= PLAY) represents the period of time you describe, in which content is being= downloaded but the video has not yet started to play. One thing the current draft is missing is figures, which would have made th= e above description much clearer. I need to learn to draw using ASCII chara= cters! From: Guangqing Deng [mailto:dengguangqing@cnnic.cn] Sent: Thursday, March 28, 2013 10:31 PM To: KEN KO Cc: ippm@ietf.org Subject: Re: RE: [ippm] FW: New Version Notification for draft-ko-ippm-stre= aming-performance-00.txt Hi, Ken, for the model, I have a small suggestion regarding to the Initial = Buffer State. In this draft, the Initial Buffer State is set to 0 and that = is OK for the model. However, it seems that the Initial Buffer State is usu= ally larger than 0 in actual situations. It is found that for most on-line = video providers (at least those in China, such as Youku, Tudou, PPLive, etc= .), there is a small period of time (usually several seconds) for commercia= l advertisement before the media content is played on the side of end users= . And in such period of time, the media content is being downloaded from th= e server to the end user and then the dejitter buffer is being filled. So w= hen the playback really starts (after the advertisement is finished), the d= ejitter buffer is not empty but has some amount of media content in it. So = maybe we can take the scenario of the Initial Buffer State being nonzero in= to consideration. And it seems interesting to compare the streaming perform= ance in such two different scenarios. ________________________________ Guangqing Deng CNNIC From: KEN KO Date: 2013-03-01 03:05 To: dengguangqing CC: ippm Subject: RE: [ippm] FW: New Version Notification for draft-ko-ippm-streamin= g-performance-00.txt Thanks for this comment. I agree that VBR encoding is typically used and th= at is frequently reflected in the short-term average rate of the video stre= am. There are also a couple of differences between the model and actual streams= that you didn't mention but are probably aware of. First, most protocols u= sed for streaming result in the stream being delivered in bursts rather tha= n as individually spaced packets. Second, many streams are available at mul= tiple encoded rates and support adaptive switching between the rates based = on the receiver's determination of variable performance in the network chan= nel. I alluded to some of the above items in the "Additional Topics" sectio= n. With regard to VBR C the variation in encoded rate would cause correspondin= g variation in the rate at which the dejitter buffer is drained, which woul= d in turn affect the Dejitter-Buffer-Fill sample metric. Whether this chang= e would better reflect actual performance depends on how well a change in t= he model represents actual VBR behavior. The current proposal uses the long= term average (essentially a CBR model) as what seems to be a necessary sim= plification, since modeling the variation in VBR strikes me as a somewhat d= aunting task, but if a model enhancement could be shown to be both represen= tative and manageable I would welcome it. With regard to bursting C I have captured many actual streams and when ther= e the network performance is significantly higher than that required to del= iver the video stream, this bursting deviates significantly from the model.= However, when the network performance is close to the required performance= to support the video, the bursts are spread over time by the network. When= network performance equals required performance, the bursts merge into eac= h other and appear as a continuous stream at the destination. So the less m= argin there is in network performance (meaning, usually, the more interesti= ng the test case), the closer the model approximates actual streaming behav= ior. With regard to adaptive streaming, the model could be enhanced to simulate = this, but this probably requires discussion with regard to whether it is ap= propriate. As it is, the metrics generated by the methodology can be descri= bed in terms of a small set of parameters including a "streaming rate." Onc= e adaptive streaming is modeled, I think it may become more difficult to ex= press the resulting metrics in intuitive terms. I'll have a brief presentation in Orlando that will touch on these topics. = Will you be there? Best regards, Ken From: Guangqing Deng [mailto:dengguangqing@cnnic.cn] Sent: Thursday, February 28, 2013 10:46 AM To: KEN KO Cc: ippm Subject: Re: [ippm] FW: New Version Notification for draft-ko-ippm-streamin= g-performance-00.txt Hi, Ken, I am also interested in the modeling of streaming performance and = have you ever done any actual network measurement to verify the accuracy of= the streaming performance model in this draft? Usually, to ensure constant= image quality, the VBR (Variable Bit Rate) coding method is used and then = the streaming rate is always time-varying. Then is it necessary to take the= dynamics of streaming rate into consideration for the streaming performanc= e model? ________________________________ Guangqing Deng cnnic From: KEN KO Date: 2013-02-19 09:30 To: ippm@ietf.org Subject: [ippm] FW: New Version Notification for draft-ko-ippm-streaming-pe= rformance-00.txt IPPM, Here is a new I-D relating to testing for streaming performance. Instead of= sending a stream to directly test one condition, it applies a streaming mo= del to metrics from TCP throughput testing to estimate performance for any = number of conditions. Comments are welcome. Regards, Ken Ko -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Monday, February 18, 2013 1:50 PM To: KEN KO Subject: New Version Notification for draft-ko-ippm-streaming-performance-0= 0.txt A new version of I-D, draft-ko-ippm-streaming-performance-00.txt has been successfully submitted by Ken Ko and posted to the IETF repository= . Filename: draft-ko-ippm-streaming-performance Revision: 00 Title: Model-Based Estimation of Streaming Performance Creation date: 2013-02-18 Group: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-ko-ippm-streamin= g-performance-00.txt Status: http://datatracker.ietf.org/doc/draft-ko-ippm-streaming-pe= rformance Htmlized: http://tools.ietf.org/html/draft-ko-ippm-streaming-perform= ance-00 Abstract: This memo defines metrics plus a methodology for post-measurement processing of sample metrics to evaluate network path performance relative to streaming video traffic. The metrics are based on established methodologies for TCP throughput testing. The post- processing methodology is based on a model of streaming traffic that allows a given sample metric to be evaluated against multiple sets of parameters representing different streaming rates, delays and buffering values. The results of the post-processing methodology are derived metrics that are suitable for statistical analysis. The IETF Secretariat _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_D14B7E40AEBFD54EA3AD964902DD7CB70460DBDCexmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think what you suggest = (which I agree with) is already reflected in the model behavior. The initia= l model state is FILL_NOPLAY. In that state, received content is written to the buffer but nothing is played out until the state transit= ion to either FILL_PLAY or MAINTAIN. That initial state (FILL_NOPLAY) repre= sents the period of time you describe, in which content is being downloaded= but the video has not yet started to play.

One thing the current dra= ft is missing is figures, which would have made the above description much = clearer. I need to learn to draw using ASCII characters!<= /p>

 <= /p>

From: Guangqing Deng [mailto:dengguangqing@cnn= ic.cn]
Sent: Thursday, March 28, 2013 10:31 PM
To: KEN KO
Cc: ippm@ietf.org
Subject: Re: RE: [ippm] FW: New Version Notification for draft-ko-ip= pm-streaming-performance-00.txt

 

Hi, Ken, f= or the model, I have a small suggestion regarding to the Initial Buffer Sta= te. In this draft, the Initial Buffer State is set to 0 and that is OK for the model. However, it seems that the Initial Buffer State = is usually larger than 0 in actual situations. It is found that for most on= -line video providers (at least those in China, such as Youku, Tudou, PPLiv= e, etc.), there is a small period of time (usually several seconds) for commercial advertisement before the = media content is played on the side of end users. And in such period of tim= e, the media content is being downloaded from the server to the end user an= d then the dejitter buffer is being filled. So when the playback really starts (after the advertisement is fin= ished), the dejitter buffer is not empty but has some amount of media conte= nt in it. So maybe we can take the scenario of the Initial Buffer State bei= ng nonzero into consideration. And it seems interesting to compare the streaming performance in such two diff= erent scenarios.

 

Guangqing Deng

CNNIC 

 

From: KEN KO

Date: 20= 13-03-01 03:05

CC: ippm

Subject: = RE: [ippm] FW: New Version Notification for draft-ko-ippm-streaming-perform= ance-00.txt

Thanks for this comment. I a= gree that VBR encoding is typically used and that is frequently reflected i= n the short-term average rate of the video stream.

There are also a couple of d= ifferences between the model and actual streams that you didn’t menti= on but are probably aware of. First, most protocols used for streaming result in the stream being delivered in bursts rather than as individually= spaced packets. Second, many streams are available at multiple encoded rat= es and support adaptive switching between the rates based on the receiver&#= 8217;s determination of variable performance in the network channel. I alluded to some of the above items in the “= ;Additional Topics” section.

With regard to VBR C the var= iation in encoded rate would cause corresponding variation in the rate at w= hich the dejitter buffer is drained, which would in turn affect the Dejitter-Buffer-Fill sample metric. Whether this change would better r= eflect actual performance depends on how well a change in the model represe= nts actual VBR behavior. The current proposal uses the long term average (e= ssentially a CBR model) as what seems to be a necessary simplification, since modeling the variation in VB= R strikes me as a somewhat daunting task, but if a model enhancement could = be shown to be both representative and manageable I would welcome it.

With regard to bursting C I = have captured many actual streams and when there the network performance is= significantly higher than that required to deliver the video stream, this bursting deviates significantly from the model. However, when= the network performance is close to the required performance to support th= e video, the bursts are spread over time by the network. When network perfo= rmance equals required performance, the bursts merge into each other and appear as a continuous stream at the = destination. So the less margin there is in network performance (meaning, u= sually, the more interesting the test case), the closer the model approxima= tes actual streaming behavior.

With regard to adaptive stre= aming, the model could be enhanced to simulate this, but this probably requ= ires discussion with regard to whether it is appropriate. As it is, the metrics generated by the methodology can be described in terms = of a small set of parameters including a “streaming rate.” Once= adaptive streaming is modeled, I think it may become more difficult to exp= ress the resulting metrics in intuitive terms.

I’ll have a brief pres= entation in Orlando that will touch on these topics. Will you be there?

Best regards,

Ken

From: Guangqing Deng [mailto:dengguangqing@cnnic.cn]
Sent: Thursday, February 28, 2013 10:46 AM
To: KEN KO
Cc: ippm
Subject: Re: [ippm] FW: New Version Notification for draft-ko-ippm-s= treaming-performance-00.txt

 

Hi, Ken, I am also interested in the m= odeling of streaming performance and have you ever done any actual network = measurement to verify the accuracy of the streaming performance model in this draft? U= sually, to ensure constant image quality, the VBR (Variable Bit Rate) codin= g method is used and then the streaming rate is always time-varying. Then i= s it necessary to take the dynamics of streaming rate into consideration for the streaming performance model?<= /span>

 

Guangqing Deng
cnnic 

 

From: KEN KO

Date: 2013-02-= 19 09:30

Subject: [ippm= ] FW: New Version Notification for draft-ko-ippm-streaming-performance-00.t= xt

IPPM, 

 

Here is a new I-D relating to&nbs= p;testing for streaming performance. Instead of&nb= sp;sending a stream to directly test one = ;condition, it applies a streaming model to&n= bsp;metrics from TCP throughput testing to es= timate performance for any number of conditio= ns. Comments are welcome.

 

Regards,

Ken Ko

 

-----Original Message-----

Sent: Monday, February 18, 2013 1:50&n= bsp;PM

To: KEN KO

Subject: New Version Notification for = draft-ko-ippm-streaming-performance-00.txt

 

 

A new version of I-D, draft-ko-ippm-st= reaming-performance-00.txt

has been successfully submitted by Ken=  Ko and posted to the IETF repository.

 

Filename:  draft-ko-ippm-streaming-performance<= /span>

Revision:  00

Title:  Model-Based Estimation of Streaming=  Performance

Creation date:  2013-02-18

Group:  Individual Submission

Number of pages: 18

 

 

Abstract:

   This memo defines metrics = ;plus a methodology for post-measurement

   processing of sample metrics&n= bsp;to evaluate network path performance

   relative to streaming video&nb= sp;traffic. The metrics are based on

   established methodologies for = TCP throughput testing. The post-

   processing methodology is base= d on a model of streaming traffic that

   allows a given sample met= ric to be evaluated against multiple sets

   of parameters representing dif= ferent streaming rates, delays and

   buffering values. The results&= nbsp;of the post-processing methodology are<= /span>

   derived metrics that are = suitable for statistical analysis.

 

          &nb= sp;            =             &nb= sp;            =             &nb= sp;            =          

 

 

The IETF Secretariat

 

_______________________________________________

ippm mailing list

--_000_D14B7E40AEBFD54EA3AD964902DD7CB70460DBDCexmb1corpadtran_-- From dengguangqing@cnnic.cn Thu Mar 28 20:31:30 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A912421F8E66 for ; Thu, 28 Mar 2013 20:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.706 X-Spam-Level: X-Spam-Status: No, score=0.706 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7goKCfV95MUK for ; Thu, 28 Mar 2013 20:31:29 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 7D6F421F8E5E for ; Thu, 28 Mar 2013 20:31:18 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 29 Mar 2013 11:31:10 +0800 Date: Fri, 29 Mar 2013 11:31:08 +0800 From: "Guangqing Deng" To: "KEN KO" References: <201302282346248720930@cnnic.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201303291131077845893@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart153111674755_=----" X-Mailman-Approved-At: Fri, 29 Mar 2013 12:58:10 -0700 Cc: "ippm@ietf.org" Subject: Re: [ippm] FW: New Version Notification for draft-ko-ippm-streaming-performance-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 03:31:30 -0000 This is a multi-part message in MIME format. ------=_001_NextPart153111674755_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEtlbiwgZm9yIHRoZSBtb2RlbCwgSSBoYXZlIGEgc21hbGwgc3VnZ2VzdGlvbiByZWdhcmRp bmcgdG8gdGhlIEluaXRpYWwgQnVmZmVyIFN0YXRlLiBJbiB0aGlzIGRyYWZ0LCB0aGUgSW5pdGlh bCBCdWZmZXIgU3RhdGUgaXMgc2V0IHRvIDAgYW5kIHRoYXQgaXMgT0sgZm9yIHRoZSBtb2RlbC4g SG93ZXZlciwgaXQgc2VlbXMgdGhhdCB0aGUgSW5pdGlhbCBCdWZmZXIgU3RhdGUgaXMgdXN1YWxs eSBsYXJnZXIgdGhhbiAwIGluIGFjdHVhbCBzaXR1YXRpb25zLiBJdCBpcyBmb3VuZCB0aGF0IGZv ciBtb3N0IG9uLWxpbmUgdmlkZW8gcHJvdmlkZXJzIChhdCBsZWFzdCB0aG9zZSBpbiBDaGluYSwg c3VjaCBhcyBZb3VrdSwgVHVkb3UsIFBQTGl2ZSwgZXRjLiksIHRoZXJlIGlzIGEgc21hbGwgcGVy aW9kIG9mIHRpbWUgKHVzdWFsbHkgc2V2ZXJhbCBzZWNvbmRzKSBmb3IgY29tbWVyY2lhbCBhZHZl cnRpc2VtZW50IGJlZm9yZSB0aGUgbWVkaWEgY29udGVudCBpcyBwbGF5ZWQgb24gdGhlIHNpZGUg b2YgZW5kIHVzZXJzLiBBbmQgaW4gc3VjaCBwZXJpb2Qgb2YgdGltZSwgdGhlIG1lZGlhIGNvbnRl bnQgaXMgYmVpbmcgZG93bmxvYWRlZCBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGVuZCB1c2VyIGFu ZCB0aGVuIHRoZSBkZWppdHRlciBidWZmZXIgaXMgYmVpbmcgZmlsbGVkLiBTbyB3aGVuIHRoZSBw bGF5YmFjayByZWFsbHkgc3RhcnRzIChhZnRlciB0aGUgYWR2ZXJ0aXNlbWVudCBpcyBmaW5pc2hl ZCksIHRoZSBkZWppdHRlciBidWZmZXIgaXMgbm90IGVtcHR5IGJ1dCBoYXMgc29tZSBhbW91bnQg b2YgbWVkaWEgY29udGVudCBpbiBpdC4gU28gbWF5YmUgd2UgY2FuIHRha2UgdGhlIHNjZW5hcmlv IG9mIHRoZSBJbml0aWFsIEJ1ZmZlciBTdGF0ZSBiZWluZyBub256ZXJvIGludG8gY29uc2lkZXJh dGlvbi4gQW5kIGl0IHNlZW1zIGludGVyZXN0aW5nIHRvIGNvbXBhcmUgdGhlIHN0cmVhbWluZyBw ZXJmb3JtYW5jZSBpbiBzdWNoIHR3byBkaWZmZXJlbnQgc2NlbmFyaW9zLg0KDQoNCg0KDQpHdWFu Z3FpbmcgRGVuZw0KQ05OSUMgDQoNCkZyb206IEtFTiBLTw0KRGF0ZTogMjAxMy0wMy0wMSAwMzow NQ0KVG86IGRlbmdndWFuZ3FpbmcNCkNDOiBpcHBtDQpTdWJqZWN0OiBSRTogW2lwcG1dIEZXOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZv cm1hbmNlLTAwLnR4dA0KVGhhbmtzIGZvciB0aGlzIGNvbW1lbnQuIEkgYWdyZWUgdGhhdCBWQlIg ZW5jb2RpbmcgaXMgdHlwaWNhbGx5IHVzZWQgYW5kIHRoYXQgaXMgZnJlcXVlbnRseSByZWZsZWN0 ZWQgaW4gdGhlIHNob3J0LXRlcm0gYXZlcmFnZSByYXRlIG9mIHRoZSB2aWRlbyBzdHJlYW0uIA0K VGhlcmUgYXJlIGFsc28gYSBjb3VwbGUgb2YgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgbW9kZWwg YW5kIGFjdHVhbCBzdHJlYW1zIHRoYXQgeW91IGRpZG6hr3QgbWVudGlvbiBidXQgYXJlIHByb2Jh Ymx5IGF3YXJlIG9mLiBGaXJzdCwgbW9zdCBwcm90b2NvbHMgdXNlZCBmb3Igc3RyZWFtaW5nIHJl c3VsdCBpbiB0aGUgc3RyZWFtIGJlaW5nIGRlbGl2ZXJlZCBpbiBidXJzdHMgcmF0aGVyIHRoYW4g YXMgaW5kaXZpZHVhbGx5IHNwYWNlZCBwYWNrZXRzLiBTZWNvbmQsIG1hbnkgc3RyZWFtcyBhcmUg YXZhaWxhYmxlIGF0IG11bHRpcGxlIGVuY29kZWQgcmF0ZXMgYW5kIHN1cHBvcnQgYWRhcHRpdmUg c3dpdGNoaW5nIGJldHdlZW4gdGhlIHJhdGVzIGJhc2VkIG9uIHRoZSByZWNlaXZlcqGvcyBkZXRl cm1pbmF0aW9uIG9mIHZhcmlhYmxlIHBlcmZvcm1hbmNlIGluIHRoZSBuZXR3b3JrIGNoYW5uZWwu IEkgYWxsdWRlZCB0byBzb21lIG9mIHRoZSBhYm92ZSBpdGVtcyBpbiB0aGUgobBBZGRpdGlvbmFs IFRvcGljc6GxIHNlY3Rpb24uDQpXaXRoIHJlZ2FyZCB0byBWQlIgqEMgdGhlIHZhcmlhdGlvbiBp biBlbmNvZGVkIHJhdGUgd291bGQgY2F1c2UgY29ycmVzcG9uZGluZyB2YXJpYXRpb24gaW4gdGhl IHJhdGUgYXQgd2hpY2ggdGhlIGRlaml0dGVyIGJ1ZmZlciBpcyBkcmFpbmVkLCB3aGljaCB3b3Vs ZCBpbiB0dXJuIGFmZmVjdCB0aGUgRGVqaXR0ZXItQnVmZmVyLUZpbGwgc2FtcGxlIG1ldHJpYy4g V2hldGhlciB0aGlzIGNoYW5nZSB3b3VsZCBiZXR0ZXIgcmVmbGVjdCBhY3R1YWwgcGVyZm9ybWFu Y2UgZGVwZW5kcyBvbiBob3cgd2VsbCBhIGNoYW5nZSBpbiB0aGUgbW9kZWwgcmVwcmVzZW50cyBh Y3R1YWwgVkJSIGJlaGF2aW9yLiBUaGUgY3VycmVudCBwcm9wb3NhbCB1c2VzIHRoZSBsb25nIHRl cm0gYXZlcmFnZSAoZXNzZW50aWFsbHkgYSBDQlIgbW9kZWwpIGFzIHdoYXQgc2VlbXMgdG8gYmUg YSBuZWNlc3Nhcnkgc2ltcGxpZmljYXRpb24sIHNpbmNlIG1vZGVsaW5nIHRoZSB2YXJpYXRpb24g aW4gVkJSIHN0cmlrZXMgbWUgYXMgYSBzb21ld2hhdCBkYXVudGluZyB0YXNrLCBidXQgaWYgYSBt b2RlbCBlbmhhbmNlbWVudCBjb3VsZCBiZSBzaG93biB0byBiZSBib3RoIHJlcHJlc2VudGF0aXZl IGFuZCBtYW5hZ2VhYmxlIEkgd291bGQgd2VsY29tZSBpdC4gDQpXaXRoIHJlZ2FyZCB0byBidXJz dGluZyCoQyBJIGhhdmUgY2FwdHVyZWQgbWFueSBhY3R1YWwgc3RyZWFtcyBhbmQgd2hlbiB0aGVy ZSB0aGUgbmV0d29yayBwZXJmb3JtYW5jZSBpcyBzaWduaWZpY2FudGx5IGhpZ2hlciB0aGFuIHRo YXQgcmVxdWlyZWQgdG8gZGVsaXZlciB0aGUgdmlkZW8gc3RyZWFtLCB0aGlzIGJ1cnN0aW5nIGRl dmlhdGVzIHNpZ25pZmljYW50bHkgZnJvbSB0aGUgbW9kZWwuIEhvd2V2ZXIsIHdoZW4gdGhlIG5l dHdvcmsgcGVyZm9ybWFuY2UgaXMgY2xvc2UgdG8gdGhlIHJlcXVpcmVkIHBlcmZvcm1hbmNlIHRv IHN1cHBvcnQgdGhlIHZpZGVvLCB0aGUgYnVyc3RzIGFyZSBzcHJlYWQgb3ZlciB0aW1lIGJ5IHRo ZSBuZXR3b3JrLiBXaGVuIG5ldHdvcmsgcGVyZm9ybWFuY2UgZXF1YWxzIHJlcXVpcmVkIHBlcmZv cm1hbmNlLCB0aGUgYnVyc3RzIG1lcmdlIGludG8gZWFjaCBvdGhlciBhbmQgYXBwZWFyIGFzIGEg Y29udGludW91cyBzdHJlYW0gYXQgdGhlIGRlc3RpbmF0aW9uLiBTbyB0aGUgbGVzcyBtYXJnaW4g dGhlcmUgaXMgaW4gbmV0d29yayBwZXJmb3JtYW5jZSAobWVhbmluZywgdXN1YWxseSwgdGhlIG1v cmUgaW50ZXJlc3RpbmcgdGhlIHRlc3QgY2FzZSksIHRoZSBjbG9zZXIgdGhlIG1vZGVsIGFwcHJv eGltYXRlcyBhY3R1YWwgc3RyZWFtaW5nIGJlaGF2aW9yLg0KV2l0aCByZWdhcmQgdG8gYWRhcHRp dmUgc3RyZWFtaW5nLCB0aGUgbW9kZWwgY291bGQgYmUgZW5oYW5jZWQgdG8gc2ltdWxhdGUgdGhp cywgYnV0IHRoaXMgcHJvYmFibHkgcmVxdWlyZXMgZGlzY3Vzc2lvbiB3aXRoIHJlZ2FyZCB0byB3 aGV0aGVyIGl0IGlzIGFwcHJvcHJpYXRlLiBBcyBpdCBpcywgdGhlIG1ldHJpY3MgZ2VuZXJhdGVk IGJ5IHRoZSBtZXRob2RvbG9neSBjYW4gYmUgZGVzY3JpYmVkIGluIHRlcm1zIG9mIGEgc21hbGwg c2V0IG9mIHBhcmFtZXRlcnMgaW5jbHVkaW5nIGEgobBzdHJlYW1pbmcgcmF0ZS6hsSBPbmNlIGFk YXB0aXZlIHN0cmVhbWluZyBpcyBtb2RlbGVkLCBJIHRoaW5rIGl0IG1heSBiZWNvbWUgbW9yZSBk aWZmaWN1bHQgdG8gZXhwcmVzcyB0aGUgcmVzdWx0aW5nIG1ldHJpY3MgaW4gaW50dWl0aXZlIHRl cm1zLg0KSaGvbGwgaGF2ZSBhIGJyaWVmIHByZXNlbnRhdGlvbiBpbiBPcmxhbmRvIHRoYXQgd2ls bCB0b3VjaCBvbiB0aGVzZSB0b3BpY3MuIFdpbGwgeW91IGJlIHRoZXJlPw0KQmVzdCByZWdhcmRz LA0KS2VuDQpGcm9tOiBHdWFuZ3FpbmcgRGVuZyBbbWFpbHRvOmRlbmdndWFuZ3FpbmdAY25uaWMu Y25dIA0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI4LCAyMDEzIDEwOjQ2IEFNDQpUbzogS0VO IEtPDQpDYzogaXBwbQ0KU3ViamVjdDogUmU6IFtpcHBtXSBGVzogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1rby1pcHBtLXN0cmVhbWluZy1wZXJmb3JtYW5jZS0wMC50eHQNCiAN CkhpLCBLZW4sIEkgYW0gYWxzbyBpbnRlcmVzdGVkIGluIHRoZSBtb2RlbGluZyBvZiBzdHJlYW1p bmcgcGVyZm9ybWFuY2UgYW5kIGhhdmUgeW91IGV2ZXIgZG9uZSBhbnkgYWN0dWFsIG5ldHdvcmsg bWVhc3VyZW1lbnQgdG8gdmVyaWZ5IHRoZSBhY2N1cmFjeSBvZiB0aGUgc3RyZWFtaW5nIHBlcmZv cm1hbmNlIG1vZGVsIGluIHRoaXMgZHJhZnQ/IFVzdWFsbHksIHRvIGVuc3VyZSBjb25zdGFudCBp bWFnZSBxdWFsaXR5LCB0aGUgVkJSIChWYXJpYWJsZSBCaXQgUmF0ZSkgY29kaW5nIG1ldGhvZCBp cyB1c2VkIGFuZCB0aGVuIHRoZSBzdHJlYW1pbmcgcmF0ZSBpcyBhbHdheXMgdGltZS12YXJ5aW5n LiBUaGVuIGlzIGl0IG5lY2Vzc2FyeSB0byB0YWtlIHRoZSBkeW5hbWljcyBvZiBzdHJlYW1pbmcg cmF0ZSBpbnRvIGNvbnNpZGVyYXRpb24gZm9yIHRoZSBzdHJlYW1pbmcgcGVyZm9ybWFuY2UgbW9k ZWw/DQogDQoNCg0KDQpHdWFuZ3FpbmcgRGVuZw0KY25uaWMgDQogDQpGcm9tOiBLRU4gS08NCkRh dGU6IDIwMTMtMDItMTkgMDk6MzANClRvOiBpcHBtQGlldGYub3JnDQpTdWJqZWN0OiBbaXBwbV0g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQta28taXBwbS1zdHJlYW1pbmct cGVyZm9ybWFuY2UtMDAudHh0DQpJUFBNLCANCiANCkhlcmUgaXMgYSBuZXcgSS1EIHJlbGF0aW5n IHRvIHRlc3RpbmcgZm9yIHN0cmVhbWluZyBwZXJmb3JtYW5jZS4gSW5zdGVhZCBvZiBzZW5kaW5n IGEgc3RyZWFtIHRvIGRpcmVjdGx5IHRlc3Qgb25lIGNvbmRpdGlvbiwgaXQgYXBwbGllcyBhIHN0 cmVhbWluZyBtb2RlbCB0byBtZXRyaWNzIGZyb20gVENQIHRocm91Z2hwdXQgdGVzdGluZyB0byBl c3RpbWF0ZSBwZXJmb3JtYW5jZSBmb3IgYW55IG51bWJlciBvZiBjb25kaXRpb25zLiBDb21tZW50 cyBhcmUgd2VsY29tZS4NCiANClJlZ2FyZHMsDQpLZW4gS28NCiANCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxOCwgMjAxMyAxOjUw IFBNDQpUbzogS0VOIEtPDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZvcm1hbmNlLTAwLnR4dA0KIA0KIA0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZvcm1hbmNlLTAwLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZW4gS28gYW5kIHBvc3RlZCB0byB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KIA0KRmlsZW5hbWU6ICBkcmFmdC1rby1pcHBtLXN0cmVhbWlu Zy1wZXJmb3JtYW5jZQ0KUmV2aXNpb246ICAwMA0KVGl0bGU6ICBNb2RlbC1CYXNlZCBFc3RpbWF0 aW9uIG9mIFN0cmVhbWluZyBQZXJmb3JtYW5jZQ0KQ3JlYXRpb24gZGF0ZTogIDIwMTMtMDItMTgN Ckdyb3VwOiAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE4DQpVUkw6 ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtv LWlwcG0tc3RyZWFtaW5nLXBlcmZvcm1hbmNlLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZv cm1hbmNlDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZvcm1hbmNlLTAwDQogDQogDQpBYnN0cmFjdDoNCiAgIFRo aXMgbWVtbyBkZWZpbmVzIG1ldHJpY3MgcGx1cyBhIG1ldGhvZG9sb2d5IGZvciBwb3N0LW1lYXN1 cmVtZW50DQogICBwcm9jZXNzaW5nIG9mIHNhbXBsZSBtZXRyaWNzIHRvIGV2YWx1YXRlIG5ldHdv cmsgcGF0aCBwZXJmb3JtYW5jZQ0KICAgcmVsYXRpdmUgdG8gc3RyZWFtaW5nIHZpZGVvIHRyYWZm aWMuIFRoZSBtZXRyaWNzIGFyZSBiYXNlZCBvbg0KICAgZXN0YWJsaXNoZWQgbWV0aG9kb2xvZ2ll cyBmb3IgVENQIHRocm91Z2hwdXQgdGVzdGluZy4gVGhlIHBvc3QtDQogICBwcm9jZXNzaW5nIG1l dGhvZG9sb2d5IGlzIGJhc2VkIG9uIGEgbW9kZWwgb2Ygc3RyZWFtaW5nIHRyYWZmaWMgdGhhdA0K ICAgYWxsb3dzIGEgZ2l2ZW4gc2FtcGxlIG1ldHJpYyB0byBiZSBldmFsdWF0ZWQgYWdhaW5zdCBt dWx0aXBsZSBzZXRzDQogICBvZiBwYXJhbWV0ZXJzIHJlcHJlc2VudGluZyBkaWZmZXJlbnQgc3Ry ZWFtaW5nIHJhdGVzLCBkZWxheXMgYW5kDQogICBidWZmZXJpbmcgdmFsdWVzLiBUaGUgcmVzdWx0 cyBvZiB0aGUgcG9zdC1wcm9jZXNzaW5nIG1ldGhvZG9sb2d5IGFyZQ0KICAgZGVyaXZlZCBtZXRy aWNzIHRoYXQgYXJlIHN1aXRhYmxlIGZvciBzdGF0aXN0aWNhbCBhbmFseXNpcy4NCiANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCiANCiANClRoZSBJRVRGIFNlY3JldGFyaWF0DQogDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5n IGxpc3QNCmlwcG1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBwbQ== ------=_001_NextPart153111674755_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Ken, for the model, I have a small suggestion= =20 regarding to the Initial Buffer State. In this draft, the Initial Buffer S= tate=20 is set to 0 and that is OK for the model. However, it seems that the Initi= al=20 Buffer State is usually larger than 0 in actual situations. It is found th= at for=20 most on-line video providers (at least those in China, such as Youku, Tudo= u,=20 PPLive, etc.), there is a small period of time (usually several seconds) f= or=20 commercial advertisement before the media content is played on the side of= end=20 users. And in such period of time, the media content is being downloaded f= rom=20 the server to the end user and then the dejitter buffer is being filled. S= o when=20 the playback really starts (after the advertisement is finished), the deji= tter=20 buffer is not empty but has some amount of media content in it. So maybe w= e can=20 take the scenario of the Initial Buffer State being nonzero into considera= tion.=20 And it seems interesting to compare the streaming performance in such two=20 different scenarios.

 
Guangqing=20 Deng
CNN= IC 
 
From: KEN KO
Date: 2013-03-01 03:05
To: dengguangqing
CC: ippm
Subject: RE: [ippm] FW: New Version Notification for=20 draft-ko-ippm-streaming-performance-00.txt

Thanks=20 for this comment. I agree that VBR encoding is typically used and that is=20 frequently reflected in the short-term average rate of the video stream.=20

There=20 are also a couple of differences between the model and actual streams that= you=20 didn=A1=AFt mention but are probably aware of. First, most protocols used = for=20 streaming result in the stream being delivered in bursts rather than as=20 individually spaced packets. Second, many streams are available at multipl= e=20 encoded rates and support adaptive switching between the rates based on th= e=20 receiver=A1=AFs determination of variable performance in the network chann= el. I=20 alluded to some of the above items in the =A1=B0Additional Topics=A1=B1=20 section.

With=20 regard to VBR =A8C the variation in encoded rate would cause corresponding= =20 variation in the rate at which the dejitter buffer is drained, which would= in=20 turn affect the Dejitter-Buffer-Fill sample metric. Whether this change wo= uld=20 better reflect actual performance depends on how well a change in the mode= l=20 represents actual VBR behavior. The current proposal uses the long term av= erage=20 (essentially a CBR model) as what seems to be a necessary simplification, = since=20 modeling the variation in VBR strikes me as a somewhat daunting task, but = if a=20 model enhancement could be shown to be both representative and manageable = I=20 would welcome it.

With=20 regard to bursting =A8C I have captured many actual streams and when there= the=20 network performance is significantly higher than that required to deliver = the=20 video stream, this bursting deviates significantly from the model. However= , when=20 the network performance is close to the required performance to support th= e=20 video, the bursts are spread over time by the network. When network perfor= mance=20 equals required performance, the bursts merge into each other and appear a= s a=20 continuous stream at the destination. So the less margin there is in netwo= rk=20 performance (meaning, usually, the more interesting the test case), the cl= oser=20 the model approximates actual streaming behavior.

With=20 regard to adaptive streaming, the model could be enhanced to simulate this= , but=20 this probably requires discussion with regard to whether it is appropriate= . As=20 it is, the metrics generated by the methodology can be described in terms = of a=20 small set of parameters including a =A1=B0streaming rate.=A1=B1 Once adapt= ive streaming is=20 modeled, I think it may become more difficult to express the resulting met= rics=20 in intuitive terms.

I=A1=AFll=20 have a brief presentation in Orlando that will touch on these topics. Will= you=20 be there?

Best=20 regards,

Ken

From:= Guangqing D= eng=20 [mailto:dengguangqing@cnnic.cn]
Sent: Thursday, February 28, 20= 13=20 10:46 AM
To: KEN KO
Cc: ippm
Subject: Re: [i= ppm]=20 FW: New Version Notification for=20 draft-ko-ippm-streaming-performance-00.txt

 

Hi, = Ken, I am also=20 interested in the modeling of streaming performance and have you ever done= any=20 actual network measurement to verify the accuracy of the streaming perform= ance=20 model in this draft? Usually, to ensure constant image quality, the VBR=20 (Variable Bit Rate) coding method is used and then the streaming rate is a= lways=20 time-varying. Then is it necessary to take the dynamics of streaming rate = into=20 consideration for the streaming performance model?

 

Guangqing Deng
cnnic 

 

From: KEN KO

Date: 2013-02-19 09:30

To: ippm@ietf.org

Subject: [ippm]=20 FW: New Version Notification for=20 draft-ko-ippm-streaming-performance-00.txt

IPPM, 

 

Here is a new I-D relating to testing for streaming performance. Instead of sending a stream to directly test one condition, it applies a streaming model to metrics from TCP throughput testing to estimate performance for any number of conditions. Comments are welcome.

 

Regards,

Ken Ko

 

-----Original Message-----

From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 

Sent: Monday, February 18, 2013 1:50 PM

To: KEN KO

Subject: New Version Notification for draft-ko-ippm-streaming-performance-00.txt

 

 

A new version of I-D, draft-ko-ippm-streaming-performance-00.txt

has been successfully submitted by Ken Ko and posted to the IETF repository.

 

Filename:=20  draft-ko-ippm-streaming-performance

Revision:=20  00

Title:=20  Model-Based Estimation of Streaming Performance

Creation date:=20  2013-02-18

Group:=20  Individual Submission

Number of pages: 18

URL:           &= nbsp; http://www.ietf.org/internet-drafts/draft-ko-ippm-streaming-= performance-00.txt

Status:          = http://datatracker.ietf.org/doc/draft-ko-ippm-streaming-performance=

Htmlized:        http://tools.ietf.org/html/draft-ko-ippm-streaming-performance-00

 

 

Abstract:

   This memo defines metrics plus a methodology for post-measurement

   processing of sample metrics to evaluate network path performance

   relative to streaming video traffic. The metrics are based on

   established methodologies for TCP throughput testing. The post-

   processing methodology is based on a model of streaming traffic that

   allows a given sample metric to be evaluated against multiple sets

   of parameters representing different streaming rates, delays and

   buffering values. The results of the post-processing methodology are

   derived metrics that are suitable for statistical analysis.

 

           &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;         

 

 

The IETF Secretariat

 

_______________________________________________

ippm mailing list

ippm@ietf.org

https://www.ietf.org/m= ailman/listinfo/ippm

------=_001_NextPart153111674755_=------