From acmorton@att.com Fri Feb 1 05:30:43 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424C321F8CF3 for ; Fri, 1 Feb 2013 05:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.359 X-Spam-Level: X-Spam-Status: No, score=-106.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 7akqaOaPa5Ao for ; Fri, 1 Feb 2013 05:30:42 -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 36FF721F8D33 for ; Fri, 1 Feb 2013 05:30:42 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id D0C5B1204A7 for ; Fri, 1 Feb 2013 08:32:13 -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 657DDF00F1 for ; Fri, 1 Feb 2013 08:30:41 -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; Fri, 1 Feb 2013 08:30:41 -0500 From: "MORTON JR., ALFRED (AL)" To: "ippm@ietf.org" Date: Fri, 1 Feb 2013 08:30:38 -0500 Thread-Topic: I-D Action: draft-morton-ippm-lmap-path-00.txt Thread-Index: Ac4AEnOcfQYpllI/Se2CDyE3Q3e/6gAbXKpA Message-ID: References: <20130201002344.18146.17390.idtracker@ietfa.amsl.com> In-Reply-To: <20130201002344.18146.17390.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ippm] FW: I-D Action: draft-morton-ippm-lmap-path-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:30:43 -0000 IPPM, This draft another element needed for large-scale measurement. Comments are welcome. regards, Al > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of internet-drafts@ietf.org > Sent: Thursday, January 31, 2013 7:24 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-morton-ippm-lmap-path-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : A Reference Path and Measurement Points for LMAP > Author(s) : Marcelo Bagnulo > Trevor Burbridge > Sam Crawford > Phil Eardley > Al Morton > Filename : draft-morton-ippm-lmap-path-00.txt > Pages : 10 > Date : 2013-01-31 >=20 > Abstract: > This document defines a reference path for Large-scale Measurement of > Broadband Access Performance (LMAP) and measurement points for > commonly used performance metrics. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-morton-ippm-lmap-path >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-morton-ippm-lmap-path-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From christofer.flinta@ericsson.com Fri Feb 1 06:57:06 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5547221F8442 for ; Fri, 1 Feb 2013 06:57:06 -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 vyUbuc6fY9vw for ; Fri, 1 Feb 2013 06:57:05 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6FD11E8099 for ; Fri, 1 Feb 2013 06:57:01 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-a2-510bd7bb4488 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F6.AE.32353.BB7DB015; Fri, 1 Feb 2013 15:56:59 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.96]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 15:56:59 +0100 From: Christofer Flinta To: "MORTON JR., ALFRED (AL)" , "ippm@ietf.org" Thread-Topic: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-02.txt Thread-Index: Ac2J3GP+HisbjpS/QXyFR1EwMZ/IMBwPLcBgABp64oABfxy/4A== Date: Fri, 1 Feb 2013 14:56:58 +0000 Message-ID: References: <201209031359.q83DxIZO004522@alpd052.aldc.att.com> In-Reply-To: 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+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvre7u69yBBh+PWFpsPTaR0aLnwTtm ByaPl/1zGD2WLPnJFMAUxWWTkpqTWZZapG+XwJUxYcNq5oL/MRVnfrxgbGDc6NXFyMkhIWAi ceTnXFYIW0ziwr31bCC2kMAhRonOfwldjFxA9iJGiRlLljGBJNgELCSO9U1l72Lk4BARCJH4 fdsGJCwsEC1x+NkGFhBbRCBG4uqv96wQtpPEwqbvjCA2i4CKxPWudiaQVl4BX4mHa+Ugxp9j lLgy8yHYSE6BMImN16tByhkFZCXuf78HNpJZQFzi1pP5TBBnCkgs2XOeGcIWlXj5+B8rSKuE gKLE8n45iHIdiQW7P7FB2NoSyxa+BivnFRCUODnzCcsERtFZSKbOQtIyC0nLLCQtCxhZVjGy 5yZm5qSXm29iBEbBwS2/DXYwbrovdohRmoNFSZw33PVCgJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbGTdUX1cJ/Wgko883oKf657GTR5tA89vMrmY74zSprN+iSrdbr+/bfeonc85Y225tL pY86NeWnNH9onKp7+uuS+lX86y50v1Jg8fyraHzWZMZu04ykizKN2hs3XXo6mV314ZfLhq9b 655PfT7HVORihLizYdFjwQa13j8XPoZnfdbfP2+vHttrJZbijERDLeai4kQAwKcFBFACAAA= 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: Fri, 01 Feb 2013 14:57:06 -0000 Hi Al, I get the impression that the use case for the draft is to monitor the subs= criber's capacity between the CPE and some point higher up in the operator = network in both directions. If this is the case, I think there should be a= problem statement in the introduction part of the draft, describing this u= se case. Also, since modems and home gateways have scarce resources when it= comes to CPU and memory, I think that it should be stated in the draft tha= t there are some requirements on the measurement protocol, such as it must = be simple and light weight. With a description of this use case and its ass= ociated requirements I find it more acceptable to have a protocol which onl= y sends bursts, since these are the simplest packet ensembles to send, and = we know it's a challenge to create packet spacing - especially by a low cos= t device.=20 Would it then be possible to add another use case in the draft, where the r= eflector is not a low-cost device, and thus less restricted by CPU and memo= ry? This use case could be met in the protocol by another TWAMP mode or par= ameter that enables trains with different send rates. With two modes/parame= ters a reflector device could declare its ensemble-sending capabilities in = the control protocol, e.g. a CPE modem would signal that it can only send b= ack-to-back bursts, while a more powerful network node may signal that it c= an send ensembles with different rates within an interval. I also think there should be a section in the draft around the interpretati= on of measurements using bursts. There are cases when delivery rate =3D APC= , but there are other cases when they are not the same. We made some simple= tests in the lab to illustrate the difference. Trains with 100 packets of = test traffic were sent from device A to B via two routers. The bottleneck l= ink between the routers is a 100 Mbps Ethernet link, which then offers 97 M= bps capacity at the IP layer. We defined four scenarios with different cros= s-traffic rates (0, 25, 50, 75 Mbps - iperf UDP CBR) over the bottleneck = link. Then we sent trains with different send rate for each scenario. Here = is a small table showing the results, where we define APC =3D 97 Mbps - cro= ss traffic. As we can see, the delivery rates may deviate quite a lot from = APC, depending on cross traffic and send rate: Cross traffic 0 25 50 75 APC 97 72 47 22 Delivery rate 97 77 65 55 Send rate =3D 100 Mbps Delivery rate 97 83 72 63 Send rate =3D 150 Mbps Delivery rate 97 94 93 88 Send rate =3D 1000 Mbps Looking at a possible down-link measurement scenario in an operator network= , the send rate of the test burst will probably be much larger than the lin= k capacity of the subscriber link, which means that the delivery rate will = show a value close to the subscriber link capacity almost regardless of the= subscriber traffic (see Send rate =3D 1000 Mbps). Any large deviation from= this value can then be interpreted either as congestion higher up in the a= ggregation part of the network or as reduced link capacity of the subscribe= r link, e.g. a distorted ADSL link. It's not clear how to differentiate bet= ween those interpretations. Perhaps the burst measurements must be compleme= nted with CPE detection of the link state? In an up-link scenario, the interpretation is even more unclear, since most= probably the train send-rate =3D subscriber link capacity. In this case th= e subscriber up-link traffic will highly affect the measurements (see Send = rate =3D 100 Mbps), and it will be hard to tell if a low delivery rate depe= nds on either user traffic, congestion in the aggregation part or reduced l= ink capacity. Regarding user traffic, I think it is not safe to assume that= there are times when the user traffic is zero. People may play games, use = Skype or watch Netflix late at night and file sharing applications are ofte= n active any time of the day. Should the CPE also monitor user traffic in o= rder to give more input for the measurements? Christofer -----Original Message----- From: MORTON JR., ALFRED (AL) [mailto:acmorton@att.com]=20 Sent: den 25 januari 2013 00:27 To: Christofer Flinta; ippm@ietf.org Subject: RE: [ippm] Fwd: New Version Notification for draft-morton-ippm-twa= mp-rate-02.txt Hi Christofer, I think it's worth considering the addition of inter-ensemble packet spacin= g. It's clear that many past capacity measurement experiments have used thi= s 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 fixed rate ense= mbles measure the same quantity, but they have different methodological con= straints (you can't send bursts greater than the bottleneck buffer capacity= , and while you can send very long ensembles of fixed rate packets you woul= d be averaging the rate measurement over a long time scale, too, and you ma= y 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 ha= ve been designed to avoid times when the customers who host the measurement= device are not sending competing traffic. Thus the emphasis is to assess t= he apparent peak rate (for a typical subscriber's segment of the path), fur= ther 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 o= ther reasons), and that may mean we have more RFCs to write. It's probably worth examining the requirements to "correctly" generate fixe= d rate packet ensembles, when the hardware doing the generation and/or meas= urement was designed for low-cost-large-scale deployment for a purpose othe= r 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 spac= ing. 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=20 > 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=20 > test packets back-to-back in the forward or reverse direction. From=20 > the collected time stamps in each receiving node the packet delivery=20 > rate for each burst can be calculated, and this delivery rate may be=20 > used as an estimate of the peak throughput for the path. However,=20 > while peak throughput is an important measure, I think a general rate=20 > measurement protocol should also enable measuring of Available Path=20 > Capacity (APC) as defined in RFC 5136. In case of a network with user=20 > traffic present (In- Service testing), peak throughput > APC, which=20 > means that the delivery rate of a burst of back-to-back packets cannot=20 > directly be used as an estimate of APC. Only if the network path is=20 > empty of cross traffic (Out- of-Service testing) peak throughput =3D=20 > APC, which means that delivery rate can be used as an APC estimate. >=20 > In order to estimate APC in a general case (both for In-Service=20 > testing and Out-of-Service testing) each measurement node must be able=20 > to send trains with different rates during a session. APC can then be=20 > estimated by comparing the receive rates with the send rates, according t= o some scheme. > I think this requirement is in line with the proposed requirement of a=20 > test protocol in draft-ietf-ippm-rate-problem-01: "The test protocol=20 > SHALL support test packet ensemble generation (category 3) ...", where =20 > Category > 3 is describes as: " One or more packet ensembles in a test stream,=20 > using a fixed ensemble size in packets and one or more fixed=20 > 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=20 > packets in 5.1.1 to allow packets to be sent with any packet interval=20 > in a burst. >=20 > 2) Measuring APC in reverse direction. > The Session-Sender needs to inform the Session-Reflector of the=20 > desired send rate for each generated burst. The simplest way to do=20 > this is to convert the desired send rate to a desired packet interval=20 > in NTP format, valid for all packets in the burst, and send that value=20 > in the Burst Initiation Packet. The Timestamp field is not used by the=20 > reflector and not reflected back in Burst Generation mode and can=20 > therefore be reused as a new field, e.g. called Desired Packet=20 > Interval. This packet interval should be used by the reflector as a=20 > waiting time for each packet in the generated burst, except for the=20 > first packet in the burst, which should be 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=20 > Of Al Morton > Sent: den 3 september 2012 15:57 > To: ippm@ietf.org > Subject: [ippm] Fwd: New Version Notification for=20 > draft-morton-ippm-twamp- rate-02.txt >=20 > IPPM, >=20 > We've updated this draft to coordinate with the problem statement as=20 > 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 steve.baillargeon@ericsson.com Fri Feb 1 08:04: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 A540721E805D for ; Fri, 1 Feb 2013 08:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEZ0ny9o6HVL for ; Fri, 1 Feb 2013 08:04:24 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED3721E804C for ; Fri, 1 Feb 2013 08:04:24 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-89-510be7870af7 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 47.94.03705.787EB015; Fri, 1 Feb 2013 17:04:23 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 11:04:16 -0500 From: Steve Baillargeon To: "MORTON JR., ALFRED (AL)" , "ippm@ietf.org" Thread-Topic: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-02.txt Thread-Index: Ac2J3GP+HisbjpS/QXyFR1EwMZ/IMBwPLcBgABp64oABfxy/4AAFODyQ Date: Fri, 1 Feb 2013 16:04:14 +0000 Message-ID: References: <201209031359.q83DxIZO004522@alpd052.aldc.att.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyuXRPgm77c+5Ag4+/DS22HpvIaNHz4B2z A5PHy/45jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4eOIqe0FDUsX0ha2MDYxn/boYOTkkBEwk fk9YzwRhi0lcuLeerYuRi0NI4AijRFPzDUYIZxmQ07IfrIpNwEJi/dxlzF2MHBwiAiESv2/b gISZBcwk/p//zwpiCwtESxx+toEFxBYRiJG4+us9K4TtJnHi6CE2EJtFQEXia9MBdpAxvAK+ Ej+nq0OsmsQk8XrWLLDxnAJ+Eju+VoKUMwrISuw+e50JYpW4xK0n86FuFpBYsuc8M4QtKvHy 8T9WCFtZYsmT/SwQ9ToSC3Z/YoOwtSWWLXwNVs8rIChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoW MLKsYuQoLU4ty003MtzECIyRYxJsjjsYF3yyPMQozcGiJM4b6nohQEggPbEkNTs1tSC1KL6o NCe1+BAjEwenVANjYfTX9mNbzBwY2/1Z6tVm57n2zHsp9X9ry8x9djw/JGoPpnG7PGJuE5vj 529kvuNhyZa1dx8I+HE7xcRMb29uXnJk3/upW2P/CbS6LlhoI+Mb/1m4W1XG9b3dnUmdPj1K 7PvZj7Ekhj5g/nLHrCCXd9OXWEaZq0vjr0+9FFuTkb1PInRT5yYlluKMREMt5qLiRAB64rIq XwIAAA== 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: Fri, 01 Feb 2013 16:04:25 -0000 Hi Al I suggest to add Christofer Flinta as a co-author of the draft-morton-ippm-= twamp-rate.=20 I believe his inputs are relevant and he can help out jump start those chan= ges on the draft. What do you think? -Steve -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Chr= istofer Flinta Sent: February-01-13 9:57 AM To: MORTON JR., ALFRED (AL); ippm@ietf.org Subject: Re: [ippm] Fwd: New Version Notification for draft-morton-ippm-twa= mp-rate-02.txt Hi Al, I get the impression that the use case for the draft is to monitor the subs= criber's capacity between the CPE and some point higher up in the operator = network in both directions. If this is the case, I think there should be a= problem statement in the introduction part of the draft, describing this u= se case. Also, since modems and home gateways have scarce resources when it= comes to CPU and memory, I think that it should be stated in the draft tha= t there are some requirements on the measurement protocol, such as it must = be simple and light weight. With a description of this use case and its ass= ociated requirements I find it more acceptable to have a protocol which onl= y sends bursts, since these are the simplest packet ensembles to send, and = we know it's a challenge to create packet spacing - especially by a low cos= t device.=20 Would it then be possible to add another use case in the draft, where the r= eflector is not a low-cost device, and thus less restricted by CPU and memo= ry? This use case could be met in the protocol by another TWAMP mode or par= ameter that enables trains with different send rates. With two modes/parame= ters a reflector device could declare its ensemble-sending capabilities in = the control protocol, e.g. a CPE modem would signal that it can only send b= ack-to-back bursts, while a more powerful network node may signal that it c= an send ensembles with different rates within an interval. I also think there should be a section in the draft around the interpretati= on of measurements using bursts. There are cases when delivery rate =3D APC= , but there are other cases when they are not the same. We made some simple= tests in the lab to illustrate the difference. Trains with 100 packets of = test traffic were sent from device A to B via two routers. The bottleneck l= ink between the routers is a 100 Mbps Ethernet link, which then offers 97 M= bps capacity at the IP layer. We defined four scenarios with different cros= s-traffic rates (0, 25, 50, 75 Mbps - iperf UDP CBR) over the bottleneck = link. Then we sent trains with different send rate for each scenario. Here = is a small table showing the results, where we define APC =3D 97 Mbps - cro= ss traffic. As we can see, the delivery rates may deviate quite a lot from = APC, depending on cross traffic and send rate: Cross traffic 0 25 50 75 APC 97 72 47 22 Delivery rate 97 77 65 55 Send rate =3D 100 Mbps Delivery rate 97 83 72 63 Send rate =3D 150 Mbps Delivery rate 97 94 93 88 Send rate =3D 1000 Mbps Looking at a possible down-link measurement scenario in an operator network= , the send rate of the test burst will probably be much larger than the lin= k capacity of the subscriber link, which means that the delivery rate will = show a value close to the subscriber link capacity almost regardless of the= subscriber traffic (see Send rate =3D 1000 Mbps). Any large deviation from= this value can then be interpreted either as congestion higher up in the a= ggregation part of the network or as reduced link capacity of the subscribe= r link, e.g. a distorted ADSL link. It's not clear how to differentiate bet= ween those interpretations. Perhaps the burst measurements must be compleme= nted with CPE detection of the link state? In an up-link scenario, the interpretation is even more unclear, since most= probably the train send-rate =3D subscriber link capacity. In this case th= e subscriber up-link traffic will highly affect the measurements (see Send = rate =3D 100 Mbps), and it will be hard to tell if a low delivery rate depe= nds on either user traffic, congestion in the aggregation part or reduced l= ink capacity. Regarding user traffic, I think it is not safe to assume that= there are times when the user traffic is zero. People may play games, use = Skype or watch Netflix late at night and file sharing applications are ofte= n active any time of the day. Should the CPE also monitor user traffic in o= rder to give more input for the measurements? Christofer -----Original Message----- From: MORTON JR., ALFRED (AL) [mailto:acmorton@att.com] Sent: den 25 januari 2013 00:27 To: Christofer Flinta; ippm@ietf.org Subject: RE: [ippm] Fwd: New Version Notification for draft-morton-ippm-twa= mp-rate-02.txt Hi Christofer, I think it's worth considering the addition of inter-ensemble packet spacin= g. It's clear that many past capacity measurement experiments have used thi= s 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 fixed rate ense= mbles measure the same quantity, but they have different methodological con= straints (you can't send bursts greater than the bottleneck buffer capacity= , and while you can send very long ensembles of fixed rate packets you woul= d be averaging the rate measurement over a long time scale, too, and you ma= y 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 ha= ve been designed to avoid times when the customers who host the measurement= device are not sending competing traffic. Thus the emphasis is to assess t= he apparent peak rate (for a typical subscriber's segment of the path), fur= ther 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 o= ther reasons), and that may mean we have more RFCs to write. It's probably worth examining the requirements to "correctly" generate fixe= d rate packet ensembles, when the hardware doing the generation and/or meas= urement was designed for low-cost-large-scale deployment for a purpose othe= r 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 spac= ing. 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=20 > test packets back-to-back in the forward or reverse direction. From=20 > the collected time stamps in each receiving node the packet delivery=20 > rate for each burst can be calculated, and this delivery rate may be=20 > used as an estimate of the peak throughput for the path. However,=20 > while peak throughput is an important measure, I think a general rate=20 > measurement protocol should also enable measuring of Available Path=20 > Capacity (APC) as defined in RFC 5136. In case of a network with user=20 > traffic present (In- Service testing), peak throughput > APC, which=20 > means that the delivery rate of a burst of back-to-back packets cannot=20 > directly be used as an estimate of APC. Only if the network path is=20 > empty of cross traffic (Out- of-Service testing) peak throughput =3D=20 > APC, which means that delivery rate can be used as an APC estimate. >=20 > In order to estimate APC in a general case (both for In-Service=20 > testing and Out-of-Service testing) each measurement node must be able=20 > to send trains with different rates during a session. APC can then be=20 > estimated by comparing the receive rates with the send rates, according t= o some scheme. > I think this requirement is in line with the proposed requirement of a=20 > test protocol in draft-ietf-ippm-rate-problem-01: "The test protocol=20 > SHALL support test packet ensemble generation (category 3) ...", where=20 > Category > 3 is describes as: " One or more packet ensembles in a test stream,=20 > using a fixed ensemble size in packets and one or more fixed=20 > 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=20 > packets in 5.1.1 to allow packets to be sent with any packet interval=20 > in a burst. >=20 > 2) Measuring APC in reverse direction. > The Session-Sender needs to inform the Session-Reflector of the=20 > desired send rate for each generated burst. The simplest way to do=20 > this is to convert the desired send rate to a desired packet interval=20 > in NTP format, valid for all packets in the burst, and send that value=20 > in the Burst Initiation Packet. The Timestamp field is not used by the=20 > reflector and not reflected back in Burst Generation mode and can=20 > therefore be reused as a new field, e.g. called Desired Packet=20 > Interval. This packet interval should be used by the reflector as a=20 > waiting time for each packet in the generated burst, except for the=20 > first packet in the burst, which should be 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=20 > 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- rate-02.txt >=20 > IPPM, >=20 > We've updated this draft to coordinate with the problem statement as=20 > 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 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From gregimirsky@gmail.com Fri Feb 1 09:37: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 DD03921F8DAB for ; Fri, 1 Feb 2013 09:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LquHZSRJ2FZc for ; Fri, 1 Feb 2013 09:37:24 -0800 (PST) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6444B21E80A3 for ; Fri, 1 Feb 2013 09:37:24 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id cy12so578051veb.6 for ; Fri, 01 Feb 2013 09:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WJNFdHTZJeV04XLoJ7kM+WMJYJ0EpAwOPCTmLNxEs5U=; b=g4RV9cXuSleF0OUU7/2IbRNt4sTbjimkwfemLURVT5F5K0g7TJtEL4wgbnE6PcBG2C CcwCipXypeMJQAlYMbDmk2J5AFJuCQpobuXCg8vr8/RB2AGFQkPEq5ZcCLeLT9Ker5Wy Mc6etjYJjEVaDjQoF7l90W1p+WoVqrqqPNnj6aQgnnw18b++oGdWgqqZHKyWYk1OFOfh GiDdh/SM7qKkbsg2CZ/F89rSAwCNqJZqKog2eX/v4mjWntx6PXLbxLUENARf4TIowlke 1vSufcnsJ0v0ZLtu5fmsb9atmKygH51We4kXz0lCO2iv0bDwx9xHL6PxulBQxddwBfyh 13Tg== MIME-Version: 1.0 X-Received: by 10.220.156.10 with SMTP id u10mr12046610vcw.28.1359740243751; Fri, 01 Feb 2013 09:37:23 -0800 (PST) Received: by 10.220.217.73 with HTTP; Fri, 1 Feb 2013 09:37:23 -0800 (PST) In-Reply-To: <1359311564321-354625.post@n7.nabble.com> References: <201209031359.q83DxIZO004522@alpd052.aldc.att.com> <1359311564321-354625.post@n7.nabble.com> Date: Fri, 1 Feb 2013 09:37:23 -0800 Message-ID: From: Greg Mirsky To: sab Content-Type: multipart/alternative; boundary=f46d0438909337334304d4ad32e8 Cc: ippm@ietf.org 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: Fri, 01 Feb 2013 17:37:26 -0000 --f46d0438909337334304d4ad32e8 Content-Type: text/plain; charset=ISO-8859-1 Dear Steve, protocol's flexibility is important and valuable quality but we should remember that performance measurements in connectionless packet switched network can not reliably characterize performance, e.g. available bandwidth, of a path between any pair of end-points. PM in connectionless PSN characterizes network, not the path that being traversed by customer traffic at given time. I'm not sure that 24/7 PM in IP PSN is useful tool for network operators. It would be great to hear operators before we proceed to adding more complexity to the protocol. Regards, Greg On Sun, Jan 27, 2013 at 10:32 AM, sab wrote: > 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. > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --f46d0438909337334304d4ad32e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Steve,
protocol's flexibility is important and valuable quality= but we should remember that performance measurements in connectionless pac= ket switched network can not reliably characterize performance, e.g. availa= ble bandwidth, of a path between any pair of end-points. PM in connectionle= ss PSN characterizes network, not the path that being traversed by customer= traffic at given time. I'm not sure that 24/7 PM in IP PSN is useful t= ool for network operators. It would be great to hear operators before we pr= oceed to adding more complexity to the protocol.

