From acmorton@att.com Wed Aug 1 11:28:20 2012 Return-Path: X-Original-To: pmol@ietfa.amsl.com Delivered-To: pmol@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7AF11E83AF; Wed, 1 Aug 2012 11:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.665 X-Spam-Level: X-Spam-Status: No, score=-105.665 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVIwr7tuPfGG; Wed, 1 Aug 2012 11:28:18 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7B511E81CE; Wed, 1 Aug 2012 11:28:17 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 14579105.0.936502.00-329.2573193.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 01 Aug 2012 18:28:18 +0000 (UTC) X-MXL-Hash: 5019754209200271-51fcd31c5f9e07a910883ef4a3aa34571a7080e7 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 q71ISGSU017699; Wed, 1 Aug 2012 14:28:17 -0400 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 q71ISDlZ017696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 14:28:14 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor); Wed, 1 Aug 2012 14:27:58 -0400 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 q71IRvQx024903; Wed, 1 Aug 2012 14:27:57 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q71IRpOV024697; Wed, 1 Aug 2012 14:27:52 -0400 Message-Id: <201208011827.q71IRpOV024697@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-240-95.vpn.east.att.com[135.70.240.95](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120801182319gw10025cufe>; Wed, 1 Aug 2012 18:23:20 +0000 X-Originating-IP: [135.70.240.95] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Aug 2012 14:27:23 -0400 To: tsvwg@ietf.org From: Al Morton 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.20.145] X-AnalysisOut: [v=1.0 c=1 a=zSOqplUit0gA:10 a=dRNClBhXWMcA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=0FD05c-RAAAA:8 a=48vgC7mUAAAA:8 a=hZG83p_y] X-AnalysisOut: [AAAA:8 a=2UFH3SNg1t3ncIyfiP8A:9 a=CjuIK1q_8ugA:10 a=3qFsgw] X-AnalysisOut: [-wyTgA:10 a=jM_x9b4JT8QA:10 a=f7GxY0FH8QIA:10 a=lZB815dzVv] X-AnalysisOut: [QA:10 a=qgRezc3XQjWTNDXG:21 a=kNLUO4gSpudhLnv1:21] Cc: pmol@ietf.org Subject: [PMOL] Fwd: Re: Fwd: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:28:20 -0000 tsvwg, When I saw this draft >Zhu Lei - Flow-based Performance Measurement (10 min) >draft-sun-tsvwg-flowbased-pm on the I-D announcement list, I asked for and received a review from the Performance Metrics Directorate. I've inserted a few of my own comments below. We try to do early review when requested by WG chairs, and since this draft is now on the tsvwg agenda we are sharing our comments with the tsvwg list. Overall, I would like to suggest that the authors examine the IPPM measurement protocols more fully and implement them to see if their need for flow-based measurement can be met without developing new protocols. Al PMDir admin >From: Andreas Johnsson A >To: "pmol@ietf.org" >Date: Mon, 2 Jul 2012 11:31:22 +0200 > > >Hi, >I have tried to put together a short review. Please see my comments >below (and please provide further comments). [ACM] = Al's additional comments. >Best regards, >Andreas Johnsson > >----- > >Comments on draft-sun-tsvwg-flowbased-pm-00.txt. > >1) The draft describes a new active measurement protocol with the >aim of measuring delay, jitter and loss over an IP path. The >protocol is similar to TWAMP (RFC5357), however the measurement >setup is performed in a TCP-like manner instead of using a specific >control plane. Despite its similarities to TWAMP there are no >references nor does the draft contain a comparison. > >2) The draft includes a description on how to calculate statistics >based on time stamps obtained by the protocol. The metrics are >delay, jitter and loss. An advice is to use RFC 6390 section 5.4.5 >guidelines for describing the metrics. > >3) The draft does not prior art in IPPM (or elsewhere) >related to delay, jitter or loss. Suggested documents are > >IPPM Delay (http://tools.ietf.org/html/rfc2679) >IPPM Loss (http://tools.ietf.org/html/rfc2680) >IPPM Delay variation (http://www.ietf.org/rfc/rfc3393.txt) [ACM] IPPM Packet Reordering RFC 4737 >ITU-T Y.1540 (http://www.itu.int/rec/T-REC-Y.1540-200711-S) > >4) I would like the authors to elaborate on their delay calculation >method. The draft assumes that the forward delay is always equal to >the reverse delay. How often is this the case? > >5) The jitter calculations are based upon the delay calculations. >Since the delay is calculated as the RTT (minus the time a packet >spends at the PM responder) divided by 2, the jitter will be the >same in both directions. Does this really reflect what is happening >on the path? Please elaborate on this. [ACM] In general, the statistics suggested here are not widely used, especially the jitter as delay variance. Suggest that the authors look at http://tools.ietf.org/html/rfc5481 and decide what measurement task and PDV method suits their needs. >-----Original Message----- >From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf >Of Al Morton >Sent: den 29 juni 2012 13:58 >To: pmol@ietf.org >Subject: [PMOL] Fwd: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt > >After reading the abstract, ... > >Would anyone volunteer to review this in a timely way? > >Al >PMDir admin > > > >From: internet-drafts@ietf.org > >To: i-d-announce@ietf.org > >Subject: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt > >X-Test-IDTracker: no > >X-IETF-IDTracker: 4.21p1 > >Date: Fri, 29 Jun 2012 01:40:50 -0700 > >X-BeenThere: i-d-announce@ietf.org > >X-Mailman-Version: 2.1.12 > >Reply-To: internet-drafts@ietf.org > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Flow-based Performance Measurement > > Author(s) : Lishun Sun > > Wendong Wang > > Fang Yu > > Filename : draft-sun-tsvwg-flowbased-pm-00.txt > > Pages : 15 > > Date : 2012-06-29 > > > >Abstract: > > The performance measurements of service flow are becoming significant > > important for administrators monitoring the fitness of the network. > > This memo defines an end-to-end application-based performance > > measurement method, which is achieved by generating synthetic > > measurement packets, injecting them to the network and analyzing the > > statistics carried in the measurement packets. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-sun-tsvwg-flowbased-pm > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-sun-tsvwg-flowbased-pm-00 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html or > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >PMOL mailing list >PMOL@ietf.org >https://www.ietf.org/mailman/listinfo/pmol >_______________________________________________ >PMOL mailing list >PMOL@ietf.org >https://www.ietf.org/mailman/listinfo/pmol From janovak@cisco.com Fri Aug 3 07:40:03 2012 Return-Path: X-Original-To: pmol@ietfa.amsl.com Delivered-To: pmol@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3CD21F8463; Fri, 3 Aug 2012 07:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmnRDfU6EUlo; Fri, 3 Aug 2012 07:40:02 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BBD9321F8DC0; Fri, 3 Aug 2012 07:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=janovak@cisco.com; l=2875; q=dns/txt; s=iport; t=1344004802; x=1345214402; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2rmf9ehrhIvQCY5pWkaFFgCw2ZQio0fkGCwU+3yA/G8=; b=PYJVWlupLrS3IJfDa9JBoxh6nbosJ/OV64piO4RdJO1cRqxpxTvX084M +2sQSXTCw63PoXGyJ2nu4wJ5BH8W++YJhNSU5StbBnhzfq/e8QWItIL1I Uk9VzMrYnwkd+4sDIpFeyc0c2KanIQmXT8gZGM0LreD69dSvZv3Cx8dSX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB7iG1CtJXG8/2dsb2JhbABFuRyBB4IgAQEBBBIBJz8MBAIBCBEEAQELFBAyHQgBAQQBDQUIGodrnESgKotIhiRgA6NxgWaCXw X-IronPort-AV: E=Sophos;i="4.77,706,1336348800"; d="scan'208";a="108211278" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 03 Aug 2012 14:40:01 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q73Ee15L003563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 14:40:01 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 09:40:01 -0500 From: "Jan Novak (janovak)" To: "Aamer Akhter (aakhter)" , "'ipfix@ietf.org'" , "'opsawg@ietf.org'" Thread-Topic: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Thread-Index: Ac0zc8BXTR41oCKqTcOQDS4l95WyzAEhILoQDYLiRuAA4E6qQA== Date: Fri, 3 Aug 2012 14:40:00 +0000 Message-ID: References: <201205161453.q4GErZNl015927@alpd052.aldc.att.com> <75C0E47A1889264493A2DCB2869AC0960F50A853@xmb-rcd-x15.cisco.com> In-Reply-To: <75C0E47A1889264493A2DCB2869AC0960F50A853@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.89.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--42.180200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hendrik Scholz , "'pmol@ietf.org'" Subject: Re: [PMOL] Comments on draft-akhter-opsawg-perfmon-ipfix-02 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:40:03 -0000 Hi again, Thanks for applying the comments. AA> Jan, can you look again ? Is there still a problem? No, sorry missed the TBD or its significance. AA> We're open to adding scope (as defined as which set of packets would th= is be applicable to). AA> Would you agree that this is more of a methodology item than a IE item? Yes, indeed, whichever of Observation domain/Scope it is, it is not the pro= perty of the IE. Jan The climate of Edinburgh is such that the weak succumb young, and the strong envy them .... Dr. Johnson -----Original Message----- From: Aamer Akhter (aakhter)=20 Sent: 30 July 2012 16:50 To: Jan Novak (janovak); 'ipfix@ietf.org'; 'opsawg@ietf.org' Cc: 'Al Morton'; 'pmol@ietf.org'; Hendrik Scholz Subject: RE: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Hi Jan, Thank-you for the review. Please find my comments below. We Hendrik and I w= ill be publishing -03 shortly.=20 -----Original Message----- From: Jan Novak (janovak)=20 Sent: Tuesday, May 22, 2012 4:58 AM To: Aamer Akhter (aakhter); ipfix@ietf.org; opsawg@ietf.org Cc: Al Morton; pmol@ietf.org Subject: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Hi Amer, I have reviewed your draft draft-akhter-opsawg-perfmon-ipfix-02.txt. There seems to be a lot of text overlap with your methodology document - se= ction 1,3, 4 could probably be abbreviated or omitted leaving the document = just with raw IPFIX IE specifications or just add the IE specification as s= ub-sections or a new section into the first document ??=20 AA> I agree that there is overlap, but it was retained for readability. But= I see your point regarding keeping the focus on the IEs in the IPFIX versi= on of the draft. Will strip some of the detail in the IPFIX version. Section 2 uses definitions from RFC5610 - I think those you use there are d= efined in RFC5102 as DataTypeSemantic, units and range while RFC5610 specifies how this information should be exported - here you are de= fining the IE itself so you should use the definitions from RFC5102 AA> I think I had used RFC5610 as it seemed to be a bit more specific about= it (eg rangeBegin and rangeEnd rather than just range). But we are fine e= ither way depending on feedback. Also the methodology documents already speaks in terms of IPFIX IEs while y= ou are trying to specify some performance metrics - the methodology could h= ave names and an exact definitions of the metric and then a reference which= IE represents the particular metric AA> will update the methodology doc with exact definitions and reference th= e IEs.=20 RFC5102 section 2.1 specifies a template for IEs with a MUST so the MUST en= tries should be literally followed in your IEs spec - namely name, elementID, description, dataType and status. From grace.yufang@huawei.com Fri Aug 17 02:35:47 2012 Return-Path: X-Original-To: pmol@ietfa.amsl.com Delivered-To: pmol@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7636021F84D3; Fri, 17 Aug 2012 02:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nkuGvDGR6Wv; Fri, 17 Aug 2012 02:35:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E28B321F841A; Fri, 17 Aug 2012 02:35:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJM30514; Fri, 17 Aug 2012 01:35:42 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Aug 2012 02:33:53 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Aug 2012 02:34:00 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.6]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Fri, 17 Aug 2012 17:33:49 +0800 From: Yufang To: Al Morton , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Fwd: Re: [PMOL] Fwd: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt Thread-Index: AQHNcBNxwMkeNQvYckWgLO7p5C52x5dd0cfA Date: Fri, 17 Aug 2012 09:33:48 +0000 Message-ID: <038A8B767A209346A5C39B552E514A920F92B5B2@szxeml546-mbs.china.huawei.com> References: <201208011827.q71IRpOV024697@alpd052.aldc.att.com> In-Reply-To: <201208011827.q71IRpOV024697@alpd052.aldc.att.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.64.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 17 Aug 2012 05:58:06 -0700 Cc: Peter McCann , Yufang , "pmol@ietf.org" , Zhulei Subject: Re: [PMOL] [tsvwg] Fwd: Re: Fwd: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 09:35:47 -0000 Hi Morton and Andreas,=20 Thanks for your comments. I have read the RFCs and give comments as follow. We called the method we proposed FPM. 1. The differences between TWAMP and FPM: (1) Technically, although FPM is an active measurement protocol, there exis= t much difference between TWAMP and FPM. First, TWAMP and FPM both support = the on-the-spot measurement, it means that they can perform measurement onl= ine=20 when traffic of applications is running. But TWAMP is probe based, in TWAMP= , extra probe measurement packets are injected to simulate real traffic, to= carry out measurements and sample the performance of the network. The freq= uency=20 of injected packets has great impact on the accuracy of measurements. For e= xample, if TWAMP wants to measure an application that transmits packets fre= quently, it should also injected probe measurement packets (TWAMP-test pack= ets) frequently, then it may make negative impact on the real traffic of ap= plications, otherwise it can't reflect the actual service performance if th= e TWAMP-test packets are sparsely inserted. FPM is based on the running traffic of applications, it collects the statis= tics of real traffic flow. FPM needs additional OAM packets participate in = measurement. The OAM packets are used to carry statistics of the path/flow/= application, they can be small and the inserted frequency can be lower. (2) In addition, in some cases, it needs to monitor the various time-varyin= g performance indexes of the IP network, the performance measurement should= be based on real traffic and reflect the real performance of the network.= =20 IP Performance Monitoring based on flow/applications is needed in many case= s. For example, in mobile operator's backhaul network, there must be perfor= mance monitoring mechanism to check the traffic status in the network, and = the applications/traffic are divided into multiple bearers with proper mobi= le QoS parameters (e.g. QCI). If the mobile network would manage bearers as= QoS and applications, then the performance of backhaul is more like to be = based on applications or QoS. With the status information, some strategies = can be implemented, for example, eNB can implement online congestion contro= l and bandwidth adjustment strategy based on the performance monitoring res= ult. TWAMP may be able to do flow-based measurement by specifying DSCP for the T= WAMP-test packets. But it can't well support the online measurement and len= gth of test packets is changeless and not varying as the real traffic packe= ts. The average performance indexes measured by this method may not be suit= able in these cases. =20 (3) For further detailed analysis: 1) Measurement Control=20 TWAMP actually consists of two parts: TWAMP-Control and TWAMP-Test. TWAMP-C= ontrol is used to initiate, start, and stop test sessions, whereas TWAMP-Te= st is used to exchange test packets between two TWAMP entities. FPM also consists of two parts: connection control and measurement process.= The Connection control consists of two parts: Connection Activation and Co= nnection Deactivation. The Connection Activation is to setup measurements, = whereas the Connection Deactivation is to stop the measurements. Actually, similar to the session initiation of TWAMP, during the Connection= Activation process of FPM, it supports the negotiation of the measurement = flow, such as the negotiation of the sender and receiver addresses and port= numbers, protocol type, periods of the measurement, DSCP in some cases. Th= ese parameters are used to extract the packets of a specific flow while the= re are several types of flow between the sender and the receiver. =20 However, the TWAMP-Control also supports the per-session encryption and aut= hentication for the control and test traffic, while the connection control = of FPM doesn't do any security mechanism in its current release (more infor= mation about security will be provided later.). For FPM doesn't use a specific control plane, and there are great differenc= es between FPM and TWAMP in security mechanism, FPM seems simpler. 2) Packets used for measurement There are eight types of packets in TWAMP besides TWAMP-Test packet. The se= rver Greeting message, Set-Up- Response message and Server-Start message ar= e used for connection setup. Request-TW-Session message and Accept-Sessions= message are used for creating test sessions. Start-Sessions message and St= art-Ack message are used for starting test sessions. Stop-Sessions message = is used to stop the session.=20 The negotiation of test Modes is carried out during the connection setup pr= ocess, if the selected Mode is not the authenticated mode and/or encrypted = mode, the encryption and authentication are also implemented. That's why TW= AMP has so many types of control packets. There are six types of packets in FPM, which include four types of control = packets (ACT, ACT-ACK, DEA, DEA-ACK) and two types of measurement packets (= FM and BR). For each measurement, the TWAMP-control messages are usually only transmitt= ed once. So packets size of these messages has little impact on the network= . But TWAMP-test packets are constantly transmitted during a test session. = So the high transmitted frequency and/or large packet size may influence th= e real traffic. As mentioned in RFC5357, the padding size of the TWAMP-test packets is at l= east 27 octets in unauthenticated mode, and at least 56 octets in authentic= ated and encrypted modes. Then the size of the TWAMP-test packets is at lea= st 56 octets in unauthenticated mode, and at least 156 octets in authentica= ted and encrypted modes. However, the size of the FPM FM packets is only 20= octets, and size of BR packets is 36 octets. Note that here the packet siz= e doesn't include the size of the IP header. In addition, the transmission of FM packets are periodical with a specific = time interval, or a certain number of traffic packets should be sent betwee= n two contiguous FM packets.=20 In theory, the transmission frequency of TWAMP-test packets should be simil= ar as the normal service packets in order to reflect the network performanc= e more accurate. So the transmission frequency of TWAMP-test packets is cer= tainly larger than that of the FM packets. As both the measurement packets size and the packets transmission frequency= of TWAMP are larger than those of FPM, TWAMP may have more negative impact= on real traffic than FPM. 3) The granularity of test flow In TWAMP, all packets of a specific control connection have the same DSCP f= ield in the IP header. Then the only granularity of the test is (SIP, DIP, = sPort, dPort, DSCP). In FMP, flow can be defined by different combinations SIP, DIP, PT, DSCP, s= Port and dPort. Three types of combinations are suggested: (SIP, DIP, PT), = or (SIP, DIP, PT, DSCP) , or (SIP, DIP, PT, sPort, dPort). Network operator= s can fetch measurement with different granularities according to their spe= cific requirements. 4) Security mechanism =20 As in TWAMP, the measurement packets are independent of the real traffic, s= o when authenticated mode and encrypted mode are selected, an independent s= ecurity mechanism needs to be established for the test. But in FPM, the measurement packets are tightly coupled with the real servi= ce packets, so the security mechanism can be shared. Then there is no neces= sary to establish a specific security mechanism for the measurement packets= . 2. Statistics The metrics in the RFCs are sampled based on a Poisson process. The Poisson= process is used to schedule the measurements. In FPM, the schedule of the FM packets is the equivalent of the schedule of= the measurements. In current version, FM packets are scheduled periodicall= y. For each pair of FM/BR packets, a statistical sample can be achieved.=20 In fact, we have just give the measurement methodology here, and the descri= ption of statistics in FPM need to be further considered and to be explaine= d in detail. =20 (1) packet reordering In RFC 4737, it listed several reasons for packet reordering and has define= d a reordering metric. It also proposed the methods how to determining whet= her or not packet reordering has occurred and how to quantify the degree of= reordering.=20 The discussion of packet reordering in FPM (section 6.2) is not for reorder= ing metric. The reordering discussed here is between the real service packe= ts and the OAM measurement packets. If reordering occurs between the FM pac= ket and the specific service packet (the FM packet may arrive earlier than = the last service packet sent before it, or later than the first service pac= ket sent after it.), it will result in statistical error of packet loss. In= TWAMP, it doesn't have such a problem. However, FPM can use the method proposed in RFC 4737 without adding any mes= sage to determine whether service packet reordering has occurred and to qua= ntify the degree of reordering. (2) packet delay RFC2679 defines a metric for one-way delay of packets across Internet paths= . The methodology proposed in this RFC is that: the Src forms a test packet= , places a timestamp in the test packet, and sends it to the Dst. The Dst t= akes a timestamp as soon as possible upon the receipt of the packet. By sub= tracting the two timestamps, an estimate of one-way delay can be computed. = =20 It is assumed that the Src and Dst are synchronized, otherwise the error an= alysis of a given implementation of the method must take into account the c= loseness of synchronization between Src and Dst.=20 This methodology can also be applied to FPM. In FPM, it also achieves the t= wo timestamps, one-way delay can be calculated by this two timestamps. But as you mentioned the assumption that the forward delay is always equal = to the reverse delay is not really proper. =20 (3) PDV/IPDV/jitter Both RFC3393 and RFC5481 suggest to avoid using the term "jitter" and stick= to delay variation, for "jitter" has a much broader than packet transfer p= erformance.=20 I think we also need to revise the related parts of our draft. For the methodology proposed in RFC3393, the IP packet delay variation (ipd= v) is the difference between the one-way-delay of the selected packets. By = subtracting the first value of One-Way-Delay from the second value the ipdv= value of the pair of packets is obtained. RFC5481 presents the formulations of IPDV and PDV: IPDV(2) =3D D(2) - D(1) =3D (R2-T2) - (R1-T1) =3D (R2-R1) - (T2-T1), PDV(i= ) =3D D(i)-D(min) The single instance of an ipdv and pdv measurement is the same in FPM. So F= PM is easy to follow the methodology defined in RFC3393 and RFC5481. =20 Above all, the definition of the statistics and calculation methods propose= d in FPM need to be further considered and the description should also foll= ow the regulations of the IPPM RFCs. However, the needed parameters have be= en already obtained by the FPM, so it can fulfill the requirements without = adding any message or field.=20 Thanks again for your comments. And I'm looking forward to more comments. W= e may give careful modification for next version. Best Regards, Fang Yu > -----Original Message----- > From: Al Morton [mailto:acmorton@att.com] =20 > Sent: 2 Aug 2012 2:27 > To: tsvwg@ietf.org > Cc: pmol@ietf.org > Subject: [tsvwg] Fwd: Re: [PMOL] Fwd: I-D Action: draft-sun-tsvwg-flowbas= ed-pm-00.txt tsvwg, When I saw this draft >Zhu Lei - Flow-based Performance Measurement (10 min) >draft-sun-tsvwg-flowbased-pm on the I-D announcement list, I asked for and received a review from the Performance Metrics Directorate. I've inserted a few of my own comments below. We try to do early review when requested by WG chairs, and since this draft is now on the tsvwg agenda we are sharing our comments with the tsvwg list. Overall, I would like to suggest that the authors examine the IPPM measurement protocols more fully and implement them to see if their need for flow-based measurement can be met without developing new protocols. Al PMDir admin >From: Andreas Johnsson A >To: "pmol@ietf.org" >Date: Mon, 2 Jul 2012 11:31:22 +0200 > > >Hi, >I have tried to put together a short review. Please see my comments=20 >below (and please provide further comments). [ACM] =3D Al's additional comments. >Best regards, >Andreas Johnsson > >----- > >Comments on draft-sun-tsvwg-flowbased-pm-00.txt. > >1) The draft describes a new active measurement protocol with the=20 >aim of measuring delay, jitter and loss over an IP path. The=20 >protocol is similar to TWAMP (RFC5357), however the measurement=20 >setup is performed in a TCP-like manner instead of using a specific=20 >control plane. Despite its similarities to TWAMP there are no=20 >references nor does the draft contain a comparison. > >2) The draft includes a description on how to calculate statistics=20 >based on time stamps obtained by the protocol. The metrics are=20 >delay, jitter and loss. An advice is to use RFC 6390 section 5.4.5=20 >guidelines for describing the metrics. > >3) The draft does not prior art in IPPM (or elsewhere)=20 >related to delay, jitter or loss. Suggested documents are > >IPPM Delay (http://tools.ietf.org/html/rfc2679) >IPPM Loss (http://tools.ietf.org/html/rfc2680) >IPPM Delay variation (http://www.ietf.org/rfc/rfc3393.txt) [ACM] IPPM Packet Reordering RFC 4737 >ITU-T Y.1540 (http://www.itu.int/rec/T-REC-Y.1540-200711-S) > >4) I would like the authors to elaborate on their delay calculation=20 >method. The draft assumes that the forward delay is always equal to=20 >the reverse delay. How often is this the case? > >5) The jitter calculations are based upon the delay calculations.=20 >Since the delay is calculated as the RTT (minus the time a packet=20 >spends at the PM responder) divided by 2, the jitter will be the=20 >same in both directions. Does this really reflect what is happening=20 >on the path? Please elaborate on this. [ACM] In general, the statistics suggested here are not widely used, especially the jitter as delay variance. Suggest that the authors look at http://tools.ietf.org/html/rfc5481 and decide what measurement task and PDV method suits their needs. >-----Original Message----- >From: pmol-bounces@ietf.org [mailto:pmol-bounces@ietf.org] On Behalf=20 >Of Al Morton >Sent: den 29 juni 2012 13:58 >To: pmol@ietf.org >Subject: [PMOL] Fwd: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt > >After reading the abstract, ... > >Would anyone volunteer to review this in a timely way? > >Al >PMDir admin > > > >From: internet-drafts@ietf.org > >To: i-d-announce@ietf.org > >Subject: I-D Action: draft-sun-tsvwg-flowbased-pm-00.txt > >X-Test-IDTracker: no > >X-IETF-IDTracker: 4.21p1 > >Date: Fri, 29 Jun 2012 01:40:50 -0700 > >X-BeenThere: i-d-announce@ietf.org > >X-Mailman-Version: 2.1.12 > >Reply-To: internet-drafts@ietf.org > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Flow-based Performance Measurement > > Author(s) : Lishun Sun > > Wendong Wang > > Fang Yu > > Filename : draft-sun-tsvwg-flowbased-pm-00.txt > > Pages : 15 > > Date : 2012-06-29 > > > >Abstract: > > The performance measurements of service flow are becoming significan= t > > important for administrators monitoring the fitness of the network. > > This memo defines an end-to-end application-based performance > > measurement method, which is achieved by generating synthetic > > measurement packets, injecting them to the network and analyzing the > > statistics carried in the measurement packets. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-sun-tsvwg-flowbased-pm > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-sun-tsvwg-flowbased-pm-00 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html or > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >PMOL mailing list >PMOL@ietf.org >https://www.ietf.org/mailman/listinfo/pmol >_______________________________________________ >PMOL mailing list >PMOL@ietf.org >https://www.ietf.org/mailman/listinfo/pmol From dromasca@avaya.com Tue Aug 21 08:34:25 2012 Return-Path: X-Original-To: pmol@ietfa.amsl.com Delivered-To: pmol@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE47421F879A for ; Tue, 21 Aug 2012 08:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.429 X-Spam-Level: X-Spam-Status: No, score=-103.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 7ENknV5Sc2HX for ; Tue, 21 Aug 2012 08:34:25 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id BF06621F8763 for ; Tue, 21 Aug 2012 08:34:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMJAJqpM1DGmAcF/2dsb2JhbABFuVwEBH6BB4IgAQEBAQMSHgoPMAwGAQgNBAQBAQsGDAsBB0UHAQEFBAEEEwgBGYdrC5wDnUSLCIQAgjxgA5tQihWCYw X-IronPort-AV: E=Sophos;i="4.77,803,1336363200"; d="scan'208";a="320587333" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Aug 2012 11:31:19 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Aug 2012 11:28:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Aug 2012 17:34:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Liaison Statement from the Broadband Forum thread-index: Ac12iUxanGB/fuvuSKermmvvwbOu4QJKPNbA From: "Romascanu, Dan (Dan)" To: Cc: Ronald Bonica Subject: [PMOL] FW: Liaison Statement from the Broadband Forum X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:34:25 -0000 This liaison looks like something the PMOL Directorate should have a saying about.=20 Regards, Dan -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Friday, August 10, 2012 2:47 AM To: IETF Discussion Subject: Liaison Statement from the Broadband Forum Folks, The Broadband Forum has sent a liaison statement to the IETF regarding a "New Project - Broadband Access Service Attributes and Performance Measures".=20 Click on the following link for details: https://datatracker.ietf.org/liaison/1179/. Please review and send comments to this list. -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf