From trammell@tik.ee.ethz.ch Wed Jan 2 23:58: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 2534F21F8967 for ; Wed, 2 Jan 2013 23:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SchbfRU9ib-3 for ; Wed, 2 Jan 2013 23:58:37 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9AECD21F867A for ; Wed, 2 Jan 2013 23:58:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 61040D9309; Thu, 3 Jan 2013 08:58:31 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 39YdbpQEDmF7; Thu, 3 Jan 2013 08:58:31 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 110F2D9304; Thu, 3 Jan 2013 08:58:31 +0100 (MET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=windows-1252 From: Brian Trammell X-Priority: 3 In-Reply-To: <201212250910121687691@cnnic.cn> Date: Thu, 3 Jan 2013 08:58:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8A8E8834-3BC7-40BC-9A42-E2EFC47A9CBE@tik.ee.ethz.ch> References: <20121012083122.13716.29945.idtracker@ietfa.amsl.com> <65974042-2522-4E12-8CFD-1236DF60CF74@tik.ee.ethz.ch> <7.0.1.0.0.20121013091948.04b1e628@att.com> <2BD26307-1A04-46CC-9F09-749F15ECD0E6@tik.ee.ethz.ch> <6293_1354613962_50BDC4CA_6293_1062_8_5AE9CCAA1B4A2248AB61B4C7F0AD5FB9097812@PEXCVZYM14.corporate.adroot.infra.ftgroup>, <37A59F9A-9D8A-432C-9CC6-8899981A1941@tik.ee.ethz.ch> <201212250910121687691@cnnic.cn> To: Guangqing Deng X-Mailer: Apple Mail (2.1499) Cc: "ippm@ietf.org" Subject: Re: [ippm] draft-trammell-ippm-hybrid-ps-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 07:58:38 -0000 Hi, Guangqing, While I'm not sure that direct references to passive measurement = techniques for IPPM metrics belong in _this_ draft -- which I'd intended = mainly to outline the problem and how to go about solving it -- you're = right that such techniques do need to be referenced and elaborated upon = as part of this effort. For information, there's a discussion of passive-measurement = approximations for IPPM one-way and round-trip delay, delay variation, = one-way loss, and connectivity in ETSI EG 202 765-3 (on which I was a = co-author, and which Google tells me is presently available at = http://www.etsi.org/deliver/etsi_eg/202700_202799/20276503/01.01.01_60/eg_= 20276503v010101p.pdf ) sections 4.x.5. While the definitions of the = one-way (4.1.5) and round-trip (4.2.5) delay methods (on which the = others are based) describe the errors inherent in the described passive = measurement techniques, they do not quantify them, nor do they really = formally describe the methods.=20 I would expect that part of the work outlined in -hybrid-ps would be to = more precisely define passive measurement methods for each of the set of = identified metrics (and I'd definitely use the ones in the ETSI guide: = RFCs 2678, 2679, 2680, 2681, and 3393, as a basis); these definitions = would have to take into account (and ideally quantify) the error = inherent in passive measurement due to observation point placement and = uncertainty about the measured traffic. Best regards, Brian (as author of -hybrid-ps) On Dec 25, 2012, at 2:10 AM, Guangqing Deng = wrote: > Hi, all, I=92m new to this mailing list and I have a minor issue = towards this draft, and forgive me if I missed something important. This = draft discusses the hybrid measurement (namely coordinate active = measurement and passive measurement for more accurate measurement = results). While it seems that there are no references of passive = measurement listed in this draft. Active measurement towards delay or = packet loss can be easily understood, while passive measurement is = difficult to understand, especially for new hand like me. I take a = glance at the RFCs of IPPM but find no RFCs directly regarding passive = measurement. Is it necessary to add some references of passive = measurement in this draft? > =20 > Best regards! > Guangqing Deng > CNNIC=20 > =20 > From: Brian Trammell > Date: 2012-12-04 19:04 > To: emile.stephan@orange.com > CC: Al Morton; ippm@ietf.org > Subject: Re: [ippm] draft-trammell-ippm-hybrid-ps-00.txt > Hi, Emile, > =20 > Indeed, the metrics defined in 5644 could, after a fact, be another = type of hybrid measurement, though the main idea behind hybrid-ps is the = integration of pure-passive with active measurement (see earlier = conversations on combined vs. concurrent hybrid [1]). The document in = its present form was meant exactly to elicit these kind of comments, = though. :) So while I'd not thought of it to date, absolutely, the = document should cover this case as well. > =20 > Given my background on the passive side of things, I'm not as familiar = with multicast measurements, but will have a deeper look at 5644 to see = how it fits in with the hybrid measurement problem as stated. > =20 > Thanks, best regards, > =20 > Brian (wearing a contributor hat) > =20 > [1] http://www.ietf.org/mail-archive/web/ippm/current/msg02952.html > =20 > On 4 Dec 2012, at 10:39, wrote: > =20 > > Hi Brian, > >=20 > > The WG already worked on 'hybrid metrics'. RFC6444 defines spatial = metrics based on end-to-end metrics defined in RFC2679 and RFC2680. > > This RFC covers unicast and multicast. Do you envision covering = multicast hybrid measurement too? > >=20 > > Regards > > Emile > >=20 > > -----Message d'origine----- > > De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de Brian Trammell > > Envoy=E9 : lundi 15 octobre 2012 12:17 > > =C0 : Al Morton > > Cc : ippm@ietf.org > > Objet : Re: [ippm] draft-trammell-ippm-hybrid-ps-00.txt > >=20 > > Hi, Al, all, > >=20 > > Thanks for your comments; comments inline... > >=20 > > On Oct 13, 2012, at 3:43 PM, Al Morton wrote: > >=20 > >> At 04:38 AM 10/12/2012, Brian Trammell wrote: > >>> I've just posted a very short draft on hybrid measurement, more a = meta-requirements list and motivation than anything else, as a starting = point for discussion at the Atlanta meeting. > >>=20 > >> Hi Brian, > >>=20 > >> I like the idea of specifying a framework for passive measurement = in=20 > >> the context of hybrid passive-active, because the comparisons = between=20 > >> the different techniques are quite useful. Your effort is = well-timed=20 > >> too, with both active and passive measurement requirements = appearing=20 > >> in the first draft of lmap requirements: > >> http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 > >> With this obvious synergy, I look forward to discussing this in=20 > >> Atlanta. > >=20 > > Yep... I specifically hope this work will prove useful in the = context of the LMAP effort, by granting more flexibility to combine = measurements from different sources. > >=20 > >> I noted one point to consider as you develop the specification: > >>=20 > >>> The proposed specification entails: > >>>=20 > >>> ... > >>>=20 > >>> o Definition of methods for spatial and temporal composition of > >>> active and passive metrics together allowing for estimated > >>> uncertainty. > >>=20 > >> One of IPPM's earlier projects updated and expanded RFC 2330 = section 9 > >> http://tools.ietf.org/html/rfc2330#section-9 > >> and defined three forms of metric composition and aggregation in = RFC 5835: > >> http://tools.ietf.org/html/rfc5835#section-5 > >>=20 > >> I think the definitions you seek above are what Steven and I called=20= > >> spatial and temporal aggregation. > >=20 > > Indeed; well, I think this covers half of it. In the = baseline-comparison case, temporal aggregation could be applied to the = (passive) baseline in order to improve the fidelity of the baseline = while reducing storage requirements. Then there's the comparison step I = suppose you could also model as "subtractive aggregation"; I still don't = really have a firm grasp on how these two operations work together. > >=20 > > You're right, though, in that what I really mean with this point is = aggregation as defined in IPPM, not composition; will change in the next = rev.=20 > >=20 > >> These are the two aspects that > >> we didn't complete for active measurements (IPPM has a spec for=20 > >> spatial composition of active measurements, > >> http://tools.ietf.org/html/rfc6049 , where we mentioned passive=20 > >> measurements at several appropriate points in a low-key overrun of=20= > >> IPPM's active-only charter...). > >>=20 > >> Just pointing out the past work that might help the new effort! > >=20 > > Many thanks; I'd remembered the spatial composition work (and, IIRC, = some initial work on temporal composition), but hadn't (re-) read yet to = see what applies where. > >=20 > > Best regards, > >=20 > > Brian > >=20 > >=20 > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > >=20 > > = __________________________________________________________________________= _______________________________________________ > >=20 > > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. > >=20 > > This message and its attachments may contain confidential or = privileged information that may be protected by law; > > they should not be distributed, used or copied without = authorisation. > > If you have received this email in error, please notify the sender = and delete this message and its attachments. > > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > > Thank you. > =20 > _______________________________________________ > 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 Thu Jan 3 02:22: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 0BA2A21F8A6C for ; Thu, 3 Jan 2013 02:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F08I9P2DxYIg for ; Thu, 3 Jan 2013 02:22:11 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1894B21F8A50 for ; Thu, 3 Jan 2013 02:22:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6344BD9310; Thu, 3 Jan 2013 11:22:10 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2AqmgwlIlUdj; Thu, 3 Jan 2013 11:22:00 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (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 2FD4CD930D; Thu, 3 Jan 2013 11:22:00 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=GB2312 From: Brian Trammell X-Priority: 3 In-Reply-To: <9277D4BDAB854FBB929155FB37642B09@LENOVO47E041CF> Date: Thu, 3 Jan 2013 11:21:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7688DD6D-EF70-479D-B86B-81831C78E9EA@tik.ee.ethz.ch> References: <9277D4BDAB854FBB929155FB37642B09@LENOVO47E041CF> To: Jiankang YAO X-Mailer: Apple Mail (2.1283) Cc: ippm@ietf.org Subject: Re: [ippm] My introduction and preparing for the IPPM meeting at IETF 86 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 10:22:12 -0000 Hi, Jiankang, We will be discussing a charter revision during and following the IETF = 86 meeting in Orlando in March 2013. Best regards, Brian On 26 Dec 2012, at 3:04 , Jiankang YAO wrote: > Helo Bill, > =20 > It is nice to hear your background information. > =20 > The Goals and Milestones in the charter said: > =20 > Done - Submit draft on spatial decomposition and multicast = metrics to the IESG > Nov 2010 - Final version of process draft > Nov 2010 - Implementation report based on process draft > Mar 2011 - Revise charter >=20 > =20 > do we need to update the Goals and Milestones? > =20 > thanks. > =20 > Jiankang Yao > =20 >=20 > =20 > =20 > =20 > =20 > =20 > =20 > -----Original Message----- > From: ippm-bounces at ietf.org [mailto:ippm-bounces at ietf.org] On = Behalf Of Bill Cerveny > Sent: Monday, December 17, 2012 5:57 AM > To: ippm at ietf.org > Subject: [ippm] My introduction and preparing for the IPPM meeting at = IETF 86 >=20 > Dear IPPM authors, contributors and participants, >=20 > I'm honored and excited to be named a co-chair of the IPPM working = group and to be given the opportunity to support the IPPM community in = this manner. I'd like to thank Matt and Henk for the extensive work = they've accomplished as IPPM WG chairs and I look forward to furthering = the work of IPPM. >=20 > A little background on who I am: >=20 > I am currently a principal software quality assurance engineer at = Arbor Networks. >=20 > My earliest involvement in Internet metrics began when I was asked to = research performance metrics for the Research and Development Internet = at AT&T Bell Laboratories. Shortly afterward, I accepted a position = with Advanced Network and Services, where I helped deploy reference = implementations of one-way delay and one-way packet loss, working with = Guy Almes, Matt Zekauskas and Sunil Kalidindi. After Advanced Network = and Services, I worked for Internet2, primarily in the advanced services = areas (IPv6 and IP multicast). >=20 > My recent IETF-related interests have been with the Benchmarking = Methodologies Working Group as well as various IPv6 working groups. >=20 > While most of my professional experience has been as an Internet = professional (geek), my early professional experience was as a = journalist, which I expect will be helpful as co-chair. I enjoy writing = and am comfortable reviewing documents. I look forward to the = opportunity to provide both technical and grammatical feedback on = working group documents to help further working group documents and = contributions. >=20 > This is my first experience as an IETF co-chair and I'm still learning = a bit about what co-chairing and IETF working group is all about. I look = forward to working with people I've known from the beginnings of the = IPPM working group as well as new contributors. There is a lot of new = work ahead of us and I'm genuinely looking forward to doing what I can = to promote these efforts. >=20 > Finally, reiterating what IPPM co-chair Brian Trammel has already = noted, it's not too early to begin planning for IETF 86 in Orlando. If = you'd like to discuss new individual contributions or individual = contributions with significant updates, please propose agenda items to = us via the e-mail address ippm-chairs at tools.ietf.org. >=20 > Best Regards, >=20 > Bill Cerveny > _______________________________________________ > ippm mailing list > ippm at 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 Thu Jan 3 02:40: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 F038421F8A49 for ; Thu, 3 Jan 2013 02:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWEIqX0lpA23 for ; Thu, 3 Jan 2013 02:40:34 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D93D821F8621 for ; Thu, 3 Jan 2013 02:40:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7C018D9309 for ; Thu, 3 Jan 2013 11:40:29 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eJ8CfcpCwsrR for ; Thu, 3 Jan 2013 11:40:29 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (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 42A48D9304 for ; Thu, 3 Jan 2013 11:40:29 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Jan 2013 11:40:28 +0100 Message-Id: To: "ippm@ietf.org" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [ippm] Liaison 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: Thu, 03 Jan 2013 10:40:35 -0000 Greetings, all, and happy (Gregorian) new year! We have received a liaison from the Broadband Forum that consists of a = series of questions to the IPPM WG and the experts therein. To = facilitate discussion, the test of the liaison (provided in Microsoft = Word format) is copied below; see = http://datatracker.ietf.org/liaison/1221/ for the original liaison. = Please reply to this message, answering questions inline; the chairs = will prepare a response in mid-February from results of the mailing list = discussion. Best regards, Brian This liaison is to inform you of the progress of Working Text WT-304 = Broadband Service Attributes and Performance Metrics and to request = responses from the IPPM WG to a number of questions. =20 In our meeting of 3-7 December 2012, the Broadband Forum identified a = number of performance metrics within RFCs that are of potential = interest. We also identified potential standards gaps between the = existing IP performance metrics and some current practices for large = scale performance testing of broadband Internet access services, as = exemplified by recent performance measurement trials conducted on behalf = of the FCC and OFCOM. The questions below are related to these potential = standards gaps and in general to the application of these metrics to = performance testing of broadband Internet access services as envisioned = by the WT-304 framework. =20 1. RFC 3148 addresses a framework for defining empirical bulk transfer = capacity metrics over transport protocols like TCP. However, a number of = factors may limit the applicability of the RFC with regard to broadband = Internet access performance testing. 1.a. It requires that a number of TCP behaviors (cwnd behavior; = loss recovery; segment size; retransmission timer) be specified beyond = the normal requirements applied to TCP implementations. Is RFC 3148 = therefore appropriate for performance testing of broadband Internet = access services that may use TCP implementations on a wide variety of = existing platforms? Is it possible to quantify the variation associated = with these behaviors, and are there ways to minimize or mitigate that = variation without manipulating the TCP implementations? 1.b. It does not discuss throughput limitations related to = bandwidth-delay product or techniques (such as use of multiple TCP = connections) commonly used to mitigate such issues. Are such techniques = considered compatible with use of RFC 3148, and if so can you provide = guidance on their use? 1.c. It recommends the collection of a number of ancillary = metrics in Section 3 that existing TCP implementations may or may not = support. Are these metrics commonly retrievable in implementations that = are not primarily intended as measurement tools? If they are not = available, how significantly is the value of a =93basic=94 throughput = measurement diminished? =20 2. RFC 6349 addresses a framework for TCP throughput testing designed = primarily for business class services. We note that this framework = requires steps such as determination of path MTU, bottleneck bandwidth = and RTT before actually performing throughput testing, which seems to = make it unsuitable for testing of broadband Internet access services. Is = this assessment correct? =20 3. Are there alternatives to RFC 3148 and RFC 6349 that we should = consider for throughput performance testing of broadband Internet access = services? =20 4. We are considering use of the following packet performance metrics = for evaluating performance of residential Internet access services: 4.a. Round trip packet delay per RFC 2681. Are there = recommendations for achieving end-to-end clock synchronization in a = residential Internet access environment that would enable measurement of = one-way packet delay for these services? 4.b. One way packet delay variation per RFC 3393, using the = methodology discussed in Section 5 to use data from the measurements to = correct errors due to unsynchronized clocks. We note that Section 5 is = presented as a basis for discussion and that the considerations as = listed require further investigation. Is the methodology discussed in = Section 5 sufficiently complete to be considered in the context of = WT-304 testing? 4.c. Round trip packet loss per RFC 2680. We welcome any comments you have on the packet performance metrics = listed above. =20 5. RFC 2544 addresses device benchmarking in non-production networks, = including non-TCP throughput testing that may be useful for capacity = measurement. Is there an alternative we should consider for non-TCP = capacity measurement for broadband Internet access services, i. e. = production networks? 6. There are several areas where we are not aware of a solution = documented within the IETF, but where we believe a solution would be = useful. Is there any current or proposed work in the following areas? 6.a. Measurement or estimation of performance relative to = application-specific classes of traffic, such as: 6.a.i. Real time traffic such as VoIP; and 6.a.ii. Near-real time traffic such as streaming video. 6.b. Measurement of DNS resolution time. =20 Thank you for your consideration of the above questions, and we look = forward to your response. The BBF welcomes input on this project from = the IETF, and we will continue to keep you informed of progress on the = Working Text. For information, the upcoming quarterly Broadband Forum = meetings are listed at the end of this liaison.= From Barry.Constantine@jdsu.com Thu Jan 3 07:23:51 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9666321E8047 for ; Thu, 3 Jan 2013 07:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeIJXddf-eqK for ; Thu, 3 Jan 2013 07:23:49 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECB521F8CB2 for ; Thu, 3 Jan 2013 07:23:31 -0800 (PST) Received: from mx6.jdsu.com ([209.36.247.248]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUOWiclVRr0pQEAWBK7YG4H+7RBwheaJB@postini.com; Thu, 03 Jan 2013 07:23:44 PST Received: from AMEXHTCA01.ds.jdsu.net (192.168.10.41) by mx6.jdsu.com (192.168.10.248) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 3 Jan 2013 07:20:40 -0800 Received: from AMEXMB01.ds.jdsu.net ([fe80::9402:2c4c:29f3:a264]) by AMEXHTCA01.ds.jdsu.net ([fe80::def:afde:7a37:2c3b%15]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 07:21:05 -0800 From: Barry Constantine To: Brian Trammell , "ippm@ietf.org" Thread-Topic: [ippm] Liaison from Broadband Forum Thread-Index: AQHN6Z7FlcOCVXRaakK1Cr3ZFYqhlZg3tg+Q Date: Thu, 3 Jan 2013 15:21:04 +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: [157.234.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] Liaison 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: Thu, 03 Jan 2013 15:23:51 -0000 Hi Brian and IPPM, Regarding question #2, it is unclear why they feel that RFC 6349 is unsuita= ble for broadband internet access services. Major network providers have adopted RFC 6349 for this very purpose. Also= , RFC 6349 addresses the potential need to use multiple TCP connections for= large BDP services (related to the 1b question). I would be happy to work with other IPPM members to provide a set of answer= s; would seem someone who is very familiar with RFC 3148? Thank you, Barry Constantine JDSU Communications Test Principal Member Technical Staff 301-325-7069 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Thursday, January 03, 2013 5:40 AM To: ippm@ietf.org Subject: [ippm] Liaison from Broadband Forum Greetings, all, and happy (Gregorian) new year! We have received a liaison from the Broadband Forum that consists of a seri= es of questions to the IPPM WG and the experts therein. To facilitate discu= ssion, the test of the liaison (provided in Microsoft Word format) is copie= d below; see http://datatracker.ietf.org/liaison/1221/ for the original lia= ison. Please reply to this message, answering questions inline; the chairs = will prepare a response in mid-February from results of the mailing list di= scussion. Best regards, Brian This liaison is to inform you of the progress of Working Text WT-304 Broadb= and Service Attributes and Performance Metrics and to request responses fro= m the IPPM WG to a number of questions. =20 In our meeting of 3-7 December 2012, the Broadband Forum identified a numbe= r of performance metrics within RFCs that are of potential interest. We als= o identified potential standards gaps between the existing IP performance m= etrics and some current practices for large scale performance testing of br= oadband Internet access services, as exemplified by recent performance meas= urement trials conducted on behalf of the FCC and OFCOM. The questions belo= w are related to these potential standards gaps and in general to the appli= cation of these metrics to performance testing of broadband Internet access= services as envisioned by the WT-304 framework. =20 1. RFC 3148 addresses a framework for defining empirical bulk transfer capa= city metrics over transport protocols like TCP. However, a number of factor= s may limit the applicability of the RFC with regard to broadband Internet = access performance testing. 1.a. It requires that a number of TCP behaviors (cwnd behavior; loss recov= ery; segment size; retransmission timer) be specified beyond the normal req= uirements applied to TCP implementations. Is RFC 3148 therefore appropriate= for performance testing of broadband Internet access services that may use= TCP implementations on a wide variety of existing platforms? Is it possibl= e to quantify the variation associated with these behaviors, and are there = ways to minimize or mitigate that variation without manipulating the TCP im= plementations? 1.b. It does not discuss throughput limitations related to bandwidth-delay= product or techniques (such as use of multiple TCP connections) commonly u= sed to mitigate such issues. Are such techniques considered compatible with= use of RFC 3148, and if so can you provide guidance on their use? 1.c. It recommends the collection of a number of ancillary metrics in Sect= ion 3 that existing TCP implementations may or may not support. Are these m= etrics commonly retrievable in implementations that are not primarily inten= ded as measurement tools? If they are not available, how significantly is t= he value of a "basic" throughput measurement diminished? =20 2. RFC 6349 addresses a framework for TCP throughput testing designed prima= rily for business class services. We note that this framework requires step= s such as determination of path MTU, bottleneck bandwidth and RTT before ac= tually performing throughput testing, which seems to make it unsuitable for= testing of broadband Internet access services. Is this assessment correct? =20 3. Are there alternatives to RFC 3148 and RFC 6349 that we should consider = for throughput performance testing of broadband Internet access services? =20 4. We are considering use of the following packet performance metrics for e= valuating performance of residential Internet access services: 4.a. Round trip packet delay per RFC 2681. Are there recommendations for a= chieving end-to-end clock synchronization in a residential Internet access = environment that would enable measurement of one-way packet delay for these= services? 4.b. One way packet delay variation per RFC 3393, using the methodology di= scussed in Section 5 to use data from the measurements to correct errors du= e to unsynchronized clocks. We note that Section 5 is presented as a basis = for discussion and that the considerations as listed require further invest= igation. Is the methodology discussed in Section 5 sufficiently complete to= be considered in the context of WT-304 testing? 4.c. Round trip packet loss per RFC 2680. We welcome any comments you have on the packet performance metrics listed a= bove. =20 5. RFC 2544 addresses device benchmarking in non-production networks, inclu= ding non-TCP throughput testing that may be useful for capacity measurement= . Is there an alternative we should consider for non-TCP capacity measureme= nt for broadband Internet access services, i. e. production networks? 6. There are several areas where we are not aware of a solution documented = within the IETF, but where we believe a solution would be useful. Is there = any current or proposed work in the following areas? 6.a. Measurement or estimation of performance relative to application-spec= ific classes of traffic, such as: 6.a.i. Real time traffic such as VoIP; and 6.a.ii. Near-real time traffic such as streaming video. 6.b. Measurement of DNS resolution time. =20 Thank you for your consideration of the above questions, and we look forwar= d to your response. The BBF welcomes input on this project from the IETF, a= nd we will continue to keep you informed of progress on the Working Text. F= or information, the upcoming quarterly Broadband Forum meetings are listed = at the end of this liaison. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From Internet-Drafts@ietf.org Thu Jan 3 11:48:52 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 335B521F8C97; Thu, 3 Jan 2013 11:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.427 X-Spam-Level: X-Spam-Status: No, score=-101.427 tagged_above=-999 required=5 tests=[AWL=1.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAa9GSPzwJdr; Thu, 3 Jan 2013 11:48:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C809821F8D09; Thu, 3 Jan 2013 11:48:51 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130103194851.29373.3383.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2013 11:48:51 -0800 Cc: ippm@ietf.org Subject: [ippm] I-D ACTION:draft-ietf-ippm-testplan-rfc2680-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 19:48:52 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Test Plan and Results for Advancing RFC 2680 on the Standards Track Author(s) : L. Ciavattone, et al Filename : draft-ietf-ippm-testplan-rfc2680 Pages : 27 Date : Jan. 3, 2013 This memo proposes to advance a performance metric RFC along the standards track, specifically RFC 2680 on One-way Loss Metrics. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2680. In this version, the results are presented in the R-tool output form. Beautification is future work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-testplan-rfc2680-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-testplan-rfc2680"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-01-03114851.I-D@ietf.org> --NextPart-- From a.botta@unina.it Fri Jan 4 03:23: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 2F86521F8A6B for ; Fri, 4 Jan 2013 03:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.77 X-Spam-Level: * X-Spam-Status: No, score=1.77 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, GB_AFFORDABLE=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y59F4TvYv6y for ; Fri, 4 Jan 2013 03:23:52 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1053021F8703 for ; Fri, 4 Jan 2013 03:23:51 -0800 (PST) Received: from [143.225.229.166] ([143.225.229.166]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r04BNnwq031204 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 4 Jan 2013 12:23:50 +0100 Message-ID: <50E6BB4B.2080805@unina.it> Date: Fri, 04 Jan 2013 12:21:47 +0100 From: Alessio Botta User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.10) Gecko/20121028 Icedove/10.0.10 MIME-Version: 1.0 To: ippm@ietf.org References: <4FFA94E0.7050504@unina.it> <04fb01cdb045$dce83590$96b8a0b0$@botta@unina.it> In-Reply-To: <04fb01cdb045$dce83590$96b8a0b0$@botta@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [ippm] IEEE ICC Workshop TRICANS: last day to register your paper! 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, 04 Jan 2013 11:23:53 -0000 [Our apologies if you receive multiple copies of this CFP] ------------------------------------------------------------- CALL FOR PAPER - Final announcement REGISTER YOUR PAPER TODAY!! ------------------------------------------------------------- 1st IEEE Workshop on Traffic Identification and Classification for Advanced Network Services and Scenarios (TRICANS) IEEE ICC 2013 workshop Budapest, Hungary, Week of ICC (9-13 June 2013) http://www.grid.unina.it/TRICANS2013 * Workshop Description * TRICANS workshop will provide an excellent international forum for sharing state-of-the-art advances and experiences in scientific research on Internet traffic identification and classification and their associated applications on advanced network scenarios and novel network services. TRICANS will explicitly consider traffic identification and classification as well as management issues related to very hot and challenging scenarios such as content-centric networks (CCN), Software Defined Networks (SDN), cloud computing systems and data centers, virtual networks, and the like. The ever-growing network link speeds have reached hundreds of Gbps and they are quickly approaching to Tbps in the core network. In order to support accurate network profiling of users and services, ISPs have been relying on Deep Packet Inspection (DPI), flow-based techniques, or other behavioral analysis of the Internet traffic. However, there are still a number of challenges in this field. On one hand, new networked applications come daily into play bringing massive amounts of traffic data to be processed in real-time. Such traffic volume keeps pushing industry and academia researchers to develop affordable yet efficient traffic identification and classification systems. To this end, there are demands for high-performance distributed and parallel traffic classification systems for both commodity or special-purposed hardware platforms. On the other hand, in the long-term, such solutions for traffic profiling will become part of the network management tools and techniques portfolio available for advanced network services. Also, new architectures and their supporting technologies, such as information- and content-centric networking architectures, cloud computing and network virtualization, and the like, will require network profiling services to enable robust and dynamic networking services capabilities. To address these research challenges, this workshop will focus on theory, tools, techniques, and applications of traffic identification and classification systems to enable advanced support for next-generation network architectures, services, and scenarios. The topics covered by the workshop include, but are not limited to, the following: - Measurement and modeling of Internet traffic for advanced networked services - Network and system troubleshooting through DPI technologies - Lightweight technologies for DPI in routers and middle-boxes - Network profiling of users and networked applications - Security and privacy in traffic identification and classification mechanisms - DPI technologies support for virtual networks and cloud computing management - Profiling network traffic in data center networks and cloud computing systems - Inferring and assessing Quality of Experience (QoE) of users and services - Novel visualization techniques for traffic classification and analysis - Packet processing support in operating systems for novel line-rate network services - Management of large network traffic data sets - SDN approaches for network performance monitoring - Traffic classification in SDN network elements and controllers - Traffic Classification and Identification of Cloud services - Traffic Classification and Identification for Internet Security - Classification and Identification of Botnet * Submission Guidelines * Prospective authors are encouraged to submit a full paper (5 pages) for review. Only original papers that have not been published or submitted for publication elsewhere will be considered. These submissions should follow the IEEE ICC 2013 formatting guidelines, templates for which are available at the main conference web page. The maximum paper length is of five (5) pages. Submission website: https://edas.info/N13453?c=13453 * Important Dates * - 4th of January 2013, registration of abstracts - 11th of January 2013, paper submission deadline - 22th of February 2013, notification deadline - 8th of March, camera ready - Workshop date: Week of ICC, 2013 (9-13 June 2013) * Workshop General Chairs * - Stenio Fernandes, Federal University of Pernambuco, Recife, Brazil - Antonio Pescapé, University of Napoli ''Federico II'', Napoli, Italy - Géza Szabó, Ericsson Traffic Laboratory, Budapest, Hungary -- Alessio Botta, PhD Dipartimento di Informatica e Sistemistica Università degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) [Room 3.09] Phone: +390817683865 - Fax: +390817683816 Skypeid: alessiobotta Email: a.botta@unina.it alessio.botta@consorzio-cini.it WWW: http://wpage.unina.it/a.botta From yaojk@cnnic.cn Fri Jan 4 17:33:27 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B2221F879B for ; Fri, 4 Jan 2013 17:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.246 X-Spam-Level: X-Spam-Status: No, score=-98.246 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEllinB38E4p for ; Fri, 4 Jan 2013 17:33:27 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 954A921F8694 for ; Fri, 4 Jan 2013 17:33:26 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 05 Jan 2013 09:33:21 +0800 Message-ID: <3517BAB0AF61480A950FF92A7EA0D0C7@LENOVO47E041CF> From: "Jiankang YAO" To: References: <9277D4BDAB854FBB929155FB37642B09@LENOVO47E041CF> Date: Sat, 5 Jan 2013 09:36:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [ippm] My introduction and preparing for the IPPM meeting atIETF 86 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 01:33:27 -0000 DQppZiBwb3NzaWJsZSwgSSB3b3VsZCBsaWtlIHRvIGRvIGEgc2hvcnQgcHJlc2VudGF0aW9uIGFi b3V0IHVzZXIgZXhwZXJpZW5jZWQgYWNjZXNzIHJhdGUgYW5kIHNoYXJlIG91ciB0ZXN0IGV4cGVy aWVuY2VzIGluIHRoaXMgY29taW5nIGlldGYgbWVldGluZy4NCg0KV2UgaGF2ZSBzZWxlY3RlZCB0 b3AgdGVuIGZhdm9yaXRlIHdlYnNpdGVzIGFuZCBnZXQgdGhlIGRvd25sb2FkIHJhdGUgd2l0aCBo dHRwIGFuZCBmdHAuDQpXZSBjYWxsZWQgdGhpcyBraW5kIG9mIGRvd25sb2FkIHJhdGUgYXMgdGhl IHVzZXIgZXhwZXJpZW5jZWQgYWNjZXNzIHJhdGUuDQpXZSBoYXZlIHRlc3RlZCB0aGUgdXNlciBl eHBlcmllbmNlZCBhY2Nlc3MgcmF0ZSBpbiBtYW55IGNpdGllcyBhbmQgcHJvdmluY2VzIGluIENo aW5hLg0KDQpUaGUgZmluYWwgYXZlcmFnZSB1c2VyIGV4cGVyaWVuY2VkIGFjY2VzcyByYXRlIHdp bGwgYmFzZSBvbiBhbmFseXNpcyBvZiB0aGUgZGF0YSB1c2luZyBzb21lIHN0YXRpc3RpY3MgbWV0 aG9kLiANCg0KSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMga2luZCBvZiB0ZXN0aW5nIG1ldGhv ZHMgb3Igc2NlbmFyaW9zIGZhbGwgaW4gdGhlIGNoYXJ0ZXIuDQoNClRoYW5rcy4NCg0KSmlhbmth bmcgWWFvIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXBwbS1ib3VuY2Vz IGF0IGlldGYub3JnIFttYWlsdG86aXBwbS1ib3VuY2VzIGF0IGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQmlsbCBDZXJ2ZW55DQpTZW50OiBNb25kYXksIERlY2VtYmVyIDE3LCAyMDEyIDU6NTcgQU0N ClRvOiBpcHBtIGF0IGlldGYub3JnDQpTdWJqZWN0OiBbaXBwbV0gTXkgaW50cm9kdWN0aW9uIGFu ZCBwcmVwYXJpbmcgZm9yIHRoZSBJUFBNIG1lZXRpbmcgYXQgSUVURiA4Ng0KDQouLi4uLi4NCg0K RmluYWxseSwgcmVpdGVyYXRpbmcgd2hhdCBJUFBNIGNvLWNoYWlyIEJyaWFuIFRyYW1tZWwgaGFz IGFscmVhZHkgbm90ZWQsIGl0J3Mgbm90IHRvbyBlYXJseSB0byBiZWdpbiBwbGFubmluZyBmb3Ig SUVURiA4NiBpbiBPcmxhbmRvLiBJZiB5b3UnZCBsaWtlIHRvIGRpc2N1c3MgbmV3IGluZGl2aWR1 YWwgY29udHJpYnV0aW9ucyBvciBpbmRpdmlkdWFsIGNvbnRyaWJ1dGlvbnMgd2l0aCBzaWduaWZp Y2FudCB1cGRhdGVzLCBwbGVhc2UgcHJvcG9zZSBhZ2VuZGEgaXRlbXMgdG8gdXMgdmlhIHRoZSBl LW1haWwgYWRkcmVzcyBpcHBtLWNoYWlycyBhdCB0b29scy5pZXRmLm9yZy4NCg0KQmVzdCBSZWdh cmRzLA0KDQpCaWxsIENlcnZlbnkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQppcHBtIG1haWxpbmcgbGlzdA0KaXBwbSBhdCBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppcHBtIG1haWxpbmcgbGlzdA0K aXBwbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBt From andreas.a.johnsson@ericsson.com Sun Jan 6 23:22:31 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF3D21F8168 for ; Sun, 6 Jan 2013 23:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo0AK6-wPCHe for ; Sun, 6 Jan 2013 23:22:30 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E89FC21F88FB for ; Sun, 6 Jan 2013 23:22:25 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-c4-50ea77af8172 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EE.8C.04318.FA77AE05; Mon, 7 Jan 2013 08:22:24 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.129]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Mon, 7 Jan 2013 08:22:23 +0100 From: Andreas Johnsson A To: Al Morton , dengguangqing , ippm Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-rate-problem-01.txt Thread-Index: AQHN34QgAGvyJqq1okW/PzEw6YcMrJgxaegsgAF+2ACACqdTIA== Date: Mon, 7 Jan 2013 07:22:22 +0000 Message-ID: References: <20121221140418.20749.35939.idtracker@ietfa.amsl.com> <7.0.1.0.0.20121221090459.04a18888@att.com> <201212302149186531281@cnnic.cn> <7.0.1.0.0.20121231083425.04956f38@att.com> In-Reply-To: <7.0.1.0.0.20121231083425.04956f38@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D26039A349A82849AC399E2B92A05EF61A1C6620ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6G8lcBBide8VhsPTaR0WL2n8ds Fj0P3jE7MHu87J/D6LHpmqTHkiU/mQKYo7hsUlJzMstSi/TtErgyeleHFiyJrdh97iFzA+PO oC5GTg4JAROJKW1drBC2mMSFe+vZuhi5OIQEDjFKHJ39lxnCWcwo8WLyTGaQKjYBK4n1XdvA bBGBBIkrh/+zgNjCAs4SUzbMhIq7SKzqPc4GYTtJnFmxix3EZhFQkXh0qIUJxOYV8JXYsO4w E8SCfYwSy6f1MIIkOAUsJE5ung7WwAh00vdTa8AamAXEJW49mc8EcaqAxJI955khbFGJl4// Ab3AAWQrSizvl4Moz5dYuWodO8QuQYmTM5+wTGAUmYVk0iwkZbOQlEHEdSQW7P7EBmFrSyxb +JoZxj5z4DETsvgCRvZVjOy5iZk56eXmmxiB0XRwy2+DHYyb7osdYpTmYFES5w13vRAgJJCe WJKanZpakFoUX1Sak1p8iJGJg1OqgVEvW+jwxDn5qpkXbj8LDf4b51Ps8vX3ouNFdz4KZtfV O0zmkFRbu7ho2YbgRR65B3v/TL/1ODjFiFnkjuYzxrDOnfULZhzbMs/v2W33Fw4fNr/994e/ ZF/sDJnf8b/tJHZUqHx5dmqBdeG6t+e678uoqmT/mPhROv/zmwXnJpru2JkmL183Y/UVJZbi jERDLeai4kQAeAQf4HQCAAA= Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 07:22:31 -0000 --_000_D26039A349A82849AC399E2B92A05EF61A1C6620ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would also like to point out RFC 6802 on rate measurements. Best regards, Andreas Johnsson From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al = Morton Sent: den 31 december 2012 14:40 To: dengguangqing; ippm Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-01.txt The short answer is "yes, in a way" (for both drafts), but you'll have to wait to see results in a contribution. Al At 08:49 AM 12/30/2012, dengguangqing wrote: I am interested in rate measurement, and have these two solutions (namely d= raft-morton-ippm-twamp-rate and draft-mathis-ippm-model-based-metrics) ever= been applied to practice? Guangqing Deng cnnic From: Al Morton Date: 2012-12-21 22:11 To: ippm Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-01.txt This update addresses comments from our recent session (IETF-85), as well as Bill Cerveny's review/comments (off-list, thanks Bill). There are already solutions to the problem in circulation: draft-morton-ippm-twamp-rate for protocol draft-mathis-ippm-model-based-metrics for methods of measurement regards, Al At 09:04 AM 12/21/2012, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : Rate Measurement Problem Statement Author(s) : Al Morton Filename : draft-ietf-ippm-rate-problem-01.txt Pages : 10 Date : 2012-12-21 Abstract: There is a rate measurement scenario which has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. This memo presents an access rate-measurement problem statement for IP Performance Metrics. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_D26039A349A82849AC399E2B92A05EF61A1C6620ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would al= so like to point out RFC 6802 on rate measurements.

 = ;

Best regar= ds,

Andreas Jo= hnsson

 = ;

 = ;

From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al Morton
Sent: den 31 december 2012 14:40
To: dengguangqing; ippm
Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-01.txt<= o:p>

 

The short answer is "yes, in a way" (for b= oth drafts),
but you'll have to wait to see results in a contribution.

Al

At 08:49 AM 12/30/2012, dengguangqing wrote:

I am interested in rate measurement, and have these = two solutions (namely draft-morton-ippm-twamp-rate and draft-mathis-ippm-mo= del-based-metrics) ever been applied to practice?
 

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

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

regards,
Al

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


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

         Title   &nb= sp;       : Rate Measurement Problem Statemen= t
         Author(s)   = ;    : Al Morton
         Filename   =      : draft-ietf-ippm-rate-problem-01.txt
         Pages   &nb= sp;       : 10
         Date   &nbs= p;        : 2012-12-21

Abstract:
   There is a rate measurement scenario which has wide-spread att= ention
   of Internet access subscribers and seemingly all industry play= ers,
   including regulators.  This memo presents an access rate-= measurement
   problem statement for IP Performance Metrics.  Key test p= rotocol
   aspects require the ability to control packet size on the test= ed path
   and enable asymmetrical packet size testing in a controller-re= sponder
   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-pro= blem-01

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


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

_______________________________________________
ippm mailing list
ippm@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/ippm

_______________________________= ________________
ippm mailing list
ippm@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/ippm

--_000_D26039A349A82849AC399E2B92A05EF61A1C6620ESESSMB105erics_-- From a.botta@unina.it Tue Jan 8 02:39:45 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 5EDFD21F8CF5 for ; Tue, 8 Jan 2013 02:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_AFFORDABLE=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68aRuuYlGsuy for ; Tue, 8 Jan 2013 02:39:44 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 40B3421F8CF4 for ; Tue, 8 Jan 2013 02:39:44 -0800 (PST) Received: from [192.168.1.5] ([151.73.134.241]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r08AdcBh005953 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 8 Jan 2013 11:39:39 +0100 Message-ID: <50EBF6EB.1040505@unina.it> Date: Tue, 08 Jan 2013 11:37:31 +0100 From: Alessio Botta User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.10) Gecko/20121028 Icedove/10.0.10 MIME-Version: 1.0 To: ippm@ietf.org References: <4FFA94E0.7050504@unina.it> <04fb01cdb045$dce83590$96b8a0b0$@botta@unina.it> In-Reply-To: <04fb01cdb045$dce83590$96b8a0b0$@botta@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [ippm] IEEE ICC Workshop TRICANS: deadline extension 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, 08 Jan 2013 10:39:45 -0000 [Our apologies if you receive multiple copies of this CFP] --------------------------------------------------------------- CALL FOR PAPER - The deadline has been extended to 25th January --------------------------------------------------------------- 1st IEEE Workshop on Traffic Identification and Classification for Advanced Network Services and Scenarios (TRICANS) IEEE ICC 2013 workshop Budapest, Hungary, Week of ICC (9-13 June 2013) http://www.grid.unina.it/TRICANS2013 * Workshop Description * TRICANS workshop will provide an excellent international forum for sharing state-of-the-art advances and experiences in scientific research on Internet traffic identification and classification and their associated applications on advanced network scenarios and novel network services. TRICANS will explicitly consider traffic identification and classification as well as management issues related to very hot and challenging scenarios such as content-centric networks (CCN), Software Defined Networks (SDN), cloud computing systems and data centers, virtual networks, and the like. The ever-growing network link speeds have reached hundreds of Gbps and they are quickly approaching to Tbps in the core network. In order to support accurate network profiling of users and services, ISPs have been relying on Deep Packet Inspection (DPI), flow-based techniques, or other behavioral analysis of the Internet traffic. However, there are still a number of challenges in this field. On one hand, new networked applications come daily into play bringing massive amounts of traffic data to be processed in real-time. Such traffic volume keeps pushing industry and academia researchers to develop affordable yet efficient traffic identification and classification systems. To this end, there are demands for high-performance distributed and parallel traffic classification systems for both commodity or special-purposed hardware platforms. On the other hand, in the long-term, such solutions for traffic profiling will become part of the network management tools and techniques portfolio available for advanced network services. Also, new architectures and their supporting technologies, such as information- and content-centric networking architectures, cloud computing and network virtualization, and the like, will require network profiling services to enable robust and dynamic networking services capabilities. To address these research challenges, this workshop will focus on theory, tools, techniques, and applications of traffic identification and classification systems to enable advanced support for next-generation network architectures, services, and scenarios. The topics covered by the workshop include, but are not limited to, the following: - Measurement and modeling of Internet traffic for advanced networked services - Network and system troubleshooting through DPI technologies - Lightweight technologies for DPI in routers and middle-boxes - Network profiling of users and networked applications - Security and privacy in traffic identification and classification mechanisms - DPI technologies support for virtual networks and cloud computing management - Profiling network traffic in data center networks and cloud computing systems - Inferring and assessing Quality of Experience (QoE) of users and services - Novel visualization techniques for traffic classification and analysis - Packet processing support in operating systems for novel line-rate network services - Management of large network traffic data sets - SDN approaches for network performance monitoring - Traffic classification in SDN network elements and controllers - Traffic Classification and Identification of Cloud services - Traffic Classification and Identification for Internet Security - Classification and Identification of Botnet * Submission Guidelines * Prospective authors are encouraged to submit a full paper (5 pages) for review. Only original papers that have not been published or submitted for publication elsewhere will be considered. These submissions should follow the IEEE ICC 2013 formatting guidelines, templates for which are available at the main conference web page. The maximum paper length is of five (5) pages. Submission website: https://edas.info/N13453?c=13453 * Important Dates * - 25th of January 2013 (EXTENDED), registration of abstracts - 25th of January 2013 (EXTENDED), paper submission deadline - 22th of February 2013, notification deadline - 8th of March 2013, camera ready - Workshop date: Week of ICC, 2013 (9-13 June 2013) * Workshop General Chairs * - Stenio Fernandes, Federal University of Pernambuco, Recife, Brazil - Antonio Pescapé, University of Napoli ''Federico II'', Napoli, Italy - Géza Szabó, Ericsson Traffic Laboratory, Budapest, Hungary -- Alessio Botta, PhD Dipartimento di Informatica e Sistemistica Università degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) [Room 3.09] Phone: +390817683865 - Fax: +390817683816 Skypeid: alessiobotta Email: a.botta@unina.it alessio.botta@consorzio-cini.it WWW: http://wpage.unina.it/a.botta From marcelo@it.uc3m.es Tue Jan 15 08:59: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 F23AB21F8505 for ; Tue, 15 Jan 2013 08:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.7 X-Spam-Level: X-Spam-Status: No, score=-104.7 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqeUtBItnegI for ; Tue, 15 Jan 2013 08:59:12 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 534C521F84F5 for ; Tue, 15 Jan 2013 08:59:11 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 1549AC34CC9; Tue, 15 Jan 2013 17:59:09 +0100 (CET) Received: from 71.24.218.87.dynamic.jazztel.es (71.24.218.87.dynamic.jazztel.es [87.218.24.71]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Tue, 15 Jan 2013 17:59:09 +0100 Message-ID: <20130115175909.n877uhka8sowwgg0@webcartero01.uc3m.es> Date: Tue, 15 Jan 2013 17:59:09 +0100 From: MARCELO BAGNULO BRAUN To: ippm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Tue, 15 Jan 2013 17:59:10 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19556.000 X-TM-AS-Result: No--0.928-7.0-31-1 X-imss-scan-details: No--0.928-7.0-31-1 Subject: [ippm] A couple of drafts on IPPM registries 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, 15 Jan 2013 16:59:13 -0000 Hi, We have posted a couple of drafts exploring possible structures for registries for metrics. One of the draft explores the possibility of having multiple independent registries for the different fields involved in defining a metric. Find it at: Title : A registry for commonly used metrics. Independent registries Author(s) : Marcelo Bagnulo Trevor Burbridge Sam Crawford Philip Eardley Al Morton Filename : draft-bagnulo-ippm-new-registry-independent-00.txt Pages : 17 Date : 2013-01-15 Abstract: This document creates a registry for commonly used metrics, defines the rules for assignments in the new registry and performs initial allocations. This document proposes one particular registry structure with independent registries for each of the fields involved. A companion document draft-bagnulo-ippm-new-registry explores an alternative structure with a single registry with multiple sub-registries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bagnulo-ippm-new-registry-independent There's also a htmlized version available at: http://tools.ietf.org/html/draft-bagnulo-ippm-new-registry-independent-00 The other draft explores an alternative structure with a single registry composed by multiple sub registries. The draft is: Title : A registry for commonly used metrics Author(s) : Marcelo Bagnulo Trevor Burbridge Sam Crawford Philip Eardley Al Morton Filename : draft-bagnulo-ippm-new-registry-00.txt Pages : 25 Date : 2013-01-15 Abstract: This document creates a registry for commonly used metrics, defines the rules for assignments in the new registry and performs initial allocations. This document proposes one particular registry structure with a single registry with multiple sub-registries. A companion document draft-bagnulo-ippm-new-registry-independent explores an alternative structure with independent registries for each of the fields involved. . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bagnulo-ippm-new-registry There's also a htmlized version available at: http://tools.ietf.org/html/draft-bagnulo-ippm-new-registry-00 Comments are welcome. Regards, marcelo -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From trammell@tik.ee.ethz.ch Wed Jan 23 04:31:25 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 C3FA921F89CE for ; Wed, 23 Jan 2013 04:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-T9e-tV6LAT for ; Wed, 23 Jan 2013 04:31:24 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0E921F8984 for ; Wed, 23 Jan 2013 04:31:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 07E3BD9307 for ; Wed, 23 Jan 2013 13:31:22 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CSV5038chpEz for ; Wed, 23 Jan 2013 13:31:21 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (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 B2730D9305 for ; Wed, 23 Jan 2013 13:31:21 +0100 (MET) From: Brian Trammell Content-Type: multipart/alternative; boundary="Apple-Mail=_D3CD09EA-5852-44BB-97ED-AE3B2BB6A192" Date: Wed, 23 Jan 2013 13:31:21 +0100 References: <9510D26531EF184D9017DF24659BB87F340D4BF0B5@EMV65-UKRD.domain1.systemhost.net> To: ippm@ietf.org Message-Id: <0CBBA68F-47DD-4667-AF42-3EF8E247883D@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [ippm] Fwd: [lmap] Proposed LMAP Charter X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 12:31:25 -0000 --Apple-Mail=_D3CD09EA-5852-44BB-97ED-AE3B2BB6A192 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Greetings, all, For those of you interested in LMAP (large-scale measurement control) = topics who aren't already on the lmap@ietf.org mailing list, there's a = discussion for a potential charter starting. This is of specific = interest to IPPM, as the proposal being discussed explicitly mentions = restricting the scope of metrics used in LMAP to those defined by IPPM.=20= (This will be my only cross-forwarding of this thread; please head over = to lmap@ietf.org to discuss.) Best regards, Brian Begin forwarded message: > From: > Subject: Re: [lmap] Proposed LMAP Charter > Date: 23 January 2013 10:54:39 GMT+01:00 > To: , , >=20 > Thanks Marc. We=92re very interested in discussing a potential = charter. > One thing we think is worth trying to do is to simplify the proposed = work as much as possible, as the potential scope is big. Of course this = could be done entirely as part of the WG=92s work, but doing this = beforehand would enable a more rapid start. Below is our attempt to = suggest some simplifying assumptions. > Each of the simplifying assumptions has some penalty, so it would be = great to hear whether people think they=92re reasonable, or = over-restrict the use case that you have in mind. If it=92s helpful we = could write up the architectural assumptions in an I-D =96 co-authors = very welcome. > So a key question is whether the prospective WG should start with a = phase of reaching consensus on architecture and choosing starting = protocols, or whether we can reach enough consensus before the next IETF = to move straight to standards work. I=92m not sure that we can decide = this right now, as it depends on how the discussion goes over the next = month or so. There are some work items below that might apply in the = latter case. > -- > Measuring broadband service on a large scale is important for network = diagnostics by providers and users, as well for public policy. = {Comment: operators may want measurement to help network planning and = network mgt like fault identification; not sure whether this needs = explicitly noting.} To conduct service measurements, Measurement Agents = (MAs) on user networks gather data, either on their own initiative or = instructed by a Controller, and then upload the measurement results to a = designated Collector. Currently measurement platforms contain up to a = few thousand MAs. However, the vision is that MAs could potentially be = embedded in every home hub, cable modem, enterprise edge router, set top = box, smartphone and so on. Standards will help this capability be more = pervasive, manageable and directly comparable. > RFCs from the IPPM WG define how to measure metrics =96 requests to = define new tests should be handled by IPPM. These tests effectively = define the communications between a MA and Test Server. {Comment: there = are likely new metrics that need to be defined (eg latency under load) = or tests under new conditions (eg current test for speed may not scale = well to high line speeds).} . In a few cases the IPPM definition may = need to be extended to move results data from the Test Server to the MA = for later reporting. > The LMAP WG makes the following architectural assumptions =96 in order = to make rapid progress with an acceptable loss of generality:- > =B7 We assume that Measurement Agent, tests Controller and = results Collector are all under control of same organisation (eg = Samknows, FCC, BT). Reason: Inter-organisation interactions (for example = to share results) is better handled by business-level negotiation than a = control protocol. > =B7 We assume the MA initiates a measurement. Reasons: having = the test schedule on MA avoids it having to check frequently with the = Controller; it is easier if the MA is behind a NAT; and the MA knows = whether the user is active and therefore whether to run test or delay = it. > =B7 We assume measurement results are sent from MA, and not = from test server. Reason-1: It is easier to secure the MA to Collector = communication. One implication is that for an upload test measured by = the test server, the result is reported back to the MA which reports it = in turn. Reason-2: Test servers may be controlled by a third party = (=91load time for IETF home page=92). > =B7 We assume no negotiation is needed between Controller and = MA. The Controller already knows the characteristics of the MA, for = instance via TR069 for Broadband Forum devices. The Controller simply = instructs (securely) the MA =93Measure this=94; the MA replies =93OK = /error=94. > =B7 Similarly we assume no negotiation is needed between the = MA and Collector. The protocol simply delivers (securely) the = measurement results from the MA to the Collector, and returns an ack or = error code. > =B7 We assume each MA is controlled by only one Controller. = Reason: to avoid different Controllers giving the MA conflicting = schedules. Note: a measurement platform may have several Controllers, = with each Controller controlling a subset of the MAs, for example one = controlling wireline MAs and one mobile MAs. > =B7 We assume the raw measurement results are reported; = filtering /averaging of measuremnts by the MA is not in the initial = scope, except as defined by IPPM as part of the metric definition. > =B7 We assume that uploading a new test capability to the MA = is out of scope. This can be done as a firmware upgrade for home hub, or = new app for PC, etc. > =B7 We assume as out of scope a network parameter server = (which stores nominal values such as the contractual data rate). The = functional role of the Network Paraemeter Server may be fulfilled by = existing OSS (such as network or home gateway management systems). = Interfaces to the NPS are pre-measurement (used by the Controller to = decide which tests to schedule) or post-measurement (used to analyse the = measurement data). > =B7 We assume data filtering is out of the initial scope. = Filtering includes: removal of outlier measurements, archiving = (curating) data for scientific research, and so on. There are certainly = some aspects where best practice would be useful but data filtering is = not a first priority. > =B7 We assume that data privacy issues are out of scope = although security is considered. The MA, Controller and Collector are = all under control of the same organisation. IPPM considers the = implications of any passive measurement tests that it defines. > The LMAP WG standardises the following items: > 1. The data model that defines the test schedule, which includes: > a. The IPPM metric to be tested and values for its parameters. = {Question: is the restriction to IPPM OK? Ie non-IPPM tests are out of = scope} > b. Test schedule: when the test should be done and how often = repeated (=91once an hour at xx.03=92). A test may also be a one-off, = done immediately on demand. > c. Output parameters: some IPPM metrics may define a choice of = outputs > d. Test Server: which server or servers should be used for the = test > e. Environmental conditions: such as =91no user traffic=92 which = means a particular instance of the test is delayed or abandoned. > f. (perhaps) Metadata: such as a mobile=92s location when the = test should be made, the line=92s nominal rate etc. There may be privacy = implications for the scenario where the measurement plaform is not = controlled by the operator; the initial scope will exclude this = scenario. > g. (perhaps) Metadat to report: for example, the MA may be able = to measure Layer 1 o 2 charcteristics such as DSL sync speed and = interleaving; the actual test is out of scope. As for the previous = bullet, there may be privacy implications for the general scenario, = which we exclude from the initial scope. > h. (perhaps) Priority: the Controller decides which tests are = done when. However a test might get delayed until it overlaps with = another scheduled test =96 which should be done (or done first)? Or = should it simply be abandoned? > 2. The data model that defines how an MA should report test = results. This may be combined with (1) above or specified as a separate = reporting schedule. This includes: > a. Where to report results to (one or more Collectors) > b. How often to report results for the different tests > c. What to do when Collector is not available (fail-over, try = again) > 3. The data model that defines the report, which includes: > a. The metric that was measured > b. The time of the test > c. Whether the test is scheduled, one-off triggered by the = Controller, or user-initiated > d. The measurement result =96 usually several results are batched = together; the result of a one-off test may be wanted immediately > e. (perhaps) Metadata, such as the mobile=92s location > f. Comment: it would make sense to use the same language as for = 1, for instance XML, YANG=85 > 4. The application level protocol for the (secure) delivery of = the test and reporting schedule (#1, #2) > a. A simple instruction =96 response protocol, with error codes = defined > b. LMAP could specify how it operates over one existing protocol = (REST style HTTP(s), Netconf=85) > 5. The application level protocol for the (secure) delivery of = the report (#3) > a. Same comments as for #4 > 6. A document explaining the simplifying architectural = assumptions in more detail. This document could also define some = terminology and explain the use cases. > Looking forward to the discussion, > Best wishes, > Trevor and Phil > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf = Of Marc Linsner > Sent: 18 January 2013 20:48 > To: lmap@ietf.org > Subject: [lmap] Proposed LMAP Charter > =20 > Let's discuss possible charter language for the proposed LMAP work. = At this point, IMO, we should propose a charter for the work that could = either be added to an existing WG's charter, or standalone as a WG = charter. That's an AD decision. A follow-on discussion to this would = obviously be the output documents and milestones. > =20 > Here is a strawman to start with -=20 > =20 > " > Measuring broadband service on a large scale is important for network = diagnostics by providers and users, as well for public policy. To = conduct service measurements, user networks gather data, either on their = own initiative or instructed by a measurement controller, and then = upload the measurement results to a designated measurement server. There = is a need to standardize a logical architecture and describe key = requirements for protocols to connect the components. A large-scale = measurement system needs to support residential and small-enterprise = networks, using either wired or wireless networks. The architecture = needs to consider the management of the active and passive measurements. > =20 > The LMAP work will include describing various use cases considered to = be Large Scale Performance Measurement systems, define the requirements = of the management of these systems, and finally define the management = communication architecture and protocols. > =20 > This work will also include discussions about the privacy and security = concerns and will address them within its documents. > " > =20 > Fire away! > =20 > -Marc Linsner- > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --Apple-Mail=_D3CD09EA-5852-44BB-97ED-AE3B2BB6A192 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Greetings, all,

For those of you = interested in LMAP (large-scale measurement control) topics who aren't = already on the lmap@ietf.org = mailing list, there's a discussion for a potential charter starting. = This is of specific interest to IPPM, as the proposal being discussed = explicitly mentions restricting the scope of metrics used in LMAP to = those defined by IPPM. 

(This will be my = only cross-forwarding of this thread; please head over to lmap@ietf.org to = discuss.)

Best = regards,

Brian

Begin forwarded = message:

Subject: Re: [lmap] Proposed LMAP = Charter
Date: 23 January 2013 10:54:39 = GMT+01:00

One thing we think is = worth trying to do is to simplify the proposed work as much as possible, = as the potential scope is big. Of course this could be done entirely as = part of the WG=92s work, but doing this beforehand would enable a more = rapid start. Below is our attempt to suggest some simplifying = assumptions.
Each of the simplifying assumptions  has some penalty, so = it would be great to hear whether people think they=92re reasonable, or = over-restrict the use case that you have in mind. If it=92s helpful we = could write up the architectural assumptions in an I-D =96 co-authors = very welcome.
So a key question is whether the prospective WG should start = with a phase of reaching consensus on architecture and choosing starting = protocols, or whether we can reach enough consensus before the next IETF = to move straight to standards work. I=92m not sure that we can decide = this right now, as it depends on how the discussion goes over the next = month or so. There are some work items below that might apply in the = latter case.
--
Measuring broadband service on = a large scale is important for network diagnostics by providers and = users, as well for public policy.  {Comment: operators may want = measurement to help network planning and network mgt like fault = identification; not sure whether this needs explicitly noting.}  To = conduct service measurements, Measurement Agents (MAs) on user networks = gather data, either on their own initiative or instructed by a = Controller, and then upload the measurement results to a designated = Collector. Currently measurement platforms contain up to a few thousand = MAs. However, the vision is that MAs could potentially be embedded in = every home hub, cable modem, enterprise edge router, set top box, = smartphone and so on. Standards will help this capability be more = pervasive, manageable and directly comparable.
RFCs from the IPPM WG define how to measure metrics =96 = requests to define new tests should be handled by IPPM. These tests = effectively define the communications between a MA and Test Server. = {Comment: there are likely new metrics that need to be defined (eg = latency under load) or tests under new conditions (eg current test for = speed may not scale well to high line speeds).} . In a few cases the = IPPM definition may need to be extended to move results data from the = Test Server to the MA for later reporting.
The LMAP WG makes the following architectural assumptions = =96 in order to make rapid progress with an acceptable loss of = generality:-
=B7 We = assume that Measurement Agent, tests Controller and results Collector = are all under control of same organisation (eg Samknows, FCC, BT). = Reason: Inter-organisation interactions (for example to share results) = is better handled by business-level negotiation than a control = protocol.
=B7 We = assume the MA initiates a measurement. Reasons: having the test schedule = on MA avoids it having to check frequently with the Controller; it is = easier if the MA is behind a NAT; and the MA knows whether the user is = active and therefore whether to run test or delay = it.
=B7 We = assume measurement results are sent from MA, and not from test server. = Reason-1: It is easier to secure the MA to Collector communication. One = implication is that for an upload test measured by the test server, the = result is reported back to the MA which reports it in turn. Reason-2: = Test servers may be controlled by a third party (=91load time for IETF = home page=92).
=B7 We = assume no negotiation is needed between Controller and MA. The = Controller already knows the characteristics of the MA, for instance via = TR069 for Broadband Forum devices. The Controller simply instructs = (securely) the MA =93Measure this=94; the MA replies =93OK = /error=94.
=B7 Similarl= y we assume no negotiation is needed between the MA and Collector. The = protocol simply delivers (securely) the measurement results from the MA = to the Collector, and returns an ack or error code.
=B7 We = assume each MA is controlled by only one Controller. Reason: to avoid = different Controllers giving the MA conflicting schedules. Note: a = measurement platform may have several Controllers, with each Controller = controlling a subset of the MAs, for example one controlling wireline = MAs and one mobile MAs.
=B7 We = assume the raw measurement results are reported; filtering /averaging of = measuremnts by the MA is not in the initial scope, except as defined by = IPPM as part of the metric definition.
=B7 We = assume that uploading a new test capability to the MA is out of scope. = This can be done as a firmware upgrade for home hub, or new app for PC, = etc.
=B7 We = assume as out of scope a network parameter server (which stores nominal = values such as the contractual data rate). The functional role of the = Network Paraemeter Server may be fulfilled by existing OSS (such as = network or home gateway management systems). Interfaces to the NPS are = pre-measurement (used by the Controller to decide which tests to = schedule) or post-measurement (used to analyse the measurement = data).
=B7 We = assume data filtering is out of the initial scope. Filtering includes: = removal of outlier measurements, archiving (curating) data for = scientific research, and so on. There are certainly some aspects where = best practice would be useful but data filtering is not a first = priority.
=B7 We = assume that data privacy issues are out of scope although security is = considered. The MA, Controller and Collector are all under control of = the same organisation. IPPM considers the implications of any passive = measurement tests that it defines.
The LMAP WG standardises the following = items:
1. The data = model that defines the test schedule, which = includes:
a. The IPPM = metric to be tested and values for its parameters. {Question: is the = restriction to IPPM OK? Ie non-IPPM tests are out of = scope}
b. Test = schedule: when the test should be done and how often repeated (=91once = an hour at xx.03=92). A test may also be a one-off, done immediately on = demand.
c. Output = parameters: some IPPM metrics may define a choice of = outputs
d. Test Server: = which server or servers should be used for the test
e. Environmental = conditions: such as =91no user traffic=92 which means a particular = instance of the test is delayed or abandoned.
f. (perhaps) = Metadata: such as a mobile=92s location when the test should be made, = the line=92s nominal rate etc. There may be privacy implications for the = scenario where the measurement plaform is not controlled by the = operator; the initial scope will exclude this = scenario.
g. (perhaps) = Metadat to report: for example, the MA may be able to measure Layer 1 o = 2 charcteristics such as DSL sync speed and interleaving; the actual = test is out of scope. As for the previous bullet, there may be privacy = implications for the general scenario, which we exclude from the initial = scope.
h. (perhaps) = Priority: the Controller decides which tests are done when. However a = test might get delayed until it overlaps with another scheduled test =96 = which should be done (or done first)? Or should it simply be = abandoned?
2. The data model that defines how an MA should = report test results. This may be combined with (1) above or specified as = a separate reporting schedule. This = includes:
a. Where to report results to (one or more = Collectors)
b. How often to report results for the = different tests
c. What to do when Collector is not available = (fail-over, try again)
      The data = model that defines the report, which includes:
a. The metric = that was measured
      The time of = the test
c. Whether the = test is scheduled, one-off triggered by the Controller, or = user-initiated
      The = measurement result =96 usually several results are batched together; the = result of a one-off test may be wanted immediately
e. (perhaps) = Metadata, such as the mobile=92s location
f. Comment: it = would make sense to use the same language as for 1, for instance XML, = YANG=85
4. The = application level protocol for the (secure) delivery of the test and = reporting schedule (#1, #2)
      A simple = instruction =96 response protocol, with error codes = defined
b. LMAP could = specify how it operates over one existing protocol (REST style HTTP(s), = Netconf=85)
5. The = application level protocol for the (secure) delivery of the report = (#3)
a. Same comments = as for #4
6. A document = explaining the simplifying architectural assumptions in more detail. = This document could also define some terminology and explain the use = cases.
Looking forward to the = discussion,
Best wishes,
Trevor and Phil
From: lmap-bounces@ietf.org = [mailto:lmap-bounces@ietf.org] On Behalf Of Marc = Linsner
Sent: 18 January 2013 = 20:48
To: lmap@ietf.org
Subject: [lmap] Proposed LMAP = Charter
Let's discuss possible charter language for the = proposed LMAP work.  At this point, IMO, we should propose a = charter for the work that could either be added to an existing WG's = charter, or standalone as a WG charter.  That's an AD decision. =  A follow-on discussion to this would obviously be the output = documents and milestones.
Here is a strawman to start = with - 
The = LMAP work will include describing various use cases considered to be = Large Scale Performance Measurement systems, define the requirements of = the management of these systems, and finally define the management = communication architecture and protocols.
This = work will also include discussions about the privacy and security = concerns and will address them within its documents.
"lmap@ietf.org
https://www.ietf.org/ma= ilman/listinfo/lmap

= --Apple-Mail=_D3CD09EA-5852-44BB-97ED-AE3B2BB6A192-- From christofer.flinta@ericsson.com Thu Jan 24 02:12: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 C52B821F8950 for ; Thu, 24 Jan 2013 02:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry62+qBplSFL for ; Thu, 24 Jan 2013 02:12:04 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2868421F894D for ; Thu, 24 Jan 2013 02:12:03 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-19-510108f2f357 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B0.1F.19728.2F801015; Thu, 24 Jan 2013 11:12:03 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.96]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 11:12:02 +0100 From: Christofer Flinta To: Al Morton , "ippm@ietf.org" Thread-Topic: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-02.txt Thread-Index: Ac2J3GP+HisbjpS/QXyFR1EwMZ/IMBwPLcBg Date: Thu, 24 Jan 2013 10:12:01 +0000 Message-ID: References: <201209031359.q83DxIZO004522@alpd052.aldc.att.com> In-Reply-To: <201209031359.q83DxIZO004522@alpd052.aldc.att.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvre5nDsZAg3tr+Sy2HpvIaNHz4B2z A5PHy/45jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr41XyOtWC1asXaPZdYGxgXynUxcnJICJhI PLy6mRnCFpO4cG89WxcjF4eQwCFGiVP3D7BCOIsZJe4t+csCUsUmYCFxrG8qO4gtIuAosbtn FRuILSwQLXH42QYWiHiMxNVf71khbCOJhze/g21gEVCVWLJrE5jNK+ArcXntRDBbSMBO4umz p0C9HBycAvYSvz7XgoQZBWQl7n+/BzaSWUBc4taT+UwQhwpILNlzHupoUYmXj/+xgrRKCChK LO+XgyjXkViw+xMbhK0tsWzha6itghInZz5hmcAoOgvJ1FlIWmYhaZmFpGUBI8sqRvbcxMyc 9HKjTYzASDi45bfqDsY750QOMUpzsCiJ84a7XggQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wBjdPMHHgV1jm0VBZRSP6eQbrfLGensljwUtZeIN8Ix4/ohxz0zL5+4/Ex9+nS1z6eLqG1oX pwW9/9qcJPOrOUCHS0iqS7657O+6oNr2SeGPFGOMCxyEK07t5i9xeBST5Xxllv/eLXc3Xlt5 YsWH3VuSwrXfCzby5aXMXT2npdZ9euCdtGMZC5RYijMSDbWYi4oTAbuyg1BSAgAA Subject: Re: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-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, 24 Jan 2013 10:12:05 -0000 Hi Al, IPPM group, I have some comments on draft-morton-ippm-twamp-rate-02. As I understand it, the proposed protocol enables sending bursts of test pa= ckets back-to-back in the forward or reverse direction. From the collected = time stamps in each receiving node the packet delivery rate for each burst = can be calculated, and this delivery rate may be used as an estimate of the= peak throughput for the path. However, while peak throughput is an importa= nt measure, I think a general rate measurement protocol should also enable = measuring of Available Path Capacity (APC) as defined in RFC 5136. In case = of a network with user traffic present (In-Service testing), peak throughpu= t > APC, which means that the delivery rate of a burst of back-to-back pack= ets cannot directly be used as an estimate of APC. Only if the network path= is empty of cross traffic (Out-of-Service testing) peak throughput =3D APC= , which means that delivery rate can be used as an APC estimate. In order to estimate APC in a general case (both for In-Service testing and= Out-of-Service testing) each measurement node must be able to send trains = with different rates during a session. APC can then be estimated by compari= ng the receive rates with the send rates, according to some scheme. I think= this requirement is in line with the proposed requirement of a test protoc= ol in draft-ietf-ippm-rate-problem-01: "The test protocol SHALL support tes= t packet ensemble generation (category 3) ...", where Category 3 is descri= bes as: " One or more packet ensembles in a test stream, using a fixed ense= mble size in packets and one or more fixed intra-ensemble packet spacings (= including zero spacing)." To meet this requirement, I propose two small changes to draft-morton-ippm-= twamp-rate-02: 1) Measuring APC in forward direction. The only change needed is to relax the requirement on the sending of packet= s in 5.1.1 to allow packets to be sent with any packet interval in a burst. 2) Measuring APC in reverse direction. The Session-Sender needs to inform the Session-Reflector of the desired sen= d rate for each generated burst. The simplest way to do this is to convert = the desired send rate to a desired packet interval in NTP format, valid for= all packets in the burst, and send that value in the Burst Initiation Pack= et. The Timestamp field is not used by the reflector and not reflected back= in Burst Generation mode and can therefore be reused as a new field, e.g. = called Desired Packet Interval. This packet interval should be used by the = reflector as a waiting time for each packet in the generated burst, except = for the first packet in the burst, which should be sent as quickly as possi= ble. I believe these changes may strengthen the draft. Best regards Christofer Flinta Ericsson Research -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al = Morton Sent: den 3 september 2012 15:57 To: ippm@ietf.org Subject: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-r= ate-02.txt IPPM, We've updated this draft to coordinate with the problem statement as it now= stands. Al and Len >A new version of I-D, draft-morton-ippm-twamp-rate-02.txt >has been successfully submitted and posted to the IETF repository. > >Filename: draft-morton-ippm-twamp-rate >Revision: 02 >Title: TWAMP Burst Rate Measurement Features >Creation date: 2012-09-03 >WG ID: Individual Submission >Number of pages: 19 >URL:=20 >http://www.ietf.org/internet-drafts/draft-morton-ippm-twamp-rate-02.txt >Status: http://datatracker.ietf.org/doc/draft-morton-ippm-twamp-r= ate >Htmlized: http://tools.ietf.org/html/draft-morton-ippm-twamp-rate-0= 2 >Diff:=20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-morton-ippm-twamp-rate-02 > >Abstract: > This memo describes two rate-measurement features for the core > specification of TWAMP - the Two-Way Active Measurement Protocol: an > optional capability where the reflector host responds with a > controlled burst of test-session packets (instead of a single > packet), and an optional test mode that requires the responder to > measure a burst of test packets and communicate the results in > truncated packet(s). Both features add the ability to control packet > size in the tested direction, enabling asymmetrical packet size > testing. There is an open question on using TCP transport instead of > UDP. > > >=20 > > > >The IETF Secretariat _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Thu Jan 24 15:26:41 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E87A11E8099 for ; Thu, 24 Jan 2013 15:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msxtx-cPG+Hl for ; Thu, 24 Jan 2013 15:26:40 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 94DC021F853A for ; Thu, 24 Jan 2013 15:26:34 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id A2A3112085E; Thu, 24 Jan 2013 18:27:48 -0500 (EST) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id 9F696F00C0; Thu, 24 Jan 2013 18:26:33 -0500 (EST) 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, 24 Jan 2013 18:26:33 -0500 From: "MORTON JR., ALFRED (AL)" To: Christofer Flinta , "ippm@ietf.org" Date: Thu, 24 Jan 2013 18:26:31 -0500 Thread-Topic: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-02.txt Thread-Index: Ac2J3GP+HisbjpS/QXyFR1EwMZ/IMBwPLcBgABp64oA= Message-ID: References: <201209031359.q83DxIZO004522@alpd052.aldc.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-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, 24 Jan 2013 23:26:41 -0000 Hi Christofer, I think it's worth considering the addition of inter-ensemble packet=20 spacing. It's clear that many past capacity measurement experiments have used this technique. But it's probably worth hearing from folks about their current experiments, too. For example: You mentioned that bursts can be used to estimate the peak throughput, and Available Path Capacity is also needed, and unless there is no user traffic, peak > available. I think there are cases where burst and=20 fixed rate ensembles measure the same quantity, but they have different methodological constraints (you can't send bursts greater than the=20 bottleneck buffer capacity, and while you can send very long ensembles of fixed rate packets you would be averaging the rate measurement over=20 a long time scale, too, and you may end up measuring different values because of the different time-scales).=20 Most of the Internet access rate studies conducted in the last few years have been designed to avoid times when the customers who host the measureme= nt device are not sending competing traffic. Thus the emphasis is to assess the apparent peak rate (for a typical subscriber's segment of the path), fu= rther=20 limited by any other bottlenecks with traffic from other subscribers, sort of an available capacity for the rest of the path. Strictly speaking, the rate being measured doesn't have a parallel in RFC 5136 (for this and=20 other reasons), and that may mean we have more RFCs to write. It's probably worth examining the requirements to "correctly" generate fixed rate packet ensembles, when the hardware doing the generation and/or measurement was designed for low-cost-large-scale deployment for a purpose other than measurement. Most of us are thinking "LMAP" these days. In any case, the current TWAMP draft is compliant with the rate-problem dra= ft requirement as stated, because "one or more" spacings includes zero spacing= . I hope other knowledgeable folks will chime in, too. Al > -----Original Message----- > From: Christofer Flinta [mailto:christofer.flinta@ericsson.com] > Sent: Thursday, January 24, 2013 5:12 AM > To: MORTON JR., ALFRED (AL); ippm@ietf.org > Subject: RE: [ippm] Fwd: New Version Notification for draft-morton-ippm- > twamp-rate-02.txt >=20 > Hi Al, IPPM group, >=20 > I have some comments on draft-morton-ippm-twamp-rate-02. >=20 > As I understand it, the proposed protocol enables sending bursts of test > packets back-to-back in the forward or reverse direction. From the > collected time stamps in each receiving node the packet delivery rate for > each burst can be calculated, and this delivery rate may be used as an > estimate of the peak throughput for the path. However, while peak > throughput is an important measure, I think a general rate measurement > protocol should also enable measuring of Available Path Capacity (APC) as > defined in RFC 5136. In case of a network with user traffic present (In- > Service testing), peak throughput > APC, which means that the delivery > rate of a burst of back-to-back packets cannot directly be used as an > estimate of APC. Only if the network path is empty of cross traffic (Out- > of-Service testing) peak throughput =3D APC, which means that delivery ra= te > can be used as an APC estimate. >=20 > In order to estimate APC in a general case (both for In-Service testing > and Out-of-Service testing) each measurement node must be able to send > trains with different rates during a session. APC can then be estimated b= y > comparing the receive rates with the send rates, according to some scheme= . > I think this requirement is in line with the proposed requirement of a > test protocol in draft-ietf-ippm-rate-problem-01: "The test protocol SHAL= L > support test packet ensemble generation (category 3) ...", where Categor= y > 3 is describes as: " One or more packet ensembles in a test stream, using > a fixed ensemble size in packets and one or more fixed intra-ensemble > packet spacings (including zero spacing)." >=20 > To meet this requirement, I propose two small changes to draft-morton- > ippm-twamp-rate-02: >=20 > 1) Measuring APC in forward direction. > The only change needed is to relax the requirement on the sending of > packets in 5.1.1 to allow packets to be sent with any packet interval in = a > burst. >=20 > 2) Measuring APC in reverse direction. > The Session-Sender needs to inform the Session-Reflector of the desired > send rate for each generated burst. The simplest way to do this is to > convert the desired send rate to a desired packet interval in NTP format, > valid for all packets in the burst, and send that value in the Burst > Initiation Packet. The Timestamp field is not used by the reflector and > not reflected back in Burst Generation mode and can therefore be reused a= s > a new field, e.g. called Desired Packet Interval. This packet interval > should be used by the reflector as a waiting time for each packet in the > generated burst, except for the first packet in the burst, which should b= e > sent as quickly as possible. >=20 > I believe these changes may strengthen the draft. >=20 > Best regards > Christofer Flinta > Ericsson Research >=20 >=20 > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of A= l > Morton > Sent: den 3 september 2012 15:57 > To: ippm@ietf.org > Subject: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp= - > rate-02.txt >=20 > IPPM, >=20 > We've updated this draft to coordinate with the problem statement as it > now stands. >=20 > Al and Len >=20 > >A new version of I-D, draft-morton-ippm-twamp-rate-02.txt > >has been successfully submitted and posted to the IETF repository. > > > >Filename: draft-morton-ippm-twamp-rate > >Revision: 02 > >Title: TWAMP Burst Rate Measurement Features > >Creation date: 2012-09-03 > >WG ID: Individual Submission > >Number of pages: 19 > >URL: > >http://www.ietf.org/internet-drafts/draft-morton-ippm-twamp-rate-02.txt > >Status: http://datatracker.ietf.org/doc/draft-morton-ippm-twamp= - > rate > >Htmlized: http://tools.ietf.org/html/draft-morton-ippm-twamp-rate= - > 02 > >Diff: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-morton-ippm-twamp-rate-02 > > > >Abstract: > > This memo describes two rate-measurement features for the core > > specification of TWAMP - the Two-Way Active Measurement Protocol: an > > optional capability where the reflector host responds with a > > controlled burst of test-session packets (instead of a single > > packet), and an optional test mode that requires the responder to > > measure a burst of test packets and communicate the results in > > truncated packet(s). Both features add the ability to control packe= t > > size in the tested direction, enabling asymmetrical packet size > > testing. There is an open question on using TCP transport instead o= f > > UDP. > > > > > > > > > > > > > >The IETF Secretariat >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From a.botta@unina.it Fri Jan 25 10:00:19 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E82921F8795 for ; Fri, 25 Jan 2013 10:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKOoGhdm5Y63 for ; Fri, 25 Jan 2013 10:00:18 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 593AB21F8445 for ; Fri, 25 Jan 2013 10:00:18 -0800 (PST) Received: from [143.225.229.166] ([143.225.229.166]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r0PI0Ft3023689 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 25 Jan 2013 19:00:15 +0100 Message-ID: <5102C76A.4070809@unina.it> Date: Fri, 25 Jan 2013 18:56:58 +0100 From: Alessio Botta User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.11) Gecko/20121123 Icedove/10.0.11 MIME-Version: 1.0 To: ippm@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [ippm] =?windows-1252?q?High_Performance_and_Programmable_Network?= =?windows-1252?q?ing_=28HPPN=9213=29_-_deadline_is_very_close?= 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, 25 Jan 2013 18:00:19 -0000 [Our apologies if you receive multiple copies of this CFP] --------------------------------------------------------------- CALL FOR PAPER - The deadline (4th of February) is very close!! --------------------------------------------------------------- 1st Workshop on High Performance and Programmable Networking 2013 (HPPN’13) A workshop of the ACM Symposium on High-Performance Parallel and Distributed Computing, New York City, June 17-21, 2013 http://www.grid.unina.it/HPPN2013 * Workshop Description * HPPN (High Performance and Programmable Networking) 2013 Workshop will provide an international forum for presenting and discussing the latest experiences and achievements in the field of programmable and high performance networking platforms. The main idea of the workshop is to share experiences and state-of-the-art advances related to using and researching with platforms like NetFPGA, GPUs, and other programmable hardware in the field of computer networks. Due the growing speed and complexity of networking services and infrastructures, there is an increasing interest in the networking research community to create faster and smarter network devices and operations for experimental purposes and for developing open network infrastructures. HPPN 2013 will explicitly consider analysis and implementation of high performance and programmable networking platforms related to very hot and challenging scenarios, such as content-centric networks (CCN), Software Defined Networks (SDN), cloud computing systems and data centers, virtual networks, and the like. HPPN 2013 will focus on theory, tools, techniques, and applications that enable the use of programmable hardware platforms to support for high performance next-generation network architectures, services, and scenarios. It explicitly asks for implementation and testing of novel open software platforms over programmable and high performance hardware (e.g., implementation and testing of Software Defined Radios, Software Defined Networks, Intrusion Detection Systems, etc. over high performance hardware platforms). The following topics are of the interest for the workshop (not exhaustive list): - Routing and Switching architectures - Intrusion Prevention and Detection, Firewalling - Network Packet Signature Matching and Packet Classification - Network Traffic Classification, Network Traffic Generation - Network Monitoring, Traffic measurement platforms - OpenFlow and Software Defined Network implementations - Implementation and Performance Tuning in Virtualized Networking Infrastructures - Software Defined Radio and Wireless Systems - Online and Offline Massive Network Data Analysis - Performance Comparison among High Performance architectures (FPGA vs. Multicore CPU vs. GPU vs. etc) - Energy comparison of systems and applications implemented using High Performance architectures - Energy-aware deployment of protocols, systems, and services - Implementation of Machine Learning approaches using High performance architectures - Performance Acceleration and Improvements - Performance Measurement of High Performance Networking systems - Performance Optimization in Network Operating Systems * Important Dates * Abstract submission: February 4th, 2013 (11:59PM PST) Paper submission: February 11th, 2013 (11:59PM PST) Acceptance notification: March 18th, 2013 Final papers due: April 15th, 2013 * Submission Instructions * Each submission must be a single PDF file no longer than eight (8) pages in length. Papers should be prepared in ACM SIG Proceedings format (http://www.acm.org/sigs/publications/proceedings-templates) and submitted electronically (as a PDF file). Papers must include the author name and affiliation for single-blind peer reviewing by the program committee. Authors of accepted papers are expected to present their papers at the workshop. The website for submission is: https://www.easychair.org/account/signin.cgi?conf=hppn13 * Workshop Chairs * Antonio Pescapè, University of Napoli Federico II, Italy Stenio Fernandes, Federal University of Pernambuco, Brazil *********************************** -- Alessio Botta, PhD Dipartimento di Informatica e Sistemistica Università degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) [Room 3.09] Phone: +390817683865 - Fax: +390817683816 Skypeid: alessiobotta Email: a.botta@unina.it alessio.botta@consorzio-cini.it WWW: http://wpage.unina.it/a.botta From steve.baillargeon@videotron.ca Sun Jan 27 10:32:45 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 8780B21F84C8 for ; Sun, 27 Jan 2013 10:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.242 X-Spam-Level: * X-Spam-Status: No, score=1.242 tagged_above=-999 required=5 tests=[AWL=2.088, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dr0GYFO0aqa for ; Sun, 27 Jan 2013 10:32:45 -0800 (PST) Received: from joe.nabble.com (216-139-250-139.aus.us.siteprotect.com [216.139.250.139]) by ietfa.amsl.com (Postfix) with ESMTP id 067E821F84C9 for ; Sun, 27 Jan 2013 10:32:45 -0800 (PST) Received: from tom.nabble.com ([192.168.236.105]) by joe.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TzX24-0003yM-Bf for ippm@ietf.org; Sun, 27 Jan 2013 10:32:44 -0800 Date: Sun, 27 Jan 2013 10:32:44 -0800 (PST) From: sab To: ippm@ietf.org Message-ID: <1359311564321-354625.post@n7.nabble.com> In-Reply-To: References: <201209031359.q83DxIZO004522@alpd052.aldc.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-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: Sun, 27 Jan 2013 18:32:45 -0000 Hi Al I agree with the changes proposed by Christofer. They will improve the protocol and its usability. Measuring the available path capacity may not be important to end users but it is definitively an important metric for the operators especially when it is measured 24/7. As I indicated in the Quebec meeting, the protocol should be flexible enough to accomodate any spacing between test packets in a burst in both forward and reverse directions. We should not worry about cost here. It is up to the implementer to decide the appropriate spacing and the balance between benefits and costs. I don't think we need to worry about LMAP as well. LMAP has it is own set of objectives. As far as I know, we started the rate discussion much before LMAP and the TWAMP protocol should not ignore this use case. Regards Steve Baillargeon -- View this message in context: http://ietf.10.n7.nabble.com/Fwd-New-Version-Notification-for-draft-morton-ippm-twamp-rate-02-txt-tp250601p354625.html Sent from the IETF - ippm mailing list archive at Nabble.com. From tiziano.ionta@telecomitalia.it Wed Jan 30 06:17:55 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 05D7321F8B13; Wed, 30 Jan 2013 06:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et8Pvy5O77Wc; Wed, 30 Jan 2013 06:17:51 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2796821F8B18; Wed, 30 Jan 2013 06:17:51 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 30 Jan 2013 15:17:48 +0100 Received: from GRFMBX702BA020.griffon.local ([10.188.101.11]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Wed, 30 Jan 2013 15:17:48 +0100 From: Ionta Tiziano To: "'ippm@ietf.org'" , "'ippm-bounces@ietf.org'" Importance: high X-Priority: 1 Date: Wed, 30 Jan 2013 15:17:48 +0100 Thread-Topic: [ippm] Compatibility between Cisco IPSLA and Juniper RPM Thread-Index: Ac38vLlhqkFdQCDpQlirawTkap7HFQCN4TlQ Message-ID: <885CC0380486234DBF486FA72FE9BE3BAB61430E21@GRFMBX702BA020.griffon.local> References: <201209031359.q83DxIZO004522@alpd052.aldc.att.com> <1359311564321-354625.post@n7.nabble.com> In-Reply-To: <1359311564321-354625.post@n7.nabble.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ippm] Compatibility between Cisco IPSLA and Juniper RPM 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, 30 Jan 2013 14:17:55 -0000 Hi all, I would like to know if there any compatibility between Cisco IPSLA and Jun= iper RPM. Can they interact somehow? Thanks. Tiziano Ionta -----Messaggio originale----- Da: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] Per conto di sab Inviato: domenica 27 gennaio 2013 19.33 A: ippm@ietf.org Oggetto: Re: [ippm] Fwd: New Version Notification for draft-morton-ippm-twa= mp-rate-02.txt Hi Al I agree with the changes proposed by Christofer. They will improve the protocol and its usability. Measuring the available path capacity may not be important to end users but it is definitively an important metric for the operators especially when it is measured 24/7. As I indicated in the Quebec meeting, the protocol should be flexible enoug= h to accomodate any spacing between test packets in a burst in both forward and reverse directions. We should not worry about cost here. It is up to th= e implementer to decide the appropriate spacing and the balance between benefits and costs. I don't think we need to worry about LMAP as well. LMAP has it is own set o= f objectives. As far as I know, we started the rate discussion much before LMAP and the TWAMP protocol should not ignore this use case. Regards Steve Baillargeon -- View this message in context: http://ietf.10.n7.nabble.com/Fwd-New-Version-= Notification-for-draft-morton-ippm-twamp-rate-02-txt-tp250601p354625.html Sent from the IETF - ippm mailing list archive at Nabble.com. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From a.botta@unina.it Thu Jan 31 11:11: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 81CA221F8DFA for ; Thu, 31 Jan 2013 11:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOJ+l65iW+7w for ; Thu, 31 Jan 2013 11:11:25 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2B52821F8D15 for ; Thu, 31 Jan 2013 11:11:24 -0800 (PST) Received: from [143.225.229.166] ([143.225.229.166]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r0VJBJMU013527 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2013 20:11:21 +0100 Message-ID: <510AC109.6070406@unina.it> Date: Thu, 31 Jan 2013 20:07:53 +0100 From: Alessio Botta User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.11) Gecko/20121123 Icedove/10.0.11 MIME-Version: 1.0 To: ippm@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [ippm] =?windows-1252?q?HPPN=9213_-_abstracts_due_on_Monday!?= 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, 31 Jan 2013 19:11:26 -0000 [Our apologies if you receive multiple copies of this CFP] --------------------------------------------------------------- CALL FOR PAPER - Last announcement, the deadline for abstract submission is in 4 days --------------------------------------------------------------- 1st Workshop on High Performance and Programmable Networking 2013 (HPPN’13) A workshop of the ACM Symposium on High-Performance Parallel and Distributed Computing, New York City, June 17-21, 2013 http://www.grid.unina.it/HPPN2013 * Workshop Description * HPPN (High Performance and Programmable Networking) 2013 Workshop will provide an international forum for presenting and discussing the latest experiences and achievements in the field of programmable and high performance networking platforms. The main idea of the workshop is to share experiences and state-of-the-art advances related to using and researching with platforms like NetFPGA, GPUs, and other programmable hardware in the field of computer networks. Due the growing speed and complexity of networking services and infrastructures, there is an increasing interest in the networking research community to create faster and smarter network devices and operations for experimental purposes and for developing open network infrastructures. HPPN 2013 will explicitly consider analysis and implementation of high performance and programmable networking platforms related to very hot and challenging scenarios, such as content-centric networks (CCN), Software Defined Networks (SDN), cloud computing systems and data centers, virtual networks, and the like. HPPN 2013 will focus on theory, tools, techniques, and applications that enable the use of programmable hardware platforms to support for high performance next-generation network architectures, services, and scenarios. It explicitly asks for implementation and testing of novel open software platforms over programmable and high performance hardware (e.g., implementation and testing of Software Defined Radios, Software Defined Networks, Intrusion Detection Systems, etc. over high performance hardware platforms). The following topics are of the interest for the workshop (not exhaustive list): - Routing and Switching architectures - Intrusion Prevention and Detection, Firewalling - Network Packet Signature Matching and Packet Classification - Network Traffic Classification, Network Traffic Generation - Network Monitoring, Traffic measurement platforms - OpenFlow and Software Defined Network implementations - Implementation and Performance Tuning in Virtualized Networking Infrastructures - Software Defined Radio and Wireless Systems - Online and Offline Massive Network Data Analysis - Performance Comparison among High Performance architectures (FPGA vs. Multicore CPU vs. GPU vs. etc) - Energy comparison of systems and applications implemented using High Performance architectures - Energy-aware deployment of protocols, systems, and services - Implementation of Machine Learning approaches using High performance architectures - Performance Acceleration and Improvements - Performance Measurement of High Performance Networking systems - Performance Optimization in Network Operating Systems * Important Dates * Abstract submission: February 4th, 2013 (11:59PM PST) Paper submission: February 11th, 2013 (11:59PM PST) Acceptance notification: March 18th, 2013 Final papers due: April 15th, 2013 * Submission Instructions * Each submission must be a single PDF file no longer than eight (8) pages in length. Papers should be prepared in ACM SIG Proceedings format (http://www.acm.org/sigs/publications/proceedings-templates) and submitted electronically (as a PDF file). Papers must include the author name and affiliation for single-blind peer reviewing by the program committee. Authors of accepted papers are expected to present their papers at the workshop. The website for submission is: https://www.easychair.org/account/signin.cgi?conf=hppn13 * Workshop Chairs * Antonio Pescapè, University of Napoli Federico II, Italy Stenio Fernandes, Federal University of Pernambuco, Brazil *********************************** -- Alessio Botta, PhD Dipartimento di Informatica e Sistemistica Università degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) [Room 3.09] Phone: +390817683865 - Fax: +390817683816 Skypeid: alessiobotta Email: a.botta@unina.it alessio.botta@consorzio-cini.it WWW: http://wpage.unina.it/a.botta