Regards,
Greg

On Sun, Jan 27, 2013= at 10:32 AM, sab <steve.baillargeon@videotron.ca> wrote:
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 s= et of
objectives. =A0As 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-N= otification-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
ht= tps://www.ietf.org/mailman/listinfo/ippm

--f46d0438909337334304d4ad32e8-- From steve.baillargeon@videotron.ca Fri Feb 1 10:56:47 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D4021E8045 for ; Fri, 1 Feb 2013 10:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[AWL=1.044, 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 IcFUHuSFrV-k for ; Fri, 1 Feb 2013 10:56:46 -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 92C9C21E8041 for ; Fri, 1 Feb 2013 10:56:46 -0800 (PST) Received: from tom.nabble.com ([192.168.236.105]) by joe.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1U1Ln3-0003eF-7q for ippm@ietf.org; Fri, 01 Feb 2013 10:56:45 -0800 Date: Fri, 1 Feb 2013 10:56:45 -0800 (PST) From: sab To: ippm@ietf.org Message-ID: <1359745005234-355144.post@n7.nabble.com> In-Reply-To: References: <201209031359.q83DxIZO004522@alpd052.aldc.att.com> <1359311564321-354625.post@n7.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 01 Feb 2013 18:56:47 -0000 Hi Greg I am glad you agree on the need for protocol flexibility. This is really important. It actually reduces the total complexity in the long run e.g. avoid the nee= d to add another mode Y because mode X cannot do it. I don=E2=80=99t know about you but we have reliably characterize path perfo= rmance for specific pair of endpoints. Many operators have adopted on-going path performance monitoring especially with hub-and-spoke topologies where the number of paths are limited or more or less well-understood. =20 -Steve -- View this message in context: http://ietf.10.n7.nabble.com/Fwd-New-Version-= Notification-for-draft-morton-ippm-twamp-rate-02-txt-tp250601p355144.html Sent from the IETF - ippm mailing list archive at Nabble.com. From internet-drafts@ietf.org Fri Feb 1 14:02:04 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 D635021E8041; Fri, 1 Feb 2013 14:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 MRB8EPrc9AgW; Fri, 1 Feb 2013 14:02:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A7C21E8056; Fri, 1 Feb 2013 14:02:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130201220204.18218.91881.idtracker@ietfa.amsl.com> Date: Fri, 01 Feb 2013 14:02:04 -0800 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 22:02:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : Rate Measurement Test Protocol Problem Statement Author(s) : Al Morton Filename : draft-ietf-ippm-rate-problem-02.txt Pages : 11 Date : 2013-02-01 Abstract: There is a rate measurement scenario which has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From steve.baillargeon@ericsson.com Fri Feb 1 14:43: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 4C43321E8084 for ; Fri, 1 Feb 2013 14:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM7fD8l+JLtR for ; Fri, 1 Feb 2013 14:43:04 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 91A8A21E8050 for ; Fri, 1 Feb 2013 14:43:04 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-08-510c44f7593c Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E9.61.31450.7F44C015; Fri, 1 Feb 2013 23:43:03 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 17:43:02 -0500 From: Steve Baillargeon To: "ippm@ietf.org" Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt Thread-Index: AQHOAMfan+4IuK/3AEOHNpEUAjz0YZhlmQyw Date: Fri, 1 Feb 2013 22:43:01 +0000 Message-ID: References: <20130201220204.18218.91881.idtracker@ietfa.amsl.com> In-Reply-To: <20130201220204.18218.91881.idtracker@ietfa.amsl.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyuXRPoO53F55Ag11PlS16HrxjdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq9PJ9gK3vFW/D10lLGBcQV3FyMnh4SAicTpG5OYIGwxiQv3 1rN1MXJxCAkcYZSYeWMRC4SzjFHi/+2NLCBVbAIWEuvnLmMGsUUElCVavv1hBLGFBZwlJp/+ AxV3kTi75R07hG0kcfbzbbBeFgEVialXb4PV8Ar4SnQvmQcWFxJwlNi6YCXQFRwcnAJOEkdX iIGEGQVkJXafvQ52HLOAuMStJ/OhDhWQWLLnPDOELSrx8vE/VghbWWLJk/0sEPU6Egt2f2KD sLUlli18DbVWUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyFFanFqWm25ksIkRGPjHJNh0 dzDueWl5iFGag0VJnDfI9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbN/tjyOXZ9P4+U +YYvjFJcZSjrJh/Gsu36yjk7Nkdvef95IsNUD85Fe75OuxEx9bHM2/0zA+du2yXdYy20rfTW s718vZKZZw4tdjOWSlD80l3MZtartrz4SM5jd/usWbuD1CrY1wupfGG/3/tg7ZN3TO/itC/x 9B16k/11N9e25ryG7KWBUT+VWIozEg21mIuKEwG50WdOSgIAAA== Subject: Re: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 22:43:05 -0000 Hi Al What changes did you make? -Steve -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: February-01-13 5:02 PM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : Rate Measurement Test Protocol Problem Statement Author(s) : Al Morton Filename : draft-ietf-ippm-rate-problem-02.txt Pages : 11 Date : 2013-02-01 Abstract: There is a rate measurement scenario which has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From Ruediger.Geib@telekom.de Tue Feb 5 00:39:03 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0263F21F89A3 for ; Tue, 5 Feb 2013 00:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 5mOU1l78dl-6 for ; Tue, 5 Feb 2013 00:39:02 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 0B21E21F89B9 for ; Tue, 5 Feb 2013 00:39:00 -0800 (PST) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 05 Feb 2013 09:38:57 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 5 Feb 2013 09:38:56 +0100 From: To: , Date: Tue, 5 Feb 2013 09:38:55 +0100 Thread-Topic: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-02.txt Thread-Index: Ac4AotiI2NDLp4NQSjahR8SCWu6/QwC1hrIQ Message-ID: References: <201209031359.q83DxIZO004522@alpd052.aldc.att.com> <1359311564321-354625.post@n7.nabble.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CA7A7C64CC4ADB458B74477EA99DF6F501677A3496HE111643EMEA1_" MIME-Version: 1.0 Cc: ippm@ietf.org 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: Tue, 05 Feb 2013 08:39:03 -0000 --_000_CA7A7C64CC4ADB458B74477EA99DF6F501677A3496HE111643EMEA1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, Greg. I'm not sure I understand the use case of measuring path capacity by an act= ive system as a provider. This is relevant for which kind of network and which path bandwidth's? IP c= ore networks today are based on 10, 40 or 100 Gbit/s links. Pathes in these networks aren't always= known. Regards, R=FCdiger ________________________________ From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Gre= g Mirsky Sent: Friday, February 01, 2013 6:37 PM To: sab Cc: ippm@ietf.org Subject: Re: [ippm] Fwd: New Version Notification for draft-morton-ippm-twa= mp-rate-02.txt Dear Steve, protocol's flexibility is important and valuable quality but we should reme= mber that performance measurements in connectionless packet switched networ= k can not reliably characterize performance, e.g. available bandwidth, of a= path between any pair of end-points. PM in connectionless PSN characterize= s network, not the path that being traversed by customer traffic at given t= ime. I'm not sure that 24/7 PM in IP PSN is useful tool for network operato= rs. It would be great to hear operators before we proceed to adding more co= mplexity to the protocol. Regards, Greg On Sun, Jan 27, 2013 at 10:32 AM, sab > wrote: 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 --_000_CA7A7C64CC4ADB458B74477EA99DF6F501677A3496HE111643EMEA1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks, Greg.
 
I'm not sure I understand the use case of measuring p= ath=20 capacity by an active system as a provider.
This is relevant for which kind of network and which = path=20 bandwidth's? IP core networks today are
based on 10, 40 o= r 100 Gbit/s=20 links. Pathes in these networks aren't=20 always known. 
 
Regards,
 
R=FCdiger

From: ippm-bounces@ietf.org=20 [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent:<= /B>=20 Friday, February 01, 2013 6:37 PM
To: sab
Cc:=20 ippm@ietf.org
Subject: Re: [ippm] Fwd: New Version Notification f= or=20 draft-morton-ippm-twamp-rate-02.txt

Dear Steve,
protocol's flexibility is important and valuable= =20 quality but we should remember that performance measurements in connectionl= ess=20 packet switched network can not reliably characterize performance, e.g.=20 available bandwidth, of a path between any pair of end-points. PM in=20 connectionless PSN characterizes network, not the path that being traversed= by=20 customer traffic at given time. I'm not sure that 24/7 PM in IP PSN is usef= ul=20 tool for network operators. It would be great to hear operators before we=20 proceed to adding more complexity to the=20 protocol.

Regards,
Greg

On Sun, Jan 27, 2013 at 10:32 AM, sab <steve.baillargeon@videotron.ca> wrote:
Hi Al
I agree with the changes proposed by Christofe= r.=20 They will improve the
protocol and its usability.

Measuring the= =20 available path capacity may not be important to end users but
it is=20 definitively an important metric for the operators especially when it
= is=20 measured 24/7.

As I indicated in the Quebec meeting, the protocol= =20 should be flexible enough
to accomodate any spacing between test packe= ts in=20 a burst in both forward
and reverse directions. We should not worry ab= out=20 cost here. It is up to the
implementer to decide the appropriate spaci= ng=20 and the balance between
benefits and costs.

I don't think we ne= ed to=20 worry about LMAP as well. LMAP has it is own set of
objectives.  = As=20 far as I know, we started the rate discussion much before
LMAP and the= =20 TWAMP protocol should not ignore this use case.

Regards
Steve=20 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=20 from the IETF - ippm mailing list archive at Nabble.com.
_______________________________________________
ippm m= ailing=20 list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
<= /DIV>

--_000_CA7A7C64CC4ADB458B74477EA99DF6F501677A3496HE111643EMEA1_-- From Maha.Abdallah@lip6.fr Tue Feb 5 18:46:14 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC5321F89A6 for ; Tue, 5 Feb 2013 18:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Jxkq7fM9BLo for ; Tue, 5 Feb 2013 18:46:13 -0800 (PST) Received: from isis.lip6.fr (isis.lip6.fr [IPv6:2001:660:3302:283c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 442A121F8959 for ; Tue, 5 Feb 2013 18:46:12 -0800 (PST) Received: from poleia.lip6.fr (mailtwo.desir.lip6.fr [132.227.205.24]) by isis.lip6.fr (8.14.5/lip6) with ESMTP id r162k7l9021613 for ; Wed, 6 Feb 2013 03:46:07 +0100 (CET) X-pt: isis.lip6.fr Received: by poleia.lip6.fr (Postfix, from userid 33) id 726F1CA3F8; Wed, 6 Feb 2013 03:46:02 +0100 (CET) Received: from 66.44.49.79 (SquirrelMail authenticated user abdallah) by mailtwo.lip6.fr with HTTP; Wed, 6 Feb 2013 03:46:02 +0100 Message-ID: <8c88799db3a479fac7cbd2468d16959c.squirrel@mailtwo.lip6.fr> Date: Wed, 6 Feb 2013 03:46:02 +0100 From: "Maha Abdallah" To: ippm@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (isis.lip6.fr [132.227.60.2]); Wed, 06 Feb 2013 03:46:07 +0100 (CET) X-Scanned-By: MIMEDefang 2.73 on 132.227.60.2 Subject: [ippm] Springer's MMSJ - Special Issue on Network and Systems Support for Games X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 02:46:14 -0000 Springer’s Multimedia Systems Journal (MMSJ) Special Issue on Network and Systems Support for Games http://netgames2012.lip6.fr/MMSJ-SI ====================================================================== The market for networked video games is now worth more than $1 billion in western countries. The inherent social and community-building aspects of networked video games are widening the sector's influence on other markets, making their worldwide potential growth tremendous. Virtual economies are also exploding and becoming a growing economic force to be reckoned with. We are already seeing evidence that virtual and real world economies are starting to merge, where users/avatars can exchange real goods along with virtual goods in virtual market places. Another important facet of networked games’ success is that they are allowing not only economic factors to seep through, but social and cultural ones as well. Significant efforts are put into leveraging networked games technologies beyond entertainment, and toward educational, cultural, social, environmental, humanitarian, or learning and training ends. Serious games applications in these domains will clearly continue to grow. This growth clearly poses new challenges on the underlying network and system architectures, and introduces new research questions that require synthesis of a variety of research areas. This special issue focuses on network and systems aspects of games, and covers research and engineering topics that help understand networked games of today and enable the next generation of future networked games. Submissions are solicited on all aspects of networked games, including (but not limited to): - Novel system architectures for networked games (e.g., P2P, cloud gaming) - Efficient message distribution and network protocol design - State synchronization and lag compensation techniques - Network traffic modeling, measurement, and impact on network infrastructure - System benchmarking, performance evaluation, and provisioning - Operating system enhancements, service platforms, and middleware - Scalability issues for massively multiplayer online games (MMOG) - Multiplayer usability and user behavior studies - Personal communications and conferencing in games - Games on mobile devices and other resource-constrained systems - Networks of sensors and actuators, networked haptics - Quality of service and quality of experience - Dynamic and user-generated content authoring, management and adaptation - Content creation: non-linear storytelling, object capturing, algorithmic creation - Security, authentication, accounting and digital rights management - Cheat detection and prevention - Social networking in multiplayer games - Collaborative learning and training in multiplayer serious games IMPORTANT DATES ================ Submission Deadline: March 31, 2013, 2013, 23:59 EDT First Round Notification: May 20, 2013 Revised Paper Due: July 15, 2013 Final Decision: August 26, 2013 SUBMISSION INSTRUCTIONS ======================== Prospective authors should prepare their manuscripts in accordance with the formatting and submission instructions of Springer’s Multimedia Systems Journal: https://www.editorialmanager.com/mmsj/. Submitted articles should report original research results, and must not be under consideration for publication elsewhere. Submissions that are extended versions of previously published conference/workshop papers must technically extend the published version by at least 30%, must explain in the accompanying cover letter the novel and significant contribution of the extended work, and must explicitly cite the published conference/workshop version. GUEST EDITORS ============== Maha Abdallah, Pierre and Marie Curie University, France Khaled Boussetta, University of Paris 13, France Wei Tsang Ooi, National University of Singapore, Singapore From trammell@tik.ee.ethz.ch Fri Feb 8 00:47:11 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF8F21F86FD for ; Fri, 8 Feb 2013 00:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 kXlSJPcoGvQN for ; Fri, 8 Feb 2013 00:47:10 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 50D7021F86AA for ; Fri, 8 Feb 2013 00:47:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F2908D9308 for ; Fri, 8 Feb 2013 09:47:03 +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 mN1vldOES5QX for ; Fri, 8 Feb 2013 09:47:03 +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 B8B27D9307 for ; Fri, 8 Feb 2013 09:47:03 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3FA2CB52-17AF-47AD-AA00-49C1A17D7435@tik.ee.ethz.ch> Date: Fri, 8 Feb 2013 09:47:02 +0100 To: "ippm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [ippm] IPPM Agenda in Orlando X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 08:47:11 -0000 Greetings, all, At IETF 86 in Orlando, the IPPM Working Group will meet in two sessions. = In the first session, we will discuss progress on current working group = drafts as well as individual drafts under consideration for adoption as = WG items; in the second session, we'll discuss a new charter for the = working group, drawing on the background of discussions during the = first. These sessions will probably take place on subsequent days, = though the agenda is not yet final. Many of you have already talked to us about presenting at the meeting; = however, please send or re-send requests for presentation slots to = ippm-chairs@tools.ietf.org, so we can put together an agenda for the = first session. Many thanks, best regards, Brian From a.botta@unina.it Fri Feb 8 06:19:40 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE0321F8888 for ; Fri, 8 Feb 2013 06:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 wO-BhX8XGvBS for ; Fri, 8 Feb 2013 06:19:40 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id A2D4E21F8814 for ; Fri, 8 Feb 2013 06:19:39 -0800 (PST) Received: from [10.220.26.231] ([143.225.6.3]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r18EJbc6008436 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 8 Feb 2013 15:19:38 +0100 Message-ID: <5115089E.60502@unina.it> Date: Fri, 08 Feb 2013 15:15: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=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [ippm] High Performance and Programmable Networking 2013 (HPPN'13) - 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: Fri, 08 Feb 2013 14:19:40 -0000 [Our apologies if you receive multiple copies of this CFP] ----------------------------------------------------------------- CALL FOR PAPER - The deadline has been extended to February 20th ----------------------------------------------------------------- 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 20th, 2013 (EXTENDED) (11:59PM PST) Paper submission: February 20th, 2013 (EXTENDED) (11:59PM PST) Acceptance notification: April 5th, 2013 Final papers due: April 15th, 2013 * Submission Instructions * Each submission must be a single PDF file *6 (six) pages* in length, with a possible extension to 8 (eight) pages (with no extra fees). 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 internet-drafts@ietf.org Sun Feb 17 13:15: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 D85C121F8B58; Sun, 17 Feb 2013 13:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 VcXeyACR7IXT; Sun, 17 Feb 2013 13:15:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E46621F8B49; Sun, 17 Feb 2013 13:15:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130217211555.27012.72287.idtracker@ietfa.amsl.com> Date: Sun, 17 Feb 2013 13:15:55 -0800 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-testplan-rfc2680-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, 17 Feb 2013 21:15:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : Test Plan and Results for Advancing RFC 2680 on the Stan= dards Track Author(s) : Len Ciavattone Ruediger Geib Al Morton Matthias Wieser Filename : draft-ietf-ippm-testplan-rfc2680-02.txt Pages : 27 Date : 2013-02-17 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-testplan-rfc2680 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-testplan-rfc2680-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From acmorton@att.com Mon Feb 18 10:36:08 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 12E1821F8510 for ; Mon, 18 Feb 2013 10:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 0oWeBua2bHbU for ; Mon, 18 Feb 2013 10:36:06 -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 BEAC721F871D for ; Mon, 18 Feb 2013 10:36:06 -0800 (PST) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 326A0120734; Mon, 18 Feb 2013 13:38:18 -0500 (EST) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id 99AE4E36F1; Mon, 18 Feb 2013 13:29:46 -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; Mon, 18 Feb 2013 13:36:05 -0500 From: "MORTON JR., ALFRED (AL)" To: "ippm@ietf.org" Date: Mon, 18 Feb 2013 13:36:04 -0500 Thread-Topic: I-D Action: draft-ietf-ippm-testplan-rfc2680-02.txt Thread-Index: Ac4NVAX11CbtWAumQ5m8alY5XbnJvAAshSyQ Message-ID: References: <20130217211555.27012.72287.idtracker@ietfa.amsl.com> In-Reply-To: <20130217211555.27012.72287.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "matthias_michael.wieser@stud.tu-darmstadt.de" , "CIAVATTONE, LEN" Subject: Re: [ippm] I-D Action: draft-ietf-ippm-testplan-rfc2680-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 18:36:08 -0000 IPPM, The revisions to the WG memo below are the result of preparing the first draft RFC 2680 bis, which can be found at the URLs below: Filename: draft-morton-ippm-2680-bis Revision: 00 Title: A One-Way Loss Metric for IPPM Creation date: 2013-02-17 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-morton-ippm-2680= -bis-00.txt Status: http://datatracker.ietf.org/doc/draft-morton-ippm-2680-bis Htmlized: http://tools.ietf.org/html/draft-morton-ippm-2680-bis-00 Abstract: This memo (RFC 2680 bis) defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. regards, Al > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of internet-drafts@ietf.org > Sent: Sunday, February 17, 2013 4:16 PM > To: i-d-announce@ietf.org > Cc: ippm@ietf.org > Subject: I-D Action: draft-ietf-ippm-testplan-rfc2680-02.txt >=20 >=20 > 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. >=20 > Title : Test Plan and Results for Advancing RFC 2680 on > the Standards Track > Author(s) : Len Ciavattone > Ruediger Geib > Al Morton > Matthias Wieser > Filename : draft-ietf-ippm-testplan-rfc2680-02.txt > Pages : 27 > Date : 2013-02-17 >=20 > Abstract: > 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. >=20 > In this version, the results are presented in the R-tool output form. > Beautification is future work. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-testplan-rfc2680 >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-testplan-rfc2680-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From ken.ko@adtran.com Mon Feb 18 17:30:14 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A4D21E8051 for ; Mon, 18 Feb 2013 17:30:14 -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 P8V7LDtLmV3m for ; Mon, 18 Feb 2013 17:30:14 -0800 (PST) Received: from p02c12o149.mxlogic.net (p02c12o149.mxlogic.net [208.65.145.82]) by ietfa.amsl.com (Postfix) with ESMTP id D781421E8044 for ; Mon, 18 Feb 2013 17:30:13 -0800 (PST) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o149.mxlogic.net(mxl_mta-7.0.0-0) over TLS secured channel with ESMTP id 5a5d2215.0.218937.00-304.520221.p02c12o149.mxlogic.net (envelope-from ); Mon, 18 Feb 2013 18:30:13 -0700 (MST) X-MXL-Hash: 5122d5a57cff3be6-338bf01e2d9efab9b2665fa6add88b3ba2458905 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%14]) with mapi id 14.01.0438.000; Mon, 18 Feb 2013 19:30:12 -0600 From: KEN KO To: "ippm@ietf.org" Thread-Topic: New Version Notification for draft-ko-ippm-streaming-performance-00.txt Thread-Index: Ac4OP6doC0aeTAg0QxucUfNonLQELg== Date: Tue, 19 Feb 2013 01:30:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.196] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=f/H/8pOM c=1 sm=1 a=0XgpNN2/4a34ymu16SVwsQ==:17 a] X-AnalysisOut: [=aQomRHkrLCgA:10 a=0sAT2sIeamgA:10 a=qZHQZMT3apYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=O4Ev-HXITIQA:10 a=48vgC7mUAAAA:8 a=uxsNnmEpOFoZZ] X-AnalysisOut: [X7s_jYA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=G-0daofmxk] X-AnalysisOut: [dInRjB:21 a=gW22hPGNDeY8Y5nk:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Subject: [ippm] FW: New Version Notification for draft-ko-ippm-streaming-performance-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 01:30:14 -0000 SVBQTSwgDQoNCkhlcmUgaXMgYSBuZXcgSS1EIHJlbGF0aW5nIHRvIHRlc3RpbmcgZm9yIHN0cmVh bWluZyBwZXJmb3JtYW5jZS4gSW5zdGVhZCBvZiBzZW5kaW5nIGEgc3RyZWFtIHRvIGRpcmVjdGx5 IHRlc3Qgb25lIGNvbmRpdGlvbiwgaXQgYXBwbGllcyBhIHN0cmVhbWluZyBtb2RlbCB0byBtZXRy aWNzIGZyb20gVENQIHRocm91Z2hwdXQgdGVzdGluZyB0byBlc3RpbWF0ZSBwZXJmb3JtYW5jZSBm b3IgYW55IG51bWJlciBvZiBjb25kaXRpb25zLiBDb21tZW50cyBhcmUgd2VsY29tZS4NCg0KUmVn YXJkcywNCktlbiBLbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNl bnQ6IE1vbmRheSwgRmVicnVhcnkgMTgsIDIwMTMgMTo1MCBQTQ0KVG86IEtFTiBLTw0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rby1pcHBtLXN0cmVhbWluZy1w ZXJmb3JtYW5jZS0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta28taXBw bS1zdHJlYW1pbmctcGVyZm9ybWFuY2UtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEtlbiBLbyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZp bGVuYW1lOgkgZHJhZnQta28taXBwbS1zdHJlYW1pbmctcGVyZm9ybWFuY2UNClJldmlzaW9uOgkg MDANClRpdGxlOgkJIE1vZGVsLUJhc2VkIEVzdGltYXRpb24gb2YgU3RyZWFtaW5nIFBlcmZvcm1h bmNlDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wMi0xOA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE4DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZvcm1h bmNlLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZvcm1hbmNlDQpIdG1saXplZDogICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZv cm1hbmNlLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIG1lbW8gZGVmaW5lcyBtZXRyaWNzIHBs dXMgYSBtZXRob2RvbG9neSBmb3IgcG9zdC1tZWFzdXJlbWVudA0KICAgcHJvY2Vzc2luZyBvZiBz YW1wbGUgbWV0cmljcyB0byBldmFsdWF0ZSBuZXR3b3JrIHBhdGggcGVyZm9ybWFuY2UNCiAgIHJl bGF0aXZlIHRvIHN0cmVhbWluZyB2aWRlbyB0cmFmZmljLiBUaGUgbWV0cmljcyBhcmUgYmFzZWQg b24NCiAgIGVzdGFibGlzaGVkIG1ldGhvZG9sb2dpZXMgZm9yIFRDUCB0aHJvdWdocHV0IHRlc3Rp bmcuIFRoZSBwb3N0LQ0KICAgcHJvY2Vzc2luZyBtZXRob2RvbG9neSBpcyBiYXNlZCBvbiBhIG1v ZGVsIG9mIHN0cmVhbWluZyB0cmFmZmljIHRoYXQNCiAgIGFsbG93cyBhIGdpdmVuIHNhbXBsZSBt ZXRyaWMgdG8gYmUgZXZhbHVhdGVkIGFnYWluc3QgbXVsdGlwbGUgc2V0cw0KICAgb2YgcGFyYW1l dGVycyByZXByZXNlbnRpbmcgZGlmZmVyZW50IHN0cmVhbWluZyByYXRlcywgZGVsYXlzIGFuZA0K ICAgYnVmZmVyaW5nIHZhbHVlcy4gVGhlIHJlc3VsdHMgb2YgdGhlIHBvc3QtcHJvY2Vzc2luZyBt ZXRob2RvbG9neSBhcmUNCiAgIGRlcml2ZWQgbWV0cmljcyB0aGF0IGFyZSBzdWl0YWJsZSBmb3Ig c3RhdGlzdGljYWwgYW5hbHlzaXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From trammell@tik.ee.ethz.ch Thu Feb 21 03:09:39 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 82D1121F8DC3 for ; Thu, 21 Feb 2013 03:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 PVqbwNGXjEQW for ; Thu, 21 Feb 2013 03:09:38 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B7FAC21F8E23 for ; Thu, 21 Feb 2013 03:09:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DA556D9493 for ; Thu, 21 Feb 2013 12:09:35 +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 8FXimEUec3+t for ; Thu, 21 Feb 2013 12:09:35 +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 A0ADAD94A1 for ; Thu, 21 Feb 2013 12:09:35 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Feb 2013 12:09:35 +0100 Message-Id: <0ED451CA-38C8-4D60-B311-3D196D431802@tik.ee.ethz.ch> To: ippm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [ippm] DRAFT agenda for IETF 86 Orlando posted X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 11:09:39 -0000 Greetings, all, The draft agenda for the IPPM sessions at IETF 86 in Orlando has been = posted to: https://datatracker.ietf.org/meeting/86/agenda/ippm/ Please direct comments or questions to ippm-chairs@tools.ietf.org In Orlando, we'll be discussing the rechartering of the working group. = This will consist both of revisions to the charter text as well as to = the milestones. We have a very full agenda during the Thursday session = to review progress on drafts we're considering to take on as working = group items, while the full session on Friday will be devoted to charter = discussion (which will subsequently be taken to the IPPM list). Best regards, Brian= From cuiyang@huawei.com Tue Feb 26 04:49: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 2989A21F8552 for ; Tue, 26 Feb 2013 04:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.497 X-Spam-Level: X-Spam-Status: No, score=-4.497 tagged_above=-999 required=5 tests=[AWL=2.102, 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 qloorO9o2T-F for ; Tue, 26 Feb 2013 04:49:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 362C421F8A1D for ; Tue, 26 Feb 2013 04:49:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOU73723; Tue, 26 Feb 2013 12:49:39 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 12:49:35 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Feb 2013 20:49:38 +0800 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.31]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Tue, 26 Feb 2013 20:49:34 +0800 From: Cuiyang To: "ippm@ietf.org" Thread-Topic: New Version Notification for draft-bi-ippm-ipsec-01.txt Thread-Index: AQHOE4A6Pva6j0rEZUizaIDgo1gkuJiMFiNw Date: Tue, 26 Feb 2013 12:49:34 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE21637319495@nkgeml505-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.139] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ippm] Fwd: New Version Notification for draft-bi-ippm-ipsec-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: Tue, 26 Feb 2013 12:49:41 -0000 V0c6DQoNCkZZSS4gV2UgaGF2ZSB1cGRhdGVkIHRoZSAtMDAgdmVyc2lvbiB3aXRoIHRoZSBjaGFu Z2VzIG9mIHRoZSBwcm9wb3NhbCdzIGFkdmFudGFnZSwgcmVtb3ZlZCBzb21lIGluY29ycmVjdCBz ZW50ZW5jZXMsIGFuZCBhZGRlZCByZWZlcmVuY2VzLg0KQW55IGNvbW1lbnQgaXMgd2VsY29tZS4g VGhhbmtzIQ0KDQpCZXN0IHJlZ2FyZHMsDQpZYW5nDQo9PT09PT09PT09PT09PT09PT0NCiBZYW5n IEN1aSwgIFBoLkQuDQogSHVhd2VpIFRlY2hub2xvZ2llcw0KIGN1aXlhbmdAaHVhd2VpLmNvbQ0K DQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDog MjAxM+W5tDLmnIgyNuaXpSAxOjQ4DQrmlLbku7bkuro6IEtvbnN0YW50aW5vcyBQZW50aWtvdXNp cw0K5oqE6YCBOiBCaXhpYW95dTsgQ3VpeWFuZw0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWJpLWlwcG0taXBzZWMtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWJpLWlwcG0taXBzZWMtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEtvc3RhcyBQZW50aWtvdXNpcyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiBy ZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWJpLWlwcG0taXBzZWMNClJldmlzaW9uOgkg MDENClRpdGxlOgkJIE5ldHdvcmsgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgZm9yIElQc2VjDQpD cmVhdGlvbiBkYXRlOgkgMjAxMy0wMi0yNQ0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpOdW1iZXIgb2YgcGFnZXM6IDEyDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJpLWlwcG0taXBzZWMtMDEudHh0DQpTdGF0dXM6ICAg ICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmktaXBwbS1pcHNl Yw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaS1p cHBtLWlwc2VjLTAxDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWJpLWlwcG0taXBzZWMtMDENCg0KQWJzdHJhY3Q6DQogICBJUHNlYyBpcyBh IG1hdHVyZSB0ZWNobm9sb2d5IHdpdGggc2V2ZXJhbCBpbnRlcm9wZXJhYmxlDQogICBpbXBsZW1l bnRhdGlvbnMuICBJbmRlZWQsIHRoZSB1c2Ugb2YgSVBzZWMgdHVubmVscyBpcyBpbmNyZWFzaW5n bHkNCiAgIGdhaW5pbmcgcG9wdWxhcml0eSBpbiBzZXZlcmFsIGRlcGxveW1lbnQgc2NlbmFyaW9z LCBub3QgdGhlIGxlYXN0IGluDQogICB3aGF0IHVzZWQgdG8gYmUgc29sZWx5IGFyZWFzIG9mIHRy YWRpdGlvbmFsIHRlbGVjb21tdW5pY2F0aW9uDQogICBwcm90b2NvbHMuICBXaWRlciBkZXBsb3lt ZW50IGNhbGxzIGZvciBtZWNoYW5pc21zIGFuZCBtZXRob2RzIHRoYXQNCiAgIGVuYWJsZSB0dW5u ZWwgZW5kLXVzZXJzLCBhcyB3ZWxsIGFzIG9wZXJhdG9ycywgdG8gbWVhc3VyZSBvbmUtd2F5IGFu ZA0KICAgdHdvLXdheSBuZXR3b3JrIHBlcmZvcm1hbmNlLiAgVW5mb3J0dW5hdGVseSwgaG93ZXZl ciwgc3RhbmRhcmQgSVANCiAgIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IHNlY3VyaXR5IG1lY2hh bmlzbXMgY2Fubm90IGJlIHJlYWRpbHkgdXNlZA0KICAgd2l0aCBJUHNlYy4gIFRoaXMgZG9jdW1l bnQgbWFrZXMgdGhlIGNhc2UgZm9yIGVtcGxveWluZyBJUHNlYyB0bw0KICAgcHJvdGVjdCBPL1RX QU1QIGFuZCBwcm9wb3NlcyBhIG1ldGhvZCB3aGljaCBjb21iaW5lcyBJS0V2MiBhbmQNCiAgIE8v VFdBTVAgYXMgZGVmaW5lZCBpbiBSRkMgNDY1NiBhbmQgUkZDIDUzNTcsIHJlc3BlY3RpdmVseS4g IFRoaXMNCiAgIHNwZWNpZmljYXRpb24gYWltcywgb24gdGhlIG9uZSBoYW5kLCB0byBlbnN1cmUg dGhhdCBPL1RXQU1QIGNhbiBiZQ0KICAgc2VjdXJlZCwgd2hpbGUgb24gdGhlIG90aGVyIGhhbmQs IGl0IGV4dGVuZHMgdGhlIGFwcGxpY2FiaWxpdHkgb2YNCiAgIE8vVFdBTVAgdG8gbmV0d29ya3Mg dGhhdCBoYXZlIGFscmVhZHkgZGVwbG95ZWQgSVBzZWMuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From acmorton@att.com Tue Feb 26 09:49:29 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 DAA6121F8740 for ; Tue, 26 Feb 2013 09:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 rzHFgQGd6bUn for ; Tue, 26 Feb 2013 09:49:29 -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 288BF21F8739 for ; Tue, 26 Feb 2013 09:49:29 -0800 (PST) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id ECA38120906; Tue, 26 Feb 2013 12:51:58 -0500 (EST) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id B2944E36E9; Tue, 26 Feb 2013 12:42:50 -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; Tue, 26 Feb 2013 12:49:28 -0500 From: "MORTON JR., ALFRED (AL)" To: "ippm@ietf.org" Date: Tue, 26 Feb 2013 12:49:28 -0500 Thread-Topic: New Version Notification for draft-morton-ippm-2330-update-01.txt Thread-Index: Ac4RWODsnFPrBXIJSnCdnJtK88M2JgC7tw/Q Message-ID: References: <20130223000053.24751.79546.idtracker@ietfa.amsl.com> In-Reply-To: <20130223000053.24751.79546.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [ippm] FW: New Version Notification for draft-morton-ippm-2330-update-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: Tue, 26 Feb 2013 17:49:30 -0000 SVBQTSwNCg0KSm9hY2hpbSBhbmQgSSBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0IHByb3Bvc2luZyB0 byB1cGRhdGUgdGhlIA0KZnJhbWV3b3JrIFJGQyAyMzMwIHdpdGggZGV0YWlscyB0byBhZGRyZXNz IG5ldyBtZWFzdXJlbWVudCBjaGFsbGVuZ2VzLg0KDQpTcGVjaWZpY2FsbHksIHdlIGhhdmUgcHJv cG9zZWQgYSBkZWZpbml0aW9uIGZvciBSZWFjdGl2ZSBOZXR3b3JrIEJlaGF2aW9yLg0KKHNlZSBz ZWN0aW9uIDEuMSBvZiB0aGUgdGV4dCBmaWxlLCBJIG5vdGVkIHRoYXQgdGhlIEhUTUwgdmVyc2lv biBpc24ndCBsb2FkaW5nKQ0KV2UndmUgcmVmaW5lZCBvdXIgb3duIHdvcmRpbmcgYnkgd29ya2lu ZyB0aHJvdWdoIGEgc2VyaWVzIG9mIHRlY2hub2xvZ3kgZXhhbXBsZXMsDQpzb21lIG9mIHdoaWNo IHdlJ2xsIHNoYXJlIGR1cmluZyBvdXIgNSBtaW51dGUgYWdlbmRhIHNsb3QuDQoNClBsZWFzZSBy ZWFkIHRoZSBkcmFmdCBhbmQgdGhlIGlwcG0tbGlzdCBhcmNoaXZlIGZvciBkaXNjdXNzaW9ucyAN CndpdGggUsO8ZGlnZXIgR2VpYiBhbmQgTWF0dCBNYXRoaXMgcHJpb3IgdG8gSUVURi04NS4gDQpG dXJ0aGVyIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpyZWdhcmRzLA0KSm9hY2hpbSBhbmQgQWwN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IEZyaWRh eSwgRmVicnVhcnkgMjIsIDIwMTMgNzowMSBQTQ0KLi4uDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1tb3J0b24taXBwbS0yMzMwLXVwZGF0ZS0wMS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBBbCBNb3J0b24gYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiBy ZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6CSBkcmFmdC1tb3J0b24taXBwbS0yMzMwLXVwZGF0 ZQ0KPiBSZXZpc2lvbjoJIDAxDQo+IFRpdGxlOgkJIEFkdmFuY2VkIFN0cmVhbSBhbmQgU2FtcGxp bmcgRnJhbWV3b3JrIGZvciBJUFBNDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTAyLTIyDQo+IEdy b3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDExDQo+IFVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt bW9ydG9uLWlwcG0tMjMzMC11cGRhdGUtMDEudHh0DQo+IFN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tb3J0b24taXBwbS0yMzMwLXVwZGF0ZQ0K PiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1vcnRv bi1pcHBtLTIzMzAtdXBkYXRlLTAxDQo+IERpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbW9ydG9uLWlwcG0tMjMzMC11cGRhdGUtMDENCj4gDQo+ IEFic3RyYWN0Og0KPiAgICBUbyBvYnRhaW4gcmVwZWF0YWJsZSByZXN1bHRzIGluIG1vZGVybiBu ZXR3b3JrcywgdGVzdCBkZXNjcmlwdGlvbnMNCj4gICAgbmVlZCBhbiBleHBhbmRlZCBzdHJlYW0g cGFyYW1ldGVyIGZyYW1ld29yayB0aGF0IGFsc28gYXVnbWVudHMNCj4gICAgYXNwZWN0cyBzcGVj aWZpZWQgYXMgVHlwZS1QIGZvciB0ZXN0IHBhY2tldHMuICBUaGlzIG1lbW8gcHJvcG9zZXMgdG8N Cj4gICAgdXBkYXRlIHRoZSBJUCBQZXJmb3JtYW5jZSBNZXRyaWNzIChJUFBNKSBGcmFtZXdvcmsg d2l0aCBhZHZhbmNlZA0KPiAgICBjb25zaWRlcmF0aW9ucyBmb3IgbWVhc3VyZW1lbnQgbWV0aG9k b2xvZ3kgYW5kIHRlc3RpbmcuICBUaGUgZXhpc3RpbmcNCj4gICAgZnJhbWV3b3JrIG1vc3RseSBh c3N1bWVzIGRldGVybWluaXN0aWMgY29ubmVjdGl2aXR5LCBhbmQgdGhhdCBhDQo+ICAgIHNpbmds ZSB0ZXN0IHN0cmVhbSB3aWxsIHJlcHJlc2VudCB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBw YXRoDQo+ICAgIHdoZW4gaXQgaXMgYWdncmVnYXRlZCB3aXRoIG90aGVyIGZsb3dzLiAgTmV0d29y a3MgaGF2ZSBldm9sdmVkIGFuZA0KPiAgICB0ZXN0IHN0cmVhbSBkZXNjcmlwdGlvbnMgbXVzdCBl dm9sdmUgd2l0aCB0aGVtLCBvdGhlcndpc2UgdW5leHBlY3RlZA0KPiAgICBuZXR3b3JrIGZlYXR1 cmVzIG1heSBkb21pbmF0ZSB0aGUgbWVhc3VyZWQgcGVyZm9ybWFuY2UuICBUaGlzIG1lbW8NCj4g ICAgZGVzY3JpYmVzIG5ldyBzdHJlYW0gcGFyYW1ldGVycyBmb3IgYm90aCBuZXR3b3JrIGNoYXJh Y3Rlcml6YXRpb24gYW5kDQo+ICAgIHN1cHBvcnQgb2YgYXBwbGljYXRpb24gZGVzaWduIHVzaW5n IElQUE0gbWV0cmljcy4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlh dA0KDQo= From dengguangqing@cnnic.cn Thu Feb 28 07:46:35 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B137721F87EA for ; Thu, 28 Feb 2013 07:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.442 X-Spam-Level: * X-Spam-Status: No, score=1.442 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmNUrccwXMEn for ; Thu, 28 Feb 2013 07:46:35 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id B14EF21F87B9 for ; Thu, 28 Feb 2013 07:46:33 -0800 (PST) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO dgq-pc) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 28 Feb 2013 23:46:21 +0800 Date: Thu, 28 Feb 2013 23:46:25 +0800 From: "Guangqing Deng" To: "KEN KO" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201302282346248720930@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart782078644728_=----" Cc: ippm Subject: Re: [ippm] FW: New Version Notification for draft-ko-ippm-streaming-performance-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dengguangqing List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 15:46:35 -0000 This is a multi-part message in MIME format. ------=_001_NextPart782078644728_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEtlbiwgSSBhbSBhbHNvIGludGVyZXN0ZWQgaW4gdGhlIG1vZGVsaW5nIG9mIHN0cmVhbWlu ZyBwZXJmb3JtYW5jZSBhbmQgaGF2ZSB5b3UgZXZlciBkb25lIGFueSBhY3R1YWwgbmV0d29yayBt ZWFzdXJlbWVudCB0byB2ZXJpZnkgdGhlIGFjY3VyYWN5IG9mIHRoZSBzdHJlYW1pbmcgcGVyZm9y bWFuY2UgbW9kZWwgaW4gdGhpcyBkcmFmdD8gVXN1YWxseSwgdG8gZW5zdXJlIGNvbnN0YW50IGlt YWdlIHF1YWxpdHksIHRoZSBWQlIgKFZhcmlhYmxlIEJpdCBSYXRlKSBjb2RpbmcgbWV0aG9kIGlz IHVzZWQgYW5kIHRoZW4gdGhlIHN0cmVhbWluZyByYXRlIGlzIGFsd2F5cyB0aW1lLXZhcnlpbmcu IFRoZW4gaXMgaXQgbmVjZXNzYXJ5IHRvIHRha2UgdGhlIGR5bmFtaWNzIG9mIHN0cmVhbWluZyBy YXRlIGludG8gY29uc2lkZXJhdGlvbiBmb3IgdGhlIHN0cmVhbWluZyBwZXJmb3JtYW5jZSBtb2Rl bD8NCg0KDQoNCg0KR3VhbmdxaW5nIERlbmcNCmNubmljIA0KDQpGcm9tOiBLRU4gS08NCkRhdGU6 IDIwMTMtMDItMTkgMDk6MzANClRvOiBpcHBtQGlldGYub3JnDQpTdWJqZWN0OiBbaXBwbV0gRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQta28taXBwbS1zdHJlYW1pbmctcGVy Zm9ybWFuY2UtMDAudHh0DQpJUFBNLCANCg0KSGVyZSBpcyBhIG5ldyBJLUQgcmVsYXRpbmcgdG8g dGVzdGluZyBmb3Igc3RyZWFtaW5nIHBlcmZvcm1hbmNlLiBJbnN0ZWFkIG9mIHNlbmRpbmcgYSBz dHJlYW0gdG8gZGlyZWN0bHkgdGVzdCBvbmUgY29uZGl0aW9uLCBpdCBhcHBsaWVzIGEgc3RyZWFt aW5nIG1vZGVsIHRvIG1ldHJpY3MgZnJvbSBUQ1AgdGhyb3VnaHB1dCB0ZXN0aW5nIHRvIGVzdGlt YXRlIHBlcmZvcm1hbmNlIGZvciBhbnkgbnVtYmVyIG9mIGNvbmRpdGlvbnMuIENvbW1lbnRzIGFy ZSB3ZWxjb21lLg0KDQpSZWdhcmRzLA0KS2VuIEtvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxOCwgMjAxMyAxOjUwIFBNDQpU bzogS0VOIEtPDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWtv LWlwcG0tc3RyZWFtaW5nLXBlcmZvcm1hbmNlLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1rby1pcHBtLXN0cmVhbWluZy1wZXJmb3JtYW5jZS0wMC50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2VuIEtvIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICBkcmFmdC1rby1pcHBtLXN0cmVhbWluZy1wZXJmb3Jt YW5jZQ0KUmV2aXNpb246ICAwMA0KVGl0bGU6ICBNb2RlbC1CYXNlZCBFc3RpbWF0aW9uIG9mIFN0 cmVhbWluZyBQZXJmb3JtYW5jZQ0KQ3JlYXRpb24gZGF0ZTogIDIwMTMtMDItMTgNCkdyb3VwOiAg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE4DQpVUkw6ICAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtvLWlwcG0tc3Ry ZWFtaW5nLXBlcmZvcm1hbmNlLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZvcm1hbmNlDQpI dG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtvLWlwcG0t c3RyZWFtaW5nLXBlcmZvcm1hbmNlLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIG1lbW8gZGVm aW5lcyBtZXRyaWNzIHBsdXMgYSBtZXRob2RvbG9neSBmb3IgcG9zdC1tZWFzdXJlbWVudA0KICAg cHJvY2Vzc2luZyBvZiBzYW1wbGUgbWV0cmljcyB0byBldmFsdWF0ZSBuZXR3b3JrIHBhdGggcGVy Zm9ybWFuY2UNCiAgIHJlbGF0aXZlIHRvIHN0cmVhbWluZyB2aWRlbyB0cmFmZmljLiBUaGUgbWV0 cmljcyBhcmUgYmFzZWQgb24NCiAgIGVzdGFibGlzaGVkIG1ldGhvZG9sb2dpZXMgZm9yIFRDUCB0 aHJvdWdocHV0IHRlc3RpbmcuIFRoZSBwb3N0LQ0KICAgcHJvY2Vzc2luZyBtZXRob2RvbG9neSBp cyBiYXNlZCBvbiBhIG1vZGVsIG9mIHN0cmVhbWluZyB0cmFmZmljIHRoYXQNCiAgIGFsbG93cyBh IGdpdmVuIHNhbXBsZSBtZXRyaWMgdG8gYmUgZXZhbHVhdGVkIGFnYWluc3QgbXVsdGlwbGUgc2V0 cw0KICAgb2YgcGFyYW1ldGVycyByZXByZXNlbnRpbmcgZGlmZmVyZW50IHN0cmVhbWluZyByYXRl cywgZGVsYXlzIGFuZA0KICAgYnVmZmVyaW5nIHZhbHVlcy4gVGhlIHJlc3VsdHMgb2YgdGhlIHBv c3QtcHJvY2Vzc2luZyBtZXRob2RvbG9neSBhcmUNCiAgIGRlcml2ZWQgbWV0cmljcyB0aGF0IGFy ZSBzdWl0YWJsZSBmb3Igc3RhdGlzdGljYWwgYW5hbHlzaXMuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ== ------=_001_NextPart782078644728_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

<= FONT=20 face=3D"Times New Roman">Hi, Ken, I=20 am also interested in the modeling of streaming performance and have you e= ver=20 done any actual network measurement to verify the accuracy of the streamin= g=20 performance model in this draft? Usually, to ensure constant image quality= , the=20 VBR (Variable Bit Rate) coding method is used and then the streaming rate = is=20 always time-varying. Then is it necessary to take the dynamics of streamin= g rate=20 into consideration for the streaming performance=20 model?

 
Gua= ngqing=20 Deng
cnnic 
 
From: KEN KO
Date: 2013-02-19 09:30
To: ippm@ietf.org
Subject: [ippm] FW: New Version Notification for=20 draft-ko-ippm-streaming-performance-00.txt
IPPM, 
 
Here is a new I-D relating to test= ing for streaming performance. Instead of se= nding a stream to directly test one con= dition, it applies a streaming model to = ;metrics from TCP throughput testing to esti= mate performance for any number of condition= s. Comments are welcome.
 
Regards,
Ken Ko
 
-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf= .org] 
Sent: Monday, February 18, 2013 1:50 PM=
To: KEN KO
Subject: New Version Notification for draft-= ko-ippm-streaming-performance-00.txt
 
 
A new version of I-D, draft-ko-ippm-streamin= g-performance-00.txt
has been successfully submitted by Ken = Ko and posted to the IETF repository.
 
Filename:  draft-ko-ippm-streaming-performance
Revision:  00
Title:=20  Model-Based Estimation of Streaming Performance<= /DIV>
Creation date:  2013-02-18
Group:  Individual Submission
Number of pages: 18
URL:           = ;  http://www.ietf.org/internet-drafts/draft-ko-ippm-streaming-p= erformance-00.txt
Status:          ht= tp://datatracker.ietf.org/doc/draft-ko-ippm-streaming-performance
Htmlized:        http://tools= .ietf.org/html/draft-ko-ippm-streaming-performance-00
 
 
Abstract:
   This memo defines metrics plus&= nbsp;a methodology for post-measurement
   processing of sample metrics to=  evaluate network path performance
   relative to streaming video tra= ffic. The metrics are based on
   established methodologies for TCP&nb= sp;throughput testing. The post-
   processing methodology is based = ;on a model of streaming traffic that
   allows a given sample metric&nb= sp;to be evaluated against multiple sets
   of parameters representing different=  streaming rates, delays and
   buffering values. The results o= f the post-processing methodology are
   derived metrics that are suitab= le for statistical analysis.
 
           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;        
 
 
The IETF Secretariat
 
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
------=_001_NextPart782078644728_=------ From steve.baillargeon@ericsson.com Thu Feb 28 10:00:17 2013 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8311121F8738 for ; Thu, 28 Feb 2013 10:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HGn2RPxj+iR for ; Thu, 28 Feb 2013 10:00:16 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A2CCB21F8611 for ; Thu, 28 Feb 2013 10:00:03 -0800 (PST) X-AuditID: c618062d-b7f0d6d00000097e-0b-512f9b22bdc9 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 8A.36.02430.22B9F215; Thu, 28 Feb 2013 19:00:03 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Thu, 28 Feb 2013 13:00:02 -0500 From: Steve Baillargeon To: Al Morton Thread-Topic: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-02.txt Thread-Index: Ac2J3GP+HisbjpS/QXyFR1EwMZ/IMBwPLcBgBu+WZZA= Date: Thu, 28 Feb 2013 18:00:01 +0000 Message-ID: References: <201209031359.q83DxIZO004522@alpd052.aldc.att.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPrK7ybP1AgwvtfBZbj01ktOh58I7Z gcnjZf8cRo8lS34yBTBFcdmkpOZklqUW6dslcGXMOvmAuWCvXEXLwreMDYzvJboYOTkkBEwk ZmyYxQZhi0lcuLceyObiEBI4wigxt2kzK0hCSGA5o8TFT/UgNpuAhcT6ucuYQWwRAQWJ75dW sYPYzALKEntfzWcEsYUFoiUOP9vAAlETI3H113ugORxAtpXEuu8xIGEWAVWJI+fPg5XwCvhK HNo5ixFibxOjRPuGo0wgCU4BP4n9Z9aD3cAoICux++x1Johd4hK3nsxngjhaQGLJnvPMELao xMvH/1ghbGWJ73MesUDU60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSbhWTsLCQts5C0zELS soCRZRUjR2lxalluupHBJkZglByTYNPdwbjnpeUhRmkOFiVx3iDXCwFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGJW97+hv273wm5fkustzU52E3m28lWQlPMsjxYmh0TbqC8c+pol6Zj8q 97xZcuOse6zjtM+rmV+J50g90RbTf9TVM/NVS9vbT7172d/8SXSYPTsjlHnbl4Nf5W7U5bDv EL988eSKTcpNBqqX03eenP9d4prygStJ86YteNuy8diy+32PBPYZHDykxFKckWioxVxUnAgA WFW19GACAAA= Cc: "ippm@ietf.org" 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, 28 Feb 2013 18:00:17 -0000 Hi Al I have 3 comments about draft-morton-ippm-twamp-rate-02.txt. 1- In Section 4 where you are listing the MUST for the test protocol, you a= re missing variable intra-packet spacing in the pair, ensemble or train 2- In section 5, I would like to see a requirement on the test protocol for= the two-way architecture where it can measure the rate in a specific trans= mission direction using a single Type-P test session where the test session= has its own test data stream and also measure rates in both forward and re= verse transmission directions using a single Type-P test session where the = forward direction data stream is also used to measure the reverse direction= rate.=20 3- In section 3, you indicate the two-way measurement architecture is favo= red and I agree. You also indicate that each direction of transmission must= be evaluated separately and I agree. However this paragraph does not clari= fy the meaning of test streams vs test sessions. If you imply that each tes= t stream requires its own test session, then I don't agree this is a good a= rchitectural decision since in many access networks following a hub-and-spo= ke topology, I expect the spoke to be the low complexity device (as you hav= e indicated) and the hub to be the controller where the test sessions are c= onfigured, activated/deactivated and where data is probably collected. With= In-Service testing including 24/7 monitoring, one challenge is the number = of concurrent test sessions supported at the hub/controller. It is often th= e limiting factor for scaling the measurement system. Therefore it is desir= able to include the case where a single test session can measure both the f= orward and reverse rates for a given Type-P packet. If you don't, you could= end-up with twice as many test sessions than actually needed.=20 Regards Steve B -----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 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm