From Henning.Schulzrinne@fcc.gov Fri Nov 30 15:53:14 2012 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 24A0221F866B; Fri, 30 Nov 2012 15:53:14 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH1kdURjJ2oU; Fri, 30 Nov 2012 15:53:13 -0800 (PST) Received: from dmz-mail1.fcc.gov (dmz-mail1.fcc.gov [192.104.54.105]) by ietfa.amsl.com (Postfix) with ESMTP id 1B61121F8AEA; Fri, 30 Nov 2012 15:53:12 -0800 (PST) Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas01.fccnet.win.fcc.gov ([fe80::1d27:de47:ad2e:9062%13]) with mapi id 14.01.0421.002; Fri, 30 Nov 2012 18:53:08 -0500 From: Henning Schulzrinne To: Al Morton , Matt Mathis Thread-Topic: [lmap] [ippm] Focus on Tests, Not Architectures... Thread-Index: AQHNy5XIAIpq06ASp0eBzU25n0xt15gDDoZh Date: Fri, 30 Nov 2012 23:53:08 +0000 Message-ID: References: <7.0.1.0.0.20121125083420.085ee458@att.com> , <7.0.1.0.0.20121125225022.085ee310@att.com> In-Reply-To: <7.0.1.0.0.20121125225022.085ee310@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.63] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 02 Dec 2012 13:58:10 -0800 Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [ippm] [lmap] Focus on Tests, Not Architectures... 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, 30 Nov 2012 23:53:14 -0000 One thing that I have learned through the MBA experience that it is hard to= find a single metric that addresses all use cases. For example, consumers = (and national bodies charged with consumer protection) might want to know w= hether advertised rates agree with actual rates. Unless ISPs are advertisin= g the model-based metric, it may not be as useful. For other applications, = such as VoIP, latency and packet loss for specific traffic types matter. Ha= ving a metric that is RTT-independent and uses a different traffic pattern = is not helpful in that case, as much as it might be otherwise. On a more general note, from a consumer perspective, there are probably thr= ee kinds of metrics that are useful: (a) Comparison between advertised and real-life metric, to allow fair compa= rison of different providers. (b) Relative metrics: I don't much care what the number is (it could be exp= ressed in some number between 0 and 100, rather than Mb/s or ms), but it sh= ould preserve relative ordering. If provider A is significantly better acco= rding to the metric X, I should expect my application (related to that metr= ic) to perform significantly better, even if I don't get the exact same per= formance. A rough example for that is cellular throughput: It is very unlik= ely that an individual consumer will get exactly the average throughput mea= sured by whatever entity, given geographic and device variations, but they = should still be able to pick a better-performing carrier based on that metr= ic. That's similar to Al's gas mileage example, "your mileage may vary", bu= t any Prius is still likely to get better gas mileage than a Lincoln Naviga= tor. (c) Threshold metrics: The metric should tell me whether a particular servi= ce is likely to be suitable for my need. Latency is the classical example: = If my access link has a round-trip latency of 400 ms, I may die prematurely= in a first-person-shooter game. Absolute accuracy isn't that important (sa= y, 400 vs. 420 ms), but consistent definition of the path component and oth= er attributes is. Some metrics might serve all three roles, but the emphasis differs. I would be interested in comments on the metrics that the FCC Measurement B= roadband America project uses. (a) Which ones need standardization first? (Some are already based on IPPM = RFCs, but most aren't.) (b) Which ones might be less valuable and/or should be substantially modifi= ed? See http://transition.fcc.gov/cgb/measuringbroadbandreport/2012/Technical-A= ppendix.pdf (pg. 22) for the current list. Henning ________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Al Morton = [acmorton@att.com] Sent: Monday, November 26, 2012 12:20 AM To: Matt Mathis Cc: lmap@ietf.org; Nicholas Weaver; ippm@ietf.org; Brian Trammell Subject: Re: [lmap] [ippm] Focus on Tests, Not Architectures... Matt, I think we agree that better metrics are needed for LMAP, and that ideally a metric can be applied at any point or pair of points. RFC 2330 and most IPPM metrics have a decidedly Source-to-Destination host construction. Frankly, we did a better job with arbitrary measurement points in Rec Y.1540. It's worth a look: http://www.itu.int/rec/T-REC-Y.1540/en There are many goals the new metrics could serve: - externally observable - measurable by users - easily related to user application performance - service verification - support consumer choice of ??? - etc. We need to agree on the set that are needed. While there may be some information in a measurement that covers a combination of networks, measuring more than one network is only useful when the combined network path delivers the target performance - the sunny day outcome. Otherwise, they are inconclusive, as you said in your memo. Some target performance levels only apply in the scope where they are offered. We don't really have the milk fat scenario here, unless the producer, the truck driver, the convenience store, and your home refrigerator can all add some unknown amount of fat to the milk. ;-) When considering this problem, I've been thinking of the fuel efficiency ratings provided for new cars in the US and Europe (at least). The specs illustrate very well that the quantity measured is variable depending on the conditions of the measurement (in the US, the miles per gallon for city and highway driving), and they imply the range of values that normal users can experience (a fairly wide range). These are some aspects that would be useful to reproduce in our metrics, I think. regards, and YMMV, Al From acmorton@att.com Sun Dec 2 19:04:41 2012 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 2546E21F8971; Sun, 2 Dec 2012 19:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.338 X-Spam-Level: X-Spam-Status: No, score=-104.338 tagged_above=-999 required=5 tests=[AWL=2.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 pOA2e4hZTErN; Sun, 2 Dec 2012 19:04:40 -0800 (PST) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 977A321F8973; Sun, 2 Dec 2012 19:04:39 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 3c61cb05.0.148325.00-490.387146.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 03 Dec 2012 03:04:39 +0000 (UTC) X-MXL-Hash: 50bc16c740eedd27-cb7ecad2f1d06e640536e1370a679ea29ef3ce09 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qB334Y76022114; Sun, 2 Dec 2012 19:04:35 -0800 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qB334UO4022020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Dec 2012 19:04:31 -0800 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor); Sun, 2 Dec 2012 19:04:17 -0800 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qB334GKB003156; Sun, 2 Dec 2012 22:04:16 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qB3349Wb003065; Sun, 2 Dec 2012 22:04:10 -0500 Received: from lt-hp1044652.att.com (vpn-135-70-98-242.vpn.swst.att.com[135.70.98.242](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121203030403gw100632pre>; Mon, 3 Dec 2012 03:04:09 +0000 X-Originating-IP: [135.70.98.242] Message-Id: <7.0.1.0.0.20121202213404.0020f330@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 02 Dec 2012 22:02:31 -0500 To: Henning Schulzrinne , Matt Mathis From: Al Morton In-Reply-To: References: <7.0.1.0.0.20121125083420.085ee458@att.com> <7.0.1.0.0.20121125225022.085ee310@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=UcDmvtuN c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=uA28CKpmbTUA:10 a=5-yN49bxW6EA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=KV2HdAoy] X-AnalysisOut: [uXUA:10 a=doUQZJtgAAAA:8 a=48vgC7mUAAAA:8 a=hZG83p_yAAAA:8] X-AnalysisOut: [ a=6jU5HIQSCzjAYxuITDEA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=6jP4kvS9rEKP4eQ2:21 a=QrV_FUjDGCsq] X-AnalysisOut: [-n9y:21] Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [ippm] [lmap] Focus on Tests, Not Architectures... 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, 03 Dec 2012 03:04:41 -0000 Regarding "advertised rates": - I think there's variation among the underlying units of measure for the numbers advertised today - this is the point I tried to make during Henning's Transport Area presentation. It would certainly help with service verification if the parameters describing service were clearly defined for those performing the verification - I appreciate that most consumers won't care much about the units of measure, but verification should be scientific (e.g., conducted at the same layer as the spec). - The model-based metrics have appeal to me, in that they are derived from fundamental metrics that we have a reasonable hope of specifying sufficiently such that independent implementations and different hardware/software platforms will be able to make equivalent measurements. It may even turn-out that similar methods can provide a basis for model-based estimates of multiple (application?) metrics (Matt's memo focuses on TCP, which is certainly enough for now). Changing topics slightly, in the list: http://transition.fcc.gov/cgb/measuringbroadbandreport/2012/Technical-Appendix.pdf (pg. 22) I'd prefer to pare this down to start. Even where we have RFCs to refer to, the details of the test stream (for active measurement without user traffic, or active/hybrid measurement during user traffic) need to be agreed, and even the question of whether tests will be conducted during user activity or not needs discussion, maybe this is the first question to address. Al At 06:53 PM 11/30/2012, Henning Schulzrinne wrote: >One thing that I have learned through the MBA experience that it is >hard to find a single metric that addresses all use cases. For >example, consumers (and national bodies charged with consumer >protection) might want to know whether advertised rates agree with >actual rates. Unless ISPs are advertising the model-based metric, it >may not be as useful. For other applications, such as VoIP, latency >and packet loss for specific traffic types matter. Having a metric >that is RTT-independent and uses a different traffic pattern is not >helpful in that case, as much as it might be otherwise. > >On a more general note, from a consumer perspective, there are >probably three kinds of metrics that are useful: > >(a) Comparison between advertised and real-life metric, to allow >fair comparison of different providers. > >(b) Relative metrics: I don't much care what the number is (it could >be expressed in some number between 0 and 100, rather than Mb/s or >ms), but it should preserve relative ordering. If provider A is >significantly better according to the metric X, I should expect my >application (related to that metric) to perform significantly >better, even if I don't get the exact same performance. A rough >example for that is cellular throughput: It is very unlikely that an >individual consumer will get exactly the average throughput measured >by whatever entity, given geographic and device variations, but they >should still be able to pick a better-performing carrier based on >that metric. That's similar to Al's gas mileage example, "your >mileage may vary", but any Prius is still likely to get better gas >mileage than a Lincoln Navigator. > >(c) Threshold metrics: The metric should tell me whether a >particular service is likely to be suitable for my need. Latency is >the classical example: If my access link has a round-trip latency of >400 ms, I may die prematurely in a first-person-shooter game. >Absolute accuracy isn't that important (say, 400 vs. 420 ms), but >consistent definition of the path component and other attributes is. > >Some metrics might serve all three roles, but the emphasis differs. > >I would be interested in comments on the metrics that the FCC >Measurement Broadband America project uses. > >(a) Which ones need standardization first? (Some are already based >on IPPM RFCs, but most aren't.) > >(b) Which ones might be less valuable and/or should be substantially modified? > >See >http://transition.fcc.gov/cgb/measuringbroadbandreport/2012/Technical-Appendix.pdf >(pg. 22) for the current list. > >Henning > >________________________________ >From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Al >Morton [acmorton@att.com] >Sent: Monday, November 26, 2012 12:20 AM >To: Matt Mathis >Cc: lmap@ietf.org; Nicholas Weaver; ippm@ietf.org; Brian Trammell >Subject: Re: [lmap] [ippm] Focus on Tests, Not Architectures... > >Matt, > >I think we agree that better metrics are needed for LMAP, >and that ideally a metric can be applied at any point or pair of points. > >RFC 2330 and most IPPM metrics have a decidedly Source-to-Destination >host construction. Frankly, we did a better job with arbitrary >measurement points in Rec Y.1540. It's worth a look: >http://www.itu.int/rec/T-REC-Y.1540/en > >There are many goals the new metrics could serve: > - externally observable > - measurable by users > - easily related to user application performance > - service verification > - support consumer choice of ??? > - etc. >We need to agree on the set that are needed. > >While there may be some information in a measurement that covers >a combination of networks, measuring more than one network >is only useful when the combined network path delivers >the target performance - the sunny day outcome. Otherwise, >they are inconclusive, as you said in your memo. Some target >performance levels only apply in the scope where they are offered. > >We don't really have the milk fat scenario here, unless the producer, >the truck driver, the convenience store, and your home refrigerator >can all add some unknown amount of fat to the milk. ;-) > >When considering this problem, I've been thinking of the fuel >efficiency ratings provided for new cars in the US and Europe (at least). >The specs illustrate very well that the quantity measured is variable >depending on the conditions of the measurement (in the US, the miles per >gallon for city and highway driving), and they imply the >range of values that normal users can experience (a fairly wide range). >These are some aspects that would be useful to reproduce in our >metrics, I think. > >regards, and YMMV, >Al From Henning.Schulzrinne@fcc.gov Sun Dec 2 20:10:35 2012 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 970F121F8991; Sun, 2 Dec 2012 20:10:35 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MSPoIiqyoI3; Sun, 2 Dec 2012 20:10:30 -0800 (PST) Received: from dmz-mail2.fcc.gov (dmz-mail2.fcc.gov [192.104.54.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBF321F8992; Sun, 2 Dec 2012 20:10:29 -0800 (PST) Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas02.fccnet.win.fcc.gov ([fe80::2d69:114:8552:212f%13]) with mapi id 14.01.0421.002; Sun, 2 Dec 2012 23:10:27 -0500 From: Henning Schulzrinne To: Al Morton , Matt Mathis Thread-Topic: Advertised rate tests Thread-Index: AQHN0QumbGgQnnYOlU+Klp+qOrfGXg== Date: Mon, 3 Dec 2012 04:10:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: [ippm] Advertised rate tests 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, 03 Dec 2012 04:10:35 -0000 Changing the subject to reflect one topic.=0A= =0A= Currently, the FCC MBA effort measures long-term TCP throughput on a reason= ably well-defined sub-path, roughly reflecting the part of the path seen as= being under the direct control of the consumer ISP. The measurements indic= ate that this tends to agree with the advertised rates. In the old days, it= made sense to compare this to "line rate", but that's clearly not useful a= ny more, given that even DSL is now a variable-rate (line-noise dependent) = L2 service. The rate is essentially determined, at least for cable and fibe= r, by rate controllers.=0A= =0A= Are you suggesting that the long-term TCP throughput is not a good headline= metric?=0A= =0A= For the model-based metric, do they provide a similar Mb/s metric that is l= ikely to correspond to the advertised throughput? In other words, would a m= odel-based metric for a "20 Mb/s" service yield 20 Mb/s or some other numbe= r?=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Al Morton = [acmorton@att.com]=0A= Sent: Sunday, December 02, 2012 10:02 PM=0A= To: Henning Schulzrinne; Matt Mathis=0A= Cc: ippm@ietf.org; Nicholas Weaver; Brian Trammell; lmap@ietf.org=0A= Subject: Re: [lmap] [ippm] Focus on Tests, Not Architectures...=0A= =0A= Regarding "advertised rates":=0A= =0A= - I think there's variation among the underlying units of measure for=0A= the numbers advertised today - this is the point I tried to make=0A= during Henning's Transport Area presentation. It would certainly help=0A= with service verification if the parameters describing service were=0A= clearly defined for those performing the verification - I appreciate tha= t=0A= most consumers won't care much about the units of measure, but verificat= ion=0A= should be scientific (e.g., conducted at the same layer as the spec).=0A= =0A= - The model-based metrics have appeal to me, in that they are derived=0A= from fundamental metrics that we have a reasonable hope of specifying=0A= sufficiently such that independent implementations and different=0A= hardware/software platforms will be able to make equivalent measurements= .=0A= It may even turn-out that similar methods can provide a basis for=0A= model-based estimates of multiple (application?) metrics (Matt's=0A= memo focuses on TCP, which is certainly enough for now).=0A= From Henning.Schulzrinne@fcc.gov Sun Dec 2 20:14:53 2012 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 59B6321F8992; Sun, 2 Dec 2012 20:14:53 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDmWUrSJYCbZ; Sun, 2 Dec 2012 20:14:52 -0800 (PST) Received: from dmz-mail2.fcc.gov (dmz-mail2.fcc.gov [192.104.54.11]) by ietfa.amsl.com (Postfix) with ESMTP id A8A3A21F8991; Sun, 2 Dec 2012 20:14:52 -0800 (PST) Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas01.fccnet.win.fcc.gov ([fe80::1d27:de47:ad2e:9062%13]) with mapi id 14.01.0421.002; Sun, 2 Dec 2012 23:14:51 -0500 From: Henning Schulzrinne To: Al Morton , Matt Mathis Thread-Topic: List of metrics Thread-Index: AQHN0Qy9FKy7sELVoUuyeA/UzUluFA== Date: Mon, 3 Dec 2012 04:14:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: [ippm] List of 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: Mon, 03 Dec 2012 04:14:53 -0000 Currently, all the active metrics assume an idle link, as the goal is to me= asure the link performance without background traffic. (We can leave out th= e only passive metric, the total byte count, as that's probably not all tha= t interesting for this discussion.)=0A= =0A= At least from our experience, removing samples due to user activity is not = a major problem, i.e., it removes only a marginal number of busy-hour sampl= es.=0A= =0A= I don't see how any other measurement policy can yield useful results for t= he current metrics.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Al Morton = [acmorton@att.com]=0A= Sent: Sunday, December 02, 2012 10:02 PM=0A= To: Henning Schulzrinne; Matt Mathis=0A= Cc: ippm@ietf.org; Nicholas Weaver; Brian Trammell; lmap@ietf.org=0A= Subject: Re: [lmap] [ippm] Focus on Tests, Not Architectures...=0A= =0A= =0A= Changing topics slightly, in the list:=0A= http://transition.fcc.gov/cgb/measuringbroadbandreport/2012/Technical-Appen= dix.pdf=0A= (pg. 22)=0A= =0A= I'd prefer to pare this down to start. Even where we have RFCs to refer to,= =0A= the details of the test stream (for active measurement without user traffic= ,=0A= or active/hybrid measurement during user traffic) need to be agreed,=0A= and even the question of whether tests will be conducted during user=0A= activity or not needs discussion, maybe this is the first question to=0A= address.=0A= =0A= Al= From acmorton@att.com Mon Dec 3 05:58:01 2012 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 CDBEA21F86B1; Mon, 3 Dec 2012 05:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.506 X-Spam-Level: X-Spam-Status: No, score=-105.506 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 U1-YvI6+As4S; Mon, 3 Dec 2012 05:58:01 -0800 (PST) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id C815B21F8668; Mon, 3 Dec 2012 05:58:00 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 8efacb05.0.234697.00-427.621754.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 03 Dec 2012 13:58:00 +0000 (UTC) X-MXL-Hash: 50bcafe848b4597e-16927f636aaa961b70a7430f961e7119f49ba073 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qB3Dvx6S013447; Mon, 3 Dec 2012 05:57:59 -0800 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qB3DvssC013386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 05:57:56 -0800 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor); Mon, 3 Dec 2012 05:57:26 -0800 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qB3DvQEb021747; Mon, 3 Dec 2012 08:57:26 -0500 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qB3DvJ0H021593; Mon, 3 Dec 2012 08:57:19 -0500 Received: from lt-hp1044652.att.com (dn135-16-251-78.dhcpn.ugn.att.com[135.16.251.78](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121203135716gw100632q0e>; Mon, 3 Dec 2012 13:57:17 +0000 X-Originating-IP: [135.16.251.78] Message-Id: <7.0.1.0.0.20121203083106.07e57808@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 03 Dec 2012 08:55:43 -0500 To: Henning Schulzrinne , Matt Mathis From: Al Morton In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=UcDmvtuN c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=DwyFDWaKD4wA:10 a=9lgtAcny86UA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=eSl8r9IW] X-AnalysisOut: [rWUA:10 a=48vgC7mUAAAA:8 a=B6KMzFptAAAA:20 a=gS61Lz15b1P9q] X-AnalysisOut: [OwGdlkA:9 a=CjuIK1q_8ugA:10 a=_W_S_7VecoQA:10 a=lZB815dzVv] X-AnalysisOut: [QA:10 a=Hz7IrDYlS0cA:10 a=9GkpEwqxJgc93UgZ:21 a=iYxQocQxDI] X-AnalysisOut: [oqMkhk:21 a=XBp72y_trfwdYDgt:21] Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [ippm] Advertised rate tests 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, 03 Dec 2012 13:58:01 -0000 At 11:10 PM 12/2/2012, Henning Schulzrinne wrote:
Changing the subject to reflect one topic.
Currently, the FCC MBA effort measures long-term TCP throughput on a reasonably well-defined sub-path, roughly reflecting the part of the path seen as being under the direct control of the consumer ISP. The measurements indicate that this tends to agree with the advertised rates. In the old days, it made sense to compare this to "line rate", but that's clearly not useful any more, given that even DSL is now a variable-rate (line-noise dependent) L2 service. The rate is essentially determined, at least for cable and fiber, by rate controllers.

I think that line rate may be a worthwhile member of the
measurement list, especially when it is variable (capturing
variability within a given spec should be an important aspect
of this exercise, IMO).
Some ISPs are just selling an IP packet transfer service,
and the advertised rate may include IP header and payload.
TCP throughput is measured at a higher layer (just
the tip of the iceberg when it comes to differences).

Are you suggesting that the long-term TCP throughput is not a good headline metric?

I would suggest that it is one of several, because especially with TCP,
YMMV due to many factors along the transport connection's path.
TCP Throughput seems closer to "city" miles per gallon than "highway",
so I think some highway-end metric may be useful, too.

For the model-based metric, do they provide a similar Mb/s metric that is likely to correspond to the advertised throughput? In other words, would a model-based metric for a "20 Mb/s" service yield 20 Mb/s or some other number?

The short answer is yes. I think it's reasonable to assume that what
we standardize will influence the specifications that ISPs advertise.
For more details, see Matt's memo
http://tools.ietf.org/html/draft-mathis-ippm-model-based-metrics-00
and doc at
https://docs.google.com/document/d/1KDJMuZ2cWfXbnWjgwNDpN4w5smvZLfCL-gTk6Xgx1mI/edit#

regards,
Al


Henning

________________________________________
From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Al Morton [acmorton@att.com]
Sent: Sunday, December 02, 2012 10:02 PM
To: Henning Schulzrinne; Matt Mathis
Cc: ippm@ietf.org; Nicholas Weaver; Brian Trammell; lmap@ietf.org
Subject: Re: [lmap] [ippm]  Focus on Tests, Not Architectures...

Regarding "advertised rates":

- I think there's variation among the underlying units of measure for
   the numbers advertised today - this is the point I tried to make
   during Henning's Transport Area presentation. It would certainly help
   with service verification if the parameters describing service were
   clearly defined for those performing the verification - I appreciate that
   most consumers won't care much about the units of measure, but verification
   should be scientific (e.g., conducted at the same layer as the spec).

