From mattmathis@google.com Mon Apr 1 14:30:03 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E669C21E80FD for ; Mon, 1 Apr 2013 14:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PImMpd892epa for ; Mon, 1 Apr 2013 14:30:02 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E3F9921E80F5 for ; Mon, 1 Apr 2013 14:30:01 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id aq17so2824295iec.33 for ; Mon, 01 Apr 2013 14:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=m9r0qAhazWy935ip3jXDl5GyBtXmXxCKKaWxTqW1FQY=; b=aNradT7Zx5khieiaiCyd/cBaipBY0UpCE63j12mC9e89za7efAxq44Upf4ao0kRDMM w5VL47gO8L2R+8mjxvauFdsZ7J/7BLrNEEQuNECUtcKXco39CQpfWpQiL3R0ZIceIixP h4R2Y2qzcBuJv3/T8jID0XbmRA4LHvoZK+0KSlXlimR3RyBUznq7r9WURcnJ5hB+wHD/ iBI3zn4hvGn/ONANWaADah2czTw2RJY+vgHG6xeVUF2mEW7aoKGMqAfoH/KLF8FGAEHZ 9BAmYfJfpcdwjBdD9Wb0qigVIdZ+w/kkGFZ8tcI0d7tUilMcZuU0fu6Q3/JPBn7wojzm bMRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=m9r0qAhazWy935ip3jXDl5GyBtXmXxCKKaWxTqW1FQY=; b=Rh+A4q+XRQRAqYEHARE6HvRuhVdKfJXGAR8coqpPbnSvjQn8mdb5mQOL5Bhdhrp1Sj plBkqhDKcC3J9LkpB15whgcH5aeWOM16VZTRJQeaGTlc3TBF1S98Hylk83PIq2F6v1+g G/OXwQmNbChgqtarpT1qanjjad+UvE3B0WnByr7OmMIW6bA5clhnEAQDffBfV5py2efR XSY2oFnjhmMgPbGQLJtb41atvSQrWToEcbNZm+IC3MaXKVC8tXoZ0N3Da7Mgx6oVNy60 KSTyhizb2/1DgcxQ62TZQSybLgDrQ/xY6cVoNXI9F89CddbYfpmmJimSK9myQWYiAZgF MhnQ== MIME-Version: 1.0 X-Received: by 10.43.125.199 with SMTP id gt7mr5479523icc.48.1364851801481; Mon, 01 Apr 2013 14:30:01 -0700 (PDT) Received: by 10.64.78.164 with HTTP; Mon, 1 Apr 2013 14:30:01 -0700 (PDT) In-Reply-To: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> Date: Mon, 1 Apr 2013 14:30:01 -0700 Message-ID: From: Matt Mathis To: Brian Trammell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQngD2O3jbp8BTcvgO4qOG6Je0oju2VWpO3P1doNX9Grb2Njz9fDXrbmpvP0TFTveh5kIJ/QDUWhtZM9YXOJ7h03gz9jWfGqcMooOCdcZe+KQEosKLYx1J0Ej06qEUIOcLm2M1ahf7RzxLq6FirOrkcZYNDF+GH21uZQqQ+hGHro09lyxRJn4jQ9Ti2dSxNC2bNjJ2bS Cc: "ippm@ietf.org" Subject: Re: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:30:03 -0000 In my comments below, "abstain" generally means that I don't see enough value in the work to be worth my time, but I see insignificant harm in others supporting it. Since there is a risk that such items draw precious energy out of the working group as a whole, an abstain vote should be counted as a weak no. On Tue, Mar 26, 2013 at 1:12 AM, Brian Trammell wrote: > (1) draft-morton-ippm-2330-update-01 > Mon Year - Submit draft of RFC 2330bis (Framework update) > to IESG as Proposed Standard Yes 2330 needs work, and this is a good starting point/placeholder, although I think this specific document has too narrow of scope. Yes I will review and contribute. > (2) draft-morton-ippm-2679-bis-01 > Mon Year - Submit draft of RFC 2679bis (One-Way Delay update) > to IESG as Proposed Standard Abstain > (3) draft-morton-ippm-2680-bis-00 > Mon Year - Submit draft of RFC 2680bis (One-Way Loss update) > to IESG as Proposed Standard Abstain > (4) draft-morton-ippm-lmap-path-01 > Mon Year - Submit draft on reference path for measurement location > to IESG as Proposed Standard Yes, I support this and will help. Consider folding it into 2330bis. > (5) draft-mathis-ippm-model-based-metrics-01 > Mon Year - Submit draft on model-based TCP bulk transfer capacity metrics > to IESG as Proposed Standard Yes & Yes > (6) draft-ko-ippm-streaming-performance-00 > Mon Year - Submit draft on model-based streaming performance metrics > to IESG as Proposed Standard Abstain > (7) draft-bi-ippm-ipsec-01 > Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Standard Yes, we (other person singular) should do this. No, I can't help. > With respect to the following milestone, there are two drafts, which we would presume would be unified through the working group process; it's not necessary at this time to indicate which approach you support. > > (8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new-registry-independent-00 > Mon Year - Submit draft on metrics registry to IESG as Proposed Standard I wonder if this would be a better fit for LMAP? I think the root problem here is certifying implementations and operational interoperability, which are not areas where we have any experience. IPPM has been about on the wire measurements and properties, not about user interfaces, etc. I would say no for an IPPM work item, but would support it under LMAP. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. From marcelo@it.uc3m.es Mon Apr 1 14:52:42 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB6221F9125 for ; Mon, 1 Apr 2013 14:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a2cwHHRsQQg for ; Mon, 1 Apr 2013 14:52:40 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 08C6C21F9122 for ; Mon, 1 Apr 2013 14:52:38 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9018511BD7E0 for ; Mon, 1 Apr 2013 23:52:38 +0200 (CEST) X-uc3m-safe: yes Received: from [192.168.1.101] (r186-52-184-168.dialup.adsl.anteldata.net.uy [186.52.184.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id A0B5711BD7D7 for ; Mon, 1 Apr 2013 23:52:37 +0200 (CEST) Message-ID: <515A019F.7050807@it.uc3m.es> Date: Mon, 01 Apr 2013 23:52:31 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ippm@ietf.org References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTHACL 134 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Mon, 01 Apr 2013 23:52:38 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19762.002 X-TM-AS-Result: No--25.940-7.0-31-1 X-imss-scan-details: No--25.940-7.0-31-1 Subject: Re: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:52:42 -0000 El 01/04/13 23:30, Matt Mathis escribió: > > > (8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new-registry-independent-00 > Mon Year - Submit draft on metrics registry to IESG as Proposed Standard > I wonder if this would be a better fit for LMAP? I think the root > problem here is certifying implementations and operational > interoperability, mmm, this is not how i see this. I mean, the goal here is to define a registry for metrics that are specified enough so it is practical to implement them. Basically, if we intend to have a protocol that can instruct a measurement agent something like "run test number 5 with input parameters a,b and c" then test number 5 should be specified enough so that it is practical to implement it. For exmaple, leaving an arbitraty P-type, probably in general is too generic to leave it open. OTOH, defining that the packet is a UDP packet with a variable lenght of padding (where the lentgh of the padding and the source and address ports are input parameters) seems like a more feasible approach. So, i dont think certification of implementations is how i would phrase it. It is certainly about interoperability, but i guess this is what the IETF is about. I believe this belong to IPPM because i think expertise on the metrcis is critical. The idea is to define entries in the registry by narrowing down some of the input paramters of the metrcis that IPPM has already defined. It probably could be done also in lmap, but it makes more sense to me in ippm, as the metrics the registry will cover have been defined here. Regards, marcelo > which are not areas where we have any experience. > IPPM has been about on the wire measurements and properties, not about > user interfaces, etc. > I would say no for an IPPM work item, but would support it under LMAP. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat > privacy and security as matters of life and death, because for some > users, they are. > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From trammell@tik.ee.ethz.ch Tue Apr 2 00:21:47 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B79321F9847 for ; Tue, 2 Apr 2013 00:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq5+xt2WzhSK for ; Tue, 2 Apr 2013 00:21:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DB17721F9845 for ; Tue, 2 Apr 2013 00:21:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D50E9D930A; Tue, 2 Apr 2013 09:21:42 +0200 (MEST) 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 VVXsqd5gjtao; Tue, 2 Apr 2013 09:21:42 +0200 (MEST) Received: from [192.168.0.5] (unknown [121.99.65.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 68AACD9308; Tue, 2 Apr 2013 09:21:41 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <515A019F.7050807@it.uc3m.es> Date: Tue, 2 Apr 2013 20:21:34 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <3A04A5F7-F718-4F3F-AA47-DD0D4598389D@tik.ee.ethz.ch> References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <515A019F.7050807@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1503) Cc: ippm@ietf.org Subject: Re: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 07:21:47 -0000 hi, Marcelo, Matt, all As I understand the work, it pretty clearly fits into the (expanded) = IPPM charter, with an understanding that what's in the present draft = will be elaborated within the working group. This is one of those things = that will probably be discussed both on the IPPM and LMAP list, but I = agree that expertise on the metrics will be critical in developing the = registry; that indicates that it probably belongs in IPPM. Alternately, if it turns out later that this registry is becoming = something LMAP-specific, it could certainly be moved over to LMAP at = some point in the future. Best regards, Brian On 2 Apr 2013, at 10:52, marcelo bagnulo braun = wrote: > El 01/04/13 23:30, Matt Mathis escribi=F3: >>=20 >>=20 >> (8) draft-bagnulo-ippm-new-registry-00, = draft-bagnulo-ippm-new-registry-independent-00 >> Mon Year - Submit draft on metrics registry to IESG as Proposed = Standard >> I wonder if this would be a better fit for LMAP? I think the root >> problem here is certifying implementations and operational >> interoperability, >=20 > mmm, this is not how i see this. > I mean, the goal here is to define a registry for metrics that are = specified enough so it is practical to implement them. > Basically, if we intend to have a protocol that can instruct a = measurement agent something like "run test number 5 with input = parameters a,b and c" then test number 5 should be specified enough so = that it is practical to implement it. > For exmaple, leaving an arbitraty P-type, probably in general is too = generic to leave it open. OTOH, defining that the packet is a UDP packet = with a variable lenght of padding (where the lentgh of the padding and = the source and address ports are input parameters) seems like a more = feasible approach. >=20 > So, i dont think certification of implementations is how i would = phrase it. > It is certainly about interoperability, but i guess this is what the = IETF is about. >=20 > I believe this belong to IPPM because i think expertise on the metrcis = is critical. The idea is to define entries in the registry by narrowing = down some of the input paramters of the metrcis that IPPM has already = defined. >=20 > It probably could be done also in lmap, but it makes more sense to me = in ippm, as the metrics the registry will cover have been defined here. >=20 > Regards, marcelo >=20 >=20 >=20 >> which are not areas where we have any experience. >> IPPM has been about on the wire measurements and properties, not = about >> user interfaces, etc. >> I would say no for an IPPM work item, but would support it under = LMAP. >>=20 >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >>=20 >> Privacy matters! We know from recent events that people are using = our >> services to speak in defiance of unjust governments. We treat >> privacy and security as matters of life and death, because for some >> users, they are. >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >>=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From samita.chakrabarti@ericsson.com Tue Apr 2 17:57:02 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AD521E803C for ; Tue, 2 Apr 2013 17:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLxbsaj4pnPW for ; Tue, 2 Apr 2013 17:57:01 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3AE11E809C for ; Tue, 2 Apr 2013 17:57:01 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-a4-515b7e5c27ac Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C7.0A.02411.C5E7B515; Wed, 3 Apr 2013 02:57:00 +0200 (CEST) Received: from EUSAAMB102.ericsson.se ([147.117.188.119]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 20:56:59 -0400 From: Samita Chakrabarti To: Brian Trammell , "ippm@ietf.org" Thread-Topic: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items. Thread-Index: AQHOKfm06YI0OBj8t0Gzw+XWLxGDaZjDs01Q Date: Wed, 3 Apr 2013 00:56:58 +0000 Message-ID: References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> In-Reply-To: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPrG5MXXSgwfU2Q4ueB++YLd4/72Rx YPJYsuQnk8exD1/ZApiiuGxSUnMyy1KL9O0SuDJuvWtiLHjgUvFxqUkDY495FyMnh4SAicSk wx+ZIGwxiQv31rN1MXJxCAkcZZSYsfUVlLOMUWLP+z1sIFVsAlYSHb172EFsEQFfiXmHbrKA 2MICkRJt/S8ZIeJREp//dTNB2EYSe/e+YAaxWQRUJBZdOA42hxeo98fnblYQW0jAUeL17mdg czgFnCR2TFwNVs8IdNH3U2vA5jALiEvcejIf6lIBiSV7zjND2KISLx//Y4WwlSW+z3nEAlGv I7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYwcpcWpZbnpRoab GIHRcEyCzXEH44JPlocYpTlYlMR5Q10vBAgJpCeWpGanphakFsUXleakFh9iZOLglGpgjPY9 onJo6SOtnZX2H4z2FeVXZwf+mCNwcILmM5d/vYw7WBmOhTdvXa2+1Ni6YubCO3+XKL8J3K+5 +WVwlyjvNJdS6T2H5v2sU0u+bvcsraDgp3HluoLrmd9r54VbzXG1+Xta4NOt3cayh3TO1kfq WvrOnzJvJYtCSzff8v3pRmtTBEu7/j+MU2Ipzkg01GIuKk4EAPJZ2Q1UAgAA Subject: Re: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 00:57:02 -0000 Hi Brian, The revised charter mentions near the 2nd last paragraph - "The WG also encourages work which improves the availability of information= about the context in which measurements were taken." ---> is this alludin= g to usecase document of TWAMP/OWAMP and some of the asociated metrics ( si= nce the currents documents are not very clear)? We discussed that during t= he charter discussion at IETF 86. Also, at the charter discussion, we agreed on MIB definition for the measur= ement protocols. Not sure if it was captured in the meeting minutes. Lookin= g at the charter I did not find coverage for it. Could this be clarified? I have some comments on the list of documents below as you requested commen= ts by April 3rd. Please see in-line. =20 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Tuesday, March 26, 2013 1:13 AM To: ippm@ietf.org Subject: [ippm] Consensus on new IPPM Charter; call for draft adoption as W= G items. Greetings, all, Having applied comments in this thread to the charter, we've arrived at the= draft charter text below this message. I've seen on the order of a dozen comments supporting adoption of the chart= er, some with suggestions for improvement that have been applied to the bel= ow. Seeing no comments not supporting adoption, it appears that we have cle= ar consensus for the adoption of the draft charter text. Many thanks to all= for your comments! The next step is to adopt drafts from those which have been presented at th= e IPPM meeting in Orlando and/or discussed to date on the list, and to dete= rmine the milestones for those drafts.=20 For the following drafts and milestones, please indicate: (a) whether you support the adoption of the draft as a working group item f= or the associated milestone, and (b) whether you have reviewed the draft, and/or are willing to review it as= a working group item (1) draft-morton-ippm-2330-update-01 Mon Year - Submit draft of RFC 2330bis (Framework update) to IESG as Proposed Standard =3D=3D> Yes on adoption.=20 (2) draft-morton-ippm-2679-bis-01 Mon Year - Submit draft of RFC 2679bis (One-Way Delay update)=20 to IESG as Proposed Standard =3D=3D> Yes on adoption.=20 (3) draft-morton-ippm-2680-bis-00 Mon Year - Submit draft of RFC 2680bis (One-Way Loss update)=20 to IESG as Proposed Standard =3D=3D> Yes on adoption.=20 (4) draft-morton-ippm-lmap-path-01 Mon Year - Submit draft on reference path for measurement location to IESG as Proposed Standard =3D=3D> Yes on adoption.=20 (5) draft-mathis-ippm-model-based-metrics-01 Mon Year - Submit draft on model-based TCP bulk transfer capacity metrics to IESG as Proposed Standard =3D=3D=3D> This document's intended status is "experimental". I'd support it for wg do= cument as experimental. More experience is needed to make it a std wg docum= ent. (6) draft-ko-ippm-streaming-performance-00 Mon Year - Submit draft on model-based streaming performance metrics=20 to IESG as Proposed Standard =3D=3D=3D> This document is an INFORMATIONAL document. Not sure why it shou= ld be submitted as proposed standard. It has a lot of useful information. B= ut I think it is premature yet to adopt as a wg draft and more time for dis= cussion and understanding is needed. (7) draft-bi-ippm-ipsec-01 Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Stand= ard =3D=3D=3D> Support adoption. More work is needed. With respect to the following milestone, there are two drafts, which we wou= ld presume would be unified through the working group process; it's not nec= essary at this time to indicate which approach you support. (8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new-registry-ind= ependent-00 Mon Year - Submit draft on metrics registry to IESG as Proposed Standard I'd like to try to evaluate consensus on adoption on each draft by next Wed= nesday, April 3, absent continuing discussion. =3D=3D=3D> Would like to see more discussion on the merged document and wor= king group review before they individually become wg documents. Best regards, -Samita [Charter text follows] IP Performance Metrics (ippm) ----------------------------- Charter Current Status: Active Chairs: Brian Trammell=20 Bill Cerveny =20 Transport Area Directors: Martin Stiemerling Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: http://www.ietf.org/mail-archive/web/ippm Description of Working Group: The IP Performance Metrics (IPPM) Working Group develops and maintains stan= dard metrics that can be applied to the quality, performance, and reliabili= ty of Internet data delivery services and applications. It also develops an= d maintains protocols for the measurement of these metrics. These metrics a= re designed such that they can be used by network operators, end users, or = independent testing groups. Metrics developed by the IPPM WG are intended t= o provide unbiased quantitative performance measurements and not a value ju= dgement. The IPPM WG has produced documents that define specific metrics and procedu= res for accurately measuring and documenting these metrics. The working gro= up will continue advancing these metrics along the standards track, using t= he guidelines stated in RFC 6576. To the extent possible, these metrics wil= l be used as the basis for future work on metrics in the WG. The WG will develop the minimum number of new metrics and models needed to = more accurately quantitatively characterize the network path(s) under test = and/or the performance of transport and application layer protocols on thes= e path(s). New metric definitions will state how the definition improves on an existin= g metric definition, or assesses a property of network performance not prev= iously covered by a defined metric. Additional methods will be defined for the composition and calibration of I= PPM-defined metrics, as well as active, passive and hybrid measurement meth= ods for these metrics. In addition, the WG encourages work which describes = the applicability of metrics and measurement methods, especially to improve= understanding of the tradeoffs involved among active, passive, and hybrid = methods. The WG may update its core framework RFC 2330 as necessary to accommodate t= hese activities. The WG has produced protocols for communication among test equipment to ena= ble the measurement of the one- and two-way metrics (OWAMP and TWAMP respec= tively). These protocols will be advanced along the standards track. The WG will fur= ther develop and improve these protocols. The WG may develop new measuremen= t protocols as necessary to support new metrics. New metric and protocol de= velopment will focus on the suitability of measurements for automation, in = order to support large-scale measurement efforts. Agreement about the definitions of metrics and methods of measurement enabl= es accurate, reproducible, and equivalent results across different implemen= tations. To this end, the WG will define and maintain a registry of metric = definitions. The WG encourages work which assesses the comparability of mea= surements of IPPM metrics with metrics developed elsewhere. The WG also enc= ourages work which improves the availability of information about the conte= xt in which measurements were taken. The IPPM WG seeks cooperation with other appropriate standards bodies and f= orums to promote consistent approaches and metrics. Within the IETF process= , IPPM metric definitions and measurement protocols will be subject to as r= igorous a scrutiny for usefulness, clarity, and accuracy as other protocol = standards. The IPPM WG will interact with other areas of IETF activity whos= e scope intersects with the requirement of these specific metrics. The WG w= ill, on request, provide input to other IETF working groups on the use and = implementation of these metrics. Milestones: Mon Year - Submit draft on access rate measurement protocol problem stateme= nt to IESG as Informational Mon Year - Submit draft on RFC 2680 standards-track advancement testing to IESG as Informational =20 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From samita.chakrabarti@ericsson.com Tue Apr 2 18:21:05 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E04E21F8610 for ; Tue, 2 Apr 2013 18:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 d6xwXY1jXhsJ for ; Tue, 2 Apr 2013 18:21:04 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 516A021F85EB for ; Tue, 2 Apr 2013 18:21:03 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-3e-515b83fef523 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A9.7A.02411.EF38B515; Wed, 3 Apr 2013 03:21:03 +0200 (CEST) Received: from EUSAAMB102.ericsson.se ([147.117.188.119]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 21:21:02 -0400 From: Samita Chakrabarti To: "ippm@ietf.org" , Brian Trammell Thread-Topic: ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt Thread-Index: Ac4wCYCvCzj1WZwXS6yv17y4sc0U7A== Date: Wed, 3 Apr 2013 01:21:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_ECA43DA70480A3498E43C3471FB2E1F01BEA6FF5eusaamb102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXSPt+7/5uhAg3NLWCx6Hrxjtnj/vJPF gcljyZKfTB7HPnxlC2CK4rJJSc3JLEst0rdL4Mp4tWYuU8F0w4qrTV/ZGxj3aXUxcnJICJhI fPp5mwnCFpO4cG89WxcjF4eQwFFGidWTN7JAOMsYJf5On8YKUsUmYCXR0buHHcQWEfCV2NDy mRHEFhawk9h2eiYrRNxZ4vf3JywQtp7E+dYzYDaLgIrEselrgTZwcPAC9f69XwkSZgRa/P3U GrAjmAXEJW49mQ91kIDEkj3nmSFsUYmXj/+xQtjKEt/nPGKBqM+XWNBwB6yGV0BQ4uTMJywT GIVmIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxalluupHhJkZg NByTYHPcwbjgk+UhRmkOFiVx3lDXCwFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGLuupXWE xlexb9wfMXV9Ya7BrN7Oh57WL5u2zGxuqf1tcPmUw9eq59adX83zloqJMz9TnC5aflN8+V7t RSbf5HSDWcyeTgjkd41lv7jHIkFrnWzauQ+M/Y8OHM1cIBRYc/Z6quK3ppiMXzuSNz/JKSmd KD+v2ezeresFvQYNR2T2Rtp+qGhsV2Ipzkg01GIuKk4EAI9dxg9UAgAA Subject: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 01:21:05 -0000 --_000_ECA43DA70480A3498E43C3471FB2E1F01BEA6FF5eusaamb102erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello : This is regarding my comment at the IETF86 ippm meeting for the section 5 (= Test Protocol Control & Generation Requirements) section. Toward the end of the section, the document states: "The ability to control packet size on the tested path and enable asymmetrical packet size testing in a two-way architecture are REQUIRED." Request: Relax the requirement for "assymetrical" packet size so that the r= equirement document allows both symmetric and assymetric packet sizes in fo= rward and reverse direction. I was asked to provide a usecase for the request and here it is: Normally in fixed Broadband network, so far we are mostly interested with d= ata traffic download and thus we can see 80/20 (apprx) traffic distribution= in forward and reverse direction. Most often in the forward path we have a= ctual traffic packets and in upward direction it is most likely short packe= t sizes due to acknowledgements etc. However, looking forward in current and future deployment and in Mobile Bro= adband networks when we consider applications like VoLTE, peer-to-peer comm= unication, video-chat etc. we can easily expect that forward and reverse di= rection traffic rate and sizes are equivalent. Since the converged network= carries both mobile and fixed broadband traffic, it is important for many = carriers to measure the IP-network performance by using active measurement = protocol with same packet size of the traffic and in some cases with same r= ate in both directions ( i,e both symmetric and assymetric). Thus, we will need to allow both symmetric and assymetric measurement packe= t sizes and rates in forward and reverse direction. Hope this helps in understanding the requirement. Best regards, -Samita --_000_ECA43DA70480A3498E43C3471FB2E1F01BEA6FF5eusaamb102erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello :=
 <= /div>
This is regarding my comment at the IETF86 ippm meet= ing for the section 5 (Test Protocol Control & Generation Requirements) section.
Toward the end of the section, the document states:
"The ability to control packet size on the tested path and enable=
asymmetrical packet size testing in a two-way architecture are
REQUIRED."
 
Request: Relax the requirement for "assymetrical" packet siz= e so that the requirement document allows both symmetric and assymetric pac= ket sizes in forward and reverse direction.
 
I was asked to provide a usecase for the request and here it is:
Normally in fixed Broadband network, so far we are mostly interested w= ith data traffic download and thus we can see 80/20 (apprx) traffic distrib= ution in forward and reverse direction. Most often in the forward path we have actual traffic packets and in upward= direction it is most likely short packet sizes due to acknowledgements etc= .
However, looking forward in current and future deployment and in Mobil= e Broadband networks when we consider applications like VoLTE, peer-to-peer= communication, video-chat etc. we can easily expect that forward and reverse direction traffic rate and sizes are= equivalent.  Since the converged network carries both mobile and fixe= d broadband traffic, it is important for many carriers to measure the IP-ne= twork performance by using active measurement protocol with same packet size of the traffic and in some cases with same r= ate in both directions ( i,e both symmetric and assymetric).
Thus, we will need to allow both symmetric and assymetric measurement = packet sizes and rates in forward and reverse direction.
Hope this helps in understanding the requirement.
 
Best regards,
-Samita
 
 <= /div> --_000_ECA43DA70480A3498E43C3471FB2E1F01BEA6FF5eusaamb102erics_-- From mattmathis@google.com Tue Apr 2 18:35:26 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4646B21F8721 for ; Tue, 2 Apr 2013 18:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybe9rjoSxt67 for ; Tue, 2 Apr 2013 18:35:25 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4B92621F8714 for ; Tue, 2 Apr 2013 18:35:25 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id c11so1146298ieb.15 for ; Tue, 02 Apr 2013 18:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=wqxWt8YzHz2n2H48S0RgPu/QWdwXWKxJjjuYh9xIGeM=; b=GSotcJtKtaoKIGrcvAyNiV2B0JtqcWye3tC7Gpkz3KjAUmfh5P6pWd6uo1s/dnOYsE /LnmfRvxEgDV6Bg3/8K2cfrirlorjRIdPS4wWw8pPjA5sLrpRhmfejKoTlUG8jg9Xc+/ AzL+PV7WQaa7MJ2LR99Y75ISdy5dMI8kA0Unbg1/rS5xSOV/XbXiQ0WYWigpQeiAKcg9 2/Hm3q2zsFAJJEHSjdGLr5/3JGt/sdSFDrmIlahMC640zIYholjQZX1HjTM3FCchYRp4 ZqK+OcSsk6SWqf5KLukyJDSdO1Uaeb1ZeBF/YVnjpLOCFFJUwWg4DHjZKfNZMYW1MwKK XGwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=wqxWt8YzHz2n2H48S0RgPu/QWdwXWKxJjjuYh9xIGeM=; b=Fc127gHY63E+hkRA7hzsGt3aCa/IGjSbssCUeOESb4yNfDNdKqS/IBXhKz2T2rTle0 9CUBNffAawV1iJ+pwmgERukKz2qYfFEsrxEoeRXFfEWT4sYAc0T1bKOvPgjEo4OxLL9h cUkJRAKIAcgQGIzvIMbijBZ9frQClrmiJ/phGVxKieOWij5zt7wZyrehqdLuK9R+Q5VR 1g5YOJvuEpX+dxyHH8q2BkL30iBjk77cR3OSiHbkk/sr+szj9H3XOlVY4Myo+rJ0NXdG zmVkxYmn9zTV4p4xJUZazoOtPYGSlsTz5cTTWVLC3m0zUieOMitBgrV05gfaxunDpPS+ i8Ow== MIME-Version: 1.0 X-Received: by 10.50.79.201 with SMTP id l9mr6013126igx.79.1364952924613; Tue, 02 Apr 2013 18:35:24 -0700 (PDT) Received: by 10.64.78.164 with HTTP; Tue, 2 Apr 2013 18:35:24 -0700 (PDT) In-Reply-To: References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> Date: Tue, 2 Apr 2013 18:35:24 -0700 Message-ID: From: Matt Mathis To: Samita Chakrabarti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnHJ7sHG1ERwtLy6pLnUFegMfPWsviBOzV6ooF9CbQ3766tpxZqxdNJg6PapzbUOunaUExtBR5XU8+rLSZK61U3Zgr5Qfu311homepebLDIab0kUADd5Cf/cReYdb4nd8jDOlb7uvlpAagfU0uCu+Oht8HItqcOadCYANCP8QkTqzyTNHyDJY7I0iqmAZQggXn+HUzk Cc: "ippm@ietf.org" Subject: Re: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 01:35:26 -0000 I think "The WG also encourages work which improves the availability of information about the context in which measurements were taken." is alluding to metadata and related issues. E.g. draft-mathis-ippm-data-curation-00.txt But this draft is about to expire. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Tue, Apr 2, 2013 at 5:56 PM, Samita Chakrabarti wrote: > Hi Brian, > > The revised charter mentions near the 2nd last paragraph - > "The WG also encourages work which improves the availability of informati= on about the context in which measurements were taken." ---> is this allud= ing to usecase document of TWAMP/OWAMP and some of the asociated metrics ( = since the currents documents are not very clear)? We discussed that during= the charter discussion at IETF 86. > > Also, at the charter discussion, we agreed on MIB definition for the meas= urement protocols. Not sure if it was captured in the meeting minutes. Look= ing at the charter I did not find coverage for it. Could this be clarified? > > I have some comments on the list of documents below as you requested comm= ents by April 3rd. > Please see in-line. > > > > > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of B= rian Trammell > Sent: Tuesday, March 26, 2013 1:13 AM > To: ippm@ietf.org > Subject: [ippm] Consensus on new IPPM Charter; call for draft adoption as= WG items. > > Greetings, all, > > Having applied comments in this thread to the charter, we've arrived at t= he draft charter text below this message. > > I've seen on the order of a dozen comments supporting adoption of the cha= rter, some with suggestions for improvement that have been applied to the b= elow. Seeing no comments not supporting adoption, it appears that we have c= lear consensus for the adoption of the draft charter text. Many thanks to a= ll for your comments! > > The next step is to adopt drafts from those which have been presented at = the IPPM meeting in Orlando and/or discussed to date on the list, and to de= termine the milestones for those drafts. > > For the following drafts and milestones, please indicate: > > (a) whether you support the adoption of the draft as a working group item= for the associated milestone, and > (b) whether you have reviewed the draft, and/or are willing to review it = as a working group item > > (1) draft-morton-ippm-2330-update-01 > Mon Year - Submit draft of RFC 2330bis (Framework update) > to IESG as Proposed Standard > > =3D=3D> Yes on adoption. > > > > (2) draft-morton-ippm-2679-bis-01 > Mon Year - Submit draft of RFC 2679bis (One-Way Delay update) > to IESG as Proposed Standard > > =3D=3D> Yes on adoption. > > (3) draft-morton-ippm-2680-bis-00 > Mon Year - Submit draft of RFC 2680bis (One-Way Loss update) > to IESG as Proposed Standard > > =3D=3D> Yes on adoption. > > (4) draft-morton-ippm-lmap-path-01 > Mon Year - Submit draft on reference path for measurement location > to IESG as Proposed Standard > > =3D=3D> Yes on adoption. > > (5) draft-mathis-ippm-model-based-metrics-01 > Mon Year - Submit draft on model-based TCP bulk transfer capacity metrics > to IESG as Proposed Standard > > =3D=3D=3D> > This document's intended status is "experimental". I'd support it for wg = document as experimental. More experience is needed to make it a std wg doc= ument. > > (6) draft-ko-ippm-streaming-performance-00 > Mon Year - Submit draft on model-based streaming performance metrics > to IESG as Proposed Standard > > > =3D=3D=3D> This document is an INFORMATIONAL document. Not sure why it sh= ould be submitted as proposed standard. It has a lot of useful information.= But I think it is premature yet to adopt as a wg draft and more time for d= iscussion and understanding is needed. > > > (7) draft-bi-ippm-ipsec-01 > Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Sta= ndard > > =3D=3D=3D> Support adoption. More work is needed. > > > With respect to the following milestone, there are two drafts, which we w= ould presume would be unified through the working group process; it's not n= ecessary at this time to indicate which approach you support. > > (8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new-registry-i= ndependent-00 > Mon Year - Submit draft on metrics registry to IESG as Proposed Standard > > I'd like to try to evaluate consensus on adoption on each draft by next W= ednesday, April 3, absent continuing discussion. > > > =3D=3D=3D> Would like to see more discussion on the merged document and w= orking group review before > they individually become wg documents. > > > Best regards, > -Samita > > > > > > > [Charter text follows] > > IP Performance Metrics (ippm) > ----------------------------- > > Charter > > Current Status: Active > > Chairs: > Brian Trammell > Bill Cerveny > > Transport Area Directors: > Martin Stiemerling > Martin Stiemerling > > Transport Area Advisor: > Martin Stiemerling > > Mailing Lists: > General Discussion: ippm@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ippm > Archive: http://www.ietf.org/mail-archive/web/ippm > > Description of Working Group: > > The IP Performance Metrics (IPPM) Working Group develops and maintains st= andard metrics that can be applied to the quality, performance, and reliabi= lity of Internet data delivery services and applications. It also develops = and maintains protocols for the measurement of these metrics. These metrics= are designed such that they can be used by network operators, end users, o= r independent testing groups. Metrics developed by the IPPM WG are intended= to provide unbiased quantitative performance measurements and not a value = judgement. > > The IPPM WG has produced documents that define specific metrics and proce= dures for accurately measuring and documenting these metrics. The working g= roup will continue advancing these metrics along the standards track, using= the guidelines stated in RFC 6576. To the extent possible, these metrics w= ill be used as the basis for future work on metrics in the WG. > > The WG will develop the minimum number of new metrics and models needed t= o more accurately quantitatively characterize the network path(s) under tes= t and/or the performance of transport and application layer protocols on th= ese path(s). > New metric definitions will state how the definition improves on an exist= ing metric definition, or assesses a property of network performance not pr= eviously covered by a defined metric. > > Additional methods will be defined for the composition and calibration of= IPPM-defined metrics, as well as active, passive and hybrid measurement me= thods for these metrics. In addition, the WG encourages work which describe= s the applicability of metrics and measurement methods, especially to impro= ve understanding of the tradeoffs involved among active, passive, and hybri= d methods. > > The WG may update its core framework RFC 2330 as necessary to accommodate= these activities. > > The WG has produced protocols for communication among test equipment to e= nable the measurement of the one- and two-way metrics (OWAMP and TWAMP resp= ectively). > These protocols will be advanced along the standards track. The WG will f= urther develop and improve these protocols. The WG may develop new measurem= ent protocols as necessary to support new metrics. New metric and protocol = development will focus on the suitability of measurements for automation, i= n order to support large-scale measurement efforts. > > Agreement about the definitions of metrics and methods of measurement ena= bles accurate, reproducible, and equivalent results across different implem= entations. To this end, the WG will define and maintain a registry of metri= c definitions. The WG encourages work which assesses the comparability of m= easurements of IPPM metrics with metrics developed elsewhere. The WG also e= ncourages work which improves the availability of information about the con= text in which measurements were taken. > > The IPPM WG seeks cooperation with other appropriate standards bodies and= forums to promote consistent approaches and metrics. Within the IETF proce= ss, IPPM metric definitions and measurement protocols will be subject to as= rigorous a scrutiny for usefulness, clarity, and accuracy as other protoco= l standards. The IPPM WG will interact with other areas of IETF activity wh= ose scope intersects with the requirement of these specific metrics. The WG= will, on request, provide input to other IETF working groups on the use an= d implementation of these metrics. > > Milestones: > > Mon Year - Submit draft on access rate measurement protocol problem state= ment > to IESG as Informational > Mon Year - Submit draft on RFC 2680 standards-track advancement testing > to IESG as Informational > > > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From trammell@tik.ee.ethz.ch Tue Apr 2 18:42:48 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B187911E809C for ; Tue, 2 Apr 2013 18:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kS0fOmKKb99 for ; Tue, 2 Apr 2013 18:42:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA5721F87D1 for ; Tue, 2 Apr 2013 18:42:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 247C2D9308; Wed, 3 Apr 2013 03:42:42 +0200 (MEST) 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 7Dz1l2oRv4K0; Wed, 3 Apr 2013 03:42:41 +0200 (MEST) Received: from wifi-172-24-50-56.uoa-wifi.auckland.ac.nz (wireless-nat-2.auckland.ac.nz [130.216.30.113]) (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 D5071D9305; Wed, 3 Apr 2013 03:42:40 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: Date: Wed, 3 Apr 2013 14:42:37 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <478A428E-354C-49F8-973D-E499A31D6550@tik.ee.ethz.ch> References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> To: Samita Chakrabarti X-Mailer: Apple Mail (2.1503) Cc: "ippm@ietf.org" Subject: Re: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 01:42:48 -0000 Hi, Samita, Thanks for your input! Comments and clarifications inline... On 3 Apr 2013, at 13:56, Samita Chakrabarti = wrote: > Hi Brian, >=20 > The revised charter mentions near the 2nd last paragraph - > "The WG also encourages work which improves the availability of = information about the context in which measurements were taken." ---> = is this alluding to usecase document of TWAMP/OWAMP and some of the = asociated metrics ( since the currents documents are not very clear)? = We discussed that during the charter discussion at IETF 86. This language is intended for metadata, i.e. as in the expiring = data-curation draft, as well as the reference path draft. TWAMP/OWAMP use cases are covered by the catch-all "...[t]he WG will = further develop and improve these protocols." > Also, at the charter discussion, we agreed on MIB definition for the = measurement protocols. Not sure if it was captured in the meeting = minutes. Looking at the charter I did not find coverage for it. Could = this be clarified? I consider this work to be covered, as well, under protocol development = and improvement, especially with respect to applicability of automation. > (5) draft-mathis-ippm-model-based-metrics-01 > Mon Year - Submit draft on model-based TCP bulk transfer capacity = metrics > to IESG as Proposed Standard >=20 > =3D=3D=3D> > This document's intended status is "experimental". I'd support it for = wg document as experimental. More experience is needed to make it a std = wg document. Oops. Thank you for catching this; this was a copy-paste error. The = proposed status would be experimental. > (6) draft-ko-ippm-streaming-performance-00 > Mon Year - Submit draft on model-based streaming performance metrics=20= > to IESG as Proposed Standard >=20 >=20 > =3D=3D=3D> This document is an INFORMATIONAL document. Not sure why it = should be submitted as proposed standard. It has a lot of useful = information. But I think it is premature yet to adopt as a wg draft and = more time for discussion and understanding is needed. Again, oops. As above, this is a copy-paste error. We'd adopt as = informational. Many thanks, best regards, Brian From k.pentikousis@huawei.com Wed Apr 3 09:48:50 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212D721F8F1A for ; Wed, 3 Apr 2013 09:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNIQ9b3iXhjO for ; Wed, 3 Apr 2013 09:48:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B7CEC21F8F0B for ; Wed, 3 Apr 2013 09:48:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARJ55350; Wed, 03 Apr 2013 16:48:47 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Apr 2013 17:48:30 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Apr 2013 17:48:43 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.5.6]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.007; Thu, 4 Apr 2013 00:48:38 +0800 From: Konstantinos Pentikousis To: Brian Trammell , "ippm@ietf.org" Thread-Topic: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items. Thread-Index: AQHOKlRVjyWNc4c3/06u14pm4dosBpjEufnw Date: Wed, 3 Apr 2013 16:48:36 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23F431991@szxeml511-mbx.china.huawei.com> References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> In-Reply-To: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:48:50 -0000 Dear Brian, all, |(a) whether you support the adoption of the draft as a working group |item for the associated milestone, and |(b) whether you have reviewed the draft, and/or are willing to review it |as a working group item Here's my $0.02: |(1) draft-morton-ippm-2330-update-01 |Mon Year - Submit draft of RFC 2330bis (Framework update) | to IESG as Proposed Standard Yes to both (a) and (b), and could contribute text from a wireless/mobile n= etwork perspective. |(2) draft-morton-ippm-2679-bis-01 |Mon Year - Submit draft of RFC 2679bis (One-Way Delay update) | to IESG as Proposed Standard | |(3) draft-morton-ippm-2680-bis-00 |Mon Year - Submit draft of RFC 2680bis (One-Way Loss update) | to IESG as Proposed Standard | |(4) draft-morton-ippm-lmap-path-01 |Mon Year - Submit draft on reference path for measurement location | to IESG as Proposed Standard For (2)-(4), Yes to both (a) and (b) |(5) draft-mathis-ippm-model-based-metrics-01 |Mon Year - Submit draft on model-based TCP bulk transfer capacity |metrics Yes to both (a) and (b), and could contribute text from a wireless/mobile n= etwork perspective as well. |(6) draft-ko-ippm-streaming-performance-00 |Mon Year - Submit draft on model-based streaming performance metrics | to IESG as Proposed Standard I think this is interesting and would support it as an _informational_ docu= ment, as Brian clarified. Although some more discussion and more aspects/co= nsiderations should be included in the draft, as I mentioned in the last me= eting, I think this can easily be done as this becomes a WG item. |(7) draft-bi-ippm-ipsec-01 |Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed |Standard | Yes to both (a) and (b), and as a co-author would be happy to see others fr= om the WG joining this work. |With respect to the following milestone, there are two drafts, which we |would presume would be unified through the working group process; it's |not necessary at this time to indicate which approach you support. | |(8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new-registry- |independent-00 |Mon Year - Submit draft on metrics registry to IESG as Proposed Standard I think this would be quite useful to have, and therefore Yes to both (a) a= nd (b) Best regards, Kostas From trammell@tik.ee.ethz.ch Thu Apr 4 13:59:54 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A6E21F8D2C for ; Thu, 4 Apr 2013 13:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPIO-RcTRH9D for ; Thu, 4 Apr 2013 13:59:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DB0E421F8556 for ; Thu, 4 Apr 2013 13:59:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D6C61D9305 for ; Thu, 4 Apr 2013 22:59:45 +0200 (MEST) 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 8SMA-KwZoNY7 for ; Thu, 4 Apr 2013 22:59:45 +0200 (MEST) Received: from [192.168.0.5] (unknown [121.99.65.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8CDEAD9304 for ; Thu, 4 Apr 2013 22:59:44 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> Date: Fri, 5 Apr 2013 09:59:41 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> To: "ippm@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: Re: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items. X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:59:54 -0000 Greetings, all, Many thanks to those of you who have already replied on the adoption of = drafts under the new IPPM charter. If you have further input, please = send it to the list by the end of Friday 5 April (i.e., today or = tomorrow, depending on your time zone); we'd like to put together a list = of milestones shortly. Many thanks, and best regards, Brian (chair hat) On 26 Mar 2013, at 21:12, Brian Trammell = wrote: > Greetings, all, >=20 > Having applied comments in this thread to the charter, we've arrived = at the draft charter text below this message. >=20 > I've seen on the order of a dozen comments supporting adoption of the = charter, some with suggestions for improvement that have been applied to = the below. Seeing no comments not supporting adoption, it appears that = we have clear consensus for the adoption of the draft charter text. Many = thanks to all for your comments! >=20 > The next step is to adopt drafts from those which have been presented = at the IPPM meeting in Orlando and/or discussed to date on the list, and = to determine the milestones for those drafts.=20 >=20 > For the following drafts and milestones, please indicate: >=20 > (a) whether you support the adoption of the draft as a working group = item for the associated milestone, and > (b) whether you have reviewed the draft, and/or are willing to review = it as a working group item >=20 > (1) draft-morton-ippm-2330-update-01 > Mon Year - Submit draft of RFC 2330bis (Framework update) > to IESG as Proposed Standard >=20 > (2) draft-morton-ippm-2679-bis-01 > Mon Year - Submit draft of RFC 2679bis (One-Way Delay update)=20 > to IESG as Proposed Standard >=20 > (3) draft-morton-ippm-2680-bis-00 > Mon Year - Submit draft of RFC 2680bis (One-Way Loss update)=20 > to IESG as Proposed Standard >=20 > (4) draft-morton-ippm-lmap-path-01 > Mon Year - Submit draft on reference path for measurement location > to IESG as Proposed Standard >=20 > (5) draft-mathis-ippm-model-based-metrics-01 > Mon Year - Submit draft on model-based TCP bulk transfer capacity = metrics > to IESG as Proposed Standard >=20 > (6) draft-ko-ippm-streaming-performance-00 > Mon Year - Submit draft on model-based streaming performance metrics=20= > to IESG as Proposed Standard >=20 > (7) draft-bi-ippm-ipsec-01 > Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed = Standard >=20 > With respect to the following milestone, there are two drafts, which = we would presume would be unified through the working group process; = it's not necessary at this time to indicate which approach you support. >=20 > (8) draft-bagnulo-ippm-new-registry-00, = draft-bagnulo-ippm-new-registry-independent-00 > Mon Year - Submit draft on metrics registry to IESG as Proposed = Standard >=20 > I'd like to try to evaluate consensus on adoption on each draft by = next Wednesday, April 3, absent continuing discussion. >=20 > Many thanks, best regards, >=20 > Brian >=20 >=20 > [Charter text follows] >=20 > IP Performance Metrics (ippm) > ----------------------------- >=20 > Charter >=20 > Current Status: Active >=20 > Chairs: > Brian Trammell=20 > Bill Cerveny >=20 > Transport Area Directors: > Martin Stiemerling > Martin Stiemerling >=20 > Transport Area Advisor: > Martin Stiemerling >=20 > Mailing Lists: > General Discussion: ippm@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ippm > Archive: http://www.ietf.org/mail-archive/web/ippm >=20 > Description of Working Group: >=20 > The IP Performance Metrics (IPPM) Working Group develops and maintains = standard > metrics that can be applied to the quality, performance, and = reliability of > Internet data delivery services and applications. It also develops and > maintains protocols for the measurement of these metrics. These = metrics are > designed such that they can be used by network operators, end users, = or > independent testing groups. Metrics developed by the IPPM WG are = intended to > provide unbiased quantitative performance measurements and not a value > judgement. >=20 > The IPPM WG has produced documents that define specific metrics and = procedures > for accurately measuring and documenting these metrics. The working = group will > continue advancing these metrics along the standards track, using the > guidelines stated in RFC 6576. To the extent possible, these metrics = will be > used as the basis for future work on metrics in the WG. >=20 > The WG will develop the minimum number of new metrics and models = needed to more > accurately quantitatively characterize the network path(s) under test = and/or > the performance of transport and application layer protocols on these = path(s). > New metric definitions will state how the definition improves on an = existing > metric definition, or assesses a property of network performance not = previously > covered by a defined metric. >=20 > Additional methods will be defined for the composition and calibration = of > IPPM-defined metrics, as well as active, passive and hybrid = measurement methods > for these metrics. In addition, the WG encourages work which describes = the > applicability of metrics and measurement methods, especially to = improve > understanding of the tradeoffs involved among active, passive, and = hybrid > methods. >=20 > The WG may update its core framework RFC 2330 as necessary to = accommodate these > activities. >=20 > The WG has produced protocols for communication among test equipment = to enable > the measurement of the one- and two-way metrics (OWAMP and TWAMP = respectively). > These protocols will be advanced along the standards track. The WG = will further > develop and improve these protocols. The WG may develop new = measurement > protocols as necessary to support new metrics. New metric and protocol > development will focus on the suitability of measurements for = automation, in > order to support large-scale measurement efforts. >=20 > Agreement about the definitions of metrics and methods of measurement = enables > accurate, reproducible, and equivalent results across different > implementations. To this end, the WG will define and maintain a = registry of > metric definitions. The WG encourages work which assesses the = comparability of > measurements of IPPM metrics with metrics developed elsewhere. The WG = also > encourages work which improves the availability of information about = the > context in which measurements were taken. >=20 > The IPPM WG seeks cooperation with other appropriate standards bodies = and > forums to promote consistent approaches and metrics. Within the IETF = process, > IPPM metric definitions and measurement protocols will be subject to = as > rigorous a scrutiny for usefulness, clarity, and accuracy as other = protocol > standards. The IPPM WG will interact with other areas of IETF activity = whose > scope intersects with the requirement of these specific metrics. The = WG will, > on request, provide input to other IETF working groups on the use and > implementation of these metrics. >=20 > Milestones: >=20 > Mon Year - Submit draft on access rate measurement protocol problem = statement > to IESG as Informational > Mon Year - Submit draft on RFC 2680 standards-track advancement = testing > to IESG as Informational >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From dromasca@avaya.com Sun Apr 7 02:44:48 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DDC21F8D33; Sun, 7 Apr 2013 02:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.502 X-Spam-Level: X-Spam-Status: No, score=-103.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OeP6W8dcnkk; Sun, 7 Apr 2013 02:44:47 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id B91EE21F8D2A; Sun, 7 Apr 2013 02:44:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHpXMFHGmAcF/2dsb2JhbABEgma/Tn8Wc4IfAQEBAQMBAQEPKDQLDAQCAQgNBAQBAQsUCQcnCxQIAQgBAQQBDQUIGodxAQukVpw/BI1TgRAmCwcGgllhA5xailGBUoE2gXI1 X-IronPort-AV: E=Sophos;i="4.84,760,1355115600"; d="scan'208";a="5923559" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Apr 2013 05:44:46 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Apr 2013 05:42:09 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Sun, 7 Apr 2013 05:44:45 -0400 From: "Romascanu, Dan (Dan)" To: David Sinicrope , "lmap@ietf.org" , "ippm@ietf.org" Thread-Topic: [lmap] FW: Marked for action ? - RE: incoming liaison statement from Broadband Forum Thread-Index: Ac4r5VPor3vVk41YSeqEXZtZkmdyvgHjpEPg Date: Sun, 7 Apr 2013 09:44:44 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C2F7C@AZ-FFEXMB04.global.avaya.com> References: <871EB8879748FA458598F0461906289317C52C@eusaamb103.ericsson.se> In-Reply-To: <871EB8879748FA458598F0461906289317C52C@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ops-ads@tools.ietf.org" Subject: Re: [ippm] [lmap] FW: Marked for action ? - RE: incoming liaison statement from Broadband Forum X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 09:44:48 -0000 Hi David, Thank you for forwarding this.=20 Please note that LMAP is not yet constitute as a working group. We are work= ing towards submitting a charter to the IESG for approval in view of format= ting a WG, but this process will not be completed before 5/24. We are welco= ming mail list contributions that can help in the process of defining the s= cope of the future WG and discussions around these contributions on the mai= l list, but we are not in the situation to answer such contributions by sen= ding back liaison statements.=20 Regards, Dan > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > David Sinicrope > Sent: Thursday, March 28, 2013 8:58 PM > To: lmap@ietf.org; ippm@ietf.org > Cc: ops-ads@tools.ietf.org > Subject: [lmap] FW: Marked for action ? - RE: incoming liaison statement > from Broadband Forum >=20 > Please note the following incoming liaison statement from the Broadband > Forum concerning the LMAP activity. > https://datatracker.ietf.org/liaison/1243/ > This is the latest of a few liaisons from the Broadband Forum on this > activity. If possible a response should be sent by 5/24 to ensure it > reaches the Broadband Forum by their 2Q2013 meeting. > Regards, > Dave Sinicrope > BBF Liaison to the IETF > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From trammell@tik.ee.ethz.ch Mon Apr 8 02:29:37 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1021F8EE1 for ; Mon, 8 Apr 2013 02:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BID7M3T+yhHS for ; Mon, 8 Apr 2013 02:29:36 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 29A9F21F8DEF for ; Mon, 8 Apr 2013 02:29:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 56508D930B for ; Mon, 8 Apr 2013 11:29:34 +0200 (MEST) 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 L6zcFxSy-tUZ for ; Mon, 8 Apr 2013 11:29:34 +0200 (MEST) Received: from [192.168.0.5] (unknown [121.99.65.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 6CEE9D9305 for ; Mon, 8 Apr 2013 11:29:33 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <95B045E6-C024-4A71-81FF-7403E7EBE6CF@tik.ee.ethz.ch> Date: Mon, 8 Apr 2013 21:29:28 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <95B045E6-C024-4A71-81FF-7403E7EBE6CF@tik.ee.ethz.ch> To: "ippm@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: [ippm] Consensus on draft adoption as WG items X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 09:29:37 -0000 Greetings, all, Given the response to the consensus call for document adoption, here's = where we see consensus on the next milestones for the IPPM working = group: (1) draft-morton-ippm-2330-update-01 Mon Year - Submit draft of RFC 2330bis (Framework update) to IESG as Proposed Standard Clear support for adoption, with pledges for reviews and contributions. (2) draft-morton-ippm-2679-bis-01 Mon Year - Submit draft of RFC 2679bis (One-Way Delay update)=20 to IESG as Proposed Standard Mixed support for adoption, with at least one pledge for review and = contribution. (3) draft-morton-ippm-2680-bis-00 Mon Year - Submit draft of RFC 2680bis (One-Way Loss update)=20 to IESG as Proposed Standard Mixed support for adoption, with at least one pledge for review and = contribution. (4) draft-morton-ippm-lmap-path-01 Mon Year - Submit draft on reference path for measurement location to IESG as Proposed Standard Clear support for adoption, with pledges for reviews and contributions, = and a suggestion that the WG may consider folding this into -2330-update. (5) draft-mathis-ippm-model-based-metrics-01 Mon Year - Submit draft on model-based TCP bulk transfer capacity = metrics to IESG as Experimental Clear support for adoption (with correction of intended status to Experimental), with pledges for reviews and contributions. (6) draft-ko-ippm-streaming-performance-00 Mon Year - Submit draft on model-based streaming performance metrics=20 to IESG as Informational Mixed support for adoption, with correction of intended status and=20 indication that the document needs to mature a bit. (7) draft-bi-ippm-ipsec-01 Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed = Standard Clear support for adoption, with indication that the document needs some = work within the WG. (8) draft-bagnulo-ippm-new-registry-00, = draft-bagnulo-ippm-new-registry-independent-00 Mon Year - Submit draft on metrics registry to IESG as Proposed Standard Mixed support for adoption, with indication that the document should be discussed and developed further before adoption. Given this, we propose that we adopt the following drafts as the next = set of milestones: draft-morton-ippm-2330-update draft-morton-ippm-lmap-path draft-mathis-ippm-model-based-metrics draft-bi-ippm-ipsec Given that draft-morton-ippm-2679-bis and draft-morton-ippm-2680-bis may = depend on 2330-update, they should be developed in parallel with it, and = considered for adoption as it nears completion. The remaining drafts are all clearly in scope for the new charter, so = please continue developing them, with discussion on the list as = necessary. Specifically, the new registry drafts should be unified into = a single approach, and adopted following further development. After consulting with the authors, we suggest the following milestones = for existing WG drafts: Jul 2013 - Submit draft on RFC 2680 standards-track advancement testing = to IESG as Informational Dec 2013 - Submit draft on access rate measurement protocol problem = statement to IESG as Informational I'd suggest the following milestones for the new drafts; authors, please = respond if these are not realistic: Dec 2013 - Submit draft updating the IPPM Framework (2330-update) to = IESG as Proposed Standard Dec 2013 - Submit draft on reference path for measurement location to = IESG as Proposed Standard Mar 2014 - Submit draft on model-based TCP bulk transfer capacity = metrics to IESG as Experimental Mar 2014 - Submit draft on OWAMP / TWAMP Security to IESG as Proposed = Standard Please be prompt with any comments on this proposal; we'd like to hand = the proposed charter and milestones up to our AD this week. Best regards, Brian and Bill= From marcelo@it.uc3m.es Mon Apr 8 03:18:23 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2E021F936D for ; Mon, 8 Apr 2013 03:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4xDH29ckb1s for ; Mon, 8 Apr 2013 03:18:22 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id E7EF921F933F for ; Mon, 8 Apr 2013 03:18:14 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3ED79CB7D99 for ; Mon, 8 Apr 2013 12:18:13 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost9.it.uc3m.es (unknown [163.117.139.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 2EE8BCB7C2C for ; Mon, 8 Apr 2013 12:18:13 +0200 (CEST) Message-ID: <51629964.5000308@it.uc3m.es> Date: Mon, 08 Apr 2013 12:18:12 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ippm@ietf.org References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <95B045E6-C024-4A71-81FF-7403E7EBE6CF@tik.ee.ethz.ch> <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> In-Reply-To: <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Mon, 08 Apr 2013 12:18:13 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19782.005 X-TM-AS-Result: No--38.140-7.0-31-1 X-imss-scan-details: No--38.140-7.0-31-1 Subject: Re: [ippm] Consensus on draft adoption as WG items X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 10:18:23 -0000 Hi, I agree with most of this. One comment about the metric registry work. I agree that the draft need more discussion and the WG is not ready for adopting it. But wouldnt make sense to include a milestone about this in the charter even if we dont adopt a document at this stage? Thanks, marcelo El 08/04/13 11:29, Brian Trammell escribió: > Greetings, all, > > Given the response to the consensus call for document adoption, here's where we see consensus on the next milestones for the IPPM working group: > > > (1) draft-morton-ippm-2330-update-01 > Mon Year - Submit draft of RFC 2330bis (Framework update) > to IESG as Proposed Standard > > Clear support for adoption, with pledges for reviews and contributions. > > > (2) draft-morton-ippm-2679-bis-01 > Mon Year - Submit draft of RFC 2679bis (One-Way Delay update) > to IESG as Proposed Standard > > Mixed support for adoption, with at least one pledge for review and contribution. > > > (3) draft-morton-ippm-2680-bis-00 > Mon Year - Submit draft of RFC 2680bis (One-Way Loss update) > to IESG as Proposed Standard > > Mixed support for adoption, with at least one pledge for review and contribution. > > > (4) draft-morton-ippm-lmap-path-01 > Mon Year - Submit draft on reference path for measurement location > to IESG as Proposed Standard > > Clear support for adoption, with pledges for reviews and contributions, and a > suggestion that the WG may consider folding this into -2330-update. > > > (5) draft-mathis-ippm-model-based-metrics-01 > Mon Year - Submit draft on model-based TCP bulk transfer capacity metrics > to IESG as Experimental > > Clear support for adoption (with correction of intended status to > Experimental), with pledges for reviews and contributions. > > > (6) draft-ko-ippm-streaming-performance-00 > Mon Year - Submit draft on model-based streaming performance metrics > to IESG as Informational > > Mixed support for adoption, with correction of intended status and > indication that the document needs to mature a bit. > > > (7) draft-bi-ippm-ipsec-01 > Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Standard > > Clear support for adoption, with indication that the document needs some work > within the WG. > > > (8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new-registry-independent-00 > Mon Year - Submit draft on metrics registry to IESG as Proposed Standard > > Mixed support for adoption, with indication that the document should be > discussed and developed further before adoption. > > > Given this, we propose that we adopt the following drafts as the next set of milestones: > > draft-morton-ippm-2330-update > draft-morton-ippm-lmap-path > draft-mathis-ippm-model-based-metrics > draft-bi-ippm-ipsec > > Given that draft-morton-ippm-2679-bis and draft-morton-ippm-2680-bis may depend on 2330-update, they should be developed in parallel with it, and considered for adoption as it nears completion. > > The remaining drafts are all clearly in scope for the new charter, so please continue developing them, with discussion on the list as necessary. Specifically, the new registry drafts should be unified into a single approach, and adopted following further development. > > After consulting with the authors, we suggest the following milestones for existing WG drafts: > > Jul 2013 - Submit draft on RFC 2680 standards-track advancement testing to IESG as Informational > Dec 2013 - Submit draft on access rate measurement protocol problem statement to IESG as Informational > > I'd suggest the following milestones for the new drafts; authors, please respond if these are not realistic: > > Dec 2013 - Submit draft updating the IPPM Framework (2330-update) to IESG as Proposed Standard > Dec 2013 - Submit draft on reference path for measurement location to IESG as Proposed Standard > Mar 2014 - Submit draft on model-based TCP bulk transfer capacity metrics to IESG as Experimental > Mar 2014 - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Standard > > Please be prompt with any comments on this proposal; we'd like to hand the proposed charter and milestones up to our AD this week. > > > Best regards, > > Brian and Bill > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From trammell@tik.ee.ethz.ch Mon Apr 8 03:49:26 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9725321F9193 for ; Mon, 8 Apr 2013 03:49:26 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lSPlv9P3GGn for ; Mon, 8 Apr 2013 03:49:26 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9168821F9184 for ; Mon, 8 Apr 2013 03:49:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3505AD930B; Mon, 8 Apr 2013 12:49:22 +0200 (MEST) 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 nxj-8wH9oU2o; Mon, 8 Apr 2013 12:49:21 +0200 (MEST) Received: from [192.168.0.5] (unknown [121.99.65.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0501FD9304; Mon, 8 Apr 2013 12:49:19 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <51629964.5000308@it.uc3m.es> Date: Mon, 8 Apr 2013 22:49:14 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <4910FA8F-CD73-49E7-9402-F43E741187BE@tik.ee.ethz.ch> References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <95B045E6-C024-4A71-81FF-7403E7EBE6CF@tik.ee.ethz.ch> <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> <51629964.5000308@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1503) Cc: ippm@ietf.org Subject: Re: [ippm] Consensus on draft adoption as WG items X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 10:49:26 -0000 Hi, Marcelo, Now that we have agreed charter text which will covers all the work we = want to do now and that we think we will want to do over the next few = years (the hard part), the intention is that we can quickly update = milestones, with much less work, coincident with document adoptions as = WG items. I suspect we could evaluate subsequent revisions of drafts = fitting the charter text and update the milestones as often as once per = meeting cycle, if the the individual and WG drafts progress quickly = enough. Given that model, I'm not sure I see what the value is in = placing a milestone on this charter without a document ready to cover = it. Best regards, Brian On 8 Apr 2013, at 22:18, marcelo bagnulo braun = wrote: > Hi, >=20 > I agree with most of this. > One comment about the metric registry work. I agree that the draft = need more discussion and the WG is not ready for adopting it. >=20 > But wouldnt make sense to include a milestone about this in the = charter even if we dont adopt a document at this stage? >=20 > Thanks, marcelo >=20 >=20 > El 08/04/13 11:29, Brian Trammell escribi=F3: >> Greetings, all, >>=20 >> Given the response to the consensus call for document adoption, = here's where we see consensus on the next milestones for the IPPM = working group: >>=20 >>=20 >> (1) draft-morton-ippm-2330-update-01 >> Mon Year - Submit draft of RFC 2330bis (Framework update) >> to IESG as Proposed Standard >>=20 >> Clear support for adoption, with pledges for reviews and = contributions. >>=20 >>=20 >> (2) draft-morton-ippm-2679-bis-01 >> Mon Year - Submit draft of RFC 2679bis (One-Way Delay update) >> to IESG as Proposed Standard >>=20 >> Mixed support for adoption, with at least one pledge for review and = contribution. >>=20 >>=20 >> (3) draft-morton-ippm-2680-bis-00 >> Mon Year - Submit draft of RFC 2680bis (One-Way Loss update) >> to IESG as Proposed Standard >>=20 >> Mixed support for adoption, with at least one pledge for review and = contribution. >>=20 >>=20 >> (4) draft-morton-ippm-lmap-path-01 >> Mon Year - Submit draft on reference path for measurement location >> to IESG as Proposed Standard >>=20 >> Clear support for adoption, with pledges for reviews and = contributions, and a >> suggestion that the WG may consider folding this into -2330-update. >>=20 >>=20 >> (5) draft-mathis-ippm-model-based-metrics-01 >> Mon Year - Submit draft on model-based TCP bulk transfer capacity = metrics >> to IESG as Experimental >>=20 >> Clear support for adoption (with correction of intended status to >> Experimental), with pledges for reviews and contributions. >>=20 >>=20 >> (6) draft-ko-ippm-streaming-performance-00 >> Mon Year - Submit draft on model-based streaming performance metrics >> to IESG as Informational >>=20 >> Mixed support for adoption, with correction of intended status and >> indication that the document needs to mature a bit. >>=20 >>=20 >> (7) draft-bi-ippm-ipsec-01 >> Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed = Standard >>=20 >> Clear support for adoption, with indication that the document needs = some work >> within the WG. >>=20 >>=20 >> (8) draft-bagnulo-ippm-new-registry-00, = draft-bagnulo-ippm-new-registry-independent-00 >> Mon Year - Submit draft on metrics registry to IESG as Proposed = Standard >>=20 >> Mixed support for adoption, with indication that the document should = be >> discussed and developed further before adoption. >>=20 >>=20 >> Given this, we propose that we adopt the following drafts as the next = set of milestones: >>=20 >> draft-morton-ippm-2330-update >> draft-morton-ippm-lmap-path >> draft-mathis-ippm-model-based-metrics >> draft-bi-ippm-ipsec >>=20 >> Given that draft-morton-ippm-2679-bis and draft-morton-ippm-2680-bis = may depend on 2330-update, they should be developed in parallel with it, = and considered for adoption as it nears completion. >>=20 >> The remaining drafts are all clearly in scope for the new charter, so = please continue developing them, with discussion on the list as = necessary. Specifically, the new registry drafts should be unified into = a single approach, and adopted following further development. >>=20 >> After consulting with the authors, we suggest the following = milestones for existing WG drafts: >>=20 >> Jul 2013 - Submit draft on RFC 2680 standards-track advancement = testing to IESG as Informational >> Dec 2013 - Submit draft on access rate measurement protocol problem = statement to IESG as Informational >>=20 >> I'd suggest the following milestones for the new drafts; authors, = please respond if these are not realistic: >>=20 >> Dec 2013 - Submit draft updating the IPPM Framework (2330-update) to = IESG as Proposed Standard >> Dec 2013 - Submit draft on reference path for measurement location to = IESG as Proposed Standard >> Mar 2014 - Submit draft on model-based TCP bulk transfer capacity = metrics to IESG as Experimental >> Mar 2014 - Submit draft on OWAMP / TWAMP Security to IESG as Proposed = Standard >>=20 >> Please be prompt with any comments on this proposal; we'd like to = hand the proposed charter and milestones up to our AD this week. >>=20 >>=20 >> Best regards, >>=20 >> Brian and Bill >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >>=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Mon Apr 8 07:01:05 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F4D21F9726 for ; Mon, 8 Apr 2013 07:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGXx6smfIU8t for ; Mon, 8 Apr 2013 07:01:04 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 530E421F971F for ; Mon, 8 Apr 2013 07:01:04 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 65F3F1205F4; Mon, 8 Apr 2013 10:01:16 -0400 (EDT) Received: from njfpsrvexg5.research.att.com (njfpsrvexg5.research.att.com [135.207.177.27]) by mail-blue.research.att.com (Postfix) with ESMTP id B8B11F0160; Mon, 8 Apr 2013 10:01:03 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg5.research.att.com ([fe80::a501:da3:2345:4587%10]) with mapi; Mon, 8 Apr 2013 10:01:03 -0400 From: "MORTON JR., ALFRED C (AL)" To: Brian Trammell , marcelo bagnulo braun Date: Mon, 8 Apr 2013 10:01:02 -0400 Thread-Topic: [ippm] Consensus on draft adoption as WG items Thread-Index: Ac40RsO+ntxgRya5SiiaISC6PXbqvgAFiTlw Message-ID: References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <95B045E6-C024-4A71-81FF-7403E7EBE6CF@tik.ee.ethz.ch> <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> <51629964.5000308@it.uc3m.es> <4910FA8F-CD73-49E7-9402-F43E741187BE@tik.ee.ethz.ch> In-Reply-To: <4910FA8F-CD73-49E7-9402-F43E741187BE@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ippm@ietf.org" Subject: Re: [ippm] Consensus on draft adoption as WG items X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 14:01:05 -0000 Hi Brian, Marcelo, all, IMO, there are a few areas where conscientious working group participants s= hould contribute, in addition to the natural preference to work on new proposals. These areas= are part of=20 the overhead of being a standards body. Liaison replies, specification main= tenance, and developing support specifications (registry) are not exciting and won't win= the election,=20 but they all require attention at some point. In our priorities for the fut= ure, let's keep in mind that the IETF standards process is always on the list. So, let's move ahead with the new WG drafts and also see what we can accomp= lish across the board of proposals, as you've suggested. regards, Al > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Monday, April 08, 2013 6:49 AM > To: marcelo bagnulo braun > Cc: ippm@ietf.org > Subject: Re: [ippm] Consensus on draft adoption as WG items >=20 > Hi, Marcelo, >=20 > Now that we have agreed charter text which will covers all the work we > want to do now and that we think we will want to do over the next few > years (the hard part), the intention is that we can quickly update > milestones, with much less work, coincident with document adoptions as WG > items. I suspect we could evaluate subsequent revisions of drafts fitting > the charter text and update the milestones as often as once per meeting > cycle, if the the individual and WG drafts progress quickly enough. Given > that model, I'm not sure I see what the value is in placing a milestone o= n > this charter without a document ready to cover it. >=20 > Best regards, >=20 > Brian >=20 > On 8 Apr 2013, at 22:18, marcelo bagnulo braun wrote= : >=20 > > Hi, > > > > I agree with most of this. > > One comment about the metric registry work. I agree that the draft need > more discussion and the WG is not ready for adopting it. > > > > But wouldnt make sense to include a milestone about this in the charter > even if we dont adopt a document at this stage? > > > > Thanks, marcelo > > > > > > El 08/04/13 11:29, Brian Trammell escribi=F3: > >> Greetings, all, > >> > >> Given the response to the consensus call for document adoption, here's > where we see consensus on the next milestones for the IPPM working group: > >> > >> > >> (1) draft-morton-ippm-2330-update-01 > >> Mon Year - Submit draft of RFC 2330bis (Framework update) > >> to IESG as Proposed Standard > >> > >> Clear support for adoption, with pledges for reviews and contributions= . > >> > >> > >> (2) draft-morton-ippm-2679-bis-01 > >> Mon Year - Submit draft of RFC 2679bis (One-Way Delay update) > >> to IESG as Proposed Standard > >> > >> Mixed support for adoption, with at least one pledge for review and > contribution. > >> > >> > >> (3) draft-morton-ippm-2680-bis-00 > >> Mon Year - Submit draft of RFC 2680bis (One-Way Loss update) > >> to IESG as Proposed Standard > >> > >> Mixed support for adoption, with at least one pledge for review and > contribution. > >> > >> > >> (4) draft-morton-ippm-lmap-path-01 > >> Mon Year - Submit draft on reference path for measurement location > >> to IESG as Proposed Standard > >> > >> Clear support for adoption, with pledges for reviews and contributions= , > and a > >> suggestion that the WG may consider folding this into -2330-update. > >> > >> > >> (5) draft-mathis-ippm-model-based-metrics-01 > >> Mon Year - Submit draft on model-based TCP bulk transfer capacity > metrics > >> to IESG as Experimental > >> > >> Clear support for adoption (with correction of intended status to > >> Experimental), with pledges for reviews and contributions. > >> > >> > >> (6) draft-ko-ippm-streaming-performance-00 > >> Mon Year - Submit draft on model-based streaming performance metrics > >> to IESG as Informational > >> > >> Mixed support for adoption, with correction of intended status and > >> indication that the document needs to mature a bit. > >> > >> > >> (7) draft-bi-ippm-ipsec-01 > >> Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed > Standard > >> > >> Clear support for adoption, with indication that the document needs > some work > >> within the WG. > >> > >> > >> (8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new- > registry-independent-00 > >> Mon Year - Submit draft on metrics registry to IESG as Proposed > Standard > >> > >> Mixed support for adoption, with indication that the document should b= e > >> discussed and developed further before adoption. > >> > >> > >> Given this, we propose that we adopt the following drafts as the next > set of milestones: > >> > >> draft-morton-ippm-2330-update > >> draft-morton-ippm-lmap-path > >> draft-mathis-ippm-model-based-metrics > >> draft-bi-ippm-ipsec > >> > >> Given that draft-morton-ippm-2679-bis and draft-morton-ippm-2680-bis > may depend on 2330-update, they should be developed in parallel with it, > and considered for adoption as it nears completion. > >> > >> The remaining drafts are all clearly in scope for the new charter, so > please continue developing them, with discussion on the list as necessary= . > Specifically, the new registry drafts should be unified into a single > approach, and adopted following further development. > >> > >> After consulting with the authors, we suggest the following milestones > for existing WG drafts: > >> > >> Jul 2013 - Submit draft on RFC 2680 standards-track advancement testin= g > to IESG as Informational > >> Dec 2013 - Submit draft on access rate measurement protocol problem > statement to IESG as Informational > >> > >> I'd suggest the following milestones for the new drafts; authors, > please respond if these are not realistic: > >> > >> Dec 2013 - Submit draft updating the IPPM Framework (2330-update) to > IESG as Proposed Standard > >> Dec 2013 - Submit draft on reference path for measurement location to > IESG as Proposed Standard > >> Mar 2014 - Submit draft on model-based TCP bulk transfer capacity > metrics to IESG as Experimental > >> Mar 2014 - Submit draft on OWAMP / TWAMP Security to IESG as Proposed > Standard > >> > >> Please be prompt with any comments on this proposal; we'd like to hand > the proposed charter and milestones up to our AD this week. > >> > >> > >> Best regards, > >> > >> Brian and Bill > >> _______________________________________________ > >> ippm mailing list > >> ippm@ietf.org > >> https://www.ietf.org/mailman/listinfo/ippm > >> > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From marcelo@it.uc3m.es Mon Apr 8 07:41:38 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E31921F97F2 for ; Mon, 8 Apr 2013 07:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luvX5hHGEMCa for ; Mon, 8 Apr 2013 07:41:37 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9200D21F93F3 for ; Mon, 8 Apr 2013 07:41:37 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 52E97FA955C; Mon, 8 Apr 2013 16:41:36 +0200 (CEST) X-uc3m-safe: yes Received: from [163.117.203.127] (unknown [163.117.203.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id E6D9F9D4573; Mon, 8 Apr 2013 16:41:35 +0200 (CEST) Message-ID: <5162D71E.4020202@it.uc3m.es> Date: Mon, 08 Apr 2013 16:41:34 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian Trammell References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <95B045E6-C024-4A71-81FF-7403E7EBE6CF@tik.ee.ethz.ch> <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> <51629964.5000308@it.uc3m.es> <4910FA8F-CD73-49E7-9402-F43E741187BE@tik.ee.ethz.ch> In-Reply-To: <4910FA8F-CD73-49E7-9402-F43E741187BE@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Mon, 08 Apr 2013 16:41:36 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19782.006 X-TM-AS-Result: No--42.301-7.0-31-1 X-imss-scan-details: No--42.301-7.0-31-1 Cc: ippm@ietf.org Subject: Re: [ippm] Consensus on draft adoption as WG items X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 14:41:38 -0000 Hi, I was not aware of the model, im my previous experience milestone updating is not so agile, but if this is how plan to run the wg, i am fine with yoour approach and i agree we can wait. Regards, marcelo El 08/04/13 12:49, Brian Trammell escribió: > Hi, Marcelo, > > Now that we have agreed charter text which will covers all the work we want to do now and that we think we will want to do over the next few years (the hard part), the intention is that we can quickly update milestones, with much less work, coincident with document adoptions as WG items. I suspect we could evaluate subsequent revisions of drafts fitting the charter text and update the milestones as often as once per meeting cycle, if the the individual and WG drafts progress quickly enough. Given that model, I'm not sure I see what the value is in placing a milestone on this charter without a document ready to cover it. > > Best regards, > > Brian > > On 8 Apr 2013, at 22:18, marcelo bagnulo braun wrote: > >> Hi, >> >> I agree with most of this. >> One comment about the metric registry work. I agree that the draft need more discussion and the WG is not ready for adopting it. >> >> But wouldnt make sense to include a milestone about this in the charter even if we dont adopt a document at this stage? >> >> Thanks, marcelo >> >> >> El 08/04/13 11:29, Brian Trammell escribió: >>> Greetings, all, >>> >>> Given the response to the consensus call for document adoption, here's where we see consensus on the next milestones for the IPPM working group: >>> >>> >>> (1) draft-morton-ippm-2330-update-01 >>> Mon Year - Submit draft of RFC 2330bis (Framework update) >>> to IESG as Proposed Standard >>> >>> Clear support for adoption, with pledges for reviews and contributions. >>> >>> >>> (2) draft-morton-ippm-2679-bis-01 >>> Mon Year - Submit draft of RFC 2679bis (One-Way Delay update) >>> to IESG as Proposed Standard >>> >>> Mixed support for adoption, with at least one pledge for review and contribution. >>> >>> >>> (3) draft-morton-ippm-2680-bis-00 >>> Mon Year - Submit draft of RFC 2680bis (One-Way Loss update) >>> to IESG as Proposed Standard >>> >>> Mixed support for adoption, with at least one pledge for review and contribution. >>> >>> >>> (4) draft-morton-ippm-lmap-path-01 >>> Mon Year - Submit draft on reference path for measurement location >>> to IESG as Proposed Standard >>> >>> Clear support for adoption, with pledges for reviews and contributions, and a >>> suggestion that the WG may consider folding this into -2330-update. >>> >>> >>> (5) draft-mathis-ippm-model-based-metrics-01 >>> Mon Year - Submit draft on model-based TCP bulk transfer capacity metrics >>> to IESG as Experimental >>> >>> Clear support for adoption (with correction of intended status to >>> Experimental), with pledges for reviews and contributions. >>> >>> >>> (6) draft-ko-ippm-streaming-performance-00 >>> Mon Year - Submit draft on model-based streaming performance metrics >>> to IESG as Informational >>> >>> Mixed support for adoption, with correction of intended status and >>> indication that the document needs to mature a bit. >>> >>> >>> (7) draft-bi-ippm-ipsec-01 >>> Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Standard >>> >>> Clear support for adoption, with indication that the document needs some work >>> within the WG. >>> >>> >>> (8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new-registry-independent-00 >>> Mon Year - Submit draft on metrics registry to IESG as Proposed Standard >>> >>> Mixed support for adoption, with indication that the document should be >>> discussed and developed further before adoption. >>> >>> >>> Given this, we propose that we adopt the following drafts as the next set of milestones: >>> >>> draft-morton-ippm-2330-update >>> draft-morton-ippm-lmap-path >>> draft-mathis-ippm-model-based-metrics >>> draft-bi-ippm-ipsec >>> >>> Given that draft-morton-ippm-2679-bis and draft-morton-ippm-2680-bis may depend on 2330-update, they should be developed in parallel with it, and considered for adoption as it nears completion. >>> >>> The remaining drafts are all clearly in scope for the new charter, so please continue developing them, with discussion on the list as necessary. Specifically, the new registry drafts should be unified into a single approach, and adopted following further development. >>> >>> After consulting with the authors, we suggest the following milestones for existing WG drafts: >>> >>> Jul 2013 - Submit draft on RFC 2680 standards-track advancement testing to IESG as Informational >>> Dec 2013 - Submit draft on access rate measurement protocol problem statement to IESG as Informational >>> >>> I'd suggest the following milestones for the new drafts; authors, please respond if these are not realistic: >>> >>> Dec 2013 - Submit draft updating the IPPM Framework (2330-update) to IESG as Proposed Standard >>> Dec 2013 - Submit draft on reference path for measurement location to IESG as Proposed Standard >>> Mar 2014 - Submit draft on model-based TCP bulk transfer capacity metrics to IESG as Experimental >>> Mar 2014 - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Standard >>> >>> Please be prompt with any comments on this proposal; we'd like to hand the proposed charter and milestones up to our AD this week. >>> >>> >>> Best regards, >>> >>> Brian and Bill >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm > From mattmathis@google.com Mon Apr 8 08:53:34 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179AF21F9593 for ; Mon, 8 Apr 2013 08:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.145 X-Spam-Level: X-Spam-Status: No, score=-101.145 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, 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 X6CT4n2QcPd3 for ; Mon, 8 Apr 2013 08:53:32 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 22F0F21F9738 for ; Mon, 8 Apr 2013 08:53:31 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id tp5so6921444ieb.8 for ; Mon, 08 Apr 2013 08:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7UQnYVmTAIwZqyVnKWy0mhoYhDgDVifDpc1yu1idK68=; b=bSIu7q5OAoViCzHphTS0tBjZyGEQUCm+dBtPl+8LMpBxN9tPDskUQsvi6Nt85w+cjk X3Si/PmaRKmUps3N8i395AWn3XmrctWFXE78lTzRJYk2SVWmKfXE9C3tYSfT91oTsrk9 79I0g5WGt4vN82K3mWuhScEEeyNzUoSWBu6/sT/pwHcCeck/qeB3cA9874l/sijhGMxQ 5dKPJnFrrwOn7TlF/rIWudDTjVN9+yPDjUVs2+o4KONHMmPxUWwYWqSyc1nKcZHIxb0j CGkyS+f40IkftclBNCefed26Gz5208a1/lEh/nzsgR+Eec8v6uzX70eZlMRSpImTAADQ uQpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=7UQnYVmTAIwZqyVnKWy0mhoYhDgDVifDpc1yu1idK68=; b=B/9LpYmpeTQ0qzvWGZUXmpkkC6rcWjqx8eWGfGJD/afwc0Rv1WfflBA2Yvh9eRVWt3 YLJgnYoM/g2todvkyqN0zfmBQV5mzzPHJmIBKoEfT+BqLbc8syzd89qUOd9+xHEtlLRg kqLx2oVpTjc/JlFboeYkhdmftqqDIX/ubiMQV/4lrubyPzabknLeDePA4xFwiHHLaG+j EOy4SMt1o+Qzx4Z0gWE7dNbtukbu8WET8NjZHpdMLAjTZ4cg/DPWObfaeWKJ0Ew8DyHK +sQVMT6zVp4qzKH0fP61e1Pl2P7DHXUMYUsdTXO+yeqVXl6oPjBu6T9hAYPC85MELyZS nqBA== MIME-Version: 1.0 X-Received: by 10.43.117.136 with SMTP id fm8mr12443386icc.33.1365436404384; Mon, 08 Apr 2013 08:53:24 -0700 (PDT) Received: by 10.50.194.197 with HTTP; Mon, 8 Apr 2013 08:53:24 -0700 (PDT) In-Reply-To: <5162D71E.4020202@it.uc3m.es> References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <95B045E6-C024-4A71-81FF-7403E7EBE6CF@tik.ee.ethz.ch> <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> <51629964.5000308@it.uc3m.es> <4910FA8F-CD73-49E7-9402-F43E741187BE@tik.ee.ethz.ch> <5162D71E.4020202@it.uc3m.es> Date: Mon, 8 Apr 2013 08:53:24 -0700 Message-ID: From: Matt Mathis To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=bcaec5182488d8e4f204d9db6fc7 X-Gm-Message-State: ALoCoQkPIpxIuuKxIw+6WS/AzsWSPC5hJJqdh8klA3H0QjOv6SPCWccQBtHPe/zJt/Z1itwiCMwcs8Xkc3DDOSjQycJoI8iO0shvtDyxQllThQoBRyuuWgAQXc0gON1pykwEj7p8aAuAKtORCxI1zmqnEH63tM5+mmV94qlFZoW+l3uLdA8vznrj84utUbdre86/r65qV8MA Cc: "ippm@ietf.org" Subject: Re: [ippm] Consensus on draft adoption as WG items X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 15:53:34 -0000 --bcaec5182488d8e4f204d9db6fc7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The agility of updating milestones is sensitive to the clarity of the charter: changes that are clearly in scope don't require (significantly) wider discussion. If the scope is vague, or the item a stretch, others (WG chairs defending their turf and/or the IESG) have to be involved in a conversation.... A IESG approved, clear, up to date charter with placeholders for future projects makes milestone adjustments easy. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, Apr 8, 2013 at 7:41 AM, marcelo bagnulo braun w= rote: > Hi, > > I was not aware of the model, im my previous experience milestone updatin= g > is not so agile, but if this is how plan to run the wg, i am fine with > yoour approach and i agree we can wait. > > Regards, marcelo > > > El 08/04/13 12:49, Brian Trammell escribi=F3: > > Hi, Marcelo, >> >> Now that we have agreed charter text which will covers all the work we >> want to do now and that we think we will want to do over the next few ye= ars >> (the hard part), the intention is that we can quickly update milestones, >> with much less work, coincident with document adoptions as WG items. I >> suspect we could evaluate subsequent revisions of drafts fitting the >> charter text and update the milestones as often as once per meeting cycl= e, >> if the the individual and WG drafts progress quickly enough. Given that >> model, I'm not sure I see what the value is in placing a milestone on th= is >> charter without a document ready to cover it. >> >> Best regards, >> >> Brian >> >> On 8 Apr 2013, at 22:18, marcelo bagnulo braun >> wrote: >> >> Hi, >>> >>> I agree with most of this. >>> One comment about the metric registry work. I agree that the draft need >>> more discussion and the WG is not ready for adopting it. >>> >>> But wouldnt make sense to include a milestone about this in the charter >>> even if we dont adopt a document at this stage? >>> >>> Thanks, marcelo >>> >>> >>> El 08/04/13 11:29, Brian Trammell escribi=F3: >>> >>>> Greetings, all, >>>> >>>> Given the response to the consensus call for document adoption, here's >>>> where we see consensus on the next milestones for the IPPM working gro= up: >>>> >>>> >>>> (1) draft-morton-ippm-2330-update-**01 >>>> Mon Year - Submit draft of RFC 2330bis (Framework update) >>>> to IESG as Proposed Standard >>>> >>>> Clear support for adoption, with pledges for reviews and contributions= . >>>> >>>> >>>> (2) draft-morton-ippm-2679-bis-01 >>>> Mon Year - Submit draft of RFC 2679bis (One-Way Delay update) >>>> to IESG as Proposed Standard >>>> >>>> Mixed support for adoption, with at least one pledge for review and >>>> contribution. >>>> >>>> >>>> (3) draft-morton-ippm-2680-bis-00 >>>> Mon Year - Submit draft of RFC 2680bis (One-Way Loss update) >>>> to IESG as Proposed Standard >>>> >>>> Mixed support for adoption, with at least one pledge for review and >>>> contribution. >>>> >>>> >>>> (4) draft-morton-ippm-lmap-path-01 >>>> Mon Year - Submit draft on reference path for measurement location >>>> to IESG as Proposed Standard >>>> >>>> Clear support for adoption, with pledges for reviews and contributions= , >>>> and a >>>> suggestion that the WG may consider folding this into -2330-update. >>>> >>>> >>>> (5) draft-mathis-ippm-model-based-**metrics-01 >>>> Mon Year - Submit draft on model-based TCP bulk transfer capacity >>>> metrics >>>> to IESG as Experimental >>>> >>>> Clear support for adoption (with correction of intended status to >>>> Experimental), with pledges for reviews and contributions. >>>> >>>> >>>> (6) draft-ko-ippm-streaming-**performance-00 >>>> Mon Year - Submit draft on model-based streaming performance metrics >>>> to IESG as Informational >>>> >>>> Mixed support for adoption, with correction of intended status and >>>> indication that the document needs to mature a bit. >>>> >>>> >>>> (7) draft-bi-ippm-ipsec-01 >>>> Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed >>>> Standard >>>> >>>> Clear support for adoption, with indication that the document needs >>>> some work >>>> within the WG. >>>> >>>> >>>> (8) draft-bagnulo-ippm-new-**registry-00, draft-bagnulo-ippm-new-** >>>> registry-independent-00 >>>> Mon Year - Submit draft on metrics registry to IESG as Proposed Standa= rd >>>> >>>> Mixed support for adoption, with indication that the document should b= e >>>> discussed and developed further before adoption. >>>> >>>> >>>> Given this, we propose that we adopt the following drafts as the next >>>> set of milestones: >>>> >>>> draft-morton-ippm-2330-update >>>> draft-morton-ippm-lmap-path >>>> draft-mathis-ippm-model-based-**metrics >>>> draft-bi-ippm-ipsec >>>> >>>> Given that draft-morton-ippm-2679-bis and draft-morton-ippm-2680-bis >>>> may depend on 2330-update, they should be developed in parallel with i= t, >>>> and considered for adoption as it nears completion. >>>> >>>> The remaining drafts are all clearly in scope for the new charter, so >>>> please continue developing them, with discussion on the list as necess= ary. >>>> Specifically, the new registry drafts should be unified into a single >>>> approach, and adopted following further development. >>>> >>>> After consulting with the authors, we suggest the following milestones >>>> for existing WG drafts: >>>> >>>> Jul 2013 - Submit draft on RFC 2680 standards-track advancement testin= g >>>> to IESG as Informational >>>> Dec 2013 - Submit draft on access rate measurement protocol problem >>>> statement to IESG as Informational >>>> >>>> I'd suggest the following milestones for the new drafts; authors, >>>> please respond if these are not realistic: >>>> >>>> Dec 2013 - Submit draft updating the IPPM Framework (2330-update) to >>>> IESG as Proposed Standard >>>> Dec 2013 - Submit draft on reference path for measurement location to >>>> IESG as Proposed Standard >>>> Mar 2014 - Submit draft on model-based TCP bulk transfer capacity >>>> metrics to IESG as Experimental >>>> Mar 2014 - Submit draft on OWAMP / TWAMP Security to IESG as Proposed >>>> Standard >>>> >>>> Please be prompt with any comments on this proposal; we'd like to hand >>>> the proposed charter and milestones up to our AD this week. >>>> >>>> >>>> Best regards, >>>> >>>> Brian and Bill >>>> ______________________________**_________________ >>>> 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 >>> >> >> > ______________________________**_________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/**listinfo/ippm > --bcaec5182488d8e4f204d9db6fc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The agility of updating milestones is sensitive to the cla= rity of the charter: changes that are clearly in scope don't require (s= ignificantly) wider discussion. =A0If the scope is vague, or the item a str= etch, others (WG chairs defending their turf and/or the IESG) have to be in= volved in a conversation....

A IESG approved, clear, up to date charter with placeh= olders for future projects makes milestone adjustments easy.=A0
=

Tha= nks,
--MM--
The best way to predict the future is to create it. =A0- Alan Kay=

Privacy matters! =A0We know from recent events that people are usin= g our services to speak in defiance of unjust governments. =A0 We treat pri= vacy and security as matters of life and death, because for some users, the= y are.


On Mon, Apr 8, 2013 at 7:41 AM, marcelo = bagnulo braun <marcelo@it.uc3m.es> wrote:
Hi,

I was not aware of the model, im my previous experience milestone updating = is not so agile, but if this is how plan to run the wg, i am fine with yoou= r approach and i agree we can wait.

Regards, marcelo


El 08/04/13 12:49, Brian Trammell escribi=F3:

Hi, Marcelo,

Now that we have agreed charter text which will covers all the work we want= to do now and that we think we will want to do over the next few years (th= e hard part), the intention is that we can quickly update milestones, with = much less work, coincident with document adoptions as WG items. I suspect w= e could evaluate subsequent revisions of drafts fitting the charter text an= d update the milestones as often as once per meeting cycle, if the the indi= vidual and WG drafts progress quickly enough. Given that model, I'm not= sure I see what the value is in placing a milestone on this charter withou= t a document ready to cover it.

Best regards,

Brian

On 8 Apr 2013, at 22:18, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

Hi,

I agree with most of this.
One comment about the metric registry work. I agree that the draft need mor= e discussion and the WG is not ready for adopting it.

But wouldnt make sense to include a milestone about this in the charter eve= n if we dont adopt a document at this stage?

Thanks, marcelo


El 08/04/13 11:29, Brian Trammell escribi=F3:
Greetings, all,

Given the response to the consensus call for document adoption, here's = where we see consensus on the next milestones for the IPPM working group:

(1) draft-morton-ippm-2330-update-01
Mon Year - Submit draft of RFC 2330bis (Framework update)
=A0 =A0 =A0 =A0 =A0 to IESG as Proposed Standard

Clear support for adoption, with pledges for reviews and contributions.


(2) draft-morton-ippm-2679-bis-01
Mon Year - Submit draft of RFC 2679bis (One-Way Delay update)
=A0 =A0 =A0 =A0 =A0 to IESG as Proposed Standard

Mixed support for adoption, with at least one pledge for review and contrib= ution.


(3) draft-morton-ippm-2680-bis-00
Mon Year - Submit draft of RFC 2680bis (One-Way Loss update)
=A0 =A0 =A0 =A0 =A0 to IESG as Proposed Standard

Mixed support for adoption, with at least one pledge for review and contrib= ution.


(4) draft-morton-ippm-lmap-path-01
Mon Year - Submit draft on reference path for measurement location
=A0 =A0 =A0 =A0 =A0 to IESG as Proposed Standard

Clear support for adoption, with pledges for reviews and contributions, and= a
suggestion that the WG may consider folding this into -2330-update.


(5) draft-mathis-ippm-model-based-metrics-01
Mon Year - Submit draft on model-based TCP bulk transfer capacity metrics =A0 =A0 =A0 =A0 =A0 to IESG as Experimental

Clear support for adoption (with correction of intended status to
Experimental), with pledges for reviews and contributions.


(6) draft-ko-ippm-streaming-performance-00
Mon Year - Submit draft on model-based streaming performance metrics
=A0 =A0 =A0 =A0 =A0 to IESG as Informational

Mixed support for adoption, with correction of intended status and
indication that the document needs to mature a bit.


(7) draft-bi-ippm-ipsec-01
Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Stand= ard

Clear support for adoption, with indication that the document needs some wo= rk
within the WG.


(8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new-registry-independent-00
Mon Year - Submit draft on metrics registry to IESG as Proposed Standard
Mixed support for adoption, with indication that the document should be
discussed and developed further before adoption.


Given this, we propose that we adopt the following drafts as the next set o= f milestones:

draft-morton-ippm-2330-update
draft-morton-ippm-lmap-path
draft-mathis-ippm-model-based-metrics
draft-bi-ippm-ipsec

Given that draft-morton-ippm-2679-bis and draft-morton-ippm-2680-bis may de= pend on 2330-update, they should be developed in parallel with it, and cons= idered for adoption as it nears completion.

The remaining drafts are all clearly in scope for the new charter, so pleas= e continue developing them, with discussion on the list as necessary. Speci= fically, the new registry drafts should be unified into a single approach, = and adopted following further development.

After consulting with the authors, we suggest the following milestones for = existing WG drafts:

Jul 2013 - Submit draft on RFC 2680 standards-track advancement testing to = IESG as Informational
Dec 2013 - Submit draft on access rate measurement protocol problem stateme= nt to IESG as Informational

I'd suggest the following milestones for the new drafts; authors, pleas= e respond if these are not realistic:

Dec 2013 - Submit draft updating the IPPM Framework (2330-update) to IESG a= s Proposed Standard
Dec 2013 - Submit draft on reference path for measurement location to IESG = as Proposed Standard
Mar 2014 - Submit draft on model-based TCP bulk transfer capacity metrics t= o IESG as Experimental
Mar 2014 - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Stand= ard

Please be prompt with any comments on this proposal; we'd like to hand = the proposed charter and milestones up to our AD this week.


Best regards,

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

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


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

--bcaec5182488d8e4f204d9db6fc7-- From k.pentikousis@huawei.com Mon Apr 8 15:06:56 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCD521F8A40 for ; Mon, 8 Apr 2013 15:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FI3wJGhAUbMP for ; Mon, 8 Apr 2013 15:06:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AD6F821F8F0B for ; Mon, 8 Apr 2013 15:06:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQE53953; Mon, 08 Apr 2013 22:06:45 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Apr 2013 23:06:15 +0100 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Apr 2013 23:06:43 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.5.6]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.007; Tue, 9 Apr 2013 06:06:40 +0800 From: Konstantinos Pentikousis To: Brian Trammell , "ippm@ietf.org" Thread-Topic: [ippm] Consensus on draft adoption as WG items Thread-Index: AQHONGGIR7w1+Dum9kmNIGX26p0RHZjM3uOA Date: Mon, 8 Apr 2013 22:06:39 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23F432CE4@szxeml511-mbx.china.huawei.com> References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <95B045E6-C024-4A71-81FF-7403E7EBE6CF@tik.ee.ethz.ch> <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> In-Reply-To: <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.65.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ippm] Consensus on draft adoption as WG items X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 22:06:56 -0000 Dear Brian, Bill, all, |I'd suggest the following milestones for the new drafts; authors, please |respond if these are not realistic: | |Mar 2014 - Submit draft on OWAMP / TWAMP Security to IESG as Proposed |Standard I think this is a realistic, although a tad pessimistic target. I'm ok with= it and I'd like to call for anyone who's interested in this line of work t= o email me as we will be preparing a much improved version for Berlin. Comm= ents, suggestions, nits, and text most welcome. Best regards, Kostas From trammell@tik.ee.ethz.ch Mon Apr 8 15:17:47 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068CB21F9311 for ; Mon, 8 Apr 2013 15:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb-AmNDQu2Ks for ; Mon, 8 Apr 2013 15:17:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8F821F84CC for ; Mon, 8 Apr 2013 15:17:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 14200D930C; Tue, 9 Apr 2013 00:17:42 +0200 (MEST) 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 WXXvDteVItuy; Tue, 9 Apr 2013 00:17:41 +0200 (MEST) Received: from wifi-172-23-11-84.uoa-wifi.auckland.ac.nz (wireless-nat-3.auckland.ac.nz [130.216.30.114]) (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 EB7D8D9305; Tue, 9 Apr 2013 00:17:40 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23F432CE4@szxeml511-mbx.china.huawei.com> Date: Tue, 9 Apr 2013 10:17:36 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <95B045E6-C024-4A71-81FF-7403E7EBE6CF@tik.ee.ethz.ch> <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> <8D38716F0C1A444BA0CD7E96454366C23F432CE4@szxeml511-mbx.china.huawei.com> To: Konstantinos Pentikousis X-Mailer: Apple Mail (2.1503) Cc: "ippm@ietf.org" Subject: Re: [ippm] Consensus on draft adoption as WG items X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 22:17:47 -0000 hi, Kostas, We could certainly move this up to Dec '13, if you like.=20 Cheers, Brian On 9 Apr 2013, at 10:06, Konstantinos Pentikousis = wrote: > Dear Brian, Bill, all, >=20 > |I'd suggest the following milestones for the new drafts; authors, = please > |respond if these are not realistic: > | > >=20 > |Mar 2014 - Submit draft on OWAMP / TWAMP Security to IESG as Proposed > |Standard >=20 > I think this is a realistic, although a tad pessimistic target. I'm ok = with it and I'd like to call for anyone who's interested in this line of = work to email me as we will be preparing a much improved version for = Berlin. Comments, suggestions, nits, and text most welcome. >=20 > Best regards, >=20 > Kostas From hannes.tschofenig@gmx.net Tue Apr 9 13:31:12 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AE121F9816 for ; Tue, 9 Apr 2013 13:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnHOoEXHVSwM for ; Tue, 9 Apr 2013 13:31:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 76BA521F9826 for ; Tue, 9 Apr 2013 13:31:10 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M950d-1UICYD2nlN-00CPCW for ; Tue, 09 Apr 2013 22:31:00 +0200 Received: (qmail invoked by alias); 09 Apr 2013 20:30:58 -0000 Received: from 199-119-118-18.i95.net (EHLO [10.0.1.136]) [199.119.118.18] by mail.gmx.net (mp029) with SMTP; 09 Apr 2013 22:30:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+AInh6yT2AzvnF4XJ0STqLs8oqSZfG/+nUEszW3s Mn6PxICOwigo90 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> Date: Tue, 9 Apr 2013 23:30:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Tue, 09 Apr 2013 14:35:05 -0700 Cc: "ops-ads@tools.ietf.org" , Hannes Tschofenig , Roger Marks , "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [ippm] [lmap] incoming liaison statement from IEEE Project P802.16.3 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 20:31:12 -0000 Hi Dan,=20 thanks for sending the liaison around. I read through it and I have a = few remarks.=20 It might be useful to highlight that the IETF#86 discussion was a BOF = and the purpose of the BOF is not to work out the solution but rather to = discuss whether a working group should be formed. As such, it is quite = naturual that not all design aspects have been discussed during that = meeting.=20 With regard to the questions: Question 1: "we wonder if the LMAP discussions have considered the use = of both public and private Measurement Servers Protocol work, as it is usually done in the IETF, does not imply that a = specific entity runs the server. As such, any work that comes out of a = (yet-to-be-created) LMAP working group will most likely be run by public = and privacy entities. I would in general say that there is a distinction = between the protocol aspects and the deployment aspect. Who runs a = specific service is a deployment question and not necessarily a protocol = design question.=20 "Private" in this context is a also a bit confusing because it does not = necessarily mean that private only refers to a server run by the same = entity that runs the client, particularly if the client is located on = the end device (under the control of the end user). Question 2: "=46rom our perspective, privacy is a core issue and helped = to motivate our architecture at the most basic level." Security and privacy are certainly dealt with in IETF protocols although = I have to say that the range of what an acceptable level of privacy and = security protection constitutes varies quite significantly between = different participants. Even the understanding of what privacy and = security is varies quite a lot. I am sure the IEEE in the meanwhile has = noticed that as well with their experience in WEP. There are two = documents that are worthwhile to look at to make sure that we actually = talk the same language:=20 For security have a look at RFC 3552 (see = http://tools.ietf.org/html/rfc3552) and for privacy take a look at = http://tools.ietf.org/html/draft-iab-privacy-considerations-07.=20 In Section 7 of the privacy document you can find a couple of questions = that are, of course, also applicable to the LMAP work, namely:=20 - Data Minimization - User Participation - Security - General Have a look at this document since there are not too many documents = around that give privacy guidelines for people working in a standards = developing context.=20 One of the most important parts in this work is certainly the user = participation, which typically is easier to accomplish when the = architecture allows the end user to actually give consent to the data = collection selectively and also allows the end user to revoke their = consent at any time. In general, such consent is more difficult to = provide when the functionality is provided purely network internally, = i.e., when the user does not have any new software running on their end = devices. Luckily the measurements are most meaningful when they are = truely end-to-end tests rather than testing a sub-set of the end-to-end = communication path (which had been earlier in other measurement = projects).=20 Another important point is certainly what information is collected and = provided to third parties. Anonymizing data might be a possibility but = truely anonymized data are less meaningful. A future working group will = have to certainly look at the trade-offs between the different = identifiers involved.=20 Ciao Hannes PS: I may not know enough about the IEEE but the statement "our project = is targeted directly at mobile users (independent of air interface = technology)" raised some questions for me. I believe the IEEE could best = provide their expertise when they work on radio related technology.=20 On Mar 28, 2013, at 10:17 AM, Romascanu, Dan (Dan) wrote: > Hi, >=20 > Please note the following incoming liaison statement from IEEE Project = P802.16.3 concerning the LMAP activity.=20 >=20 > https://datatracker.ietf.org/liaison/1244/ >=20 > Comments and discussions are welcome.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From k.pentikousis@huawei.com Wed Apr 10 16:30:06 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D3E21F8C04 for ; Wed, 10 Apr 2013 16:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+7syeqGToFH for ; Wed, 10 Apr 2013 16:30:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 490FC21F8B16 for ; Wed, 10 Apr 2013 16:30:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARR65661; Wed, 10 Apr 2013 23:30:03 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Apr 2013 00:29:31 +0100 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Apr 2013 07:30:02 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.5.6]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.007; Thu, 11 Apr 2013 07:29:57 +0800 From: Konstantinos Pentikousis To: Brian Trammell Thread-Topic: [ippm] Consensus on draft adoption as WG items Thread-Index: AQHONGGIR7w1+Dum9kmNIGX26p0RHZjM3uOA//9//ACAAzjb8A== Date: Wed, 10 Apr 2013 23:29:56 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23F433638@szxeml511-mbx.china.huawei.com> References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <95B045E6-C024-4A71-81FF-7403E7EBE6CF@tik.ee.ethz.ch> <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> <8D38716F0C1A444BA0CD7E96454366C23F432CE4@szxeml511-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.192.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ippm@ietf.org" Subject: Re: [ippm] Consensus on draft adoption as WG items X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 23:30:06 -0000 Hi Brian, all |We could certainly move this up to Dec '13, if you like. Unless someone else objects, it sounds good to me.=20 Best regards, Kostas From trammell@tik.ee.ethz.ch Wed Apr 10 16:50:49 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE0121F8C8C for ; Wed, 10 Apr 2013 16:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t34tnD-5Avf7 for ; Wed, 10 Apr 2013 16:50:49 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 209E421F8ADC for ; Wed, 10 Apr 2013 16:50:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 538A0D949D; Thu, 11 Apr 2013 01:50:48 +0200 (MEST) 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 D6tFruqv8bd2; Thu, 11 Apr 2013 01:50:48 +0200 (MEST) Received: from wifi-172-23-11-84.uoa-wifi.auckland.ac.nz (wireless-nat-3.auckland.ac.nz [130.216.30.114]) (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 92D43D9309; Thu, 11 Apr 2013 01:50:44 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23F433638@szxeml511-mbx.china.huawei.com> Date: Thu, 11 Apr 2013 11:50:46 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <7F48CCFD-72AC-4902-8507-40EBA396A085@tik.ee.ethz.ch> References: <41A4F582-3D65-4869-93CF-BACCADF83941@tik.ee.ethz.ch> <95B045E6-C024-4A71-81FF-7403E7EBE6CF@tik.ee.ethz.ch> <8AC71DDE-A11E-4FD5-814D-374C2FAE2171@tik.ee.ethz.ch> <8D38716F0C1A444BA0CD7E96454366C23F432CE4@szxeml511-mbx.china.huawei.com> <8D38716F0C1A444BA0CD7E96454366C23F433638@szxeml511-mbx.china.huawei.com> To: Konstantinos Pentikousis X-Mailer: Apple Mail (2.1503) Cc: "ippm@ietf.org" Subject: Re: [ippm] Consensus on draft adoption as WG items X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 23:50:49 -0000 Hi, Kostas, Sounds good; will change the milestone. Thanks, Brian On 11 Apr 2013, at 11:29, Konstantinos Pentikousis = wrote: > Hi Brian, all >=20 > |We could certainly move this up to Dec '13, if you like. >=20 > Unless someone else objects, it sounds good to me.=20 >=20 > Best regards, >=20 > Kostas From acmorton@att.com Thu Apr 11 14:49:48 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA0421F859B for ; Thu, 11 Apr 2013 14:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZXSsCPpQ4SD for ; Thu, 11 Apr 2013 14:49:47 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1C721F8585 for ; Thu, 11 Apr 2013 14:49:47 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 700B81209F8; Thu, 11 Apr 2013 17:50:05 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id 66EE1E3AE5; Thu, 11 Apr 2013 17:41:14 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Thu, 11 Apr 2013 17:49:47 -0400 From: "MORTON JR., ALFRED C (AL)" To: Samita Chakrabarti , "ippm@ietf.org" , Brian Trammell Date: Thu, 11 Apr 2013 17:49:45 -0400 Thread-Topic: ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt Thread-Index: Ac4wCYCvCzj1WZwXS6yv17y4sc0U7AG9L5CQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F1312FAF1A1E624DA0972D1C9A91379A1BFF1E2749njfpsrvexg7re_" MIME-Version: 1.0 Subject: Re: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 21:49:48 -0000 --_000_F1312FAF1A1E624DA0972D1C9A91379A1BFF1E2749njfpsrvexg7re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sumita, You make a case for testing with both symmetric and asymmetric sizes. Is that correct? Al From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Sam= ita Chakrabarti Sent: Tuesday, April 02, 2013 9:21 PM To: ippm@ietf.org; Brian Trammell Subject: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt Hello : This is regarding my comment at the IETF86 ippm meeting for the section 5 (= Test Protocol Control & Generation Requirements) section. Toward the end of the section, the document states: "The ability to control packet size on the tested path and enable asymmetrical packet size testing in a two-way architecture are REQUIRED." Request: Relax the requirement for "assymetrical" packet size so that the r= equirement document allows both symmetric and assymetric packet sizes in fo= rward and reverse direction. I was asked to provide a usecase for the request and here it is: Normally in fixed Broadband network, so far we are mostly interested with d= ata traffic download and thus we can see 80/20 (apprx) traffic distribution= in forward and reverse direction. Most often in the forward path we have a= ctual traffic packets and in upward direction it is most likely short packe= t sizes due to acknowledgements etc. However, looking forward in current and future deployment and in Mobile Bro= adband networks when we consider applications like VoLTE, peer-to-peer comm= unication, video-chat etc. we can easily expect that forward and reverse di= rection traffic rate and sizes are equivalent. Since the converged network= carries both mobile and fixed broadband traffic, it is important for many = carriers to measure the IP-network performance by using active measurement = protocol with same packet size of the traffic and in some cases with same r= ate in both directions ( i,e both symmetric and assymetric). Thus, we will need to allow both symmetric and assymetric measurement packe= t sizes and rates in forward and reverse direction. Hope this helps in understanding the requirement. Best regards, -Samita --_000_F1312FAF1A1E624DA0972D1C9A91379A1BFF1E2749njfpsrvexg7re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sumita,

You make a case for testing with both sy= mmetric and asymmetric sizes.

Is that correct?

 

Al

 

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf= Of Samita Chakrabarti
Sent: Tuesday, April 02, 2013 9:21 PM<= br>To: ippm@ietf.org; Brian Trammell
Subject: [ippm] ietf8= 6 follow-up: draft-ietf-ippm-rate-problem-02.txt

 

=  

Hello :

 

This is regar= ding my comment at the IETF86 ippm meeting for the section 5 (Tes= t Protocol Control & Generation Requirements) section.

Toward the = end of the section, the document states:

"The ability to control packet= size on the tested path and enable
asymmetrical packet size testing in = a two-way architecture are
REQUIRED."

 

Request: Relax the requi= rement for "assymetrical" packet size so that the requirement doc= ument allows both symmetric and assymetric packet sizes in forward and reve= rse direction.<= /span>

 <= /o:p>

<= p class=3DMsoNormal>I was asked to provide a usecase for the request and he= re it is:

Normally in fixed Broadband network, so far we are mostly interest= ed with data traffic download and thus we can see 80/20 (apprx) traffic dis= tribution in forward and reverse direction. Most often in the forward path = we have actual traffic packets and in upward direction it is most likely sh= ort packet sizes due to acknowledgements etc.

However, looking forward in cu= rrent and future deployment and in Mobile Broadband networks when we consid= er applications like VoLTE, peer-to-peer communication, video-chat etc. we = can easily expect that forward and reverse direction traffic rate and sizes= are equivalent.  Since the converged network carries both mobile and = fixed broadband traffic, it is important for many carriers to measure the I= P-network performance by using active measurement protocol with same packet= size of the traffic and in some cases with same rate in both directions ( = i,e both symmetric and assymetric).

Thus, we will need to allow both symmetr= ic and assymetric measurement packet sizes and rates in forward and reverse= direction.

Hope this helps in understanding the requirement.

 

Best = regards,=

-Samita=

 

 <= /span>

= --_000_F1312FAF1A1E624DA0972D1C9A91379A1BFF1E2749njfpsrvexg7re_-- From samita.chakrabarti@ericsson.com Fri Apr 12 08:38:43 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F2721F8E69 for ; Fri, 12 Apr 2013 08:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIb1O4kE+Sfn for ; Fri, 12 Apr 2013 08:38:42 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5EBA21F8E06 for ; Fri, 12 Apr 2013 08:38:28 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-6c-51682a738064 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 34.94.02430.37A28615; Fri, 12 Apr 2013 17:38:28 +0200 (CEST) Received: from EUSAAMB102.ericsson.se ([147.117.188.119]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Fri, 12 Apr 2013 11:38:27 -0400 From: Samita Chakrabarti To: "MORTON JR., ALFRED C (AL)" , "ippm@ietf.org" , Brian Trammell Thread-Topic: ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt Thread-Index: Ac4wCYCvCzj1WZwXS6yv17y4sc0U7AG9L5CQAA2gMqA= Date: Fri, 12 Apr 2013 15:38:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_ECA43DA70480A3498E43C3471FB2E1F01BEABDB1eusaamb102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPuG6JVkagwdqlwhZbj01ktOh58I7Z 4v3zThYHZo+X/XMYPZYs+cnkcezDV7YA5igum5TUnMyy1CJ9uwSujLU7LrIUXM2p+DZ7EUsD Y1t8FyMnh4SAicSKuf8ZIWwxiQv31rN1MXJxCAkcZZR4s2wHO4SznFHi9u3JTCBVbAJWEh29 e9hBbBGBeomWnsssILawgJPEjJM/mCHizhK/vz9hgbCtJO6dOgRmswioSkx5vwRsG6+Ar8SR NwugFsxklNh4o4kNJMEpECax7sEGsAZGoJO+n1oDtphZQFzi1pP5TBCnCkgs2XOeGcIWlXj5 +B8rhK0sseTJfhaI+nyJA7vmMUEsE5Q4OfMJywRGkVlIRs1CUjYLSRlEXEdiwe5PbBC2tsSy ha+ZYewzBx4zIYsvYGRfxchRWpxalptuZLCJERhVxyTYdHcw7nlpeYhRmoNFSZw3yPVCgJBA emJJanZqakFqUXxRaU5q8SFGJg5OqQbGRcllhuF5Wh3MtUfahZ9tud7c/dRv1np3nj9W2wK6 JiTI+ae3vV3se0dXq4Vr+Qqdi0u75lzMkRMU1pvS2nK28vY09jtNm2duDOwQV5RsP/f4beQF u+i8WfPNNfzu8y59vXhzYpLSWXuVF7PXej43fGn4z6Hwf67AzEDlRYZBNzd17TvX+59FiaU4 I9FQi7moOBEA1w/2mXgCAAA= Subject: Re: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:38:43 -0000 --_000_ECA43DA70480A3498E43C3471FB2E1F01BEABDB1eusaamb102erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Al, > You make a case for testing with both symmetric and asymmetric sizes. > Is that correct? Yes, that's right. I think we need to be able to measure with both symmetri= c and asymetric packet sizes in different usecase scenarios. Thanks, -Samita From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Sam= ita Chakrabarti Sent: Tuesday, April 02, 2013 9:21 PM To: ippm@ietf.org; Brian Trammell Subject: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt Hello : This is regarding my comment at the IETF86 ippm meeting for the section 5 (= Test Protocol Control & Generation Requirements) section. Toward the end of the section, the document states: "The ability to control packet size on the tested path and enable asymmetrical packet size testing in a two-way architecture are REQUIRED." Request: Relax the requirement for "assymetrical" packet size so that the r= equirement document allows both symmetric and assymetric packet sizes in fo= rward and reverse direction. I was asked to provide a usecase for the request and here it is: Normally in fixed Broadband network, so far we are mostly interested with d= ata traffic download and thus we can see 80/20 (apprx) traffic distribution= in forward and reverse direction. Most often in the forward path we have a= ctual traffic packets and in upward direction it is most likely short packe= t sizes due to acknowledgements etc. However, looking forward in current and future deployment and in Mobile Bro= adband networks when we consider applications like VoLTE, peer-to-peer comm= unication, video-chat etc. we can easily expect that forward and reverse di= rection traffic rate and sizes are equivalent. Since the converged network= carries both mobile and fixed broadband traffic, it is important for many = carriers to measure the IP-network performance by using active measurement = protocol with same packet size of the traffic and in some cases with same r= ate in both directions ( i,e both symmetric and assymetric). Thus, we will need to allow both symmetric and assymetric measurement packe= t sizes and rates in forward and reverse direction. Hope this helps in understanding the requirement. Best regards, -Samita --_000_ECA43DA70480A3498E43C3471FB2E1F01BEABDB1eusaamb102erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Al,

 

 > You make a case for testing with both = symmetric and asymmetric sizes.

 > Is that correct?

 

 

Yes, that's right. I think we need to be able to measure w= ith both symmetric and asymetric packet sizes in different usecase scenarios.

 <= /p>

Thanks,=

-Samita=  

From: ippm-bounces@ietf.org [mailto:ippm-bounces@iet= f.org] On Behalf Of Samita Chakrabarti
Sent: Tuesday, April 02, 2013 9:21 PM
To: ippm@ietf.org; Brian Trammell
Subject: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.tx= t

 

&n= bsp;

Hello :

 This is regarding my comment at the IETF86 ippm meeting for = the section 5 (Test Protocol Control & Generation Requirement= s) section.

Toward the end of the section, the document states:<= span style=3D"FONT-FAMILY: 'Arial','sans-serif'">

"The ability to control packet size on the test= ed path and enable
asymmetrical packet size testing in a two-way architecture are
REQUIRED."

 

Request: Relax the requirement for "assymetrica= l" packet size so that the requirement document allows both symmetric = and assymetric packet sizes in forward and reverse direction.

 

I was asked to provide a usecase for the request and= here it is:

Normally in fixed Broadband network, so far we are m= ostly interested with data traffic download and thus we can see 80/20 (appr= x) traffic distribution in forward and reverse direction. Most often in the= forward path we have actual traffic packets and in upward direction it is most likely short packet sizes due t= o acknowledgements etc.

However, looking forward in current and future deplo= yment and in Mobile Broadband networks when we consider applications like V= oLTE, peer-to-peer communication, video-chat etc. we can easily expect that= forward and reverse direction traffic rate and sizes are equivalent.  Since the converged network carries b= oth mobile and fixed broadband traffic, it is important for many carriers t= o measure the IP-network performance by using active measurement protocol w= ith same packet size of the traffic and in some cases with same rate in both directions ( i,e both symmetric and a= ssymetric).

Thus, we will need to allow both symmetric and assym= etric measurement packet sizes and rates in forward and reverse direction.<= span style=3D"FONT-FAMILY: 'Arial','sans-serif'">

Hope this helps in understanding the requirement.

 

Best regards,

-Samita

 

  http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-rate-problem-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Mon Apr 22 12:39:16 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B843121E80BA for ; Mon, 22 Apr 2013 12:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05t+Qm8lHQid for ; Mon, 22 Apr 2013 12:39:13 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5BA21F8FF2 for ; Mon, 22 Apr 2013 12:39:13 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 230E1120A55 for ; Mon, 22 Apr 2013 15:39:49 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id B2ECBF00F0 for ; Mon, 22 Apr 2013 15:39:12 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Mon, 22 Apr 2013 15:39:12 -0400 From: "MORTON JR., ALFRED C (AL)" To: "ippm@ietf.org" Date: Mon, 22 Apr 2013 15:39:11 -0400 Thread-Topic: New Version Notification for draft-morton-ippm-2679-bis-02.txt Thread-Index: Ac4/irhddE07fNHgQxWZfaR9T8klPwABeCBA Message-ID: References: <20130422185337.21256.61948.idtracker@ietfa.amsl.com> In-Reply-To: <20130422185337.21256.61948.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [ippm] FW: New Version Notification for draft-morton-ippm-2679-bis-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 19:39:17 -0000 VGhpcyB1cGRhdGUgZGlzY3Vzc2VzIGltcGxpY2F0aW9ucyBvZiBSRkMgNjM5MCBhbmQgUkZDIDY5 MjENCmluIHRoZSBpbnRyb2R1Y3RvcnkgImJpcyIgc2VjdGlvbi4NCg0KQWwNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgMjIs IDIwMTMgMjo1NCBQTQ0KPiBUbzogU3VuaWwgS2FsaWRpbmRpOyBNYXR0aGV3IEouWmVrYXVza2Fz OyBNT1JUT04gSlIuLCBBTEZSRUQgQyAoQUwpOyBTdW5pbA0KPiBLYWxpZGluZGk7IE1PUlRPTiBK Ui4sIEFMRlJFRCBDIChBTCk7IEd1eSBBbG1lczsgR3V5IEFsbWVzOyBNYXR0IFpla2F1c2thcw0K PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1vcnRvbi1pcHBt LTI2NzktYmlzLTAyLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1t b3J0b24taXBwbS0yNjc5LWJpcy0wMi50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBHdXkgQWxtZXMgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0K PiANCj4gRmlsZW5hbWU6CSBkcmFmdC1tb3J0b24taXBwbS0yNjc5LWJpcw0KPiBSZXZpc2lvbjoJ IDAyDQo+IFRpdGxlOgkJIEEgT25lLVdheSBEZWxheSBNZXRyaWMgZm9yIElQUE0NCj4gQ3JlYXRp b24gZGF0ZToJIDIwMTMtMDQtMjINCj4gR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ IE51bWJlciBvZiBwYWdlczogMjMNCj4gVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tb3J0b24taXBwbS0NCj4gMjY3OS1iaXMtMDIudHh0 DQo+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1tb3J0b24taXBwbS0yNjc5LQ0KPiBiaXMNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb3J0b24taXBwbS0yNjc5LWJpcy0wMg0KPiBEaWZmOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1vcnRvbi1p cHBtLTI2NzktDQo+IGJpcy0wMg0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgbWVtbyAoUkZD IDI2NzkgYmlzKSBkZWZpbmVzIGEgbWV0cmljIGZvciBvbmUtd2F5IGRlbGF5IG9mDQo+ICAgIHBh Y2tldHMgYWNyb3NzIEludGVybmV0IHBhdGhzLiAgSXQgYnVpbGRzIG9uIG5vdGlvbnMgaW50cm9k dWNlZCBhbmQNCj4gICAgZGlzY3Vzc2VkIGluIHRoZSBJUFBNIEZyYW1ld29yayBkb2N1bWVudCwg UkZDIDIzMzA7IHRoZSByZWFkZXIgaXMNCj4gICAgYXNzdW1lZCB0byBiZSBmYW1pbGlhciB3aXRo IHRoYXQgZG9jdW1lbnQuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0K From internet-drafts@ietf.org Tue Apr 23 17:22:56 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161EA21F93E3; Tue, 23 Apr 2013 17:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xgCrY+0He9X; Tue, 23 Apr 2013 17:22:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8ADF21F8A48; Tue, 23 Apr 2013 17:22:55 -0700 (PDT) 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.44.p4 Message-ID: <20130424002255.19255.21640.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2013 17:22:55 -0700 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 00:22:56 -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 Test Protocol Problem Statement Author(s) : Al Morton Filename : draft-ietf-ippm-rate-problem-03.txt Pages : 11 Date : 2013-04-23 Abstract: This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. The rate measurement scenario has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From samita.chakrabarti@ericsson.com Fri Apr 26 17:04:53 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F341E21F99EA for ; Fri, 26 Apr 2013 17:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iApB5-mw2F4f for ; Fri, 26 Apr 2013 17:04:52 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id EEE2421F99CE for ; Fri, 26 Apr 2013 17:04:51 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-24-517b162348b9 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F4.9D.02411.3261B715; Sat, 27 Apr 2013 02:04:51 +0200 (CEST) Received: from EUSAAMB102.ericsson.se ([147.117.188.119]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 20:04:50 -0400 From: Samita Chakrabarti To: "MORTON JR., ALFRED C (AL)" , "ippm@ietf.org" , Brian Trammell Thread-Topic: ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt Thread-Index: Ac4wCYCvCzj1WZwXS6yv17y4sc0U7AG9L5CQAA2gMqAC6We/EA== Date: Sat, 27 Apr 2013 00:04:49 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_ECA43DA70480A3498E43C3471FB2E1F01BEB24B7eusaamb102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyuXSPn66yWHWgwd3TihZbj01ktOh58I7Z 4v3zThYHZo+X/XMYPZYs+cnkcezDV7YA5igum5TUnMyy1CJ9uwSujC93P7IXLKmr2Hepm72B 8XleFyMnh4SAicTiCxeZIWwxiQv31rN1MXJxCAkcZZTo/riAHcJZzihx9O8eFpAqNgEriY7e PewgtohAvURLz2WwuLCAk8SMkz+YIeLOEr+/P2GBsJ0kjl/8BBZnEVCVmLvoMVicV8BX4uuH 61ALZjFKnLrxkwkkwQh0xvdTa8BsZgFxiVtP5jNBnCcgsWTPeahTRSVePv7HCmErS3yf84gF oj5fYvbmrYwQCwQlTs58wjKBUXgWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMji CxjZVzFylBanluWmGxluYgRGzzEJNscdjAs+WR5ilOZgURLnnSZVGSgkkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qBsZI5R+d3vPT2G/+bK81+We7OcJqhN1/zkhzrUfXM/pLqGo18Ps7LR059 lsjauMM+Z4XrlL/6qcE7k7yvfjrh/vpd47/j2k4X+PNKj+/Tqr/+6sMEu4xW720ufQcCNM7U pxgdebRqn+0l+T2hLvaGl7Ou8k+9cGfFS9MShhyx2fMqJznkny33VGIpzkg01GIuKk4EAPM+ /4tsAgAA Subject: Re: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 00:04:53 -0000 --_000_ECA43DA70480A3498E43C3471FB2E1F01BEB24B7eusaamb102erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Al, Does the new(03) draft clarify the following issue of symmetric and asymme= tric sizes and address my comment below? Please point to the location where it addresses the clarification. Thanks so much. -Samita ________________________________ From: Samita Chakrabarti Sent: Thursday, April 11, 2013 9:22 PM To: 'MORTON JR., ALFRED C (AL)'; ippm@ietf.org; Brian Trammell Subject: RE: ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt Hi Al, > You make a case for testing with both symmetric and asymmetric sizes. > Is that correct? Yes, that's right. I think we need to be able to measure with both symmetri= c and asymetric packet sizes in different usecase scenarios. Thanks, -Samita From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Sam= ita Chakrabarti Sent: Tuesday, April 02, 2013 9:21 PM To: ippm@ietf.org; Brian Trammell Subject: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt Hello : This is regarding my comment at the IETF86 ippm meeting for the section 5 (= Test Protocol Control & Generation Requirements) section. Toward the end of the section, the document states: "The ability to control packet size on the tested path and enable asymmetrical packet size testing in a two-way architecture are REQUIRED." Request: Relax the requirement for "assymetrical" packet size so that the r= equirement document allows both symmetric and assymetric packet sizes in fo= rward and reverse direction. I was asked to provide a usecase for the request and here it is: Normally in fixed Broadband network, so far we are mostly interested with d= ata traffic download and thus we can see 80/20 (apprx) traffic distribution= in forward and reverse direction. Most often in the forward path we have a= ctual traffic packets and in upward direction it is most likely short packe= t sizes due to acknowledgements etc. However, looking forward in current and future deployment and in Mobile Bro= adband networks when we consider applications like VoLTE, peer-to-peer comm= unication, video-chat etc. we can easily expect that forward and reverse di= rection traffic rate and sizes are equivalent. Since the converged network= carries both mobile and fixed broadband traffic, it is important for many = carriers to measure the IP-network performance by using active measurement = protocol with same packet size of the traffic and in some cases with same r= ate in both directions ( i,e both symmetric and assymetric). Thus, we will need to allow both symmetric and assymetric measurement packe= t sizes and rates in forward and reverse direction. Hope this helps in understanding the requirement. Best regards, -Samita --_000_ECA43DA70480A3498E43C3471FB2E1F01BEB24B7eusaamb102erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Al,
 
Does the new(03)  draft = ;clarify the following issue of symmetric and asymmetric sizes  and ad= dress my comment below?
Please point to the location wher= e it addresses the clarification.
 
Thanks= so much.
-Samita
From: Samita Chakrabarti
Sent: Thursday, April 11, 2013 9:22 PM
To: 'MORTON JR., ALFRED C (AL)'; ippm@ietf.org; Brian Trammell
Subject: RE: ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt
Hi Al,

 

 > You make a case for testing with both = symmetric and asymmetric sizes.

 > Is that correct?

 

 

Yes, that's right. I think we need to be able to measure w= ith both symmetric and asymetric packet sizes in different usecase scenarios.

 <= /p>

Thanks,=

-Samita=  

From: ippm-bounces@ietf.org [mailto:ippm-bounces@iet= f.org] On Behalf Of Samita Chakrabarti
Sent: Tuesday, April 02, 2013 9:21 PM
To: ippm@ietf.org; Brian Trammell
Subject: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.tx= t

 

&n= bsp;

Hello :

 This is regarding my comment at the IETF86 ippm meeting for = the section 5 (Test Protocol Control & Generation Requirement= s) section.

Toward the end of the section, the document states:<= span style=3D"FONT-FAMILY: 'Arial','sans-serif'">

"The ability to control packet size on the test= ed path and enable
asymmetrical packet size testing in a two-way architecture are
REQUIRED."

 

Request: Relax the requirement for "assymetrica= l" packet size so that the requirement document allows both symmetric = and assymetric packet sizes in forward and reverse direction.

 

I was asked to provide a usecase for the request and= here it is:

Normally in fixed Broadband network, so far we are m= ostly interested with data traffic download and thus we can see 80/20 (appr= x) traffic distribution in forward and reverse direction. Most often in the= forward path we have actual traffic packets and in upward direction it is most likely short packet sizes due t= o acknowledgements etc.

However, looking forward in current and future deplo= yment and in Mobile Broadband networks when we consider applications like V= oLTE, peer-to-peer communication, video-chat etc. we can easily expect that= forward and reverse direction traffic rate and sizes are equivalent.  Since the converged network carries b= oth mobile and fixed broadband traffic, it is important for many carriers t= o measure the IP-network performance by using active measurement protocol w= ith same packet size of the traffic and in some cases with same rate in both directions ( i,e both symmetric and a= ssymetric).

Thus, we will need to allow both symmetric and assym= etric measurement packet sizes and rates in forward and reverse direction.<= span style=3D"FONT-FAMILY: 'Arial','sans-serif'">

Hope this helps in understanding the requirement.

 

Best regards,

-Samita