- The model-based metrics have appeal to me, in that they are derived
   from fundamental metrics that we have a reasonable hope of specifying
   sufficiently such that independent implementations and different
   hardware/software platforms will be able to make equivalent measurements.
   It may even turn-out that similar methods can provide a basis for
   model-based estimates of multiple (application?) metrics (Matt's
   memo focuses on TCP, which is certainly enough for now).
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
From acmorton@att.com Mon Dec 3 06:24:15 2012 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 69C4C21F86C7; Mon, 3 Dec 2012 06:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.113 X-Spam-Level: X-Spam-Status: No, score=-106.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 1HyM5eM0XMJi; Mon, 3 Dec 2012 06:24:14 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED4321F84E9; Mon, 3 Dec 2012 06:24:14 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id d06bcb05.0.245503.00-439.653035.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 03 Dec 2012 14:24:14 +0000 (UTC) X-MXL-Hash: 50bcb60e0740803a-ce3f709bfb60a05b82952d0cde308d1700df9f4a Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qB3EOCkl006521; Mon, 3 Dec 2012 06:24:13 -0800 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qB3EO0WX006330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 06:24:06 -0800 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor); Mon, 3 Dec 2012 06:23:35 -0800 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qB3ENZOx007761; Mon, 3 Dec 2012 09:23:35 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qB3ENTZS007622; Mon, 3 Dec 2012 09:23:30 -0500 Received: from lt-hp1044652.att.com (dn135-16-251-78.dhcpn.ugn.att.com[135.16.251.78](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121203142326gw100632q1e>; Mon, 3 Dec 2012 14:23:27 +0000 X-Originating-IP: [135.16.251.78] Message-Id: <7.0.1.0.0.20121203090303.07e576c0@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 03 Dec 2012 09:21:55 -0500 To: Henning Schulzrinne , Matt Mathis From: Al Morton In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=RfEn/SRv c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=DwyFDWaKD4wA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=9-0LEm5jLw4A:10 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=doUQZJtgAAAA:8 a=m7SQDFo_DTHfN1RZ30kA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=0fBNF8E5WBn] X-AnalysisOut: [oXR2E:21 a=ZtQD0pYsygndC46T:21] Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [ippm] List of 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: Mon, 03 Dec 2012 14:24:15 -0000 Ok, then the UDP latency and UDP packet loss tests were suspended on detecting user activity, and the Latency under Load test used other active tests to provide a known load. I think it would be worthwhile to discuss hybrid active+passive testing, at least. This is what Brian had proposed in http://tools.ietf.org/html/draft-trammell-ippm-hybrid-ps-00 Such tests may tend toward use in diagnostics rather than consumer info, and the value may be tightly linked with the passive characterization of user traffic (appropriately anonymized and privatized, of course), IOW it may not be useful if the load is overly summarized. And some of the Technical Appendix page 22 list also seem diagnostic oriented and somewhat overlapping (ICMP latency, UDP Latency). It's probably good to think of usage categories as we proceed. Al At 11:14 PM 12/2/2012, Henning Schulzrinne wrote: >Currently, all the active metrics assume an idle link, as the goal >is to measure the link performance without background traffic. (We >can leave out the only passive metric, the total byte count, as >that's probably not all that interesting for this discussion.) > >At least from our experience, removing samples due to user activity >is not a major problem, i.e., it removes only a marginal number of >busy-hour samples. > >I don't see how any other measurement policy can yield useful >results for the current metrics. > >Henning > >________________________________________ >From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Al >Morton [acmorton@att.com] >Sent: Sunday, December 02, 2012 10:02 PM >To: Henning Schulzrinne; Matt Mathis >Cc: ippm@ietf.org; Nicholas Weaver; Brian Trammell; lmap@ietf.org >Subject: Re: [lmap] [ippm] Focus on Tests, Not Architectures... > > >Changing topics slightly, in the list: >http://transition.fcc.gov/cgb/measuringbroadbandreport/2012/Technical-Appendix.pdf >(pg. 22) > >I'd prefer to pare this down to start. Even where we have RFCs to refer to, >the details of the test stream (for active measurement without user traffic, >or active/hybrid measurement during user traffic) need to be agreed, >and even the question of whether tests will be conducted during user >activity or not needs discussion, maybe this is the first question to >address. > >Al >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From Henning.Schulzrinne@fcc.gov Mon Dec 3 10:25:24 2012 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 D2DD621F8955; Mon, 3 Dec 2012 10:25:24 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RD7Rd1DCyNY; Mon, 3 Dec 2012 10:25:24 -0800 (PST) Received: from dmz-mail1.fcc.gov (dmz-mail1.fcc.gov [192.104.54.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8F921F894F; Mon, 3 Dec 2012 10:25:21 -0800 (PST) Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas01.fccnet.win.fcc.gov ([fe80::1d27:de47:ad2e:9062%13]) with mapi id 14.01.0421.002; Mon, 3 Dec 2012 13:25:19 -0500 From: Henning Schulzrinne To: Al Morton , Matt Mathis Thread-Topic: [ippm] List of metrics Thread-Index: AQHN0Qy9FKy7sELVoUuyeA/UzUluFJgHIZm7gABBuso= Date: Mon, 3 Dec 2012 18:25:18 +0000 Message-ID: References: , <7.0.1.0.0.20121203090303.07e576c0@att.com> In-Reply-To: <7.0.1.0.0.20121203090303.07e576c0@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [ippm] List of 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: Mon, 03 Dec 2012 18:25:25 -0000 Yes, for all active tests, tests are suspended when user activity is detect= ed. Besides measurement accuracy, the perception was that if users (=3D vol= unteers) got the notion that participating in this project would slow down = their Internet connection, we'd lose them pretty quickly.=0A= =0A= The UDP and ICMP latency tests aren't meant to be diagnostic - they do high= light important technology differences. As you can see from the published r= eports (and the GaTech SIGCOMM paper), DSL tends to impose significantly hi= gher delays than cable, due to interleaving and other factors.=0A= =0A= I agree that hybrid tests could be useful and would likely be seen as more = diagnostic, given their inherent higher variability. I certainly wouldn't w= ant to exclude them from consideration, and don't see much difficulty of in= tegrating them into the LMAP framework, but they are probably of lower prio= rity from a public policy perspective.=0A= =0A= ________________________________________=0A= From: Al Morton [acmorton@att.com]=0A= Sent: Monday, December 03, 2012 9:21 AM=0A= To: Henning Schulzrinne; Matt Mathis=0A= Cc: lmap@ietf.org; ippm@ietf.org=0A= Subject: Re: [ippm] List of metrics=0A= =0A= Ok, then the UDP latency and UDP packet loss tests were suspended=0A= on detecting user activity, and the Latency under Load test=0A= used other active tests to provide a known load.=0A= =0A= I think it would be worthwhile to discuss hybrid active+passive=0A= testing, at least. This is what Brian had proposed in=0A= http://tools.ietf.org/html/draft-trammell-ippm-hybrid-ps-00=0A= Such tests may tend toward use in diagnostics rather than consumer info,=0A= and the value may be tightly linked with the passive characterization=0A= of user traffic (appropriately anonymized and privatized, of course),=0A= IOW it may not be useful if the load is overly summarized.=0A= =0A= And some of the Technical Appendix page 22 list also seem diagnostic=0A= oriented and somewhat overlapping (ICMP latency, UDP Latency).=0A= It's probably good to think of usage categories as we proceed.=0A= =0A= Al=0A= =0A= From a.botta@unina.it Mon Dec 3 15:39:19 2012 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 31D5711E809A for ; Mon, 3 Dec 2012 15:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.881 X-Spam-Level: ** X-Spam-Status: No, score=2.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_AFFORDABLE=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 JrLl33TLnq8f for ; Mon, 3 Dec 2012 15:39:18 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC0E11E8097 for ; Mon, 3 Dec 2012 15:39:17 -0800 (PST) Received: from [192.168.1.102] ([151.73.159.198]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id qB3NdDN4012794 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 4 Dec 2012 00:39:14 +0100 Message-ID: <50BD37C2.3050405@unina.it> Date: Tue, 04 Dec 2012 00:37:38 +0100 From: Alessio Botta User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.10) Gecko/20121028 Icedove/10.0.10 MIME-Version: 1.0 To: ippm@ietf.org References: <4FFA94E0.7050504@unina.it> <04fb01cdb045$dce83590$96b8a0b0$@botta@unina.it> In-Reply-To: <04fb01cdb045$dce83590$96b8a0b0$@botta@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [ippm] 1st IEEE ICC Workshop on Traffic Identification and Classification for Advanced Network Services and Scenarios (TRICANS): CFP 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, 03 Dec 2012 23:39:19 -0000 [Our apologies if you receive multiple copies of this CFP] ------------------------------------------------------------- CALL FOR PAPER - Second announcement ------------------------------------------------------------- 1st IEEE Workshop on Traffic Identification and Classification for Advanced Network Services and Scenarios (TRICANS) IEEE ICC 2013 workshop Budapest, Hungary, Week of ICC (9-13 June 2013) http://www.grid.unina.it/TRICANS2013 * Workshop Description * TRICANS workshop will provide an excellent international forum for sharing state-of-the-art advances and experiences in scientific research on Internet traffic identification and classification and their associated applications on advanced network scenarios and novel network services. TRICANS will explicitly consider traffic identification and classification as well as management issues related to very hot and challenging scenarios such as content-centric networks (CCN), Software Defined Networks (SDN), cloud computing systems and data centers, virtual networks, and the like. The ever-growing network link speeds have reached hundreds of Gbps and they are quickly approaching to Tbps in the core network. In order to support accurate network profiling of users and services, ISPs have been relying on Deep Packet Inspection (DPI), flow-based techniques, or other behavioral analysis of the Internet traffic. However, there are still a number of challenges in this field. On one hand, new networked applications come daily into play bringing massive amounts of traffic data to be processed in real-time. Such traffic volume keeps pushing industry and academia researchers to develop affordable yet efficient traffic identification and classification systems. To this end, there are demands for high-performance distributed and parallel traffic classification systems for both commodity or special-purposed hardware platforms. On the other hand, in the long-term, such solutions for traffic profiling will become part of the network management tools and techniques portfolio available for advanced network services. Also, new architectures and their supporting technologies, such as information- and content-centric networking architectures, cloud computing and network virtualization, and the like, will require network profiling services to enable robust and dynamic networking services capabilities. To address these research challenges, this workshop will focus on theory, tools, techniques, and applications of traffic identification and classification systems to enable advanced support for next-generation network architectures, services, and scenarios. The topics covered by the workshop include, but are not limited to, the following: - Measurement and modeling of Internet traffic for advanced networked services - Network and system troubleshooting through DPI technologies - Lightweight technologies for DPI in routers and middle-boxes - Network profiling of users and networked applications - Security and privacy in traffic identification and classification mechanisms - DPI technologies support for virtual networks and cloud computing management - Profiling network traffic in data center networks and cloud computing systems - Inferring and assessing Quality of Experience (QoE) of users and services - Novel visualization techniques for traffic classification and analysis - Packet processing support in operating systems for novel line-rate network services - Management of large network traffic data sets - SDN approaches for network performance monitoring - Traffic classification in SDN network elements and controllers - Traffic Classification and Identification of Cloud services - Traffic Classification and Identification for Internet Security - Classification and Identification of Botnet * Submission Guidelines * Prospective authors are encouraged to submit a full paper (5 pages) for review. Only original papers that have not been published or submitted for publication elsewhere will be considered. These submissions should follow the IEEE ICC 2013 formatting guidelines, templates for which are available at the main conference web page. The maximum paper length is of five (5) pages. Submission website: https://edas.info/N13453?c=13453 * Important Dates * - 4th of January 2013, registration of abstracts - 11th of January 2013, paper submission deadline - 22th of February 2013, notification deadline - 8th of March, camera ready - Workshop date: Week of ICC, 2013 (9-13 June 2013) * Workshop General Chairs * - Stenio Fernandes, Federal University of Pernambuco, Recife, Brazil - Antonio Pescapé, University of Napoli ''Federico II'', Napoli, Italy - Géza Szabó, Ericsson Traffic Laboratory, Budapest, Hungary -- Alessio Botta, PhD Dipartimento di Informatica e Sistemistica Universitŕ degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) [Room 3.09] Phone: +390817683865 - Fax: +390817683816 Skypeid: alessiobotta Email: a.botta@unina.it alessio.botta@consorzio-cini.it WWW: http://wpage.unina.it/a.botta From emile.stephan@orange.com Tue Dec 4 01:39:25 2012 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 149B621F86DE for ; Tue, 4 Dec 2012 01:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 rPKfOgRwhQNn for ; Tue, 4 Dec 2012 01:39:24 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2888C21F86A7 for ; Tue, 4 Dec 2012 01:39:23 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E1B4022C176; Tue, 4 Dec 2012 10:39:22 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AE9A1238055; Tue, 4 Dec 2012 10:39:22 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Tue, 4 Dec 2012 10:39:22 +0100 From: To: Brian Trammell Thread-Topic: [ippm] draft-trammell-ippm-hybrid-ps-00.txt Thread-Index: AQHNqr4vFsuFWY2UwkSFnux5oqkRaZgIqY7w Date: Tue, 4 Dec 2012 09:39:21 +0000 Message-ID: <6293_1354613962_50BDC4CA_6293_1062_8_5AE9CCAA1B4A2248AB61B4C7F0AD5FB9097812@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <20121012083122.13716.29945.idtracker@ietfa.amsl.com> <65974042-2522-4E12-8CFD-1236DF60CF74@tik.ee.ethz.ch> <7.0.1.0.0.20121013091948.04b1e628@att.com> <2BD26307-1A04-46CC-9F09-749F15ECD0E6@tik.ee.ethz.ch> In-Reply-To: <2BD26307-1A04-46CC-9F09-749F15ECD0E6@tik.ee.ethz.ch> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: Al Morton , "ippm@ietf.org" Subject: Re: [ippm] draft-trammell-ippm-hybrid-ps-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: Tue, 04 Dec 2012 09:39:25 -0000 Hi Brian, The WG already worked on 'hybrid metrics'. RFC6444 defines spatial metrics = based on end-to-end metrics defined in RFC2679 and RFC2680. This RFC covers unicast and multicast. Do you envision covering multicast h= ybrid measurement too? Regards Emile -----Message d'origine----- De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part de B= rian Trammell Envoy=E9=A0: lundi 15 octobre 2012 12:17 =C0=A0: Al Morton Cc=A0: ippm@ietf.org Objet=A0: Re: [ippm] draft-trammell-ippm-hybrid-ps-00.txt Hi, Al, all, Thanks for your comments; comments inline... On Oct 13, 2012, at 3:43 PM, Al Morton wrote: > At 04:38 AM 10/12/2012, Brian Trammell wrote: >> I've just posted a very short draft on hybrid measurement, more a meta-r= equirements list and motivation than anything else, as a starting point for= discussion at the Atlanta meeting. >=20 > Hi Brian, >=20 > I like the idea of specifying a framework for passive measurement in=20 > the context of hybrid passive-active, because the comparisons between=20 > the different techniques are quite useful. Your effort is well-timed=20 > too, with both active and passive measurement requirements appearing=20 > in the first draft of lmap requirements: > http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 > With this obvious synergy, I look forward to discussing this in=20 > Atlanta. Yep... I specifically hope this work will prove useful in the context of th= e LMAP effort, by granting more flexibility to combine measurements from di= fferent sources. > I noted one point to consider as you develop the specification: >=20 >> The proposed specification entails: >>=20 >> ... >>=20 >> o Definition of methods for spatial and temporal composition of >> active and passive metrics together allowing for estimated >> uncertainty. >=20 > One of IPPM's earlier projects updated and expanded RFC 2330 section 9 > http://tools.ietf.org/html/rfc2330#section-9 > and defined three forms of metric composition and aggregation in RFC 5835: > http://tools.ietf.org/html/rfc5835#section-5 >=20 > I think the definitions you seek above are what Steven and I called=20 > spatial and temporal aggregation. Indeed; well, I think this covers half of it. In the baseline-comparison ca= se, temporal aggregation could be applied to the (passive) baseline in orde= r to improve the fidelity of the baseline while reducing storage requiremen= ts. Then there's the comparison step I suppose you could also model as "sub= tractive aggregation"; I still don't really have a firm grasp on how these = two operations work together. You're right, though, in that what I really mean with this point is aggrega= tion as defined in IPPM, not composition; will change in the next rev.=20 > These are the two aspects that > we didn't complete for active measurements (IPPM has a spec for=20 > spatial composition of active measurements, > http://tools.ietf.org/html/rfc6049 , where we mentioned passive=20 > measurements at several appropriate points in a low-key overrun of=20 > IPPM's active-only charter...). >=20 > Just pointing out the past work that might help the new effort! Many thanks; I'd remembered the spatial composition work (and, IIRC, some i= nitial work on temporal composition), but hadn't (re-) read yet to see what= applies where. Best regards, Brian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From trammell@tik.ee.ethz.ch Tue Dec 4 03:04:03 2012 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 BD0D721F86B4 for ; Tue, 4 Dec 2012 03:04:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdEgrrRQrM-n for ; Tue, 4 Dec 2012 03:04:02 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6861621F86AC for ; Tue, 4 Dec 2012 03:04:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5BA1ED9309; Tue, 4 Dec 2012 12:03:58 +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 rLO7UG5PKHCv; Tue, 4 Dec 2012 12:03:58 +0100 (MET) Received: from [192.168.1.14] (unknown [80.48.104.216]) (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 F0E8BD9308; Tue, 4 Dec 2012 12:03:57 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <6293_1354613962_50BDC4CA_6293_1062_8_5AE9CCAA1B4A2248AB61B4C7F0AD5FB9097812@PEXCVZYM14.corporate.adroot.infra.ftgroup> Date: Tue, 4 Dec 2012 12:04:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <37A59F9A-9D8A-432C-9CC6-8899981A1941@tik.ee.ethz.ch> References: <20121012083122.13716.29945.idtracker@ietfa.amsl.com> <65974042-2522-4E12-8CFD-1236DF60CF74@tik.ee.ethz.ch> <7.0.1.0.0.20121013091948.04b1e628@att.com> <2BD26307-1A04-46CC-9F09-749F15ECD0E6@tik.ee.ethz.ch> <6293_1354613962_50BDC4CA_6293_1062_8_5AE9CCAA1B4A2248AB61B4C7F0AD5FB9097812@PEXCVZYM14.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1499) Cc: Al Morton , "ippm@ietf.org" Subject: Re: [ippm] draft-trammell-ippm-hybrid-ps-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: Tue, 04 Dec 2012 11:04:03 -0000 Hi, Emile, Indeed, the metrics defined in 5644 could, after a fact, be another type = of hybrid measurement, though the main idea behind hybrid-ps is the = integration of pure-passive with active measurement (see earlier = conversations on combined vs. concurrent hybrid [1]). The document in = its present form was meant exactly to elicit these kind of comments, = though. :) So while I'd not thought of it to date, absolutely, the = document should cover this case as well. Given my background on the passive side of things, I'm not as familiar = with multicast measurements, but will have a deeper look at 5644 to see = how it fits in with the hybrid measurement problem as stated. Thanks, best regards, Brian (wearing a contributor hat) [1] http://www.ietf.org/mail-archive/web/ippm/current/msg02952.html On 4 Dec 2012, at 10:39, wrote: > Hi Brian, >=20 > The WG already worked on 'hybrid metrics'. RFC6444 defines spatial = metrics based on end-to-end metrics defined in RFC2679 and RFC2680. > This RFC covers unicast and multicast. Do you envision covering = multicast hybrid measurement too? >=20 > Regards > Emile >=20 > -----Message d'origine----- > De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de Brian Trammell > Envoy=E9 : lundi 15 octobre 2012 12:17 > =C0 : Al Morton > Cc : ippm@ietf.org > Objet : Re: [ippm] draft-trammell-ippm-hybrid-ps-00.txt >=20 > Hi, Al, all, >=20 > Thanks for your comments; comments inline... >=20 > On Oct 13, 2012, at 3:43 PM, Al Morton wrote: >=20 >> At 04:38 AM 10/12/2012, Brian Trammell wrote: >>> I've just posted a very short draft on hybrid measurement, more a = meta-requirements list and motivation than anything else, as a starting = point for discussion at the Atlanta meeting. >>=20 >> Hi Brian, >>=20 >> I like the idea of specifying a framework for passive measurement in=20= >> the context of hybrid passive-active, because the comparisons between=20= >> the different techniques are quite useful. Your effort is well-timed=20= >> too, with both active and passive measurement requirements appearing=20= >> in the first draft of lmap requirements: >> http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 >> With this obvious synergy, I look forward to discussing this in=20 >> Atlanta. >=20 > Yep... I specifically hope this work will prove useful in the context = of the LMAP effort, by granting more flexibility to combine measurements = from different sources. >=20 >> I noted one point to consider as you develop the specification: >>=20 >>> The proposed specification entails: >>>=20 >>> ... >>>=20 >>> o Definition of methods for spatial and temporal composition of >>> active and passive metrics together allowing for estimated >>> uncertainty. >>=20 >> One of IPPM's earlier projects updated and expanded RFC 2330 section = 9 >> http://tools.ietf.org/html/rfc2330#section-9 >> and defined three forms of metric composition and aggregation in RFC = 5835: >> http://tools.ietf.org/html/rfc5835#section-5 >>=20 >> I think the definitions you seek above are what Steven and I called=20= >> spatial and temporal aggregation. >=20 > Indeed; well, I think this covers half of it. In the = baseline-comparison case, temporal aggregation could be applied to the = (passive) baseline in order to improve the fidelity of the baseline = while reducing storage requirements. Then there's the comparison step I = suppose you could also model as "subtractive aggregation"; I still don't = really have a firm grasp on how these two operations work together. >=20 > You're right, though, in that what I really mean with this point is = aggregation as defined in IPPM, not composition; will change in the next = rev.=20 >=20 >> These are the two aspects that >> we didn't complete for active measurements (IPPM has a spec for=20 >> spatial composition of active measurements, >> http://tools.ietf.org/html/rfc6049 , where we mentioned passive=20 >> measurements at several appropriate points in a low-key overrun of=20 >> IPPM's active-only charter...). >>=20 >> Just pointing out the past work that might help the new effort! >=20 > Many thanks; I'd remembered the spatial composition work (and, IIRC, = some initial work on temporal composition), but hadn't (re-) read yet to = see what applies where. >=20 > Best regards, >=20 > Brian >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. From acmorton@att.com Tue Dec 4 05:04:29 2012 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 EFD1521F8AD3 for ; Tue, 4 Dec 2012 05:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.77 X-Spam-Level: X-Spam-Status: No, score=-104.77 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 s46A7xK7Msri for ; Tue, 4 Dec 2012 05:04:28 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9580421F8A88 for ; Tue, 4 Dec 2012 05:04:27 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id ad4fdb05.0.632535.00-363.1744541.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 04 Dec 2012 13:04:27 +0000 (UTC) X-MXL-Hash: 50bdf4db67301379-7a7e83f3e65d4be673bebe4d502272f71adecf05 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qB4D4Q3T005624 for ; Tue, 4 Dec 2012 08:04:26 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qB4D4Hs3005581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Dec 2012 08:04:22 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Tue, 4 Dec 2012 08:03:56 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qB4D3ujC005286 for ; Tue, 4 Dec 2012 08:03:56 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qB4D3lUh005070 for ; Tue, 4 Dec 2012 08:03:53 -0500 Received: from lt-hp1044652.att.com (vpn-135-70-61-240.vpn.west.att.com[135.70.61.240](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121204130342gw100632r9e>; Tue, 4 Dec 2012 13:03:43 +0000 X-Originating-IP: [135.70.61.240] Message-Id: <7.0.1.0.0.20121204075352.04c24818@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 04 Dec 2012 08:02:06 -0500 To: Brian Trammell , From: Al Morton In-Reply-To: <37A59F9A-9D8A-432C-9CC6-8899981A1941@tik.ee.ethz.ch> References: <20121012083122.13716.29945.idtracker@ietfa.amsl.com> <65974042-2522-4E12-8CFD-1236DF60CF74@tik.ee.ethz.ch> <7.0.1.0.0.20121013091948.04b1e628@att.com> <2BD26307-1A04-46CC-9F09-749F15ECD0E6@tik.ee.ethz.ch> <6293_1354613962_50BDC4CA_6293_1062_8_5AE9CCAA1B4A2248AB61B4C7F0AD5FB9097812@PEXCVZYM14.corporate.adroot.infra.ftgroup> <37A59F9A-9D8A-432C-9CC6-8899981A1941@tik.ee.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=RfEn/SRv c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=MFFKJBWP4y8A:10 a=Akd7jVN17FkA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=Kx9YsIWO] X-AnalysisOut: [zsYA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=Wqe6L2wxlZj8vc] X-AnalysisOut: [Z-AUsA:9 a=wPNLvfGTeEIA:10 a=lo8WrvJ2A_0A:10 a=oAXR_kdF8uM] X-AnalysisOut: [A:10 a=lZB815dzVvQA:10] Cc: "ippm@ietf.org" Subject: Re: [ippm] draft-trammell-ippm-hybrid-ps-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: Tue, 04 Dec 2012 13:04:29 -0000 Yes, there are lots of combinations that might be called "hybrid", and the spatial measurements in 5644 could be viewed as "passive measurement of active test traffic" because intermediate measurement points don't terminate the stream. But we also said (in Section 1, Intro and Scope): The scope of this memo is limited to metrics using a single source packet or stream, and observations of corresponding packets along the path (spatial), at one or more destinations (one-to-group), or both. Note that all the metrics defined herein are based on observations of packets dedicated to testing, a process that is called active measurement. Passive measurement (for example, a spatial metric based on the observation of user traffic) is beyond the scope of this memo. which helps to clarify the difference, too. Al At 06:04 AM 12/4/2012, Brian Trammell wrote: >Hi, Emile, > >Indeed, the metrics defined in 5644 could, after=20 >a fact, be another type of hybrid measurement,=20 >though the main idea behind hybrid-ps is the=20 >integration of pure-passive with active=20 >measurement (see earlier conversations on=20 >combined vs. concurrent hybrid [1]). The=20 >document in its present form was meant exactly=20 >to elicit these kind of comments, though. :) So=20 >while I'd not thought of it to date, absolutely,=20 >the document should cover this case as well. > >Given my background on the passive side of=20 >things, I'm not as familiar with multicast=20 >measurements, but will have a deeper look at=20 >5644 to see how it fits in with the hybrid measurement problem as stated. > >Thanks, best regards, > >Brian (wearing a contributor hat) > >[1] http://www.ietf.org/mail-archive/web/ippm/current/msg02952.html > >On 4 Dec 2012, at 10:39, wrote: > > > Hi Brian, > > > > The WG already worked on 'hybrid metrics'.=20 > RFC6444 defines spatial metrics based on=20 > end-to-end metrics defined in RFC2679 and RFC2680. > > This RFC covers unicast and multicast. Do you=20 > envision covering multicast hybrid measurement too? > > > > Regards > > Emile > > > > -----Message d'origine----- > > De : ippm-bounces@ietf.org=20 > [mailto:ippm-bounces@ietf.org] De la part de Brian Trammell > > Envoy=E9 : lundi 15 octobre 2012 12:17 > > =C0 : Al Morton > > Cc : ippm@ietf.org > > Objet : Re: [ippm] draft-trammell-ippm-hybrid-ps-00.txt > > > > Hi, Al, all, > > > > Thanks for your comments; comments inline... > > > > On Oct 13, 2012, at 3:43 PM, Al Morton wrote: > > > >> At 04:38 AM 10/12/2012, Brian Trammell wrote: > >>> I've just posted a very short draft on=20 > hybrid measurement, more a meta-requirements=20 > list and motivation than anything else, as a=20 > starting point for discussion at the Atlanta meeting. > >> > >> Hi Brian, > >> > >> I like the idea of specifying a framework for passive measurement in > >> the context of hybrid passive-active, because the comparisons between > >> the different techniques are quite useful. Your effort is well-timed > >> too, with both active and passive measurement requirements appearing > >> in the first draft of lmap requirements: > >> http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 > >> With this obvious synergy, I look forward to discussing this in > >> Atlanta. > > > > Yep... I specifically hope this work will=20 > prove useful in the context of the LMAP effort,=20 > by granting more flexibility to combine measurements from different= sources. > > > >> I noted one point to consider as you develop the specification: > >> > >>> The proposed specification entails: > >>> > >>> ... > >>> > >>> o Definition of methods for spatial and temporal composition of > >>> active and passive metrics together allowing for estimated > >>> uncertainty. > >> > >> One of IPPM's earlier projects updated and expanded RFC 2330 section 9 > >> http://tools.ietf.org/html/rfc2330#section-9 > >> and defined three forms of metric composition and aggregation in RFC= 5835: > >> http://tools.ietf.org/html/rfc5835#section-5 > >> > >> I think the definitions you seek above are what Steven and I called > >> spatial and temporal aggregation. > > > > Indeed; well, I think this covers half of it.=20 > In the baseline-comparison case, temporal=20 > aggregation could be applied to the (passive)=20 > baseline in order to improve the fidelity of=20 > the baseline while reducing storage=20 > requirements. Then there's the comparison step=20 > I suppose you could also model as "subtractive=20 > aggregation"; I still don't really have a firm=20 > grasp on how these two operations work together. > > > > You're right, though, in that what I really=20 > mean with this point is aggregation as defined=20 > in IPPM, not composition; will change in the next rev. > > > >> These are the two aspects that > >> we didn't complete for active measurements (IPPM has a spec for > >> spatial composition of active measurements, > >> http://tools.ietf.org/html/rfc6049 , where we mentioned passive > >> measurements at several appropriate points in a low-key overrun of > >> IPPM's active-only charter...). > >> > >> Just pointing out the past work that might help the new effort! > > > > Many thanks; I'd remembered the spatial=20 > composition work (and, IIRC, some initial work=20 > on temporal composition), but hadn't (re-) read yet to see what applies= where. > > > > Best regards, > > > > Brian > > > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > > >=20 >= ___________________________________________________________________________= ______________________________________________ > > > > Ce message et ses pieces jointes peuvent=20 > contenir des informations confidentielles ou privilegiees et ne doivent= donc > > pas etre diffuses, exploites ou copies sans=20 > autorisation. Si vous avez recu ce message par erreur, veuillez le= signaler > > a l'expediteur et le detruire ainsi que les=20 > pieces jointes. Les messages electroniques etant susceptibles= d'alteration, > > France Telecom - Orange decline toute=20 > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain=20 > confidential or privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error,=20 > please notify the sender and delete this message and its attachments. > > As emails may be altered, France Telecom -=20 > Orange is not liable for messages that have=20 > been modified, changed or falsified. > > Thank you. > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From wwwrun@rfc-editor.org Wed Dec 5 17:29:23 2012 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 3BDF621F8D08; Wed, 5 Dec 2012 17:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.933 X-Spam-Level: X-Spam-Status: No, score=-101.933 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 uxrY139T0Zlb; Wed, 5 Dec 2012 17:29:22 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A8F8021F8D07; Wed, 5 Dec 2012 17:29:22 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DF8C672F4F8; Wed, 5 Dec 2012 17:21:05 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121206012105.DF8C672F4F8@rfc-editor.org> Date: Wed, 5 Dec 2012 17:21:05 -0800 (PST) Cc: ippm@ietf.org, rfc-editor@rfc-editor.org Subject: [ippm] RFC 6808 on Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track 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, 06 Dec 2012 01:29:23 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6808 Title: Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track Author: L. Ciavattone, R. Geib, A. Morton, M. Wieser Status: Informational Stream: IETF Date: December 2012 Mailbox: lencia@att.com, Ruediger.Geib@telekom.de, acmorton@att.com, matthias_michael.wieser@stud.tu-darmstadt.de Pages: 29 Characters: 62061 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ippm-testplan-rfc2679-03.txt URL: http://www.rfc-editor.org/rfc/rfc6808.txt This memo provides the supporting test plan and results to advance RFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. This memo also provides direct input for development of a revision of RFC 2679. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IP Performance Metrics Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From trammell@tik.ee.ethz.ch Tue Dec 11 06:23:13 2012 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 B312D21F8801 for ; Tue, 11 Dec 2012 06:23:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCa3N28XnpeF for ; Tue, 11 Dec 2012 06:23:13 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0B63921F87FA for ; Tue, 11 Dec 2012 06:23:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 835BFD9315 for ; Tue, 11 Dec 2012 15:23:08 +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 eQGn4-er2w-u for ; Tue, 11 Dec 2012 15:23:08 +0100 (MET) Received: from [172.16.0.154] (ec2-79-125-80-212.eu-west-1.compute.amazonaws.com [79.125.80.212]) (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 EC7F7D9310 for ; Tue, 11 Dec 2012 15:23:07 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <280536DA-B92C-47AB-AA79-7760F560E6FD@tik.ee.ethz.ch> Date: Tue, 11 Dec 2012 15:23:04 +0100 To: "ippm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [ippm] Scheduling for IETF 86 in Orlando, and an introduction 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, 11 Dec 2012 14:23:13 -0000 Greetings, all, First, let me briefly (and a bit late) say I'm honored to take over as a = co-chair of the IPPM working group. I hope as chair to be worthy of our = predecessors; thanks, again, Henk and Matt, for all your work over the = years. I figured I should briefly introduce myself as well. I've been a = lurker in IPPM for quite some time, interested in the integration of = passively and actively derived metrics, but until recently have never = really had much time to devote to it. So, you may be wondering who the = new guy is. I'm presently a researcher at ETH Zurich. My broad area of = research, across the arc of my career, is in large-scale network = measurement tools and data analysis techniques, with a focus on = efficiently squeezing interesting information out of passive network = observations. I look forward to working with you all, in carrying = forward the work of the group: there's a lot of interesting new work = coming in. To that end, working group scheduling for IETF 86 in Orlando is now = open. We have quite some time to settle on an agenda, of course, but = given how much interest there has been in various new work items, I'd = like to ask anyone who thinks they may like a slot on the agenda to = contact the chairs at ippm-chairs@tools.ietf.org, to get some guidance = on how much time we're likely to need. We'd like to focus on new = individual drafts, or individual drafts that will have significant = updates since the last meeting, targeted toward adoption in the IPPM = working group. Many thanks, and best regards, Brian= From ippm@wjcerveny.com Sun Dec 16 20:57:34 2012 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 E705E21F8C2B for ; Sun, 16 Dec 2012 20:57:33 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZyTMn0WRCXf for ; Sun, 16 Dec 2012 20:57:31 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id EFB0421F8958 for ; Sun, 16 Dec 2012 20:57:30 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 55E5220BEA for ; Sun, 16 Dec 2012 23:57:30 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Sun, 16 Dec 2012 23:57:30 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:content-type :content-transfer-encoding:subject:message-id:date:to :mime-version; s=smtpout; bh=+XkQFg8VZPac/fKTtcaGkntbqf8=; b=utu bneECn1EiaxR20BOITduDAJtpMrLZxSUfUi/WEPnoufPDLV2fKSAHV/N+88G9oYe EWxkJAFhfBdKiUtrNHgCPxrAmXXxUSEeCIu2YUTTQBKUmLvrzdQig56sSYY8UmP2 hIbiwnLJ8vt5Gly2VYWxikB74vOQPefjmxh7IcmM= X-Sasl-enc: AT3ukM+pppOedo6vxEOV8JTWPQiZ49mqgLgsj4VTZs/d 1355720250 Received: from [192.168.1.109] (unknown [24.231.199.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 0EB18482507 for ; Sun, 16 Dec 2012 23:57:29 -0500 (EST) From: Bill Cerveny Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 16 Dec 2012 23:57:29 -0500 To: ippm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [ippm] My introduction and preparing for the IPPM meeting at IETF 86 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, 17 Dec 2012 04:57:34 -0000 Dear IPPM authors, contributors and participants, I=92m honored and excited to be named a co-chair of the IPPM working = group and to be given the opportunity to support the IPPM community in = this manner. I=92d like to thank Matt and Henk for the extensive work = they=92ve accomplished as IPPM WG chairs and I look forward to = furthering the work of IPPM. A little background on who I am: I am currently a principal software quality assurance engineer at Arbor = Networks.=20 My earliest involvement in Internet metrics began when I was asked to = research performance metrics for the Research and Development Internet = at AT&T Bell Laboratories. Shortly afterward, I accepted a position = with Advanced Network and Services, where I helped deploy reference = implementations of one-way delay and one-way packet loss, working with = Guy Almes, Matt Zekauskas and Sunil Kalidindi. After Advanced Network = and Services, I worked for Internet2, primarily in the advanced services = areas (IPv6 and IP multicast). My recent IETF-related interests have been with the Benchmarking = Methodologies Working Group as well as various IPv6 working groups.=20 While most of my professional experience has been as an Internet = professional (geek), my early professional experience was as a = journalist, which I expect will be helpful as co-chair. I enjoy writing = and am comfortable reviewing documents. I look forward to the = opportunity to provide both technical and grammatical feedback on = working group documents to help further working group documents and = contributions. This is my first experience as an IETF co-chair and I=92m still learning = a bit about what co-chairing and IETF working group is all about. I look = forward to working with people I=92ve known from the beginnings of the = IPPM working group as well as new contributors. There is a lot of new = work ahead of us and I=92m genuinely looking forward to doing what I can = to promote these efforts. Finally, reiterating what IPPM co-chair Brian Trammel has already noted, = it=92s not too early to begin planning for IETF 86 in Orlando. If you=92d = like to discuss new individual contributions or individual contributions = with significant updates, please propose agenda items to us via the = e-mail address ippm-chairs@tools.ietf.org. Best Regards, Bill Cerveny= From Ruediger.Geib@telekom.de Sun Dec 16 23:16:03 2012 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 5BD9C21F89E9 for ; Sun, 16 Dec 2012 23:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 JpNIYLVzqAqB for ; Sun, 16 Dec 2012 23:16:02 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD3D21F89C3 for ; Sun, 16 Dec 2012 23:16:01 -0800 (PST) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 17 Dec 2012 08:15:58 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 17 Dec 2012 08:15:43 +0100 From: To: , Date: Mon, 17 Dec 2012 08:15:41 +0100 Thread-Topic: [ippm] My introduction and preparing for the IPPM meeting at IETF 86 Thread-Index: Ac3cEw23UTH1c8kQQpi1fsyEaDor5gAEnqVA Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ippm@ietf.org Subject: Re: [ippm] My introduction and preparing for the IPPM meeting at IETF 86 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, 17 Dec 2012 07:16:03 -0000 Hi Bill, welcome to the IPPM WG. Loooking forward to meet you again, in Berlin hopefully. Matt, thank's for your work and best wishes for your future. and best regards R=FCdiger -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Bil= l Cerveny Sent: Monday, December 17, 2012 5:57 AM To: ippm@ietf.org Subject: [ippm] My introduction and preparing for the IPPM meeting at IETF = 86 Dear IPPM authors, contributors and participants, I'm honored and excited to be named a co-chair of the IPPM working group an= d to be given the opportunity to support the IPPM community in this manner.= I'd like to thank Matt and Henk for the extensive work they've accomplishe= d as IPPM WG chairs and I look forward to furthering the work of IPPM. A little background on who I am: I am currently a principal software quality assurance engineer at Arbor Net= works. My earliest involvement in Internet metrics began when I was asked to resea= rch performance metrics for the Research and Development Internet at AT&T B= ell Laboratories. Shortly afterward, I accepted a position with Advanced N= etwork and Services, where I helped deploy reference implementations of one= -way delay and one-way packet loss, working with Guy Almes, Matt Zekauskas = and Sunil Kalidindi. After Advanced Network and Services, I worked for Inte= rnet2, primarily in the advanced services areas (IPv6 and IP multicast). My recent IETF-related interests have been with the Benchmarking Methodolog= ies Working Group as well as various IPv6 working groups. While most of my professional experience has been as an Internet profession= al (geek), my early professional experience was as a journalist, which I ex= pect will be helpful as co-chair. I enjoy writing and am comfortable review= ing documents. I look forward to the opportunity to provide both technical = and grammatical feedback on working group documents to help further working= group documents and contributions. This is my first experience as an IETF co-chair and I'm still learning a bi= t about what co-chairing and IETF working group is all about. I look forwar= d to working with people I've known from the beginnings of the IPPM working= group as well as new contributors. There is a lot of new work ahead of us = and I'm genuinely looking forward to doing what I can to promote these effo= rts. Finally, reiterating what IPPM co-chair Brian Trammel has already noted, it= 's not too early to begin planning for IETF 86 in Orlando. If you'd like to= discuss new individual contributions or individual contributions with sign= ificant updates, please propose agenda items to us via the e-mail address i= ppm-chairs@tools.ietf.org. Best Regards, Bill Cerveny _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From internet-drafts@ietf.org Fri Dec 21 06:04:37 2012 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 1E23E21F8596; Fri, 21 Dec 2012 06:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 m98o4aHAui9a; Fri, 21 Dec 2012 06:04:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2564E21F853E; Fri, 21 Dec 2012 06:04:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121221140418.20749.35939.idtracker@ietfa.amsl.com> Date: Fri, 21 Dec 2012 06:04:18 -0800 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-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: Fri, 21 Dec 2012 14:04:37 -0000 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 Problem Statement Author(s) : Al Morton Filename : draft-ietf-ippm-rate-problem-01.txt Pages : 10 Date : 2012-12-21 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 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From acmorton@att.com Fri Dec 21 06:18:17 2012 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 15B5C21F85E4 for ; Fri, 21 Dec 2012 06:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.158 X-Spam-Level: X-Spam-Status: No, score=-105.158 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 XCqapaY6T5nV for ; Fri, 21 Dec 2012 06:18:15 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4BD21F85E2 for ; Fri, 21 Dec 2012 06:18:15 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 6af64d05.0.1854510.00-336.5151440.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 21 Dec 2012 14:18:15 +0000 (UTC) X-MXL-Hash: 50d46fa7663a347d-4d819769ca5e4ae33c4fb87d84a7da2984940e71 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qBLEIDeK024431 for ; Fri, 21 Dec 2012 06:18:14 -0800 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qBLEI8C4024356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Dec 2012 06:18:12 -0800 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor) for ; Fri, 21 Dec 2012 06:16:58 -0800 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qBLEGkXA028105 for ; Fri, 21 Dec 2012 09:16:46 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qBLEGZRN027807 for ; Fri, 21 Dec 2012 09:16:38 -0500 Received: from lt-hp1044652.att.com (vpn-135-70-197-75.vpn.east.att.com[135.70.197.75](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121221141617gw100632b4e>; Fri, 21 Dec 2012 14:16:17 +0000 X-Originating-IP: [135.70.197.75] Message-Id: <7.0.1.0.0.20121221090459.04a18888@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 21 Dec 2012 09:11:21 -0500 To: ippm@ietf.org From: Al Morton In-Reply-To: <20121221140418.20749.35939.idtracker@ietfa.amsl.com> References: <20121221140418.20749.35939.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=GL+/5JxK c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=AuZGAmeUtKsA:10 a=qevIr9MzNokA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=lKOzZDsA] X-AnalysisOut: [1IEA:10 a=48vgC7mUAAAA:8 a=CO0uU8qm741it1JjjWEA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=_W_S_7VecoQA:10 a=lZB815dzVvQA:10 a=JT9JqnVl5f] X-AnalysisOut: [hgTyO_:21] Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-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: Fri, 21 Dec 2012 14:18:17 -0000 This update addresses comments from our recent session (IETF-85),
as well as Bill Cerveny's review/comments (off-list, thanks Bill).

There are already solutions to the problem in circulation:
draft-morton-ippm-twamp-rate  for protocol
draft-mathis-ippm-model-based-metrics for methods of measurement

regards,
Al

At 09:04 AM 12/21/2012, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Performance Metrics Working Group of the IETF.

         Title           : Rate Measurement Problem Statement
         Author(s)       : Al Morton
         Filename        : draft-ietf-ippm-rate-problem-01.txt
         Pages           : 10
         Date            : 2012-12-21

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 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-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-rate-problem-01


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 a.botta@unina.it Fri Dec 21 09:32:34 2012 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 DE90121F8AE3 for ; Fri, 21 Dec 2012 09:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_AFFORDABLE=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 Ns7B6t62rZJI for ; Fri, 21 Dec 2012 09:32:34 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id BFCB921F8AD2 for ; Fri, 21 Dec 2012 09:32:33 -0800 (PST) Received: from [143.225.229.166] ([143.225.229.166]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id qBLHWQE9025868 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 21 Dec 2012 18:32:26 +0100 Message-ID: <50D49CAF.6000305@unina.it> Date: Fri, 21 Dec 2012 18:30:23 +0100 From: Alessio Botta User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.10) Gecko/20121028 Icedove/10.0.10 MIME-Version: 1.0 To: ippm@ietf.org References: <4FFA94E0.7050504@unina.it> <04fb01cdb045$dce83590$96b8a0b0$@botta@unina.it> In-Reply-To: <04fb01cdb045$dce83590$96b8a0b0$@botta@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [ippm] 1st IEEE ICC Workshop on Traffic Identification and Classification for Advanced Network Services and Scenarios (TRICANS): CFP 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, 21 Dec 2012 17:32:35 -0000 [Our apologies if you receive multiple copies of this CFP] ------------------------------------------------------------- CALL FOR PAPER - Third announcement ------------------------------------------------------------- 1st IEEE Workshop on Traffic Identification and Classification for Advanced Network Services and Scenarios (TRICANS) IEEE ICC 2013 workshop Budapest, Hungary, Week of ICC (9-13 June 2013) http://www.grid.unina.it/TRICANS2013 * Workshop Description * TRICANS workshop will provide an excellent international forum for sharing state-of-the-art advances and experiences in scientific research on Internet traffic identification and classification and their associated applications on advanced network scenarios and novel network services. TRICANS will explicitly consider traffic identification and classification as well as management issues related to very hot and challenging scenarios such as content-centric networks (CCN), Software Defined Networks (SDN), cloud computing systems and data centers, virtual networks, and the like. The ever-growing network link speeds have reached hundreds of Gbps and they are quickly approaching to Tbps in the core network. In order to support accurate network profiling of users and services, ISPs have been relying on Deep Packet Inspection (DPI), flow-based techniques, or other behavioral analysis of the Internet traffic. However, there are still a number of challenges in this field. On one hand, new networked applications come daily into play bringing massive amounts of traffic data to be processed in real-time. Such traffic volume keeps pushing industry and academia researchers to develop affordable yet efficient traffic identification and classification systems. To this end, there are demands for high-performance distributed and parallel traffic classification systems for both commodity or special-purposed hardware platforms. On the other hand, in the long-term, such solutions for traffic profiling will become part of the network management tools and techniques portfolio available for advanced network services. Also, new architectures and their supporting technologies, such as information- and content-centric networking architectures, cloud computing and network virtualization, and the like, will require network profiling services to enable robust and dynamic networking services capabilities. To address these research challenges, this workshop will focus on theory, tools, techniques, and applications of traffic identification and classification systems to enable advanced support for next-generation network architectures, services, and scenarios. The topics covered by the workshop include, but are not limited to, the following: - Measurement and modeling of Internet traffic for advanced networked services - Network and system troubleshooting through DPI technologies - Lightweight technologies for DPI in routers and middle-boxes - Network profiling of users and networked applications - Security and privacy in traffic identification and classification mechanisms - DPI technologies support for virtual networks and cloud computing management - Profiling network traffic in data center networks and cloud computing systems - Inferring and assessing Quality of Experience (QoE) of users and services - Novel visualization techniques for traffic classification and analysis - Packet processing support in operating systems for novel line-rate network services - Management of large network traffic data sets - SDN approaches for network performance monitoring - Traffic classification in SDN network elements and controllers - Traffic Classification and Identification of Cloud services - Traffic Classification and Identification for Internet Security - Classification and Identification of Botnet * Submission Guidelines * Prospective authors are encouraged to submit a full paper (5 pages) for review. Only original papers that have not been published or submitted for publication elsewhere will be considered. These submissions should follow the IEEE ICC 2013 formatting guidelines, templates for which are available at the main conference web page. The maximum paper length is of five (5) pages. Submission website: https://edas.info/N13453?c=13453 * Important Dates * - 4th of January 2013, registration of abstracts - 11th of January 2013, paper submission deadline - 22th of February 2013, notification deadline - 8th of March, camera ready - Workshop date: Week of ICC, 2013 (9-13 June 2013) * Workshop General Chairs * - Stenio Fernandes, Federal University of Pernambuco, Recife, Brazil - Antonio Pescapé, University of Napoli ''Federico II'', Napoli, Italy - Géza Szabó, Ericsson Traffic Laboratory, Budapest, Hungary -- Alessio Botta, PhD Dipartimento di Informatica e Sistemistica Universitŕ degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) [Room 3.09] Phone: +390817683865 - Fax: +390817683816 Skypeid: alessiobotta Email: a.botta@unina.it alessio.botta@consorzio-cini.it WWW: http://wpage.unina.it/a.botta From dengguangqing@cnnic.cn Mon Dec 24 17:10:19 2012 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 ABD8421F8AF4 for ; Mon, 24 Dec 2012 17:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] 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 cCWZgycp2RhX for ; Mon, 24 Dec 2012 17:10:18 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 6D27A21F8B41 for ; Mon, 24 Dec 2012 17:10:16 -0800 (PST) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown218.241.103.192 (HELO user-think) (218.241.103.192) by 159.226.7.146 with SMTP; Tue, 25 Dec 2012 09:10:14 +0800 Date: Tue, 25 Dec 2012 09:10:12 +0800 From: "Guangqing Deng" To: "ippm@ietf.org" References: <20121012083122.13716.29945.idtracker@ietfa.amsl.com> <65974042-2522-4E12-8CFD-1236DF60CF74@tik.ee.ethz.ch> <7.0.1.0.0.20121013091948.04b1e628@att.com> <2BD26307-1A04-46CC-9F09-749F15ECD0E6@tik.ee.ethz.ch> <6293_1354613962_50BDC4CA_6293_1062_8_5AE9CCAA1B4A2248AB61B4C7F0AD5FB9097812@PEXCVZYM14.corporate.adroot.infra.ftgroup>, <37A59F9A-9D8A-432C-9CC6-8899981A1941@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: <201212250910121687691@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart065353152738_=----" Subject: Re: [ippm] draft-trammell-ippm-hybrid-ps-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: Tue, 25 Dec 2012 01:10:19 -0000 This is a multi-part message in MIME format. ------=_001_NextPart065353152738_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbCwgSeKAmW0gbmV3IHRvIHRoaXMgbWFpbGluZyBsaXN0IGFuZCBJIGhhdmUgYSBtaW5v ciBpc3N1ZSB0b3dhcmRzIHRoaXMgZHJhZnQsIGFuZCBmb3JnaXZlIG1lIGlmIEkgbWlzc2VkIHNv bWV0aGluZyBpbXBvcnRhbnQuIFRoaXMgZHJhZnQgZGlzY3Vzc2VzIHRoZSBoeWJyaWQgbWVhc3Vy ZW1lbnQgKG5hbWVseSBjb29yZGluYXRlIGFjdGl2ZSBtZWFzdXJlbWVudCBhbmQgcGFzc2l2ZSBt ZWFzdXJlbWVudCBmb3IgbW9yZSBhY2N1cmF0ZSBtZWFzdXJlbWVudCByZXN1bHRzKS4gV2hpbGUg aXQgc2VlbXMgdGhhdCB0aGVyZSBhcmUgbm8gcmVmZXJlbmNlcyBvZiBwYXNzaXZlIG1lYXN1cmVt ZW50IGxpc3RlZCBpbiB0aGlzIGRyYWZ0LiBBY3RpdmUgbWVhc3VyZW1lbnQgdG93YXJkcyBkZWxh eSBvciBwYWNrZXQgbG9zcyBjYW4gYmUgZWFzaWx5IHVuZGVyc3Rvb2QsIHdoaWxlIHBhc3NpdmUg bWVhc3VyZW1lbnQgaXMgZGlmZmljdWx0IHRvIHVuZGVyc3RhbmQsIGVzcGVjaWFsbHkgZm9yIG5l dyBoYW5kIGxpa2UgbWUuIEkgdGFrZSBhIGdsYW5jZSBhdCB0aGUgUkZDcyBvZiBJUFBNIGJ1dCBm aW5kIG5vIFJGQ3MgZGlyZWN0bHkgcmVnYXJkaW5nIHBhc3NpdmUgbWVhc3VyZW1lbnQuIElzIGl0 IG5lY2Vzc2FyeSB0byBhZGQgc29tZSByZWZlcmVuY2VzIG9mIHBhc3NpdmUgbWVhc3VyZW1lbnQg aW4gdGhpcyBkcmFmdD8NCg0KQmVzdCByZWdhcmRzIQ0KDQoNCg0KR3VhbmdxaW5nIERlbmcNCkNO TklDIA0KDQpGcm9tOiBCcmlhbiBUcmFtbWVsbA0KRGF0ZTogMjAxMi0xMi0wNCAxOTowNA0KVG86 IGVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbQ0KQ0M6IEFsIE1vcnRvbjsgaXBwbUBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtpcHBtXSBkcmFmdC10cmFtbWVsbC1pcHBtLWh5YnJpZC1wcy0wMC50eHQN CkhpLCBFbWlsZSwNCg0KSW5kZWVkLCB0aGUgbWV0cmljcyBkZWZpbmVkIGluIDU2NDQgY291bGQs IGFmdGVyIGEgZmFjdCwgYmUgYW5vdGhlciB0eXBlIG9mIGh5YnJpZCBtZWFzdXJlbWVudCwgdGhv dWdoIHRoZSBtYWluIGlkZWEgYmVoaW5kIGh5YnJpZC1wcyBpcyB0aGUgaW50ZWdyYXRpb24gb2Yg cHVyZS1wYXNzaXZlIHdpdGggYWN0aXZlIG1lYXN1cmVtZW50IChzZWUgZWFybGllciBjb252ZXJz YXRpb25zIG9uIGNvbWJpbmVkIHZzLiBjb25jdXJyZW50IGh5YnJpZCBbMV0pLiBUaGUgZG9jdW1l bnQgaW4gaXRzIHByZXNlbnQgZm9ybSB3YXMgbWVhbnQgZXhhY3RseSB0byBlbGljaXQgdGhlc2Ug a2luZCBvZiBjb21tZW50cywgdGhvdWdoLiA6KSBTbyB3aGlsZSBJJ2Qgbm90IHRob3VnaHQgb2Yg aXQgdG8gZGF0ZSwgYWJzb2x1dGVseSwgdGhlIGRvY3VtZW50IHNob3VsZCBjb3ZlciB0aGlzIGNh c2UgYXMgd2VsbC4NCg0KR2l2ZW4gbXkgYmFja2dyb3VuZCBvbiB0aGUgcGFzc2l2ZSBzaWRlIG9m IHRoaW5ncywgSSdtIG5vdCBhcyBmYW1pbGlhciB3aXRoIG11bHRpY2FzdCBtZWFzdXJlbWVudHMs IGJ1dCB3aWxsIGhhdmUgYSBkZWVwZXIgbG9vayBhdCA1NjQ0IHRvIHNlZSBob3cgaXQgZml0cyBp biB3aXRoIHRoZSBoeWJyaWQgbWVhc3VyZW1lbnQgcHJvYmxlbSBhcyBzdGF0ZWQuDQoNClRoYW5r cywgYmVzdCByZWdhcmRzLA0KDQpCcmlhbiAod2VhcmluZyBhIGNvbnRyaWJ1dG9yIGhhdCkNCg0K WzFdIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pcHBtL2N1cnJlbnQvbXNn MDI5NTIuaHRtbA0KDQpPbiA0IERlYyAyMDEyLCBhdCAxMDozOSwgPGVtaWxlLnN0ZXBoYW5Ab3Jh bmdlLmNvbT4gd3JvdGU6DQoNCj4gSGkgQnJpYW4sDQo+IA0KPiBUaGUgV0cgYWxyZWFkeSB3b3Jr ZWQgb24gJ2h5YnJpZCBtZXRyaWNzJy4gUkZDNjQ0NCBkZWZpbmVzIHNwYXRpYWwgbWV0cmljcyBi YXNlZCBvbiBlbmQtdG8tZW5kIG1ldHJpY3MgZGVmaW5lZCBpbiBSRkMyNjc5IGFuZCBSRkMyNjgw Lg0KPiBUaGlzIFJGQyBjb3ZlcnMgdW5pY2FzdCBhbmQgbXVsdGljYXN0LiBEbyB5b3UgZW52aXNp b24gY292ZXJpbmcgbXVsdGljYXN0IGh5YnJpZCBtZWFzdXJlbWVudCB0b28/DQo+IA0KPiBSZWdh cmRzDQo+IEVtaWxlDQo+IA0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGUgOiBp cHBtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh IHBhcnQgZGUgQnJpYW4gVHJhbW1lbGwNCj4gRW52b3nDqSA6IGx1bmRpIDE1IG9jdG9icmUgMjAx MiAxMjoxNw0KPiDDgCA6IEFsIE1vcnRvbg0KPiBDYyA6IGlwcG1AaWV0Zi5vcmcNCj4gT2JqZXQg OiBSZTogW2lwcG1dIGRyYWZ0LXRyYW1tZWxsLWlwcG0taHlicmlkLXBzLTAwLnR4dA0KPiANCj4g SGksIEFsLCBhbGwsDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHM7IGNvbW1lbnRzIGlu bGluZS4uLg0KPiANCj4gT24gT2N0IDEzLCAyMDEyLCBhdCAzOjQzIFBNLCBBbCBNb3J0b24gd3Jv dGU6DQo+IA0KPj4gQXQgMDQ6MzggQU0gMTAvMTIvMjAxMiwgQnJpYW4gVHJhbW1lbGwgd3JvdGU6 DQo+Pj4gSSd2ZSBqdXN0IHBvc3RlZCBhIHZlcnkgc2hvcnQgZHJhZnQgb24gaHlicmlkIG1lYXN1 cmVtZW50LCBtb3JlIGEgbWV0YS1yZXF1aXJlbWVudHMgbGlzdCBhbmQgbW90aXZhdGlvbiB0aGFu IGFueXRoaW5nIGVsc2UsIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGRpc2N1c3Npb24gYXQgdGhl IEF0bGFudGEgbWVldGluZy4NCj4+IA0KPj4gSGkgQnJpYW4sDQo+PiANCj4+IEkgbGlrZSB0aGUg aWRlYSBvZiBzcGVjaWZ5aW5nIGEgZnJhbWV3b3JrIGZvciBwYXNzaXZlIG1lYXN1cmVtZW50IGlu IA0KPj4gdGhlIGNvbnRleHQgb2YgaHlicmlkIHBhc3NpdmUtYWN0aXZlLCBiZWNhdXNlIHRoZSBj b21wYXJpc29ucyBiZXR3ZWVuIA0KPj4gdGhlIGRpZmZlcmVudCB0ZWNobmlxdWVzIGFyZSBxdWl0 ZSB1c2VmdWwuIFlvdXIgZWZmb3J0IGlzIHdlbGwtdGltZWQgDQo+PiB0b28sIHdpdGggYm90aCBh Y3RpdmUgYW5kIHBhc3NpdmUgbWVhc3VyZW1lbnQgcmVxdWlyZW1lbnRzIGFwcGVhcmluZyANCj4+ IGluIHRoZSBmaXJzdCBkcmFmdCBvZiBsbWFwIHJlcXVpcmVtZW50czoNCj4+IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaHVsenJpbm5lLWxtYXAtcmVxdWlyZW1lbnRzLTAwDQo+ PiBXaXRoIHRoaXMgb2J2aW91cyBzeW5lcmd5LCBJIGxvb2sgZm9yd2FyZCB0byBkaXNjdXNzaW5n IHRoaXMgaW4gDQo+PiBBdGxhbnRhLg0KPiANCj4gWWVwLi4uIEkgc3BlY2lmaWNhbGx5IGhvcGUg dGhpcyB3b3JrIHdpbGwgcHJvdmUgdXNlZnVsIGluIHRoZSBjb250ZXh0IG9mIHRoZSBMTUFQIGVm Zm9ydCwgYnkgZ3JhbnRpbmcgbW9yZSBmbGV4aWJpbGl0eSB0byBjb21iaW5lIG1lYXN1cmVtZW50 cyBmcm9tIGRpZmZlcmVudCBzb3VyY2VzLg0KPiANCj4+IEkgbm90ZWQgb25lIHBvaW50IHRvIGNv bnNpZGVyIGFzIHlvdSBkZXZlbG9wIHRoZSBzcGVjaWZpY2F0aW9uOg0KPj4gDQo+Pj4gVGhlIHBy b3Bvc2VkIHNwZWNpZmljYXRpb24gZW50YWlsczoNCj4+PiANCj4+PiAuLi4NCj4+PiANCj4+PiAg byAgRGVmaW5pdGlvbiBvZiBtZXRob2RzIGZvciBzcGF0aWFsIGFuZCB0ZW1wb3JhbCBjb21wb3Np dGlvbiBvZg0KPj4+ICAgICBhY3RpdmUgYW5kIHBhc3NpdmUgbWV0cmljcyB0b2dldGhlciBhbGxv d2luZyBmb3IgZXN0aW1hdGVkDQo+Pj4gICAgIHVuY2VydGFpbnR5Lg0KPj4gDQo+PiBPbmUgb2Yg SVBQTSdzIGVhcmxpZXIgcHJvamVjdHMgdXBkYXRlZCBhbmQgZXhwYW5kZWQgUkZDIDIzMzAgc2Vj dGlvbiA5DQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMzMwI3NlY3Rpb24tOQ0K Pj4gYW5kIGRlZmluZWQgdGhyZWUgZm9ybXMgb2YgbWV0cmljIGNvbXBvc2l0aW9uIGFuZCBhZ2dy ZWdhdGlvbiBpbiBSRkMgNTgzNToNCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4 MzUjc2VjdGlvbi01DQo+PiANCj4+IEkgdGhpbmsgdGhlIGRlZmluaXRpb25zIHlvdSBzZWVrIGFi b3ZlIGFyZSB3aGF0IFN0ZXZlbiBhbmQgSSBjYWxsZWQgDQo+PiBzcGF0aWFsIGFuZCB0ZW1wb3Jh bCBhZ2dyZWdhdGlvbi4NCj4gDQo+IEluZGVlZDsgd2VsbCwgSSB0aGluayB0aGlzIGNvdmVycyBo YWxmIG9mIGl0LiBJbiB0aGUgYmFzZWxpbmUtY29tcGFyaXNvbiBjYXNlLCB0ZW1wb3JhbCBhZ2dy ZWdhdGlvbiBjb3VsZCBiZSBhcHBsaWVkIHRvIHRoZSAocGFzc2l2ZSkgYmFzZWxpbmUgaW4gb3Jk ZXIgdG8gaW1wcm92ZSB0aGUgZmlkZWxpdHkgb2YgdGhlIGJhc2VsaW5lIHdoaWxlIHJlZHVjaW5n IHN0b3JhZ2UgcmVxdWlyZW1lbnRzLiBUaGVuIHRoZXJlJ3MgdGhlIGNvbXBhcmlzb24gc3RlcCBJ IHN1cHBvc2UgeW91IGNvdWxkIGFsc28gbW9kZWwgYXMgInN1YnRyYWN0aXZlIGFnZ3JlZ2F0aW9u IjsgSSBzdGlsbCBkb24ndCByZWFsbHkgaGF2ZSBhIGZpcm0gZ3Jhc3Agb24gaG93IHRoZXNlIHR3 byBvcGVyYXRpb25zIHdvcmsgdG9nZXRoZXIuDQo+IA0KPiBZb3UncmUgcmlnaHQsIHRob3VnaCwg aW4gdGhhdCB3aGF0IEkgcmVhbGx5IG1lYW4gd2l0aCB0aGlzIHBvaW50IGlzIGFnZ3JlZ2F0aW9u IGFzIGRlZmluZWQgaW4gSVBQTSwgbm90IGNvbXBvc2l0aW9uOyB3aWxsIGNoYW5nZSBpbiB0aGUg bmV4dCByZXYuIA0KPiANCj4+IFRoZXNlIGFyZSB0aGUgdHdvIGFzcGVjdHMgdGhhdA0KPj4gd2Ug ZGlkbid0IGNvbXBsZXRlIGZvciBhY3RpdmUgbWVhc3VyZW1lbnRzIChJUFBNIGhhcyBhIHNwZWMg Zm9yIA0KPj4gc3BhdGlhbCBjb21wb3NpdGlvbiBvZiBhY3RpdmUgbWVhc3VyZW1lbnRzLA0KPj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjA0OSAsIHdoZXJlIHdlIG1lbnRpb25lZCBw YXNzaXZlIA0KPj4gbWVhc3VyZW1lbnRzIGF0IHNldmVyYWwgYXBwcm9wcmlhdGUgcG9pbnRzIGlu IGEgbG93LWtleSBvdmVycnVuIG9mIA0KPj4gSVBQTSdzIGFjdGl2ZS1vbmx5IGNoYXJ0ZXIuLi4p Lg0KPj4gDQo+PiBKdXN0IHBvaW50aW5nIG91dCB0aGUgcGFzdCB3b3JrIHRoYXQgbWlnaHQgaGVs cCB0aGUgbmV3IGVmZm9ydCENCj4gDQo+IE1hbnkgdGhhbmtzOyBJJ2QgcmVtZW1iZXJlZCB0aGUg c3BhdGlhbCBjb21wb3NpdGlvbiB3b3JrIChhbmQsIElJUkMsIHNvbWUgaW5pdGlhbCB3b3JrIG9u IHRlbXBvcmFsIGNvbXBvc2l0aW9uKSwgYnV0IGhhZG4ndCAocmUtKSByZWFkIHlldCB0byBzZWUg d2hhdCBhcHBsaWVzIHdoZXJlLg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiANCj4gQnJpYW4NCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBpcHBtIG1haWxpbmcgbGlzdA0KPiBpcHBtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+IHBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyDQo+IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk J2FsdGVyYXRpb24sDQo+IEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLg0KPiANCj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsNCj4gdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiBBcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsg eW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K aXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXBwbQ== ------=_001_NextPart065353152738_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF

Hi, all, I=E2=80=99m new to this mailing list and= I have a minor=20 issue towards this draft, and forgive me if I missed something important. = This=20 draft discusses the hybrid measurement (namely coordinate active measureme= nt and=20 passive measurement for more accurate measurement results). While it seems= that=20 there are no references of passive measurement listed in this draft. Activ= e=20 measurement towards delay or packet loss can be easily understood, while p= assive=20 measurement is difficult to understand, especially for new hand like me. I= take=20 a glance at the RFCs of IPPM but find no RFCs directly regarding passive=20 measurement. Is it necessary to add some references of passive measurement= in=20 this draft?

 

Best=20 regards!

Guangqing=20 Deng
CNNIC 
 
Date: 2012-12-04 19:04
To: emile.stephan@orange.com
CC: Al Morton; ippm@ietf.org
Subject: Re: [ippm]=20 draft-trammell-ippm-hybrid-ps-00.txt
Hi, Emile,
 
Indeed, the metrics defined in 5644 cou= ld, after a fact, be another type of&nb= sp;hybrid measurement, though the main idea = behind hybrid-ps is the integration of pure-= passive with active measurement (see earlier = ;conversations on combined vs. concurrent hybrid&= nbsp;[1]). The document in its present form&= nbsp;was meant exactly to elicit these kind&= nbsp;of comments, though. :) So while I'd&nb= sp;not thought of it to date, absolutely,&nb= sp;the document should cover this case as&nb= sp;well.
 
Given my background on the passive side=  of things, I'm not as familiar with&nb= sp;multicast measurements, but will have a d= eeper look at 5644 to see how it f= its in with the hybrid measurement problem&n= bsp;as stated.
 
Thanks, best regards,
 
Brian (wearing a contributor hat)
 
[1] http://www.ietf.org/mail-archive/web/ippm/current/msg02952.h= tml
 
On 4 Dec 2012, at 10:39, <emile.step= han@orange.com> wrote:
 
> Hi Brian,
> 
> The WG already worked on 'hybrid&n= bsp;metrics'. RFC6444 defines spatial metrics bas= ed on end-to-end metrics defined in RFC2679&= nbsp;and RFC2680.
> This RFC covers unicast and multic= ast. Do you envision covering multicast hybr= id measurement too?
> 
> Regards
> Emile
> 
> -----Message d'origine-----
> De : ippm-bounces@ietf.org [mailto:ippm-boun= ces@ietf.org] De la part de Brian Trammell
> Envoy=C3=A9 : lundi 15 octobre 201= 2 12:17
> =C3=80 : Al Morton
> Cc : ippm@ietf.org
> Objet : Re: [ippm] draft-trammell-ippm-= hybrid-ps-00.txt
> 
> Hi, Al, all,
> 
> Thanks for your comments; comments = ;inline...
> 
> On Oct 13, 2012, at 3:43 PM,&= nbsp;Al Morton wrote:
> 
>> At 04:38 AM 10/12/2012, Brian = Trammell wrote:
>>> I've just posted a very sh= ort draft on hybrid measurement, more a = ;meta-requirements list and motivation than anyth= ing else, as a starting point for discu= ssion at the Atlanta meeting.
>> 
>> Hi Brian,
>> 
>> I like the idea of specifying&= nbsp;a framework for passive measurement in =
>> the context of hybrid passive-activ= e, because the comparisons between 
>> the different techniques are quite&= nbsp;useful. Your effort is well-timed 
>> too, with both active and pass= ive measurement requirements appearing 
>> in the first draft of lmap&nbs= p;requirements:
>> http://tools.ietf.org/html/draft-schulzrinne-lmap-requi= rements-00
>> With this obvious synergy, I l= ook forward to discussing this in 
>> Atlanta.
> 
> Yep... I specifically hope this wo= rk will prove useful in the context of&= nbsp;the LMAP effort, by granting more flexi= bility to combine measurements from different&nbs= p;sources.
> 
>> I noted one point to consider&= nbsp;as you develop the specification:
>> 
>>> The proposed specification entails:<= /DIV>
>>> 
>>> ...
>>> 
>>>  o  Definition of methods&= nbsp;for spatial and temporal composition of
>>>     active and passiv= e metrics together allowing for estimated
>>>     uncertainty.
>> 
>> One of IPPM's earlier projects = ;updated and expanded RFC 2330 section 9
>> http://tools.ietf.org/html/rfc2330#section-9
>> and defined three forms of met= ric composition and aggregation in RFC 5835:=
>> http://tools.ietf.org/html/rfc5835#section-5
>> 
>> I think the definitions you se= ek above are what Steven and I called&n= bsp;
>> spatial and temporal aggregation.
> 
> Indeed; well, I think this covers&= nbsp;half of it. In the baseline-comparison = case, temporal aggregation could be applied = to the (passive) baseline in order to i= mprove the fidelity of the baseline while&nb= sp;reducing storage requirements. Then there's th= e comparison step I suppose you could a= lso model as "subtractive aggregation"; I st= ill don't really have a firm grasp on&n= bsp;how these two operations work together.
> 
> You're right, though, in that what=  I really mean with this point is = aggregation as defined in IPPM, not composit= ion; will change in the next rev. 
> 
>> These are the two aspects that=
>> we didn't complete for active = measurements (IPPM has a spec for 
>> spatial composition of active measu= rements,
>> http://tools.ietf.org/html/rfc6049 , where&nb= sp;we mentioned passive 
>> measurements at several appropriate = ;points in a low-key overrun of 
>> IPPM's active-only charter...).
>> 
>> Just pointing out the past wor= k that might help the new effort!
> 
> Many thanks; I'd remembered the sp= atial composition work (and, IIRC, some init= ial work on temporal composition), but hadn'= t (re-) read yet to see what applies&nb= sp;where.
> 
> Best regards,
> 
> Brian
> 
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
> 
> ___________________________________________________________= ______________________________________________________________
> 
> Ce message et ses pieces jointes&n= bsp;peuvent contenir des informations confidentielles&= nbsp;ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou co= pies sans autorisation. Si vous avez recu&nb= sp;ce message par erreur, veuillez le signal= er
> a l'expediteur et le detruire ains= i que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline to= ute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci.
> 
> This message and its attachments m= ay contain confidential or privileged information=  that may be protected by law;
> they should not be distributed, us= ed or copied without authorisation.
> If you have received this email&nb= sp;in error, please notify the sender and&nb= sp;delete this message and its attachments.
> As emails may be altered, France&n= bsp;Telecom - Orange is not liable for = messages that have been modified, changed or=  falsified.
> Thank you.
 
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
------=_001_NextPart065353152738_=------ From dengguangqing@cnnic.cn Tue Dec 25 00:16:53 2012 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 6DD1821F87B1 for ; Tue, 25 Dec 2012 00:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 qMLwRelk1em8 for ; Tue, 25 Dec 2012 00:16:49 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id ED64521F866E for ; Tue, 25 Dec 2012 00:16:47 -0800 (PST) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown218.241.103.192 (HELO user-think) (218.241.103.192) by 159.226.7.146 with SMTP; Tue, 25 Dec 2012 16:16:45 +0800 Date: Tue, 25 Dec 2012 16:19:58 +0800 From: "Guangqing Deng" To: "ippm@ietf.org" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201212251619572410992@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart743871601751_=----" Subject: Re: [ippm] List of 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: Tue, 25 Dec 2012 08:16:53 -0000 This is a multi-part message in MIME format. ------=_001_NextPart743871601751_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGFsbCwgdG8gdW5kZXJzdGFuZCB0aGUgbGluayBjaGFyYWN0ZXJpc3RpYywgZG9pbmcgYWN0 aXZlIG9yIHBhc3NpdmUgbWVhc3VyZW1lbnQgZHVyaW5nIGlkbGUgdGltZSBpcyByZWNvbW1lbmRl ZDsgaG93ZXZlciwgdG8gZXZhbHVhdGUgdGhlIHVzZXIgZXhwZXJpZW5jZSBvciB0aGUgUW9TIChx dWFsaXR5IG9mIHNlcnZpY2UpIG9mIGludGVybmV0IGFwcGxpY2F0aW9ucyAobGlrZSBXZWIgc3Vy ZmluZywgVm9JUCBhbmQgbmV0d29yayB2aWRlbywgZXRjLiksIHBlcmZvcm1pbmcgbWVhc3VyZW1l bnQgd2hlbiB0aGUgbGluayBpcyBidXN5IGlzIHJlY29tbWVuZGVkLCBzaW5jZSB0aGUgdXNlciBl eHBlcmllbmNlIG9yIHRoZSBRb1Mgb2YgaW50ZXJuZXQgYXBwbGljYXRpb24gbWF5IGJlIGRlZ3Jh ZGVkIHdoZW4gdGhlIGxpbmsgaXMgYnVzeS4gSSBhbSBpbnRlcmVzdGVkIGluIHRoZSBtZWFzdXJl bWVudCBkdXJpbmcgYnVzeSB0aW1lLCBhbmQgYXJlIHRoZXJlIGFueSBtYXRlcmlhbHMgYWJvdXQg dGhpcyB0b3BpYyB3aXRoaW4gdGhpcyB3b3JrIGdyb3VwPyBJIGFtIG5vdCBzdXJlIHdoZXRoZXIg c3VjaCB0b3BpYyBpcyB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoaXMgd29ya2dyb3VwLCBhbnkgcmVz cG9uc2UgaXMgYXBwcmVjaWF0ZWQhIA0KDQpCZXN0IHJlZ2FyZHMhDQoNCg0KDQpHdWFuZ3Fpbmcg RGVuZw0KQ05OSUMgDQoNCkZyb206IEhlbm5pbmcgU2NodWx6cmlubmUNCkRhdGU6IDIwMTItMTIt MDMgMTI6MTQNClRvOiBBbCBNb3J0b247IE1hdHQgTWF0aGlzDQpDQzogbG1hcEBpZXRmLm9yZzsg aXBwbUBpZXRmLm9yZw0KU3ViamVjdDogW2lwcG1dIExpc3Qgb2YgbWV0cmljcw0KQ3VycmVudGx5 LCBhbGwgdGhlIGFjdGl2ZSBtZXRyaWNzIGFzc3VtZSBhbiBpZGxlIGxpbmssIGFzIHRoZSBnb2Fs IGlzIHRvIG1lYXN1cmUgdGhlIGxpbmsgcGVyZm9ybWFuY2Ugd2l0aG91dCBiYWNrZ3JvdW5kIHRy YWZmaWMuIChXZSBjYW4gbGVhdmUgb3V0IHRoZSBvbmx5IHBhc3NpdmUgbWV0cmljLCB0aGUgdG90 YWwgYnl0ZSBjb3VudCwgYXMgdGhhdCdzIHByb2JhYmx5IG5vdCBhbGwgdGhhdCBpbnRlcmVzdGlu ZyBmb3IgdGhpcyBkaXNjdXNzaW9uLikNCg0KQXQgbGVhc3QgZnJvbSBvdXIgZXhwZXJpZW5jZSwg cmVtb3Zpbmcgc2FtcGxlcyBkdWUgdG8gdXNlciBhY3Rpdml0eSBpcyBub3QgYSBtYWpvciBwcm9i bGVtLCBpLmUuLCBpdCByZW1vdmVzIG9ubHkgYSBtYXJnaW5hbCBudW1iZXIgb2YgYnVzeS1ob3Vy IHNhbXBsZXMuDQoNCkkgZG9uJ3Qgc2VlIGhvdyBhbnkgb3RoZXIgbWVhc3VyZW1lbnQgcG9saWN5 IGNhbiB5aWVsZCB1c2VmdWwgcmVzdWx0cyBmb3IgdGhlIGN1cnJlbnQgbWV0cmljcy4NCg0KSGVu bmluZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBs bWFwLWJvdW5jZXNAaWV0Zi5vcmcgW2xtYXAtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9m IEFsIE1vcnRvbiBbYWNtb3J0b25AYXR0LmNvbV0NClNlbnQ6IFN1bmRheSwgRGVjZW1iZXIgMDIs IDIwMTIgMTA6MDIgUE0NClRvOiBIZW5uaW5nIFNjaHVsenJpbm5lOyBNYXR0IE1hdGhpcw0KQ2M6 IGlwcG1AaWV0Zi5vcmc7IE5pY2hvbGFzIFdlYXZlcjsgQnJpYW4gVHJhbW1lbGw7IGxtYXBAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbbG1hcF0gW2lwcG1dICBGb2N1cyBvbiBUZXN0cywgTm90IEFy Y2hpdGVjdHVyZXMuLi4NCg0KDQpDaGFuZ2luZyB0b3BpY3Mgc2xpZ2h0bHksIGluIHRoZSBsaXN0 Og0KaHR0cDovL3RyYW5zaXRpb24uZmNjLmdvdi9jZ2IvbWVhc3VyaW5nYnJvYWRiYW5kcmVwb3J0 LzIwMTIvVGVjaG5pY2FsLUFwcGVuZGl4LnBkZg0KKHBnLiAyMikNCg0KSSdkIHByZWZlciB0byBw YXJlIHRoaXMgZG93biB0byBzdGFydC4gRXZlbiB3aGVyZSB3ZSBoYXZlIFJGQ3MgdG8gcmVmZXIg dG8sDQp0aGUgZGV0YWlscyBvZiB0aGUgdGVzdCBzdHJlYW0gKGZvciBhY3RpdmUgbWVhc3VyZW1l bnQgd2l0aG91dCB1c2VyIHRyYWZmaWMsDQpvciBhY3RpdmUvaHlicmlkIG1lYXN1cmVtZW50IGR1 cmluZyB1c2VyIHRyYWZmaWMpIG5lZWQgdG8gYmUgYWdyZWVkLA0KYW5kIGV2ZW4gdGhlIHF1ZXN0 aW9uIG9mIHdoZXRoZXIgdGVzdHMgd2lsbCBiZSBjb25kdWN0ZWQgZHVyaW5nIHVzZXINCmFjdGl2 aXR5IG9yIG5vdCBuZWVkcyBkaXNjdXNzaW9uLCBtYXliZSB0aGlzIGlzIHRoZSBmaXJzdCBxdWVz dGlvbiB0bw0KYWRkcmVzcy4NCg0KQWwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQppcHBtIG1haWxpbmcgbGlzdA0KaXBwbUBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBt ------=_001_NextPart743871601751_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, all, to understand the link characteristic, d= oing=20 active or passive measurement during idle time is recommended; however, to= =20 evaluate the user experience or the QoS (quality of service) of internet=20 applications (like Web surfing, VoIP and network video, etc.), performing=20 measurement when the link is busy is recommended, since the user experienc= e or=20 the QoS of internet application may be degraded when the link is busy. I a= m=20 interested in the measurement during busy time, and are there any material= s=20 about this topic within this work group? I am not sure whether such topic = is=20 within the scope of this workgroup, any response is appreciated!=20

 
Best regards!
Guangqing=20 Deng
CNN= IC 
 
Date: 2012-12-03 12:14
To: Al Morton; Matt Mathis
CC: lmap@ietf.org; <= A=20 href=3D"mailto:ippm@ietf.org">ippm@ietf.org
Subject: [ippm] List of metrics
Currently, all the active metrics assume&nbs= p;an idle link, as the goal is to = measure the link performance without background&n= bsp;traffic. (We can leave out the only = ;passive metric, the total byte count, as&nb= sp;that's probably not all that interesting = for this discussion.)
 
At least from our experience, removing = samples due to user activity is not a&n= bsp;major problem, i.e., it removes only a&n= bsp;marginal number of busy-hour samples.
 
I don't see how any other measurement&n= bsp;policy can yield useful results for the&= nbsp;current metrics.
 
Henning
 
________________________________________
From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on=  behalf of Al Morton [acmorton@att.com]
Sent: Sunday, December 02, 2012 10:02 P= M
To: Henning Schulzrinne; Matt Mathis
Cc: ippm@ietf.org; Nicholas Weaver; Brian Tr= ammell; lmap@ietf.org
Subject: Re: [lmap] [ippm]  Focus on&nb= sp;Tests, Not Architectures...
 
 
Changing topics slightly, in the list:
http://transition.fcc.gov/cgb/measuringbroadbandreport/2012/Technical= -Appendix.pdf
(pg. 22)
 
I'd prefer to pare this down to st= art. Even where we have RFCs to refer&n= bsp;to,
the details of the test stream (for&nbs= p;active measurement without user traffic,
or active/hybrid measurement during user tra= ffic) need to be agreed,
and even the question of whether tests&= nbsp;will be conducted during user
activity or not needs discussion, maybe = ;this is the first question to
address.
 
Al
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
------=_001_NextPart743871601751_=------ From yaojk@cnnic.cn Tue Dec 25 18:01:46 2012 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 3F36121F8C19 for ; Tue, 25 Dec 2012 18:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.679 X-Spam-Level: X-Spam-Status: No, score=-98.679 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] 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 roafMNMi78cw for ; Tue, 25 Dec 2012 18:01:45 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 8E53221F8C17 for ; Tue, 25 Dec 2012 18:01:43 -0800 (PST) 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; Wed, 26 Dec 2012 10:01:36 +0800 Message-ID: <9277D4BDAB854FBB929155FB37642B09@LENOVO47E041CF> From: "Jiankang YAO" To: Date: Wed, 26 Dec 2012 10:04:52 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CDE350.72CF9CF0" 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] My introduction and preparing for the IPPM meeting at IETF 86 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, 26 Dec 2012 02:01:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01CDE350.72CF9CF0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbyBCaWxsLA0KDQogICBJdCBpcyBuaWNlIHRvIGhlYXIgeW91ciBiYWNrZ3JvdW5kIGluZm9y bWF0aW9uLg0KICAgDQogICBUaGUgR29hbHMgYW5kIE1pbGVzdG9uZXMgaW4gdGhlIGNoYXJ0ZXIg c2FpZDoNCg0KICAgICBEb25lICAgICAtIFN1Ym1pdCBkcmFmdCBvbiBzcGF0aWFsIGRlY29tcG9z aXRpb24gYW5kIG11bHRpY2FzdCBtZXRyaWNzIHRvIHRoZSBJRVNHDQogIE5vdiAyMDEwIC0gRmlu YWwgdmVyc2lvbiBvZiBwcm9jZXNzIGRyYWZ0DQogIE5vdiAyMDEwIC0gSW1wbGVtZW50YXRpb24g cmVwb3J0IGJhc2VkIG9uIHByb2Nlc3MgZHJhZnQNCiAgTWFyIDIwMTEgLSBSZXZpc2UgY2hhcnRl cg0KDQogDQogICBkbyB3ZSBuZWVkIHRvIHVwZGF0ZSB0aGUgR29hbHMgYW5kIE1pbGVzdG9uZXM/ DQoNCnRoYW5rcy4NCg0KSmlhbmthbmcgWWFvDQoNCg0KDQogICANCg0KDQoNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXBwbS1ib3VuY2VzIGF0IGlldGYub3JnIFttYWls dG86aXBwbS1ib3VuY2VzIGF0IGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmlsbCBDZXJ2ZW55DQpT ZW50OiBNb25kYXksIERlY2VtYmVyIDE3LCAyMDEyIDU6NTcgQU0NClRvOiBpcHBtIGF0IGlldGYu b3JnDQpTdWJqZWN0OiBbaXBwbV0gTXkgaW50cm9kdWN0aW9uIGFuZCBwcmVwYXJpbmcgZm9yIHRo ZSBJUFBNIG1lZXRpbmcgYXQgSUVURiA4Ng0KDQpEZWFyIElQUE0gYXV0aG9ycywgY29udHJpYnV0 b3JzIGFuZCBwYXJ0aWNpcGFudHMsDQoNCkknbSBob25vcmVkIGFuZCBleGNpdGVkIHRvIGJlIG5h bWVkIGEgY28tY2hhaXIgb2YgdGhlIElQUE0gd29ya2luZyBncm91cCBhbmQgdG8gYmUgZ2l2ZW4g dGhlIG9wcG9ydHVuaXR5IHRvIHN1cHBvcnQgdGhlIElQUE0gY29tbXVuaXR5IGluIHRoaXMgbWFu bmVyLiBJJ2QgbGlrZSB0byB0aGFuayBNYXR0IGFuZCBIZW5rIGZvciB0aGUgZXh0ZW5zaXZlIHdv cmsgdGhleSd2ZSBhY2NvbXBsaXNoZWQgYXMgSVBQTSBXRyBjaGFpcnMgYW5kIEkgbG9vayBmb3J3 YXJkIHRvIGZ1cnRoZXJpbmcgdGhlIHdvcmsgb2YgSVBQTS4NCg0KQSBsaXR0bGUgYmFja2dyb3Vu ZCBvbiB3aG8gSSBhbToNCg0KSSBhbSBjdXJyZW50bHkgYSBwcmluY2lwYWwgc29mdHdhcmUgcXVh bGl0eSBhc3N1cmFuY2UgZW5naW5lZXIgYXQgQXJib3IgTmV0d29ya3MuDQoNCk15IGVhcmxpZXN0 IGludm9sdmVtZW50IGluIEludGVybmV0IG1ldHJpY3MgYmVnYW4gd2hlbiBJIHdhcyBhc2tlZCB0 byByZXNlYXJjaCBwZXJmb3JtYW5jZSBtZXRyaWNzIGZvciB0aGUgUmVzZWFyY2ggYW5kIERldmVs b3BtZW50IEludGVybmV0IGF0IEFUJlQgQmVsbCBMYWJvcmF0b3JpZXMuICBTaG9ydGx5IGFmdGVy d2FyZCwgSSBhY2NlcHRlZCBhIHBvc2l0aW9uIHdpdGggQWR2YW5jZWQgTmV0d29yayBhbmQgU2Vy dmljZXMsIHdoZXJlIEkgaGVscGVkIGRlcGxveSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb25zIG9m IG9uZS13YXkgZGVsYXkgYW5kIG9uZS13YXkgcGFja2V0IGxvc3MsIHdvcmtpbmcgd2l0aCBHdXkg QWxtZXMsIE1hdHQgWmVrYXVza2FzIGFuZCBTdW5pbCBLYWxpZGluZGkuIEFmdGVyIEFkdmFuY2Vk IE5ldHdvcmsgYW5kIFNlcnZpY2VzLCBJIHdvcmtlZCBmb3IgSW50ZXJuZXQyLCBwcmltYXJpbHkg aW4gdGhlIGFkdmFuY2VkIHNlcnZpY2VzIGFyZWFzIChJUHY2IGFuZCBJUCBtdWx0aWNhc3QpLg0K DQpNeSByZWNlbnQgSUVURi1yZWxhdGVkIGludGVyZXN0cyBoYXZlIGJlZW4gd2l0aCB0aGUgQmVu Y2htYXJraW5nIE1ldGhvZG9sb2dpZXMgV29ya2luZyBHcm91cCBhcyB3ZWxsIGFzIHZhcmlvdXMg SVB2NiB3b3JraW5nIGdyb3Vwcy4NCg0KV2hpbGUgbW9zdCBvZiBteSBwcm9mZXNzaW9uYWwgZXhw ZXJpZW5jZSBoYXMgYmVlbiBhcyBhbiBJbnRlcm5ldCBwcm9mZXNzaW9uYWwgKGdlZWspLCBteSBl YXJseSBwcm9mZXNzaW9uYWwgZXhwZXJpZW5jZSB3YXMgYXMgYSBqb3VybmFsaXN0LCB3aGljaCBJ IGV4cGVjdCB3aWxsIGJlIGhlbHBmdWwgYXMgY28tY2hhaXIuIEkgZW5qb3kgd3JpdGluZyBhbmQg YW0gY29tZm9ydGFibGUgcmV2aWV3aW5nIGRvY3VtZW50cy4gSSBsb29rIGZvcndhcmQgdG8gdGhl IG9wcG9ydHVuaXR5IHRvIHByb3ZpZGUgYm90aCB0ZWNobmljYWwgYW5kIGdyYW1tYXRpY2FsIGZl ZWRiYWNrIG9uIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzIHRvIGhlbHAgZnVydGhlciB3b3JraW5n IGdyb3VwIGRvY3VtZW50cyBhbmQgY29udHJpYnV0aW9ucy4NCg0KVGhpcyBpcyBteSBmaXJzdCBl eHBlcmllbmNlIGFzIGFuIElFVEYgY28tY2hhaXIgYW5kIEknbSBzdGlsbCBsZWFybmluZyBhIGJp dCBhYm91dCB3aGF0IGNvLWNoYWlyaW5nIGFuZCBJRVRGIHdvcmtpbmcgZ3JvdXAgaXMgYWxsIGFi b3V0LiBJIGxvb2sgZm9yd2FyZCB0byB3b3JraW5nIHdpdGggcGVvcGxlIEkndmUga25vd24gZnJv bSB0aGUgYmVnaW5uaW5ncyBvZiB0aGUgSVBQTSB3b3JraW5nIGdyb3VwIGFzIHdlbGwgYXMgbmV3 IGNvbnRyaWJ1dG9ycy4gVGhlcmUgaXMgYSBsb3Qgb2YgbmV3IHdvcmsgYWhlYWQgb2YgdXMgYW5k IEknbSBnZW51aW5lbHkgbG9va2luZyBmb3J3YXJkIHRvIGRvaW5nIHdoYXQgSSBjYW4gdG8gcHJv bW90ZSB0aGVzZSBlZmZvcnRzLg0KDQpGaW5hbGx5LCByZWl0ZXJhdGluZyB3aGF0IElQUE0gY28t Y2hhaXIgQnJpYW4gVHJhbW1lbCBoYXMgYWxyZWFkeSBub3RlZCwgaXQncyBub3QgdG9vIGVhcmx5 IHRvIGJlZ2luIHBsYW5uaW5nIGZvciBJRVRGIDg2IGluIE9ybGFuZG8uIElmIHlvdSdkIGxpa2Ug dG8gZGlzY3VzcyBuZXcgaW5kaXZpZHVhbCBjb250cmlidXRpb25zIG9yIGluZGl2aWR1YWwgY29u dHJpYnV0aW9ucyB3aXRoIHNpZ25pZmljYW50IHVwZGF0ZXMsIHBsZWFzZSBwcm9wb3NlIGFnZW5k YSBpdGVtcyB0byB1cyB2aWEgdGhlIGUtbWFpbCBhZGRyZXNzIGlwcG0tY2hhaXJzIGF0IHRvb2xz LmlldGYub3JnLg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkJpbGwgQ2VydmVueQ0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBsaXN0DQpp cHBtIGF0IGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw cG0NCg== ------=_NextPart_000_0022_01CDE350.72CF9CF0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE5MzkzIj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jY2NlOGNmPg0KPERJVj48Rk9OVCBzaXplPTI+SGVsbyBCaWxsLDwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwO0l0IGlzIG5pY2UgdG8gaGVhciB5b3VyIGJhY2tn cm91bmQgDQppbmZvcm1hdGlvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJz cDsmbmJzcDsgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7IFRo ZSBHb2FscyBhbmQgTWlsZXN0b25lcyBpbiB0aGUgY2hhcnRlciANCnNhaWQ6PC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERvbmUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LSBTdWJtaXQgDQpkcmFmdCBvbiBzcGF0aWFsIGRlY29tcG9zaXRpb24gYW5kIG11bHRpY2FzdCBt ZXRyaWNzIHRvIHRoZSBJRVNHPEJSPiZuYnNwOyBOb3YgDQoyMDEwIC0gRmluYWwgdmVyc2lvbiBv ZiBwcm9jZXNzIGRyYWZ0PEJSPiZuYnNwOyBOb3YgMjAxMCAtIEltcGxlbWVudGF0aW9uIHJlcG9y dCANCmJhc2VkIG9uIHByb2Nlc3MgZHJhZnQ8QlI+Jm5ic3A7IE1hciAyMDExIC0gUmV2aXNlIA0K Y2hhcnRlcjxCUj48QlI+Jm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5i c3A7Jm5ic3A7IGRvIHdlIG5lZWQgdG8gdXBkYXRlIHRoZSBHb2FscyBhbmQgDQpNaWxlc3RvbmVz PzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPnRoYW5rcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5KaWFua2FuZyBZYW88L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDs8L0RJVj4NCjxESVY+PEJSPjwvRElWPjwv Rk9OVD4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyA8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPkZy b206IGlwcG0tYm91bmNlcyBhdCBpZXRmLm9yZyBbPEEgDQpocmVmPSJtYWlsdG86aXBwbS1ib3Vu Y2VzIiByZWw9bm9mb2xsb3c+bWFpbHRvOmlwcG0tYm91bmNlczwvQT4gYXQgaWV0Zi5vcmddIE9u IA0KQmVoYWxmIE9mIEJpbGwgQ2VydmVueTxCUj5TZW50OiBNb25kYXksIERlY2VtYmVyIDE3LCAy MDEyIDU6NTcgQU08QlI+VG86IGlwcG0gYXQgDQppZXRmLm9yZzxCUj5TdWJqZWN0OiBbaXBwbV0g TXkgaW50cm9kdWN0aW9uIGFuZCBwcmVwYXJpbmcgZm9yIHRoZSBJUFBNIG1lZXRpbmcgDQphdCBJ RVRGIDg2PEJSPjxCUj5EZWFyIElQUE0gYXV0aG9ycywgY29udHJpYnV0b3JzIGFuZCBwYXJ0aWNp cGFudHMsPEJSPjxCUj5JJ20gDQpob25vcmVkIGFuZCBleGNpdGVkIHRvIGJlIG5hbWVkIGEgY28t Y2hhaXIgb2YgdGhlIElQUE0gd29ya2luZyBncm91cCBhbmQgdG8gYmUgDQpnaXZlbiB0aGUgb3Bw b3J0dW5pdHkgdG8gc3VwcG9ydCB0aGUgSVBQTSBjb21tdW5pdHkgaW4gdGhpcyBtYW5uZXIuIEkn ZCBsaWtlIHRvIA0KdGhhbmsgTWF0dCBhbmQgSGVuayBmb3IgdGhlIGV4dGVuc2l2ZSB3b3JrIHRo ZXkndmUgYWNjb21wbGlzaGVkIGFzIElQUE0gV0cgDQpjaGFpcnMgYW5kIEkgbG9vayBmb3J3YXJk IHRvIGZ1cnRoZXJpbmcgdGhlIHdvcmsgb2YgSVBQTS48QlI+PEJSPkEgbGl0dGxlIA0KYmFja2dy b3VuZCBvbiB3aG8gSSBhbTo8QlI+PEJSPkkgYW0gY3VycmVudGx5IGEgcHJpbmNpcGFsIHNvZnR3 YXJlIHF1YWxpdHkgDQphc3N1cmFuY2UgZW5naW5lZXIgYXQgQXJib3IgTmV0d29ya3MuPEJSPjxC Uj5NeSBlYXJsaWVzdCBpbnZvbHZlbWVudCBpbiBJbnRlcm5ldCANCm1ldHJpY3MgYmVnYW4gd2hl biBJIHdhcyBhc2tlZCB0byByZXNlYXJjaCBwZXJmb3JtYW5jZSBtZXRyaWNzIGZvciB0aGUgUmVz ZWFyY2ggDQphbmQgRGV2ZWxvcG1lbnQgSW50ZXJuZXQgYXQgQVQmYW1wO1QgQmVsbCBMYWJvcmF0 b3JpZXMuJm5ic3A7IFNob3J0bHkgYWZ0ZXJ3YXJkLCANCkkgYWNjZXB0ZWQgYSBwb3NpdGlvbiB3 aXRoIEFkdmFuY2VkIE5ldHdvcmsgYW5kIFNlcnZpY2VzLCB3aGVyZSBJIGhlbHBlZCBkZXBsb3kg DQpyZWZlcmVuY2UgaW1wbGVtZW50YXRpb25zIG9mIG9uZS13YXkgZGVsYXkgYW5kIG9uZS13YXkg cGFja2V0IGxvc3MsIHdvcmtpbmcgd2l0aCANCkd1eSBBbG1lcywgTWF0dCBaZWthdXNrYXMgYW5k IFN1bmlsIEthbGlkaW5kaS4gQWZ0ZXIgQWR2YW5jZWQgTmV0d29yayBhbmQgDQpTZXJ2aWNlcywg SSB3b3JrZWQgZm9yIEludGVybmV0MiwgcHJpbWFyaWx5IGluIHRoZSBhZHZhbmNlZCBzZXJ2aWNl cyBhcmVhcyAoSVB2NiANCmFuZCBJUCBtdWx0aWNhc3QpLjxCUj48QlI+TXkgcmVjZW50IElFVEYt cmVsYXRlZCBpbnRlcmVzdHMgaGF2ZSBiZWVuIHdpdGggdGhlIA0KQmVuY2htYXJraW5nIE1ldGhv ZG9sb2dpZXMgV29ya2luZyBHcm91cCBhcyB3ZWxsIGFzIHZhcmlvdXMgSVB2NiB3b3JraW5nIA0K Z3JvdXBzLjxCUj48QlI+V2hpbGUgbW9zdCBvZiBteSBwcm9mZXNzaW9uYWwgZXhwZXJpZW5jZSBo YXMgYmVlbiBhcyBhbiBJbnRlcm5ldCANCnByb2Zlc3Npb25hbCAoZ2VlayksIG15IGVhcmx5IHBy b2Zlc3Npb25hbCBleHBlcmllbmNlIHdhcyBhcyBhIGpvdXJuYWxpc3QsIHdoaWNoIA0KSSBleHBl Y3Qgd2lsbCBiZSBoZWxwZnVsIGFzIGNvLWNoYWlyLiBJIGVuam95IHdyaXRpbmcgYW5kIGFtIGNv bWZvcnRhYmxlIA0KcmV2aWV3aW5nIGRvY3VtZW50cy4gSSBsb29rIGZvcndhcmQgdG8gdGhlIG9w cG9ydHVuaXR5IHRvIHByb3ZpZGUgYm90aCB0ZWNobmljYWwgDQphbmQgZ3JhbW1hdGljYWwgZmVl ZGJhY2sgb24gd29ya2luZyBncm91cCBkb2N1bWVudHMgdG8gaGVscCBmdXJ0aGVyIHdvcmtpbmcg DQpncm91cCBkb2N1bWVudHMgYW5kIGNvbnRyaWJ1dGlvbnMuPEJSPjxCUj5UaGlzIGlzIG15IGZp cnN0IGV4cGVyaWVuY2UgYXMgYW4gSUVURiANCmNvLWNoYWlyIGFuZCBJJ20gc3RpbGwgbGVhcm5p bmcgYSBiaXQgYWJvdXQgd2hhdCBjby1jaGFpcmluZyBhbmQgSUVURiB3b3JraW5nIA0KZ3JvdXAg aXMgYWxsIGFib3V0LiBJIGxvb2sgZm9yd2FyZCB0byB3b3JraW5nIHdpdGggcGVvcGxlIEkndmUg a25vd24gZnJvbSB0aGUgDQpiZWdpbm5pbmdzIG9mIHRoZSBJUFBNIHdvcmtpbmcgZ3JvdXAgYXMg d2VsbCBhcyBuZXcgY29udHJpYnV0b3JzLiBUaGVyZSBpcyBhIGxvdCANCm9mIG5ldyB3b3JrIGFo ZWFkIG9mIHVzIGFuZCBJJ20gZ2VudWluZWx5IGxvb2tpbmcgZm9yd2FyZCB0byBkb2luZyB3aGF0 IEkgY2FuIHRvIA0KcHJvbW90ZSB0aGVzZSBlZmZvcnRzLjxCUj48QlI+RmluYWxseSwgcmVpdGVy YXRpbmcgd2hhdCBJUFBNIGNvLWNoYWlyIEJyaWFuIA0KVHJhbW1lbCBoYXMgYWxyZWFkeSBub3Rl ZCwgaXQncyBub3QgdG9vIGVhcmx5IHRvIGJlZ2luIHBsYW5uaW5nIGZvciBJRVRGIDg2IGluIA0K T3JsYW5kby4gSWYgeW91J2QgbGlrZSB0byBkaXNjdXNzIG5ldyBpbmRpdmlkdWFsIGNvbnRyaWJ1 dGlvbnMgb3IgaW5kaXZpZHVhbCANCmNvbnRyaWJ1dGlvbnMgd2l0aCBzaWduaWZpY2FudCB1cGRh dGVzLCBwbGVhc2UgcHJvcG9zZSBhZ2VuZGEgaXRlbXMgdG8gdXMgdmlhIA0KdGhlIGUtbWFpbCBh ZGRyZXNzIGlwcG0tY2hhaXJzIGF0IHRvb2xzLmlldGYub3JnLjxCUj48QlI+QmVzdCANClJlZ2Fy ZHMsPEJSPjxCUj5CaWxsIA0KQ2VydmVueTxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxCUj5pcHBtIG1haWxpbmcgDQpsaXN0PEJSPmlwcG0gYXQgaWV0 Zi5vcmc8QlI+PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHBtIiANCnJlbD1ub2ZvbGxvdz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwcG08L0E+PEJSPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0022_01CDE350.72CF9CF0-- From dengguangqing@cnnic.cn Sun Dec 30 05:49:14 2012 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 A8F3521F8979 for ; Sun, 30 Dec 2012 05:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.039 X-Spam-Level: X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 QlOcxcHopwV2 for ; Sun, 30 Dec 2012 05:49:14 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 6305421F8973 for ; Sun, 30 Dec 2012 05:49:13 -0800 (PST) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO dgq-pc) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 30 Dec 2012 21:49:08 +0800 Date: Sun, 30 Dec 2012 21:49:19 +0800 From: dengguangqing To: ippm References: <20121221140418.20749.35939.idtracker@ietfa.amsl.com>, <7.0.1.0.0.20121221090459.04a18888@att.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201212302149186531281@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart181852362000_=----" Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dengguangqing List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 13:49:14 -0000 This is a multi-part message in MIME format. ------=_001_NextPart181852362000_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBhbSBpbnRlcmVzdGVkIGluIHJhdGUgbWVhc3VyZW1lbnQsIGFuZCBoYXZlIHRoZXNlIHR3byBz b2x1dGlvbnMgKG5hbWVseSBkcmFmdC1tb3J0b24taXBwbS10d2FtcC1yYXRlIGFuZCBkcmFmdC1t YXRoaXMtaXBwbS1tb2RlbC1iYXNlZC1tZXRyaWNzKSBldmVyIGJlZW4gYXBwbGllZCB0byBwcmFj dGljZT8gDQoNCg0KDQoNCkd1YW5ncWluZyBEZW5nDQpjbm5pYyANCg0KRnJvbTogQWwgTW9ydG9u DQpEYXRlOiAyMDEyLTEyLTIxIDIyOjExDQpUbzogaXBwbQ0KU3ViamVjdDogUmU6IFtpcHBtXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlwcG0tcmF0ZS1wcm9ibGVtLTAxLnR4dA0KVGhpcyB1cGRh dGUgYWRkcmVzc2VzIGNvbW1lbnRzIGZyb20gb3VyIHJlY2VudCBzZXNzaW9uIChJRVRGLTg1KSwN CmFzIHdlbGwgYXMgQmlsbCBDZXJ2ZW55J3MgcmV2aWV3L2NvbW1lbnRzIChvZmYtbGlzdCwgdGhh bmtzIEJpbGwpLg0KDQpUaGVyZSBhcmUgYWxyZWFkeSBzb2x1dGlvbnMgdG8gdGhlIHByb2JsZW0g aW4gY2lyY3VsYXRpb246DQpkcmFmdC1tb3J0b24taXBwbS10d2FtcC1yYXRlICBmb3IgcHJvdG9j b2wNCmRyYWZ0LW1hdGhpcy1pcHBtLW1vZGVsLWJhc2VkLW1ldHJpY3MgZm9yIG1ldGhvZHMgb2Yg bWVhc3VyZW1lbnQNCg0KcmVnYXJkcywNCkFsDQoNCkF0IDA5OjA0IEFNIDEyLzIxLzIwMTIsIGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMu DQogVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVAgUGVyZm9ybWFuY2UgTWV0cmlj cyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KDQogICAgICAgICBUaXRsZSAgICAgICAgICAg OiBSYXRlIE1lYXN1cmVtZW50IFByb2JsZW0gU3RhdGVtZW50DQogICAgICAgICBBdXRob3Iocykg ICAgICAgOiBBbCBNb3J0b24NCiAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYt aXBwbS1yYXRlLXByb2JsZW0tMDEudHh0DQogICAgICAgICBQYWdlcyAgICAgICAgICAgOiAxMA0K ICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxMi0xMi0yMQ0KDQpBYnN0cmFjdDoNCiAgIFRo ZXJlIGlzIGEgcmF0ZSBtZWFzdXJlbWVudCBzY2VuYXJpbyB3aGljaCBoYXMgd2lkZS1zcHJlYWQg YXR0ZW50aW9uDQogICBvZiBJbnRlcm5ldCBhY2Nlc3Mgc3Vic2NyaWJlcnMgYW5kIHNlZW1pbmds eSBhbGwgaW5kdXN0cnkgcGxheWVycywNCiAgIGluY2x1ZGluZyByZWd1bGF0b3JzLiAgVGhpcyBt ZW1vIHByZXNlbnRzIGFuIGFjY2VzcyByYXRlLW1lYXN1cmVtZW50DQogICBwcm9ibGVtIHN0YXRl bWVudCBmb3IgSVAgUGVyZm9ybWFuY2UgTWV0cmljcy4gIEtleSB0ZXN0IHByb3RvY29sDQogICBh c3BlY3RzIHJlcXVpcmUgdGhlIGFiaWxpdHkgdG8gY29udHJvbCBwYWNrZXQgc2l6ZSBvbiB0aGUg dGVzdGVkIHBhdGgNCiAgIGFuZCBlbmFibGUgYXN5bW1ldHJpY2FsIHBhY2tldCBzaXplIHRlc3Rp bmcgaW4gYSBjb250cm9sbGVyLXJlc3BvbmRlcg0KICAgYXJjaGl0ZWN0dXJlLg0KDQoNCg0KVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwcG0tcmF0ZS1wcm9ibGVtDQoN ClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLXJhdGUtcHJvYmxlbS0wMQ0KDQpBIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWlwcG0tcmF0ZS1wcm9ibGVtLTAxDQoN Cg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0 Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBsaXN0DQppcHBt QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0= ------=_001_NextPart181852362000_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
I= am=20 interested in rate measurement, and have these two solutions (namely=20 draft-morton-ippm-twamp-rate and draft-mathis-ippm-model-based-m= etrics)=20 ever been applied to practice?=20
 
Gua= ngqing=20 Deng
cnnic 
 
From: Al Morton
Date: 2012-12-21 22:11
To: ippm
Subject: Re: [ippm] I-D Action:=20 draft-ietf-ippm-rate-problem-01.txt
This update addresses comments fro= m our=20 recent session (IETF-85),
as well as Bill Cerveny's review/comments=20 (off-list, thanks Bill).

There are already solutions to the problem= in=20 circulation:
draf= t-morton-ippm-twamp-rate =20 for protocol
draft-mathis-ippm-model-based-metrics=20 for methods of measurement

regards,
Al

At 09:04 AM 12/21/= 2012,=20 internet-drafts@ietf.org wrote:

A New Internet-Draft is a= vailable=20 from the on-line Internet-Drafts directories.
 This draft is a w= ork=20 item of the IP Performance Metrics Working Group of the=20 IETF.

        =20 Title           : Rate= =20 Measurement Problem=20 Statement
        =20 Author(s)       : Al=20 Morton
        =20 Filename        :=20 draft-ietf-ippm-rate-problem-01.txt
    &n= bsp;   =20 Pages           :=20 10
        =20 Date            := =20 2012-12-21

Abstract:
   There is a rate measurement=20 scenario which has wide-spread attention
   of Internet acc= ess=20 subscribers and seemingly all industry players,
   includin= g=20 regulators.  This memo presents an access=20 rate-measurement
   problem statement for IP Performance=20 Metrics.  Key test protocol
   aspects require the abi= lity=20 to control packet size on the tested path
   and enable=20 asymmetrical packet size testing in a controller-responder
 &nbs= p;=20 architecture.



The IETF datatracker status page for this d= raft=20 is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-rate= -problem

There's=20 also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ippm-rate-probl= em-01

A=20 diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-ra= te-problem-01


Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

______= _________________________________________
ippm=20 mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
------=_001_NextPart181852362000_=------ From acmorton@att.com Mon Dec 31 05:42:58 2012 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 7185C21F8815 for ; Mon, 31 Dec 2012 05:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.155 X-Spam-Level: X-Spam-Status: No, score=-105.155 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 H5dE1zuqLM5v for ; Mon, 31 Dec 2012 05:42:57 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 469D321F87FD for ; Mon, 31 Dec 2012 05:42:57 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 06691e05.0.304527.00-490.836790.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 31 Dec 2012 13:42:57 +0000 (UTC) X-MXL-Hash: 50e1966111f37571-4c36fb80782b1364dfa933d885991f1c51628e54 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qBVDgtae031896 for ; Mon, 31 Dec 2012 05:42:56 -0800 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qBVDgo6X031843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 31 Dec 2012 05:42:53 -0800 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor) for ; Mon, 31 Dec 2012 05:42:22 -0800 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qBVDgLZ0013412 for ; Mon, 31 Dec 2012 08:42:21 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qBVDgHoJ013360 for ; Mon, 31 Dec 2012 08:42:18 -0500 Received: from lt-hp1044652.att.com (vpn-135-70-203-193.vpn.east.att.com[135.70.203.193](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121231134151gw100632doe>; Mon, 31 Dec 2012 13:41:52 +0000 X-Originating-IP: [135.70.203.193] Message-Id: <7.0.1.0.0.20121231083425.04956f38@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 31 Dec 2012 08:39:36 -0500 To: dengguangqing , ippm From: Al Morton In-Reply-To: <201212302149186531281@cnnic.cn> References: <20121221140418.20749.35939.idtracker@ietfa.amsl.com> <7.0.1.0.0.20121221090459.04a18888@att.com> <201212302149186531281@cnnic.cn> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=Uu3UwZMB c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=8CrkLz0H4DIA:10 a=qevIr9MzNokA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=lKOzZDsA] X-AnalysisOut: [1IEA:10 a=48vgC7mUAAAA:8 a=OFDxwEFwAv8t9V_lns8A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=_W_S_7VecoQA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVv] X-AnalysisOut: [QA:10 a=nC0DhsEwgkzJuz0W:21] Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-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, 31 Dec 2012 13:42:58 -0000 The short answer is "yes, in a way" (for both drafts),
but you'll have to wait to see results in a contribution.

Al

At 08:49 AM 12/30/2012, dengguangqing wrote:
I am interested in rate measurement, and have these two solutions (namely draft-morton-ippm-twamp-rate and draft-mathis-ippm-model-based-metrics) ever been applied to practice?
 

Guangqing Deng
cnnic
 
From: Al Morton
Date: 2012-12-21 22:11
To: ippm
Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-01.txt
This update addresses comments from our recent session (IETF-85),
as well as Bill Cerveny's review/comments (off-list, thanks Bill).

There are already solutions to the problem in circulation:
draft-morton-ippm-twamp-rate  for protocol
draft-mathis-ippm-model-based-metrics for methods of measurement

regards,
Al

At 09:04 AM 12/21/2012, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Performance Metrics Working Group of the IETF.

         Title           : Rate Measurement Problem Statement
         Author(s)       : Al Morton
         Filename        : draft-ietf-ippm-rate-problem-01.txt
         Pages           : 10
         Date            : 2012-12-21

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 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-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-rate-problem-01


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