From Maha.Abdallah@lip6.fr Mon Oct 1 11:47:11 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043361F0D5A for ; Mon, 1 Oct 2012 11:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.049 X-Spam-Level: X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35, J_CHICKENPOX_27=0.6] 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 GHdNIFp0Rrwo for ; Mon, 1 Oct 2012 11:47:10 -0700 (PDT) Received: from isis.lip6.fr (isis.lip6.fr [IPv6:2001:660:3302:283c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5397A1F0D3F for ; Mon, 1 Oct 2012 11:47:10 -0700 (PDT) Received: from poleia.lip6.fr (mailtwo.desir.lip6.fr [132.227.205.24]) by isis.lip6.fr (8.14.5/lip6) with ESMTP id q91Il8H2017458 for ; Mon, 1 Oct 2012 20:47:08 +0200 (CEST) X-pt: isis.lip6.fr Received: by poleia.lip6.fr (Postfix, from userid 33) id 2A25A146188; Mon, 1 Oct 2012 20:47:03 +0200 (CEST) Received: from 66.44.49.79 (SquirrelMail authenticated user abdallah) by mailtwo.lip6.fr with HTTP; Mon, 1 Oct 2012 20:47:03 +0200 Message-ID: <91e1a75c5091c4724b86e8e57419ac81.squirrel@mailtwo.lip6.fr> Date: Mon, 1 Oct 2012 20:47:03 +0200 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]); Mon, 01 Oct 2012 20:47:08 +0200 (CEST) X-Scanned-By: MIMEDefang 2.73 on 132.227.60.2 Subject: [ippm] NetGames 2012 - Call for Demos (Deadline Extended to October 07, 2012) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 18:47:11 -0000 NetGames 2012 -- CALL FOR DEMOS The 11th Annual Workshop on Network and Systems Support for Games November 22-23, 2012, Venice, Italy http://netgames2012.lip6.fr/ In co-operation with ACM SIGCOMM/SIGMM Technically sponsored by IEEE Communications Society IMPORTANT DATES ================ Demo Paper Submission Deadline: October 7, 2012, 23:59 EDT (Firm Deadline) Notification of Decisions: October 14, 2012 Registration/Final Paper Due: October 28, 2012 OVERVIEW ========= The 11th edition of the Annual International Workshop on Network and Systems Support for Games (NetGames 2012) will be held in Venice, Italy, on November 22-23, 2012. As in previous years, NetGames brings together researchers and practitioners from both academia and industry to present the latest research results and challenges of today’s networked games, and to understand their requirements and possibilities in order to enable the next generation of networked games. NetGames will also have keynote and panel discussions with leading researchers and practitioners from gaming companies. Technical demonstrations showing innovative and original research related to networking and system aspects of games are solicited. Topics of interest include (but are not limited to): - Scalability, cloud support, client-server, and P2P system architectures - Efficient message distribution and network protocol design - Latency issues 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 - Massively Multiplayer Online Gaming (MMOG) - Multiplayer usability and user behavior studies - Personal communications and conferencing in games - Mobile games, resource-constrained systems, and context-based adaptation - Networks of sensors and actuators, networked haptics - Quality of service, quality of experience, and content adaptation - Dynamic and user-generated content authoring and management - 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 SUBMISSIONS ============ Demo submissions are in PDF, should be limited to 3 pages, and should follow the IEEE conference proceedings format. Each Demo submission must be accompanied by a cover letter explaining what will be actually shown during the demonstration. Demo submissions require actual demonstration of a working proof-of-concept or prototype. Reviews will be single-blind, authors must include their names and affiliations on the first page. Papers will be judged on their relevance, technical content, and the clarity of presentation. Submissions should not be under review at another venue nor previously published elsewhere. All accepted Demos papers will be archived in the ACM Digital Library and IEEE Xplore, and will published in the workshop proceedings. Submission of a Demo paper for review will be considered your agreement that at least one author will register and attend the workshop if your Demo is accepted. More information can be found at: http://netgames2012.lip6.fr/cfp.html Workshop Chairs ================ Maha Abdallah, Pierre and Marie Curie University, France Khaled Boussetta, University of Paris 13, France Local Arrangement Chairs ========================= Claudio Palazzi, Università degli Studi di Padova, Italy Sabina Rossi, Università Ca'Foscari di Venezia, Italy Industry Liaisons Chairs ========================= Dario Maggiorini, Università degli Studi di Milano, Italy Laura Anna Ripamonti, Università degli Studi di Milano, Italy Technical Program Committee ============================ Grenville Armitage, Swinburne University of Technology, Australia Ernst Biersack, Institute Eurecom, France Surendar Chandra, FXPAL, USA Kuan-Ta Chen, Academia Sinica, Taiwan Mark Claypool, Worcester Polytechnic Institute, USA Wu-chang Feng, Portland State University, USA Chris GautierDickey, University of Denver, USA Steven Gianvecchio, MITRE Corp., USA Carsten Griwodz, Simula Research Laboratory, Norway Pål Halvorsen, University of Oslo/Simula, Norway Shun-Yun Hu, Academia Sinica, Taiwan Alexandru Iosup, Delft University of Technology, The Netherlands Ben Leong, National University of Singapore, Singapore Martin Mauve, University of Dusseldorf, Germany Ketan Mayer-Patel, University of North Carolina at Chapell Hill, USA Richard Mortier, University of Nottingham, UK Timo Ojala, University of Oulu, Finland Wei Tsang Ooi, National University of Singapore, Singapore Marius Preda, TELECOM SudParis, France Shervin Shirmohammadi, University of Ottawa, Canada Gwendal Simon, TELECOM Bretagne, France Jouni Smed, University of Turku, Finland Jeff Yan, University of Newcastle, UK Sebastian Zander, Swinburne University of Technology, Australia Steering Committee =================== Maha Abdallah, Pierre and Marie Curie University, France Grenville Armitage, Swinburne University of Technology, Australia Adrian Cheok, National University of Singapore, Singapore Mark Claypool, Worcester Polytechnic Institute, USA Carsten Griwodz, Simula Research Laboratory, Norway Tristan Henderson, University of St Andrews, UK Sugih Jamin, University of Michigan, USA Shervin Shirmohammadi, University of Ottawa, Canada Lars Wolf, Technische Universität Braunschweig, Germany From mattmathis@google.com Fri Oct 5 16:12:51 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBA021F859C for ; Fri, 5 Oct 2012 16:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.77 X-Spam-Level: X-Spam-Status: No, score=-101.77 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX226UUNyf7h for ; Fri, 5 Oct 2012 16:12:51 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E9A5E21F8587 for ; Fri, 5 Oct 2012 16:12:50 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1266579wgb.13 for ; Fri, 05 Oct 2012 16:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=Ty61LTt7+1HPzo7pMpE70LnwKuhfFsFFsakaFcS4iDI=; b=mJBXAbRqL0rH0ue3CKACgntBToxROqLewYJQM3Pn96wDKHfIW5kMIYWVwnu6T3x+sL l9B6aGGo6KbEDZmwU95+oSobQgVRrhmtEBhY5q0CN2sEMtHHDb9QYYx2rD+dvtx+qC/i P3MtDeDWh+xrlXX4kTQY9e4xEZebrd9TRLz6hFmw7GNPPz0nFr2PPPHhFCBedMSEX4EV LsYaxvSP67OWckbAmPj7DlwJtOcbdeK8aLocFwL+gWsMqhj+EtfwE8V0G/5l3XIleACi FdXc0jZm14+dONib3obfHPmesEP+MeblE4tGJe9y5D9ityKvFz3JZo75R4k0fcL0ZoO3 Y1IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=Ty61LTt7+1HPzo7pMpE70LnwKuhfFsFFsakaFcS4iDI=; b=o0XFR4GDaHabelemCqo1QxMNUXlWxVD0diUaKitQlTDEu9rJYFJkGJJ+6vtXsS5x74 kLzfm8pIQjNJX5Npy5EED0bSGqRDCAByjfhZhDKIEE8Lad8Zu4rcqUa2h7qB2JzuAB0t gVKRS5MnYIcXkK6I3oYCLNmyV0BfFVBJQ3Vju+qxK5t9hX0cgi21wDRPIKQ+t+GpP5Dy SpWxxC3wgkJtRT4r+3QA26RsPFtW/wztr7kpJkmj/3V8YVDe72Yub+maZgaeNV0TAF2o l41ROo2EDZ75bLBoIBntNfp14fmDi60IZMH46OxGKsGE7p3nFXQQcg39SjC2xdTENQUb Atrg== MIME-Version: 1.0 Received: by 10.180.95.130 with SMTP id dk2mr6177152wib.18.1349478769622; Fri, 05 Oct 2012 16:12:49 -0700 (PDT) Received: by 10.195.12.99 with HTTP; Fri, 5 Oct 2012 16:12:49 -0700 (PDT) In-Reply-To: References: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> <506EF5D8.2090205@mti-systems.com> Date: Fri, 5 Oct 2012 16:12:49 -0700 Message-ID: From: Matt Mathis To: Henning Schulzrinne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlE8NZvFSADzHJKf1hDFxrNB1aIC0xr+QsIMz9beYvDugisXgToneLEPBbMYsqLkfIvJmCucTbZqlAWKVuVmOA0+R0B3SIGFKrirIDerftLyEOT+pBG7APiJLLxQSPbcV3cuM6mD+vS2eMmj8LN1u9ZKoM+2IKrsJnp31C6IgxMyLJ6HupoYSqmBFZRGz0XYB74NT8J Cc: Matthew Ford , "lmap@ietf.org" , ippm@ietf.org, Hannes Tschofenig , "Livingood, Jason" Subject: Re: [ippm] [lmap] BOF not approved? 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, 05 Oct 2012 23:12:52 -0000 +IPPM Consider doing this entire effort within IPPM. A protocol to control measurement is absolutely in scope (See for example RFC 4656) as are discussions about the choice of measurement vantage points and requirements for measurement platforms, etc. Many of the topics that might be out of scope for IPPM, are likely to be out of scope for both IETF and IRTF, for example the design on a media specific link layer control protocol probably belongs in some other forum entirely. For things that are on the edge of IPPM's scope and don't fit elsewhere, it would be far easier to tweak IPPM than to spin a new WG. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne wrote: > I can't speak for all the LMAP participants, obviously, but I was hoping = that the LMAP requirements I-D made it reasonably clear that at least our n= eeds are primarily in defining a specific set of protocols, with the metric= s being delegated to IPPM (or successor). Thus, this would not be a BCP, bu= t at least experimental. If the draft failed to make the point, I have obvi= ously some work to do... > > Henning > > ________________________________________ > From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Wesley E= ddy [wes@mti-systems.com] > Sent: Friday, October 05, 2012 10:59 AM > To: Matthew Ford > Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; lm= ap@ietf.org > Subject: Re: [lmap] BOF not approved? > > On 10/5/2012 9:55 AM, Matthew Ford wrote: >> >> On 5 Oct 2012, at 14:09, "Livingood, Jason" wrote: >> >>> My original suggestion to a few folks (before this list was established= ) >>> was to do this work in the IRTF. Perhaps we can arrange something there= , >>> even if an informal discussion of what is needed and how we might proce= ed? >>> Failing that, a bar BoF would be helpful. >>> >> >> I don't have a strong opinion about IRTF vs. bar BoF but I would strongl= y support having a meeting in Atlanta to review the situation, potentially = hear more about requirements from others, and try to figure out a (sustaina= ble) way forward for this initiative. >> > > > Obviously some work has to take place to further identify what > exactly people would like to do, and then the choice of goal > for IETF or IRTF group would be more obvious, based on the > desired outcome (e.g. standards or BCP work would indicate an > IETF WG, or it may turn out that some work could fit within > existing groups like IPPM). > > Until this is clear, I would suggest to just have a pure > side-meeting. > > -- > Wes Eddy > MTI Systems > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From acmorton@att.com Sun Oct 7 19:13:35 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F26921F8712; Sun, 7 Oct 2012 19:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 fqVieXLN-hEi; Sun, 7 Oct 2012 19:13:34 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4B14821F86C2; Sun, 7 Oct 2012 19:13:34 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id dc632705.0.141120.00-429.383209.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 08 Oct 2012 02:13:34 +0000 (UTC) X-MXL-Hash: 507236ce0533a418-268e4e19941b7dbbc070f3607b2553ca2763fd6f Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q982DX2H014536; Sun, 7 Oct 2012 22:13:33 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q982DRnZ014527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Oct 2012 22:13:28 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor); Sun, 7 Oct 2012 22:13:12 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q982DB5R011980; Sun, 7 Oct 2012 22:13:12 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q982D6W3011608; Sun, 7 Oct 2012 22:13:07 -0400 Received: from lt-hp1044652.att.com (vpn-130-10-228-200.vpn.sest.att.com[130.10.228.200](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121008021205gw100sspeme>; Mon, 8 Oct 2012 02:12:10 +0000 X-Originating-IP: [130.10.228.200] Message-Id: <7.0.1.0.0.20121007220252.0745c538@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 07 Oct 2012 22:12:31 -0400 To: Matt Mathis , Henning Schulzrinne From: Al Morton In-Reply-To: References: <10229F86C86EB444898E629583FD417118C703CA@PACDCEXMB06.cable.comcast.com> <506EF5D8.2090205@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=DfugXIRW c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=Ae4mP6Td2dcA:10 a=uZN-4-ycT8gA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=whDpgFbH] X-AnalysisOut: [l3sA:10 a=48vgC7mUAAAA:8 a=-Cb5Q1N6AAAA:8 a=6MyZ0KW2AAAA:8] X-AnalysisOut: [ a=1g_KX55Nkd4XcXew2roA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=czfYQaGQYtkA:10] Cc: Matthew Ford , ippm@ietf.org, "lmap@ietf.org" , Hannes Tschofenig , "Livingood, Jason" Subject: Re: [ippm] [lmap] BOF not approved? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 02:13:35 -0000 Thinking about the main classes of requirements in the draft, both passive and active measurement systems are desired. This may turn-out to be good combination. While IPPM is strong in metric definitions and test protocols for active measurements, I think there is some room for growth in collection protocols (especially with the degree of inter-communication envisaged in the requirements). But this is where the IETF developments to support passive measurements might help fill the gap (ipfix is the best example I can think of). regards, Al At 07:12 PM 10/5/2012, Matt Mathis wrote: >+IPPM > >Consider doing this entire effort within IPPM. A protocol to >control measurement is absolutely in scope (See for example RFC 4656) >as are discussions about the choice of measurement vantage points and >requirements for measurement platforms, etc. Many of the topics that >might be out of scope for IPPM, are likely to be out of scope for both >IETF and IRTF, for example the design on a media specific link layer >control protocol probably belongs in some other forum entirely. > >For things that are on the edge of IPPM's scope and don't fit >elsewhere, it would be far easier to tweak IPPM than to spin a new WG. > >Thanks, >--MM-- >The best way to predict the future is to create it. - Alan Kay > > >On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne > wrote: > > I can't speak for all the LMAP participants, obviously, but I was > hoping that the LMAP requirements I-D made it reasonably clear that > at least our needs are primarily in defining a specific set of > protocols, with the metrics being delegated to IPPM (or successor). > Thus, this would not be a BCP, but at least experimental. If the > draft failed to make the point, I have obviously some work to do... > > > > Henning > > > > ________________________________________ > > From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of > Wesley Eddy [wes@mti-systems.com] > > Sent: Friday, October 05, 2012 10:59 AM > > To: Matthew Ford > > Cc: marcelo bagnulo braun; Hannes Tschofenig; > Livingood, Jason; lmap@ietf.org > > Subject: Re: [lmap] BOF not approved? > > > > On 10/5/2012 9:55 AM, Matthew Ford wrote: > >> > >> On 5 Oct 2012, at 14:09, "Livingood, Jason" > wrote: > >> > >>> My original suggestion to a few folks (before this list was established) > >>> was to do this work in the IRTF. Perhaps we can arrange something there, > >>> even if an informal discussion of what is needed and how we > might proceed? > >>> Failing that, a bar BoF would be helpful. > >>> > >> > >> I don't have a strong opinion about IRTF vs. bar BoF but I would > strongly support having a meeting in Atlanta to review the > situation, potentially hear more about requirements from others, > and try to figure out a (sustainable) way forward for this initiative. > >> > > > > > > Obviously some work has to take place to further identify what > > exactly people would like to do, and then the choice of goal > > for IETF or IRTF group would be more obvious, based on the > > desired outcome (e.g. standards or BCP work would indicate an > > IETF WG, or it may turn out that some work could fit within > > existing groups like IPPM). > > > > Until this is clear, I would suggest to just have a pure > > side-meeting. > > > > -- > > Wes Eddy > > MTI Systems > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From jerome.benoit@grenouille.com Mon Oct 8 04:27:33 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDFD21F877E for ; Mon, 8 Oct 2012 04:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmYD9OH9RVR1 for ; Mon, 8 Oct 2012 04:27:33 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7F67521F875B for ; Mon, 8 Oct 2012 04:27:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id DB6C67F521; Mon, 8 Oct 2012 13:27:27 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJtKLMdH5-Fx; Mon, 8 Oct 2012 13:27:15 +0200 (CEST) Date: Mon, 8 Oct 2012 13:27:13 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: Marc Linsner Message-ID: <20121008132713.7e5976c2@nemesis.grenouille.com> In-Reply-To: References: Organization: Grenouille.com X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.11; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/+=HOSNpBA3RjECgtlkimGpP"; protocol="application/pgp-signature" Cc: ippm@ietf.org Subject: Re: [ippm] FW: [lmap] Internet LMAP Draft for Review X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:27:34 -0000 --Sig_/+=HOSNpBA3RjECgtlkimGpP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, 21 Sep 2012 09:44:21 -0400 Marc Linsner wrote: > >=20 > > A new version of I-D, draft-schulzrinne-lmap-requirements-00.txt The logical architecture is way too overloaded :=20 * I see no need to create a specific server for network characteristics. I think this can go in a GUI to configure the measurement agent, this way the measurement data, the measurement definition and the network characteristics are pushed to the data collector server, not need for the agent to contact anyone to have the network characteristics. The measurement data are acquired with all the metadatas needed to do proper data mining.=20 * The landmark server should be a derivative of the measurement agent. If the measurement agent is not able the receive measurement, you will never ever be able to achieve end to end measurements. * You miss one important point which : How will you be able to coordinate your measurement agents ? The measurement controller as you define it is not able to track agent state, and if you can't know what measurement agents are doing, you will not be able to run measurement that have strong requirements such as : having up to 100 agents running behind the same edge routing network element for example.=20 That's all (for today).=20 Regards, =20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/+=HOSNpBA3RjECgtlkimGpP Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlByuJEACgkQ+qDLUJ/pFh09UACgmhHa6q4HhJ72GS6bt1TWfMgl Ej8AoKWbDGGgyD31Qeq0kQ4Xk+Ei0odN =NcHf -----END PGP SIGNATURE----- --Sig_/+=HOSNpBA3RjECgtlkimGpP-- From Joachim.Fabini@tuwien.ac.at Mon Oct 8 08:47:48 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED6B21F8804 for ; Mon, 8 Oct 2012 08:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 Qno7gn1kPOIS for ; Mon, 8 Oct 2012 08:47:48 -0700 (PDT) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id A00D721F87B2 for ; Mon, 8 Oct 2012 08:47:47 -0700 (PDT) Received: from [128.131.88.241] (priamos.ibk.tuwien.ac.at [128.131.88.241]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id q98Flglj028865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Oct 2012 17:47:42 +0200 Message-ID: <5072F59A.50507@tuwien.ac.at> Date: Mon, 08 Oct 2012 17:47:38 +0200 From: Joachim Fabini User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: ippm@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: Al Morton Subject: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 15:47:48 -0000 Dear group, Following an initial contact on RFC 6703 (while in draft status) Al Morton and me have started to isolate and summarize some shortcomings of RFC 2330 with respect to active measurements (metrics, methodologies) in reactive and/or time-slotted networks. As it turned out during discussions, today's access networks implement optimized on-demand capacity allocation, such that several methodology properties (in particular continuity and repeatability, but also extensibility) stated in RFC 2330, section 6.2, are no longer satified. Our measurement results confirm these findings. We believe that the current status can be improved by defining an advanced stream sampling framework. There is an increased interest in these aspects (IEEE P802.16.3 project, US FCC, European Commission, National Regulators in EU) and such a stream sampling framework can help. Al has submitted the first version of the document, available at Any feedback to the mailing list is warmly welcome. In case you do not have access to the referenced publications please contact me by email. best regards Joachim -- --------------------------------------- Dr. Joachim Fabini Institute of Telecommunications Vienna University of Technology Favoritenstraße 9/389 A-1040 Vienna, Austria Tel: +43 1 58801-38813 Fax: +43 1 58801-38898 mailto: Joachim.Fabini@tuwien.ac.at --------------------------------------- From yaakov_s@rad.com Tue Oct 9 04:09:34 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCB521F8875 for ; Tue, 9 Oct 2012 04:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVt5c6c4+1tt for ; Tue, 9 Oct 2012 04:09:34 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEC321F8873 for ; Tue, 9 Oct 2012 04:09:30 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 9 Oct 2012 12:12:30 +0200 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Tue, 9 Oct 2012 13:09:25 +0200 From: Yaakov Stein To: IETF IPPM WG Thread-Topic: Microsoft's psping utility Thread-Index: Ac2mDoqZt99z3EIZSzCOWZheMqP/5w== Date: Tue, 9 Oct 2012 11:09:25 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9045920A7@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9045920A7EXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090209.507405E6.006C,ss=1,fgs=0 Subject: [ippm] Microsoft's psping utility X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:09:34 -0000 --_000_07F7D7DED63154409F13298786A2ADC9045920A7EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I just noticed this utility from Microsoft http://technet.microsoft.com/en-= us/sysinternals/jj729731 which claims to enhance "ping" with delay and bandwidth measurement, as well as having TCP modes. Has anyone looked at this utility ? Y(J)S --_000_07F7D7DED63154409F13298786A2ADC9045920A7EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I just noticed this utili= ty from Microsoft http:/= /technet.microsoft.com/en-us/sysinternals/jj729731

which claims to enhance &= quot;ping" with delay and bandwidth measurement,

as well as having TCP mod= es.

 

Has anyone looked at this= utility ?

 

Y(J)S

 

&nbs= p;

 

--_000_07F7D7DED63154409F13298786A2ADC9045920A7EXRAD5adradcoil_-- From vinayakh@gmail.com Tue Oct 9 04:18:52 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2450221F86FC for ; Tue, 9 Oct 2012 04:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WQvdtMc8f3p for ; Tue, 9 Oct 2012 04:18:51 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D81A21F8702 for ; Tue, 9 Oct 2012 04:18:51 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so3656880eek.31 for ; Tue, 09 Oct 2012 04:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q+EchkEUL4mjCe8xdqmnP6khuJiV8wSrAD8jVfWa9g8=; b=TYHqs1umw50urVoIWH9WXLD+ga/iNrzQlhwa1B48qukZMZUPKLpLnZgD9ujMpttGOo E4FyjdzS4C4XwWbKeXM0Kjwto0etlwbW0PQu3PoO5wsM8BVME8PfOavesF3K+/Tb+BSb DWgCfUNJqYNuWqBwIMDUGFGl37XpapSCQ5bv7TB3p/K49M25wuI+MQYjw2krweqFO3s0 jzzaZaYzh3bsYwP3Dvj3K6NgdcPs3aMBJ8WESQFuDjykixf3mDMARZ6ICCX5oCFAgSkn rFLk1IUFdVNf8bgQT77Xp/Xz6MauV5WQfMtxxWrV8BMiUktqAoPVAORWzLMziDHI8tBg fMFQ== MIME-Version: 1.0 Received: by 10.14.213.201 with SMTP id a49mr27071249eep.4.1349781530427; Tue, 09 Oct 2012 04:18:50 -0700 (PDT) Received: by 10.14.198.135 with HTTP; Tue, 9 Oct 2012 04:18:50 -0700 (PDT) In-Reply-To: <07F7D7DED63154409F13298786A2ADC9045920A7@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC9045920A7@EXRAD5.ad.rad.co.il> Date: Tue, 9 Oct 2012 16:48:50 +0530 Message-ID: From: Vinayak Hegde To: Yaakov Stein Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF IPPM WG Subject: Re: [ippm] Microsoft's psping utility X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:18:52 -0000 On Tue, Oct 9, 2012 at 4:39 PM, Yaakov Stein wrote: > Hi all, > > > > I just noticed this utility from Microsoft > http://technet.microsoft.com/en-us/sysinternals/jj729731 > > which claims to enhance "ping" with delay and bandwidth measurement, > > as well as having TCP modes. > > > > Has anyone looked at this utility ? I have not looked at this utility but nmap also has a bunch of options to do similar things such as 1. TCP/UDP pings 2. Latency reporting above thresholds in addition to network port scanning and topology discovery. Regards Vinayak From andreas.a.johnsson@ericsson.com Tue Oct 9 06:19:58 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B3F21F88AB for ; Tue, 9 Oct 2012 06:19:58 -0700 (PDT) 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 CDL1t7Qau2F2 for ; Tue, 9 Oct 2012 06:19:57 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C794221F88A8 for ; Tue, 9 Oct 2012 06:19:56 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-08-5074247bdaa9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3D.BD.17130.B7424705; Tue, 9 Oct 2012 15:19:55 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.11]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 9 Oct 2012 15:19:55 +0200 From: Andreas Johnsson A To: IETF IPPM WG Date: Tue, 9 Oct 2012 15:19:54 +0200 Thread-Topic: [ippm] Microsoft's psping utility Thread-Index: Ac2mD+gOsuxvJkX1S5u1DeobzZsACQAEI3jA Message-ID: <3B05069A569E6F4AB6397B968734EBEA57A6BDA2CD@ESESSCMS0363.eemea.ericsson.se> References: <07F7D7DED63154409F13298786A2ADC9045920A7@EXRAD5.ad.rad.co.il> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvrW61SkmAwfQNKhY9D94xOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/KimSwFJzkrvqw4wNTA+Iq9i5GDQ0LAROLyW88uRk4gU0zi wr31bF2MXBxCAqcYJS63LGGBcOYzSrye/I0ZpIpNwEpifdc2ZpBmEQEFiUmP/UFMFgEVic8r w0EqhAX0JFbN+8gCYosI6Euc2HSCEcI2kuj/+BhsCq9AuMTHtm2MEOMnMkosvNDGCpLgFAiU 2HFyLxuIzQh00PdTa5hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQ9aISd9rXM0LU60gs 2P2JDcLWlli28DXUYkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNwbmJmTnq5uV5qUWZy cXF+nl5x6iZGYDQc3PLbYAfjpvtihxilOViUxHn1VPf7CwmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamAseTkl0ZtpYknLJ3eGz69ff3FfOCH9Rt9euyWMFu6X5Y9EHphUylCUt+rN9tJcncys 5X+OmenNUDJU09Q1ELe18Llck/fD1OCaDO86/lvOxUXNtlxmVaw6U54pK7avKD83ecOSa6sP OL55cLE2xm152+vIWbU/I5eEsKd+1atY9UrAdV+k4DYlluKMREMt5qLiRABBY7jpVAIAAA== Subject: Re: [ippm] Microsoft's psping utility X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:19:58 -0000 Caida has gathered links to different tools. Most of them are for research = purposes.=20 http://www.caida.org/tools/taxonomy/index.xml Also ITG can do some similar stuff:=20 http://www.grid.unina.it/software/ITG/ Best regards, Andreas=20 -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Vin= ayak Hegde Sent: den 9 oktober 2012 13:19 To: Yaakov Stein Cc: IETF IPPM WG Subject: Re: [ippm] Microsoft's psping utility On Tue, Oct 9, 2012 at 4:39 PM, Yaakov Stein wrote: > Hi all, > > > > I just noticed this utility from Microsoft > http://technet.microsoft.com/en-us/sysinternals/jj729731 > > which claims to enhance "ping" with delay and bandwidth measurement, > > as well as having TCP modes. > > > > Has anyone looked at this utility ? I have not looked at this utility but nmap also has a bunch of options to d= o similar things such as 1. TCP/UDP pings 2. Latency reporting above thresh= olds in addition to network port scanning and topology discovery. Regards Vinayak _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From yaakov_s@rad.com Tue Oct 9 07:12:53 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7911F0C90 for ; Tue, 9 Oct 2012 07:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOtUDFPWzWNK for ; Tue, 9 Oct 2012 07:12:53 -0700 (PDT) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id 579BA1F0C8E for ; Tue, 9 Oct 2012 07:12:50 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 9 Oct 2012 16:24:19 +0200 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Tue, 9 Oct 2012 16:12:46 +0200 From: Yaakov Stein To: IETF IPPM WG Thread-Topic: [ippm] Microsoft's psping utility Thread-Index: Ac2mDoqZt99z3EIZSzCOWZheMqP/5///4RoAgAAh0wD//9BbUA== Date: Tue, 9 Oct 2012 14:12:46 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC904592261@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC9045920A7@EXRAD5.ad.rad.co.il> <3B05069A569E6F4AB6397B968734EBEA57A6BDA2CD@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: <3B05069A569E6F4AB6397B968734EBEA57A6BDA2CD@ESESSCMS0363.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090201.507430DF.00DC,ss=1,fgs=0 Subject: Re: [ippm] Microsoft's psping utility X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:12:53 -0000 Thanks to Andreas and Vinayak for pointing out additional active performanc= e measurement tools. The reason I asked is that we are looking into progressing the Cisco SLA pr= otocol to RFC. If there are other tools that are widely used, then perhaps we need to docu= ment them as well. Y(J)S From BCheck@NCTA.com Sun Oct 7 13:25:43 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56E221F870E; Sun, 7 Oct 2012 13:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGkIzAH6gCT3; Sun, 7 Oct 2012 13:25:42 -0700 (PDT) Received: from mail-3.ncta.com (mail-3.ncta.com [209.23.210.3]) by ietfa.amsl.com (Postfix) with ESMTP id 9176D21F870B; Sun, 7 Oct 2012 13:25:41 -0700 (PDT) Received: from MAILSTORE-A.ncta.com ([::1]) by Mailhubcas.ncta.com ([::1]) with mapi id 14.01.0379.000; Sun, 7 Oct 2012 16:25:40 -0400 From: William Check To: Matt Mathis , Henning Schulzrinne , "lmap@ietf.org" Thread-Topic: [lmap] BOF not approved? Thread-Index: AQHNore22m37bPHIg0qKpN1WSxYJ6Jeqi3MAgABng4CAAAzWAIAAEeQAgAABgwCAAIhLgIACstuA Date: Sun, 7 Oct 2012 20:25:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [212.147.27.54] Content-Type: multipart/alternative; boundary="_000_CC975CFF4791Cbchecknctacom_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 09 Oct 2012 09:49:06 -0700 Cc: Matthew Ford , "ippm@ietf.org" , "lmap@ietf.org" , Hannes Tschofenig , "Livingood, Jason" Subject: Re: [ippm] [lmap] BOF not approved? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 20:25:43 -0000 --_000_CC975CFF4791Cbchecknctacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I tend to agree that an informal discussion within the IRTF would be a good= way to proceed=85. Bill From: Matt Mathis > Date: Friday, October 5, 2012 7:12 PM To: Henning Schulzrinne > Cc: Matthew Ford >, "lmap@ietf.org" >, Wesley Eddy >, "ippm@ietf.org" >, marcelo bagnulo braun >, Hannes Tschofenig >, Jason Livingood > Subject: Re: [lmap] BOF not approved? +IPPM Consider doing this entire effort within IPPM. A protocol to control measurement is absolutely in scope (See for example RFC 4656) as are discussions about the choice of measurement vantage points and requirements for measurement platforms, etc. Many of the topics that might be out of scope for IPPM, are likely to be out of scope for both IETF and IRTF, for example the design on a media specific link layer control protocol probably belongs in some other forum entirely. For things that are on the edge of IPPM's scope and don't fit elsewhere, it would be far easier to tweak IPPM than to spin a new WG. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne > wrote: I can't speak for all the LMAP participants, obviously, but I was hoping th= at the LMAP requirements I-D made it reasonably clear that at least our nee= ds are primarily in defining a specific set of protocols, with the metrics = being delegated to IPPM (or successor). Thus, this would not be a BCP, but = at least experimental. If the draft failed to make the point, I have obviou= sly some work to do... Henning ________________________________________ From: lmap-bounces@ietf.org [lmap-bounces@iet= f.org] on behalf of Wesley Eddy [wes@mti-syst= ems.com] Sent: Friday, October 05, 2012 10:59 AM To: Matthew Ford Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; lmap= @ietf.org Subject: Re: [lmap] BOF not approved? On 10/5/2012 9:55 AM, Matthew Ford wrote: On 5 Oct 2012, at 14:09, "Livingood, Jason" > wrote: My original suggestion to a few folks (before this list was established) was to do this work in the IRTF. Perhaps we can arrange something there, even if an informal discussion of what is needed and how we might proceed? Failing that, a bar BoF would be helpful. I don't have a strong opinion about IRTF vs. bar BoF but I would strongly s= upport having a meeting in Atlanta to review the situation, potentially hea= r more about requirements from others, and try to figure out a (sustainable= ) way forward for this initiative. Obviously some work has to take place to further identify what exactly people would like to do, and then the choice of goal for IETF or IRTF group would be more obvious, based on the desired outcome (e.g. standards or BCP work would indicate an IETF WG, or it may turn out that some work could fit within existing groups like IPPM). Until this is clear, I would suggest to just have a pure side-meeting. -- Wes Eddy MTI Systems _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_CC975CFF4791Cbchecknctacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <23FB445E57DAC64CBE3B0C37243ADF9F@ncta.com> Content-Transfer-Encoding: quoted-printable
I tend to agree that an informal discussion within the IRTF would be a= good way to proceed=85.  Bill


From: Matt Mathis <mattmathis@google.com>
Date: Friday, October 5, 2012 7:12 = PM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>=
Cc: Matthew Ford <ford@isoc.org>, "lmap@ietf.org" <lmap@iet= f.org>, Wesley Eddy <wes@m= ti-systems.com>, "ippm@ietf.org" <ippm@ietf.org>, marcelo bagnulo braun <= marcelo@it.uc3m.es>, Hannes Ts= chofenig <hannes.tschofenig= @gmx.net>, Jason Livingood <j= ason_livingood@cable.comcast.com>
Subject: Re: [lmap] BOF not approve= d?

+IPPM

Consider doing this entire effort within IPPM.    = A protocol to
control measurement is absolutely in scope (See for example RFC 4656)<= /div>
as are discussions about the choice of measurement vantage points and<= /div>
requirements for measurement platforms, etc.   Many of the t= opics that
might be out of scope for IPPM, are likely to be out of scope for both=
IETF and IRTF, for example the design on a media specific link layer
control protocol probably belongs in some other forum entirely.

For things that are on the edge of IPPM's scope and don't fit
elsewhere, it would be far easier to tweak IPPM than to spin a new WG.=

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


On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne
I can't speak for all the LMAP participants, obviously, but I was hopi= ng that the LMAP requirements I-D made it reasonably clear that at least ou= r needs are primarily in defining a specific set of protocols, with the met= rics being delegated to IPPM (or successor). Thus, this would not be a BCP, but at least experimental. If t= he draft failed to make the point, I have obviously some work to do...

Henning

________________________________________
Sent: Friday, October 05, 2012 10:59 AM
To: Matthew Ford
Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood,  &n= bsp;     Jason; lmap@ietf.org
Subject: Re: [lmap] BOF not approved?

On 10/5/2012 9:55 AM, Matthew Ford wrote:

On 5 Oct 2012, at 14:09, "Livingood, Jason" <Jason_Livingood@cable.comcast.com<= /a>> wrote:

My original suggestion to a few folks (before this list was establishe= d)
was to do this work in the IRTF. Perhaps we can arrange something ther= e,
even if an informal discussion of what is needed and how we might proc= eed?
Failing that, a bar BoF would be helpful.


I don't have a strong opinion about IRTF vs. bar BoF but I would stron= gly support having a meeting in Atlanta to review the situation, potentiall= y hear more about requirements from others, and try to figure out a (sustai= nable) way forward for this initiative.



Obviously some work has to take place to further identify what
exactly people would like to do, and then the choice of goal
for IETF or IRTF group would be more obvious, based on the
desired outcome (e.g. standards or BCP work would indicate an
IETF WG, or it may turn out that some work could fit within
existing groups like IPPM).

Until this is clear, I would suggest to just have a pure
side-meeting.

--
Wes Eddy
MTI Systems
_______________________________________________
lmap mailing list
_______________________________________________
lmap mailing list
_______________________________________________
lmap mailing list


--_000_CC975CFF4791Cbchecknctacom_-- From jason_livingood@cable.comcast.com Tue Oct 9 07:42:37 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A83221F8876; Tue, 9 Oct 2012 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 lJp2BqnbCh64; Tue, 9 Oct 2012 07:42:37 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id C8CD221F8873; Tue, 9 Oct 2012 07:42:36 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.36779639; Tue, 09 Oct 2012 08:19:33 -0600 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.64]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 10:42:28 -0400 From: "Livingood, Jason" Thread-Topic: [lmap] BOF not approved? Thread-Index: AQHNore3VXTel7BurEKSo4ljwsWnGpeqi3MAgAAkdgCAAE/jAIAAEeQAgAABggCAAIhMgIAFd7MA Date: Tue, 9 Oct 2012 14:42:27 +0000 Message-ID: <10229F86C86EB444898E629583FD417118C7B367@PACDCEXMB06.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Matt Mathis , Henning Schulzrinne X-Mailman-Approved-At: Tue, 09 Oct 2012 09:49:07 -0700 Cc: Matthew Ford , "ippm@ietf.org" , "lmap@ietf.org" , Hannes Tschofenig Subject: Re: [ippm] [lmap] BOF not approved? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:42:37 -0000 +1, and it's an easy way to get started and focus on the work itself rather than process/logistics of a BoF or WG formation. Jason On 10/5/12 7:12 PM, "Matt Mathis" wrote: >+IPPM > >Consider doing this entire effort within IPPM. A protocol to >control measurement is absolutely in scope (See for example RFC 4656) >as are discussions about the choice of measurement vantage points and >requirements for measurement platforms, etc. Many of the topics that >might be out of scope for IPPM, are likely to be out of scope for both >IETF and IRTF, for example the design on a media specific link layer >control protocol probably belongs in some other forum entirely. > >For things that are on the edge of IPPM's scope and don't fit >elsewhere, it would be far easier to tweak IPPM than to spin a new WG. > >Thanks, >--MM-- >The best way to predict the future is to create it. - Alan Kay > > >On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne > wrote: >> I can't speak for all the LMAP participants, obviously, but I was >>hoping that the LMAP requirements I-D made it reasonably clear that at >>least our needs are primarily in defining a specific set of protocols, >>with the metrics being delegated to IPPM (or successor). Thus, this >>would not be a BCP, but at least experimental. If the draft failed to >>make the point, I have obviously some work to do... >> >> Henning >> >> ________________________________________ >> From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Wesley >>Eddy [wes@mti-systems.com] >> Sent: Friday, October 05, 2012 10:59 AM >> To: Matthew Ford >> Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; >>lmap@ietf.org >> Subject: Re: [lmap] BOF not approved? >> >> On 10/5/2012 9:55 AM, Matthew Ford wrote: >>> >>> On 5 Oct 2012, at 14:09, "Livingood, Jason" >>> wrote: >>> >>>> My original suggestion to a few folks (before this list was >>>>established) >>>> was to do this work in the IRTF. Perhaps we can arrange something >>>>there, >>>> even if an informal discussion of what is needed and how we might >>>>proceed? >>>> Failing that, a bar BoF would be helpful. >>>> >>> >>> I don't have a strong opinion about IRTF vs. bar BoF but I would >>>strongly support having a meeting in Atlanta to review the situation, >>>potentially hear more about requirements from others, and try to figure >>>out a (sustainable) way forward for this initiative. >>> >> >> >> Obviously some work has to take place to further identify what >> exactly people would like to do, and then the choice of goal >> for IETF or IRTF group would be more obvious, based on the >> desired outcome (e.g. standards or BCP work would indicate an >> IETF WG, or it may turn out that some work could fit within >> existing groups like IPPM). >> >> Until this is clear, I would suggest to just have a pure >> side-meeting. >> >> -- >> Wes Eddy >> MTI Systems >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap From henk@uijterwaal.nl Tue Oct 9 10:02:58 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64ED911E8145 for ; Tue, 9 Oct 2012 10:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 ftzq781iWwaj for ; Tue, 9 Oct 2012 10:02:57 -0700 (PDT) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by ietfa.amsl.com (Postfix) with ESMTP id 430AF11E810D for ; Tue, 9 Oct 2012 10:02:57 -0700 (PDT) Received: from geir.local ([193.179.210.194]) (authenticated bits=0) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id q99H2ONx090561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Oct 2012 19:02:25 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <507458A2.5040702@uijterwaal.nl> Date: Tue, 09 Oct 2012 19:02:26 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: IETF IPPM WG References: <50733A3C.90706@neclab.eu> In-Reply-To: <50733A3C.90706@neclab.eu> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <50733A3C.90706@neclab.eu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [ippm] Fwd: Draft Working Group agendas due by 2012-10-24 (Wednesday) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 17:02:58 -0000 IPPM Group, See below, the draft agenda is due in 2 weeks, if you want a slot, please drop me a note. This also applies to people who asked for a slot when scheduling the meeting, as some of the requests were tentative. Henk -------- Original Message -------- Subject: Draft Working Group agendas due by 2012-10-24 (Wednesday) Resent-Date: Mon, 8 Oct 2012 22:41:14 +0200 (CEST) Resent-From: Martin.Stiemerling@neclab.eu Resent-To: enrico.marocco@telecomitalia.it, vkg@bell-labs.com, dthaler@microsoft.com, dwing@cisco.com, flefauch@cisco.com, Richard_Woundy@cable.comcast.com, marcelo@it.uc3m.es, nanditad@google.com, pasi.sarolahti@iki.fi, tphelan@sonusnet.com, gjshep@gmail.com, matt@internet2.edu, henk@uijterwaal.nl, muraris@microsoft.com, rolf.winter@nw.neclab.eu, philip.eardley@bt.com, nishida@sfc.wide.ad.jp, beepy@netapp.com, spencer.shepler@gmail.com, zhangyunfei@chinamobile.com, sprevidi@cisco.com, lars@netapp.com, mirja.kuehlewind@ikr.uni-stuttgart.de, adamson@itd.nrl.navy.mil, lorenzo@vicisano.net, ttalpey@microsoft.com, black_david@emc.com, pasi.sarolahti@iki.fi, nishida@sfc.wide.ad.jp, michael.scharf@alcatel-lucent.com, jmpolk@cisco.com, rolf.winter@neclab.eu, gorry@erg.abdn.ac.uk, wes@mti-systems.com, martin.stiemerling@neclab.eu Date: Mon, 8 Oct 2012 22:40:28 +0200 From: Martin Stiemerling To: Hi all, Just a reminder about the deadline for the draft agendas: 2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00, upload using https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi Thanks, Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From henk@uijterwaal.nl Tue Oct 9 10:16:04 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4E511E814B for ; Tue, 9 Oct 2012 10:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 hGPO3rSApp8C for ; Tue, 9 Oct 2012 10:16:03 -0700 (PDT) Received: from smtp-vbr16.xs4all.nl (smtp-vbr16.xs4all.nl [194.109.24.36]) by ietfa.amsl.com (Postfix) with ESMTP id 35A8E11E8137 for ; Tue, 9 Oct 2012 10:16:03 -0700 (PDT) Received: from geir.local ([193.179.210.194]) (authenticated bits=0) by smtp-vbr16.xs4all.nl (8.13.8/8.13.8) with ESMTP id q99HFUrw056189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Oct 2012 19:15:31 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <50745BB3.5070300@uijterwaal.nl> Date: Tue, 09 Oct 2012 19:15:31 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: ippm@ietf.org References: <07F7D7DED63154409F13298786A2ADC9045920A7@EXRAD5.ad.rad.co.il> <3B05069A569E6F4AB6397B968734EBEA57A6BDA2CD@ESESSCMS0363.eemea.ericsson.se> <07F7D7DED63154409F13298786A2ADC904592261@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC904592261@EXRAD5.ad.rad.co.il> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [ippm] Microsoft's psping utility X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 17:16:04 -0000 On 09/10/2012 16:12, Yaakov Stein wrote: > Thanks to Andreas and Vinayak for pointing out additional active performance measurement tools. > > The reason I asked is that we are looking into progressing the Cisco SLA protocol to RFC. > If there are other tools that are widely used, then perhaps we need to document them as well. As far as I can see, this (and similar) tool just implements a metric, so I'd rather see that the documentation of the tool says that it measures metric X using the standard set in RFC Y. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ Read my blog at http://www.uijterwaal.nl/henks_hands.html From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Oct 10 08:40:54 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B5121F86C5; Wed, 10 Oct 2012 08:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=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 KWIVxkIoxc74; Wed, 10 Oct 2012 08:40:54 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3B321F864A; Wed, 10 Oct 2012 08:40:45 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5A712633B1; Wed, 10 Oct 2012 17:40:44 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 3187659A8A; Wed, 10 Oct 2012 17:40:44 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: lmap@ietf.org Date: Wed, 10 Oct 2012 17:40:43 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201210101740.43825.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: "ippm@ietf.org" Subject: Re: [ippm] [lmap] BOF not approved? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 15:40:54 -0000 Hi, at the beginning I though at well that this work might be in scope of IPPM.= =20 But after thinking more deeply about it, I'd say there is quite a lot of wo= rk=20 to do and this might be worth forming an own working group.=20 Then regarding a whole measurement architecture there might still be some m= ore=20 researchy questions but only focussing on the protocol(s) between the=20 measurement entities, I believe the problem and requirements are very clear= =20 to be addressed in the ieft. I would favor having a side meeting in Atlanta. From my point of view the=20 first step would be to get an overview on existing measurement framework to= =20 validate if the requirements listed so far cover their needs. If people tha= t=20 have designed or are administrating thus a framework are on this list and=20 would be willing to present their system that would be great. But I'm afrai= d=20 that there are actually a lot of small companies running these systems (e.g= =2E=20 webpages where private costumers can check their lines) and those people=20 might not be active in the ieft. Mirja =20 On Tuesday 09 October 2012 20:02:47 Weil, Jason wrote: > If there is agreement on initiating the discussion in the IPPM group, it > might be useful to request a time slot during Tuesday's IPPM meeting > fairly quickly to give an overview of the draft and gauge interest on work > areas. > > Jason > > On 10/9/12 10:42 AM, "Livingood, Jason" > > wrote: > >+1, and it's an easy way to get started and focus on the work itself > >rather than process/logistics of a BoF or WG formation. > > > >Jason > > > >On 10/5/12 7:12 PM, "Matt Mathis" wrote: > >>+IPPM > >> > >>Consider doing this entire effort within IPPM. A protocol to > >>control measurement is absolutely in scope (See for example RFC 4656) > >>as are discussions about the choice of measurement vantage points and > >>requirements for measurement platforms, etc. Many of the topics that > >>might be out of scope for IPPM, are likely to be out of scope for both > >>IETF and IRTF, for example the design on a media specific link layer > >>control protocol probably belongs in some other forum entirely. > >> > >>For things that are on the edge of IPPM's scope and don't fit > >>elsewhere, it would be far easier to tweak IPPM than to spin a new WG. > >> > >>Thanks, > >>--MM-- > >>The best way to predict the future is to create it. - Alan Kay > >> > >> > >>On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne > >> > >> wrote: > >>> I can't speak for all the LMAP participants, obviously, but I was > >>>hoping that the LMAP requirements I-D made it reasonably clear that at > >>>least our needs are primarily in defining a specific set of protocols, > >>>with the metrics being delegated to IPPM (or successor). Thus, this > >>>would not be a BCP, but at least experimental. If the draft failed to > >>>make the point, I have obviously some work to do... > >>> > >>> Henning > >>> > >>> ________________________________________ > >>> From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Wesl= ey > >>>Eddy [wes@mti-systems.com] > >>> Sent: Friday, October 05, 2012 10:59 AM > >>> To: Matthew Ford > >>> Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; > >>>lmap@ietf.org > >>> Subject: Re: [lmap] BOF not approved? > >>> > >>> On 10/5/2012 9:55 AM, Matthew Ford wrote: > >>>> On 5 Oct 2012, at 14:09, "Livingood, Jason" > >>>> > >>>> wrote: > >>>>> My original suggestion to a few folks (before this list was > >>>>>established) > >>>>> was to do this work in the IRTF. Perhaps we can arrange something > >>>>>there, > >>>>> even if an informal discussion of what is needed and how we might > >>>>>proceed? > >>>>> Failing that, a bar BoF would be helpful. > >>>> > >>>> I don't have a strong opinion about IRTF vs. bar BoF but I would > >>>>strongly support having a meeting in Atlanta to review the situation, > >>>>potentially hear more about requirements from others, and try to figu= re > >>>>out a (sustainable) way forward for this initiative. > >>> > >>> Obviously some work has to take place to further identify what > >>> exactly people would like to do, and then the choice of goal > >>> for IETF or IRTF group would be more obvious, based on the > >>> desired outcome (e.g. standards or BCP work would indicate an > >>> IETF WG, or it may turn out that some work could fit within > >>> existing groups like IPPM). > >>> > >>> Until this is clear, I would suggest to just have a pure > >>> side-meeting. > >>> > >>> -- > >>> Wes Eddy > >>> MTI Systems > >>> _______________________________________________ > >>> lmap mailing list > >>> lmap@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lmap > >>> _______________________________________________ > >>> lmap mailing list > >>> lmap@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lmap > > > >_______________________________________________ > >lmap mailing list > >lmap@ietf.org > >https://www.ietf.org/mailman/listinfo/lmap > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From Ruediger.Geib@telekom.de Thu Oct 11 00:53:12 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6665D21F870F for ; Thu, 11 Oct 2012 00:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmBaIZCnKCTX for ; Thu, 11 Oct 2012 00:53:11 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 968F621F870B for ; Thu, 11 Oct 2012 00:53:10 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 11 Oct 2012 09:53:04 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 11 Oct 2012 09:53:02 +0200 From: To: Date: Thu, 11 Oct 2012 09:53:01 +0200 Thread-Topic: Re: [ippm] Advanced Stream and Sampling Framework for IPPM Thread-Index: Ac2nhW+vddjUvGQaTZWOHzavWxShYA== Message-ID: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 07:53:12 -0000 Joachim, after reading your and Al's draft, it is not quite clear to me, what's the aim of the document as related to IPPM. RFC 2330 defines the following metric definition criteria: + The metrics must be concrete and well-defined, + A methodology for a metric should have the property that it is repeatable: if the methodology is used multiple times under identical conditions, the same measurements should result in the same measurements. + The metrics must exhibit no bias for IP clouds implemented with identical technology, + The metrics must exhibit understood and fair bias for IP clouds implemented with non-identical technology, + The metrics must be useful to users and providers in understanding the performance they experience or provide, + The metrics must avoid inducing artificial performance goals. I'd expect repeatability of measurements under otherwise identical conditions. If this is not given, measurements don't make sense. A measurement obviously captures performance only for the flow tested. Your proposal seems to be to add more randomisations in measurement flows. So far, IPPM recommends randomised inter packet gaps for some metrics. Does your document propose to add more randomisations, like eg. packet size or payload? You mention addresses as another parameter impacting measurement results. Further, the access to the network has an impact on results. Approaches to characterise expectable performance could be to apply different type-p streams and change chracteristics of them step by step. Or one randomises type-p streams more heavily (randomised inter packet gaps, packet sizes, payload, addresses, access type and so on). The latter will at some stage result in repeatable results only over sufficiently long time intervals (that depends on the number of randomised parameters). Could you clarify how you propose to acount for variability of the Type-P properties having an impact on performance? Regards, R=FCdiger From jason.weil@twcable.com Tue Oct 9 11:05:04 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7328B1F0CA7; Tue, 9 Oct 2012 11:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 vCkXSbJLbTjf; Tue, 9 Oct 2012 11:05:03 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 48CB61F0422; Tue, 9 Oct 2012 11:05:02 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,561,1344225600"; d="scan'208";a="432556016" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 09 Oct 2012 14:02:04 -0400 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.45]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 9 Oct 2012 14:02:40 -0400 From: "Weil, Jason" To: "Livingood, Jason" , Matt Mathis , Henning Schulzrinne Date: Tue, 9 Oct 2012 14:02:47 -0400 Thread-Topic: [lmap] BOF not approved? Thread-Index: Ac2mSEWjp6DwORGTQYizXqbZZvpOSQ== Message-ID: In-Reply-To: <10229F86C86EB444898E629583FD417118C7B367@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 11 Oct 2012 08:28:08 -0700 Cc: Matthew Ford , "lmap@ietf.org" , "ippm@ietf.org" , Hannes Tschofenig Subject: Re: [ippm] [lmap] BOF not approved? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 18:05:04 -0000 If there is agreement on initiating the discussion in the IPPM group, it might be useful to request a time slot during Tuesday's IPPM meeting fairly quickly to give an overview of the draft and gauge interest on work areas. Jason On 10/9/12 10:42 AM, "Livingood, Jason" wrote: >+1, and it's an easy way to get started and focus on the work itself >rather than process/logistics of a BoF or WG formation. > >Jason > > > >On 10/5/12 7:12 PM, "Matt Mathis" wrote: > >>+IPPM >> >>Consider doing this entire effort within IPPM. A protocol to >>control measurement is absolutely in scope (See for example RFC 4656) >>as are discussions about the choice of measurement vantage points and >>requirements for measurement platforms, etc. Many of the topics that >>might be out of scope for IPPM, are likely to be out of scope for both >>IETF and IRTF, for example the design on a media specific link layer >>control protocol probably belongs in some other forum entirely. >> >>For things that are on the edge of IPPM's scope and don't fit >>elsewhere, it would be far easier to tweak IPPM than to spin a new WG. >> >>Thanks, >>--MM-- >>The best way to predict the future is to create it. - Alan Kay >> >> >>On Fri, Oct 5, 2012 at 8:05 AM, Henning Schulzrinne >> wrote: >>> I can't speak for all the LMAP participants, obviously, but I was >>>hoping that the LMAP requirements I-D made it reasonably clear that at >>>least our needs are primarily in defining a specific set of protocols, >>>with the metrics being delegated to IPPM (or successor). Thus, this >>>would not be a BCP, but at least experimental. If the draft failed to >>>make the point, I have obviously some work to do... >>> >>> Henning >>> >>> ________________________________________ >>> From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] on behalf of Wesley >>>Eddy [wes@mti-systems.com] >>> Sent: Friday, October 05, 2012 10:59 AM >>> To: Matthew Ford >>> Cc: marcelo bagnulo braun; Hannes Tschofenig; Livingood, Jason; >>>lmap@ietf.org >>> Subject: Re: [lmap] BOF not approved? >>> >>> On 10/5/2012 9:55 AM, Matthew Ford wrote: >>>> >>>> On 5 Oct 2012, at 14:09, "Livingood, Jason" >>>> wrote: >>>> >>>>> My original suggestion to a few folks (before this list was >>>>>established) >>>>> was to do this work in the IRTF. Perhaps we can arrange something >>>>>there, >>>>> even if an informal discussion of what is needed and how we might >>>>>proceed? >>>>> Failing that, a bar BoF would be helpful. >>>>> >>>> >>>> I don't have a strong opinion about IRTF vs. bar BoF but I would >>>>strongly support having a meeting in Atlanta to review the situation, >>>>potentially hear more about requirements from others, and try to figure >>>>out a (sustainable) way forward for this initiative. >>>> >>> >>> >>> Obviously some work has to take place to further identify what >>> exactly people would like to do, and then the choice of goal >>> for IETF or IRTF group would be more obvious, based on the >>> desired outcome (e.g. standards or BCP work would indicate an >>> IETF WG, or it may turn out that some work could fit within >>> existing groups like IPPM). >>> >>> Until this is clear, I would suggest to just have a pure >>> side-meeting. >>> >>> -- >>> Wes Eddy >>> MTI Systems >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From mattmathis@google.com Thu Oct 11 18:53:42 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F0C21F848B for ; Thu, 11 Oct 2012 18:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPmcAg84194J for ; Thu, 11 Oct 2012 18:53:41 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9C10B21F8489 for ; Thu, 11 Oct 2012 18:53:41 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so74599wib.1 for ; Thu, 11 Oct 2012 18:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=fKHXDx6xWrWuzdCRFU+1V6bjaD9EOsEg/nl5C5T8bXw=; b=V3AMDe4fok0+oquInn6ggPdNegtAQoFWQldkWgrMrG7CA+rvtV+eXoBNM1VJi0ULRB kQMDZNhwjz7JJe2T0P6kbU02dGkxRTEq/mNs8b/NHgTC0hJl1Xr0JdixqyRgzDUONYyA qSuldvL/pGi980YFjCw0GkLGGS2BwZrvw12N5cKSSDBCnC7nHBOElMB5aY+insPiHVEL t2EgAE9YAxq0EHdq4g0FPxsIauw90aEYqBxI5yvHommYXy8EQ5L2UCIi2GZrfdif/XZD 4Vw6neil5y7ldhl7SpJ6YjE8oE1DC9rKUI3wX+VHEjK2J6I7t4bZ2NcEd1RwFuirCpBq 05XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=fKHXDx6xWrWuzdCRFU+1V6bjaD9EOsEg/nl5C5T8bXw=; b=owmkkjEDdsfq80dXILzpnfeLyk5NeIT0qroFEaGCxFv0CslLG+uc6GpoLxJE8eI4E4 9OBOvLdVEa+G/Jri2BoxqJ/bR0aawmF3QHvpA9ApwBNeiYJ5M9I4tYWr2EOyXkBcai0Q k9Oc3EMaw9ju6OdPXus/AAOo6ExZz9NknVM4y/neKIwghSzvjKmLCsLcZCr5hKXvaWMn 3Ij7cty8GinGZR1JfDeuZsTN8uYX0zFF/31yRFi18Swi/49XLzBuI7PrCTs1YLrLeYd3 dHKYZdQ+yCQlDGtGei3secWRfZpUyGuaIln6iKFKpTWy5yQimsvhXHoppcgCaUqaN6n0 rhlA== MIME-Version: 1.0 Received: by 10.180.78.40 with SMTP id y8mr2165266wiw.7.1350006820173; Thu, 11 Oct 2012 18:53:40 -0700 (PDT) Received: by 10.195.12.99 with HTTP; Thu, 11 Oct 2012 18:53:40 -0700 (PDT) In-Reply-To: <507458A2.5040702@uijterwaal.nl> References: <50733A3C.90706@neclab.eu> <507458A2.5040702@uijterwaal.nl> Date: Thu, 11 Oct 2012 18:53:40 -0700 Message-ID: From: Matt Mathis To: Henk Uijterwaal Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmOxGBLxZV7eQMfbxZ8YVRRNsHxwytLquorq3+PCJraiFXvz0Y+CUKajPLjnbXgnv0lm1+ZbEi+ELzuskNlcEvVcvZvS+LNYxYuj+GDrSD7fAkjX+pEWPiIzdOe14ycHUyPD9xVi/gfuVtrqYYVng4QdWHfK1W52t0ZQ7qQhRly/Mh9Yrd4ixvNGFnvQm/PWk5RZNR+ Cc: IETF IPPM WG Subject: Re: [ippm] Fwd: Draft Working Group agendas due by 2012-10-24 (Wednesday) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 01:53:42 -0000 I would like to request 2 short (10 minute) back to back slots to introduce two new Internet-Drafts. They will be: Model Based Internet Performance Metrics draft-mathis-ippm-model-based-metrics-00.txt Curating Internet Measurement Data draft-mathis-ippm-data-curation-00.txt Both are in the early developmental stages: my agenda will mostly be to recruit help. They will be posted on Monday. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Tue, Oct 9, 2012 at 10:02 AM, Henk Uijterwaal wrote: > IPPM Group, > > See below, the draft agenda is due in 2 weeks, if you want a slot, > please drop me a note. This also applies to people who asked for a > slot when scheduling the meeting, as some of the requests were > tentative. > > Henk > > > > -------- Original Message -------- > Subject: Draft Working Group agendas due by 2012-10-24 (Wednesday) > Resent-Date: Mon, 8 Oct 2012 22:41:14 +0200 (CEST) > Resent-From: Martin.Stiemerling@neclab.eu > Resent-To: enrico.marocco@telecomitalia.it, vkg@bell-labs.com, > dthaler@microsoft.com, dwing@cisco.com, flefauch@cisco.com, > Richard_Woundy@cable.comcast.com, marcelo@it.uc3m.es, > nanditad@google.com, pasi.sarolahti@iki.fi, tphelan@sonusnet.com, > gjshep@gmail.com, matt@internet2.edu, henk@uijterwaal.nl, > muraris@microsoft.com, rolf.winter@nw.neclab.eu, philip.eardley@bt.com, > nishida@sfc.wide.ad.jp, beepy@netapp.com, spencer.shepler@gmail.com, > zhangyunfei@chinamobile.com, sprevidi@cisco.com, lars@netapp.com, > mirja.kuehlewind@ikr.uni-stuttgart.de, adamson@itd.nrl.navy.mil, > lorenzo@vicisano.net, ttalpey@microsoft.com, black_david@emc.com, > pasi.sarolahti@iki.fi, nishida@sfc.wide.ad.jp, > michael.scharf@alcatel-lucent.com, jmpolk@cisco.com, > rolf.winter@neclab.eu, gorry@erg.abdn.ac.uk, wes@mti-systems.com, > martin.stiemerling@neclab.eu > Date: Mon, 8 Oct 2012 22:40:28 +0200 > From: Martin Stiemerling > To: > > Hi all, > > Just a reminder about the deadline for the draft agendas: > > 2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00, > upload using https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi > > Thanks, > > Martin > > -- > martin.stiemerling@neclab.eu > > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From mattmathis@google.com Thu Oct 11 19:35:06 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2359421F8514 for ; Thu, 11 Oct 2012 19:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbDf2c0G6HNi for ; Thu, 11 Oct 2012 19:35:05 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 532C721F8513 for ; Thu, 11 Oct 2012 19:35:05 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so132050wib.13 for ; Thu, 11 Oct 2012 19:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=hwLGO6fEJMFM15EptLF7wLhYvIhuMyMQdJB5dpzWax8=; b=PQoIvOo7Ji6huC5D+vyuqwaXkScr5I0e+NPmQ/hml1PDYVXGDj8VJtCgsyJwfvyZBk xGMAvx4h/w5+42jikZvNHvEvGiv6PGXcAY+TTn0rAC1sn6J7u5MJa35Y4hBQQ00LOFUd QLxCl6aOv/n+H0+tDy2lEV3UQC2d1oY8hB9DmKbbMxxCByNX1WQhZrQw1ZrtWTWhk+cN 1/5N3zxbP7a3U/jxQEKIuJJnDBAavOMvIPCxaRXnrVQ6AoQLGDMTm9i59/J/ev+THshV At7jOJXAzqQG6wP9tGRCJaKD8rLN4c/kv05mpKmxdV1aaQaZfN8oJuNSLMADE+ni726g vk5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=hwLGO6fEJMFM15EptLF7wLhYvIhuMyMQdJB5dpzWax8=; b=ODMQD5YeIKdfYi2K4DuPE2aQ5boYblVQWOrvKUCoirGemoDgjyYn+yY+FPfgT135sO gZC2JsLea2D3hhXKvdx5qy/LcPN2wsY+kusJiQcqi0IMkpYjUmJPKJOhX37453ZU2pN3 3LhCwpQ4/c1s4yfVcYfa1CVtmPWUhxE8tPFNi3uBzVlgPgXYCEGjXSwVVTOH5E5PkLOP kssW9TERtpcw6sP3eRBMCC7BWhqa7egTcIZO64PXaHLrfdWJCtV6RIVlngtHhqnLDfwm hIc98SWZyiR9BDeUX4yZYU15rwasiKQM0lKmIOLkmfDP6rwcoVswWKGh8vRAd8uNmvJt J4cw== MIME-Version: 1.0 Received: by 10.216.199.10 with SMTP id w10mr1678854wen.198.1350009304268; Thu, 11 Oct 2012 19:35:04 -0700 (PDT) Received: by 10.195.12.99 with HTTP; Thu, 11 Oct 2012 19:35:04 -0700 (PDT) In-Reply-To: <5072F59A.50507@tuwien.ac.at> References: <5072F59A.50507@tuwien.ac.at> Date: Thu, 11 Oct 2012 19:35:04 -0700 Message-ID: From: Matt Mathis To: Joachim Fabini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkXcKAHdMfg7pLPH2jblCW4WkGMOEZHyBvOkaW0RJadhLuz4Ee4/JYPLdcRN9zofyzD1XD46VDsXalfAwqX3siuXTnh/QU+t8aROjuE6G4rkfWas+NRgCPqetsCTAryUiGZyU4e7iz/HAj02yVuvMFt1BDH+kBHMUqDdxpPQabO/wOR430EhoqKvuscoIe1PZvfU67X Cc: Al Morton , ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 02:35:06 -0000 I think this is a really good start. You might want to add a general notion of "pre-load" which would be traffic sent before a test to cause the network to transition into an active or higher load state. Also perhaps a general notion of "test load bound" which defines the point at which a test designed to measure low power states might be at risk of causing a transition into a higher power state. One other item for 2330: in the list of metric criteria, we failed to include "actionable" - some of the existing metrics don't provide any guidance for somebody who is unhappy with the results. Although "actionable" might be considered to be a sub item of "meaningful", some existing metrics don't do so well, even though they have well defined meanings. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, Oct 8, 2012 at 8:47 AM, Joachim Fabini wrote: > Dear group, > > Following an initial contact on RFC 6703 (while in draft status) Al Morto= n > and me have started to isolate and summarize some shortcomings of RFC 233= 0 > with respect to active measurements (metrics, methodologies) in reactive > and/or time-slotted networks. As it turned out during discussions, today'= s > access networks implement optimized on-demand capacity allocation, such t= hat > several methodology properties (in particular continuity and repeatabilit= y, > but also extensibility) stated in RFC 2330, section 6.2, are no longer > satified. Our measurement results confirm these findings. > > We believe that the current status can be improved by defining an advance= d > stream sampling framework. There is an increased interest in these aspect= s > (IEEE P802.16.3 project, US FCC, European Commission, National Regulators= in > EU) and such a stream sampling framework can help. > > Al has submitted the first version of the document, available at > > > Any feedback to the mailing list is warmly welcome. In case you do not ha= ve > access to the referenced publications please contact me by email. > > best regards > Joachim > > -- > --------------------------------------- > Dr. Joachim Fabini > Institute of Telecommunications > Vienna University of Technology > Favoritenstra=DFe 9/389 > A-1040 Vienna, Austria > > Tel: +43 1 58801-38813 > Fax: +43 1 58801-38898 > mailto: Joachim.Fabini@tuwien.ac.at > --------------------------------------- > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From Joachim.Fabini@tuwien.ac.at Thu Oct 11 23:38:23 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6FB21F8450 for ; Thu, 11 Oct 2012 23:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 c+G3t1fYeFKh for ; Thu, 11 Oct 2012 23:38:21 -0700 (PDT) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9086C21F841E for ; Thu, 11 Oct 2012 23:38:20 -0700 (PDT) Received: from [128.131.88.241] (priamos.ibk.tuwien.ac.at [128.131.88.241]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id q9C6cAA8002801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2012 08:38:10 +0200 Message-ID: <5077BAD0.7080908@tuwien.ac.at> Date: Fri, 12 Oct 2012 08:38:08 +0200 From: Joachim Fabini User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Matt Mathis References: <5072F59A.50507@tuwien.ac.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Al Morton , ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 06:38:23 -0000 On 12.10.2012 04:35, Matt Mathis wrote: > I think this is a really good start. Thank you. > You might want to add a general > notion of "pre-load" which would be traffic sent before a test to > cause the network to transition into an active or higher load state. > Also perhaps a general notion of "test load bound" which defines the > point at which a test designed to measure low power states might be at > risk of causing a transition into a higher power state. The new stream and sampling framework is supposed to assess and define parameter restrictions which are likely to impact on (or improve) measurement repeatability in reactive networks (or other types of network which differ from the deterministic wire model which RFC 2330 silently assumes). Pre-load, a technique commonly used in today's 3G network measurements, is definitely one aspect. We have generalized this in the draft by the term "recent history" (alternatively precondition). There might be other preconditions which influence on results, too. Our main aim is to have the framework as general as possible. > One other item for 2330: in the list of metric criteria, we failed to > include "actionable" - some of the existing metrics don't provide any > guidance for somebody who is unhappy with the results. Although > "actionable" might be considered to be a sub item of "meaningful", > some existing metrics don't do so well, even though they have well > defined meanings. RFC 2330 defines extensibility, which (combined with repeatability) imo fits pretty much what you describe as "actionable". The solution which we are currently preferring is to find/define a set of metrics which can assess a) repeatability and b) extensibility of a measurement methodology. E.g., using measurement samples of one or two subsequent measurement scenarios (metric & methodology) as input, these metrics should provide hints if 1) there is a likelihood of repeatability and 2) we can extend measurement results to other scenarios/parameters - in the sense of metric linearity for a specific methodology. Perhaps even more important and easier to realize is a metric output that properties 1) and 2) are NOT fulfilled. We could circumscribe such meta-metrics as QoMM, "quality of metric and methodology". This is basically what the framework is about, assess the quality of measurements and propose ways how to improve it. regards Joachim > > On Mon, Oct 8, 2012 at 8:47 AM, Joachim Fabini > wrote: >> Dear group, >> >> Following an initial contact on RFC 6703 (while in draft status) Al Morton >> and me have started to isolate and summarize some shortcomings of RFC 2330 >> with respect to active measurements (metrics, methodologies) in reactive >> and/or time-slotted networks. As it turned out during discussions, today's >> access networks implement optimized on-demand capacity allocation, such that >> several methodology properties (in particular continuity and repeatability, >> but also extensibility) stated in RFC 2330, section 6.2, are no longer >> satified. Our measurement results confirm these findings. >> >> We believe that the current status can be improved by defining an advanced >> stream sampling framework. There is an increased interest in these aspects >> (IEEE P802.16.3 project, US FCC, European Commission, National Regulators in >> EU) and such a stream sampling framework can help. >> >> Al has submitted the first version of the document, available at >> >> >> Any feedback to the mailing list is warmly welcome. In case you do not have >> access to the referenced publications please contact me by email. >> >> best regards >> Joachim >> >> -- >> --------------------------------------- >> Dr. Joachim Fabini >> Institute of Telecommunications >> Vienna University of Technology >> Favoritenstraße 9/389 >> A-1040 Vienna, Austria >> >> Tel: +43 1 58801-38813 >> Fax: +43 1 58801-38898 >> mailto: Joachim.Fabini@tuwien.ac.at >> --------------------------------------- >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm > > From Ruediger.Geib@telekom.de Fri Oct 12 00:13:23 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3827421F84F3 for ; Fri, 12 Oct 2012 00:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V38RY44NTm13 for ; Fri, 12 Oct 2012 00:13:22 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 67F1021F84F0 for ; Fri, 12 Oct 2012 00:13:20 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 12 Oct 2012 09:12:14 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 12 Oct 2012 09:10:49 +0200 From: To: , Date: Fri, 12 Oct 2012 09:10:48 +0200 Thread-Topic: [ippm] Advanced Stream and Sampling Framework for IPPM Thread-Index: Ac2oRDQxHLjAvG37SKu9yLpJSVTXKgAAZs4g Message-ID: References: <5072F59A.50507@tuwien.ac.at> <5077BAD0.7080908@tuwien.ac.at> In-Reply-To: <5077BAD0.7080908@tuwien.ac.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: acmorton@att.com, ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 07:13:23 -0000 Joachim, Matt, I've copied in a section of RFC2330 below, which deals with metric design and result interpretation in the case of dynamic network behaviour. >From what I've read of Matt, his interpretion of Joachims work is to find load or usage conditions, under which network behaviour changes. The metric then is a load (and may be a RTT or other parameters)? One could of course characterise the perfromance by delay, loss and so on before that behaviour shift and afterwards. But the aim of these new metrics is to change network behaviour? I'm not an expert on wireless access networks. To me, repeatability of metric measurements is a very important aspect. IPPM should pick up this work, if the number of parameters having an impact on the metric is small enough to enable useful results. If however temporal background load, local weather conditions or other factors which aren't captured by the metric, have a signigicant impact, I wonder about the interpretation of the results. Regards, R=FCdiger ---------Extract of RFC2330---------------------------- Note further that, in practice, it may not be practical to know (or be able to quantify) the conditions relevant to a measurement at a given time. For example, since the instantaneous load (in packets to be served) at a given router in a high-speed wide-area network can vary widely over relatively brief periods and will be very hard for an external observer to quantify, various statistics of a given metric may be more repeatable, or may better exhibit continuity. In that case those particular statistics should be specified when the metric is specified. Finally, some measurement methodologies may be 'conservative' in the sense that the act of measurement does not modify, or only slightly modifies, the value of the performance metric the methodology attempts to measure. {Comment: for example, in a wide-are high-speed network under modest load, a test using several small 'ping' packets to measure delay would likely not interfere (much) with the delay properties of that network as observed by others. The corresponding statement about tests using a large flow to measure flow capacity would likely fail.} -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Joa= chim Fabini Sent: Friday, October 12, 2012 8:38 AM To: Matt Mathis Cc: Al Morton; ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM On 12.10.2012 04:35, Matt Mathis wrote: > I think this is a really good start. Thank you. > You might want to add a general > notion of "pre-load" which would be traffic sent before a test to > cause the network to transition into an active or higher load state. > Also perhaps a general notion of "test load bound" which defines the > point at which a test designed to measure low power states might be at > risk of causing a transition into a higher power state. The new stream and sampling framework is supposed to assess and define parameter restrictions which are likely to impact on (or improve) measurement repeatability in reactive networks (or other types of network which differ from the deterministic wire model which RFC 2330 silently assumes). Pre-load, a technique commonly used in today's 3G network measurements, is definitely one aspect. We have generalized this in the draft by the term "recent history" (alternatively precondition). There might be other preconditions which influence on results, too. Our main aim is to have the framework as general as possible. > One other item for 2330: in the list of metric criteria, we failed to > include "actionable" - some of the existing metrics don't provide any > guidance for somebody who is unhappy with the results. Although > "actionable" might be considered to be a sub item of "meaningful", > some existing metrics don't do so well, even though they have well > defined meanings. RFC 2330 defines extensibility, which (combined with repeatability) imo fits pretty much what you describe as "actionable". The solution which we are currently preferring is to find/define a set of metrics which can assess a) repeatability and b) extensibility of a measurement methodology. E.g., using measurement samples of one or two subsequent measurement scenarios (metric & methodology) as input, these metrics should provide hints if 1) there is a likelihood of repeatability and 2) we can extend measurement results to other scenarios/parameters - in the sense of metric linearity for a specific methodology. Perhaps even more important and easier to realize is a metric output that properties 1) and 2) are NOT fulfilled. We could circumscribe such meta-metrics as QoMM, "quality of metric and methodology". This is basically what the framework is about, assess the quality of measurements and propose ways how to improve it. regards Joachim > > On Mon, Oct 8, 2012 at 8:47 AM, Joachim Fabini > wrote: >> Dear group, >> >> Following an initial contact on RFC 6703 (while in draft status) Al Mort= on >> and me have started to isolate and summarize some shortcomings of RFC 23= 30 >> with respect to active measurements (metrics, methodologies) in reactive >> and/or time-slotted networks. As it turned out during discussions, today= 's >> access networks implement optimized on-demand capacity allocation, such = that >> several methodology properties (in particular continuity and repeatabili= ty, >> but also extensibility) stated in RFC 2330, section 6.2, are no longer >> satified. Our measurement results confirm these findings. >> >> We believe that the current status can be improved by defining an advanc= ed >> stream sampling framework. There is an increased interest in these aspec= ts >> (IEEE P802.16.3 project, US FCC, European Commission, National Regulator= s in >> EU) and such a stream sampling framework can help. >> >> Al has submitted the first version of the document, available at >> >> >> Any feedback to the mailing list is warmly welcome. In case you do not h= ave >> access to the referenced publications please contact me by email. >> >> best regards >> Joachim >> >> -- >> --------------------------------------- >> Dr. Joachim Fabini >> Institute of Telecommunications >> Vienna University of Technology >> Favoritenstra=DFe 9/389 >> A-1040 Vienna, Austria >> >> Tel: +43 1 58801-38813 >> Fax: +43 1 58801-38898 >> mailto: Joachim.Fabini@tuwien.ac.at >> --------------------------------------- >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From trammell@tik.ee.ethz.ch Fri Oct 12 01:38:24 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F0C21F8551 for ; Fri, 12 Oct 2012 01:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.766 X-Spam-Level: X-Spam-Status: No, score=-6.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 MKTYNA-eZ+-s for ; Fri, 12 Oct 2012 01:38:23 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 505FB21F8550 for ; Fri, 12 Oct 2012 01:38:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2B873D9314 for ; Fri, 12 Oct 2012 10:38:22 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ziJrfGYSH24Y for ; Fri, 12 Oct 2012 10:38:21 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-121-161.antanet.ch [80.75.121.161]) (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 D983ED930B for ; Fri, 12 Oct 2012 10:38:21 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Oct 2012 10:38:19 +0200 References: <20121012083122.13716.29945.idtracker@ietfa.amsl.com> To: ippm@ietf.org Message-Id: <65974042-2522-4E12-8CFD-1236DF60CF74@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [ippm] Fwd: New Version Notification for draft-trammell-ippm-hybrid-ps-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 08:38:24 -0000 Greetings, all, I've just posted a very short draft on hybrid measurement, more a = meta-requirements list and motivation than anything else, as a starting = point for discussion at the Atlanta meeting. Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-trammell-ippm-hybrid-ps-00.txt > Date: October 12, 2012 10:31:22 AM GMT+02:00 > To: trammell@tik.ee.ethz.ch >=20 >=20 > A new version of I-D, draft-trammell-ippm-hybrid-ps-00.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Filename: draft-trammell-ippm-hybrid-ps > Revision: 00 > Title: Hybrid Measurement using IPPM Metrics > Creation date: 2012-10-12 > WG ID: Individual Submission > Number of pages: 4 > URL: = http://www.ietf.org/internet-drafts/draft-trammell-ippm-hybrid-ps-00.txt > Status: = http://datatracker.ietf.org/doc/draft-trammell-ippm-hybrid-ps > Htmlized: = http://tools.ietf.org/html/draft-trammell-ippm-hybrid-ps-00 >=20 >=20 > Abstract: > Hybrid measurement is the combination of metrics derived from = passive > and active measurement to produce a measurement result. This > document discusses use cases for hybrid measurement using metrics > defined within the IPPM framework >=20 >=20 >=20 >=20 > The IETF Secretariat From Ruediger.Geib@telekom.de Fri Oct 12 03:14:24 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70B921F8501 for ; Fri, 12 Oct 2012 03:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSVHeMCsEon3 for ; Fri, 12 Oct 2012 03:14:23 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7B64221F8510 for ; Fri, 12 Oct 2012 03:14:22 -0700 (PDT) Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 12 Oct 2012 12:14:15 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 12 Oct 2012 12:14:11 +0200 From: To: Date: Fri, 12 Oct 2012 12:14:10 +0200 Thread-Topic: [ippm] Advanced Stream and Sampling Framework for IPPM Thread-Index: Ac2oXX6bB/o7dLvAQbKEDs4BTWdniwAA6duQ Message-ID: References: <5077E552.3070002@tuwien.ac.at> In-Reply-To: <5077E552.3070002@tuwien.ac.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 10:14:25 -0000 Joachim, thanks, I got most parts of your intents right, I guess. I'm having an issue only with the wording may be. Under otherwise identical conditions, a result must be reproducible. No matter which preload etc. there is, this must hold. If the same flow sees different metric results, it only indicates that conditions have not been identical. It's a pholosophical discussion, which events form part of "condition", one of which may be load history. What is new is indeed, that you propose to influence network conditions by a test stream. This is justified, if the measurement flow is not deviating significantly from any ordinary customer network flow, I think. Allright, I'll drop out of discussion for some time now. Regards, R=FCdiger -----Original Message----- From: Joachim Fabini [mailto:Joachim.Fabini@tuwien.ac.at] Sent: Friday, October 12, 2012 11:40 AM To: Geib, R=FCdiger Cc: ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM Ruediger, thank you for your comments. The point is that RFC 2330 does neither consider reactive networks nor preconditions (link history). When it was written we had deterministic networks (wires), but with on-demand ressource allocation performance of today's links depends to a large extent on flow state and history which is typically transparent to the user, being maintained at layers below IP. Router queuing is a topic in RFC2330 - but its impact on performance is minor compared to what current access links do - see below. Main difference is imo that user-generated traffic typically does not influence on router queueing strategies. But it does exhibit a huge bias on measurements in reactive networks, being main reason for huge performance variations. Please find some more detailed responses to your topics inline. Am 11.10.2012 09:53, schrieb Ruediger.Geib@telekom.de: > Joachim, > > after reading your and Al's draft, it is not quite clear to me, > what's the aim of the document as related to IPPM. > > RFC 2330 defines the following metric definition criteria: > + The metrics must be concrete and well-defined, > + A methodology for a metric should have the property that it is > repeatable: if the methodology is used multiple times under > identical conditions, the same measurements should result in the > same measurements. > + The metrics must exhibit no bias for IP clouds implemented with > identical technology, > + The metrics must exhibit understood and fair bias for IP clouds > implemented with non-identical technology, > + The metrics must be useful to users and providers in understanding > the performance they experience or provide, > + The metrics must avoid inducing artificial performance goals. > > > I'd expect repeatability of measurements under otherwise identical > conditions. If this is not given, measurements don't make sense. That's the statement of RFC 2330 and from a theory point of view I fully agree with you. But defining repeatability imo boils down to defining "identical conditions". My believe after some years in large-scale mobile network measurements is that in some networks types it is straight-forward impossible to create identical (pre)conditions. In particular this applies to measurements in reactive (e.g., mobile 3G) networks where the impact of external factors (radio provisioning, users in a cell, instantaneous own traffic and traffic history) outweighs most of the factors mentioned in RFC 2330 by orders of magnitude. E.g., depending exclusively on recent load history, the identical measurement packet can have a more than 100-times variation in one-way delay (20ms to 5s). From a theoretical point of view we could therefore conclude RFC 2330: measurements in today's 3G or other wireless networks do _never_ make sense because we can never reproduce identical conditions (except in a fully isolated environment). Don't think that the LAMP group is happy with this finding. Al and me have started work on this draft considering that it is useful to relax instead the "identical" condition of RFC 2330 which we can not satisfy, anyhow. Our feeling is that it is more important for black-box measurements to a) determine whether the network under test behaves deterministic or reactive, b) propose metrics for testing on irregularities which Matt has questioned (e.g., multi-modal sample distributions are a first indication of potential reactive network behavior) and c) provide guidelines and constraints that can help to improve measurement representativeness and repeatibility. I think that it is also a highly valuable result to confirm that results for specific measurement methodologies on a specific link do _not_ satisfy particular RFC 2330 properties and applications should be prepared to face non-deterministic link behavior. > A measurement obviously captures performance only for the flow tested. Yes. But nevertheless most measurements (consider LAMP) intend to obtain "representative" measurements - whatever this means. My understanding of LAMP is that they want representative measurements with respect to i) repeatability (from _user_ perspective this means: comparable results when a user maintains the parameters constant which he can influence on, e.g., measures the same flow at the same location using identical devices), ii) extensibility (e.g.: can (or can't) the user infer from his existing measurement results on the performance for a packet size which has not been tested). > Your > proposal seems to be to add more randomisations in measurement flows. So > far, IPPM recommends randomised inter packet gaps for some metrics. That's not really a proposal. In my measurements I have used orthogonal components of randomization in an attempt to capture a broadest possible, representative image of a network link's behavior. It's the point where we can start from in restricting parameters to increase determinism. > Does your document propose to add more randomisations, like eg. packet > size or payload? You mention addresses as another parameter impacting > measurement results. Further, the access to the network has an impact > on results. More randomisation might be useful to cover a wider range of possible network link behavior. However, the document is rather about defining stream constraints, reasoning about the meaningfulness of measurement results and discussing parameters which can influence on the result. Addresses have been mentioned in the draft to emphasize that we must be prepared to handle technology changes beyond what's covered in RFC 2330, which are transparent to the measurements. While in most cases such an access technology change should be detectable through IP adresss changes (case in which we could revert to distinct points of attachment/interfaces as discussed by RFC 2330), it is theoretically possible for a mobile operator to provide the same IP address after a device has switched from 2G to 3G or after it has changed the cell. Such a handover is transparent to the measurement process and significant effort is required to detect it (AT modem commands typically can help). > > Approaches to characterise expectable performance could be to apply > different type-p streams and change chracteristics of them step by step. > > Or one randomises type-p streams more heavily (randomised inter packet > gaps, packet sizes, payload, addresses, access type and so on). > > The latter will at some stage result in repeatable results only over > sufficiently long time intervals (that depends on the number of > randomised parameters). > > Could you clarify how you propose to acount for variability of the > Type-P properties having an impact on performance? For giving people focused on core network measurements an impression of what orders of magnitude we are talking about, please have a look at the attached x-y scatter plot which depicts HSPA uplink for a continuous 35-hour end-to-end measurement session: same location, same device, same session. (Just a kind of worst-case example, don't want to restrict discussion to mobile networks, although I consider the challenges in mobile networks to be higher than in wired ones). The measurement uses a stream based on two independent, uniform distributed random variables, one for delay (100ms-5000ms) and one for payload size (64 bytes - 1400 bytes): a random-sized packet is sent at random send time. Any dot in the figure corresponds to one measurement sample (50K in total). Depicted are 80% of all samples, the CDF reveals that 20% have delays higher than 200ms. To test repeatability we pre-compute and store the so-called measurement scenario in advance, i.e., we are able to measure the identical data stream again at a later point in time. The figure confirms that the link/network uses _massive_ flow state at lower layers. The proposed framework should give an overview and guidelines on how to tailor various stream parameters (which, as you propose, we plan to constrain incrementally). And if it is not possible to constrain sufficient parameters (e.g., because the network operator deploys a time-of-day depending scheduling) to be repeatable then the draft should provide metrics which can evaluate the results and warn. Factors which we have noticed so far to improve measurement determinism and repeatability are, e.g., constant (instantaneous) data rate and increased data rate. There might be many more for other technologies. Summarizing: I consider the requirement for "identical" conditions to be a major limitation of RFC 2330 with respect to real-life appropriateness. While being theoretically sound (and avoiding many complex discussions), this a-priori prevents measurement repeatability or extensibility in shared access networks with potential on-demand ressource allocation. Taken verbatim, the term "identical" conditions restricts the applicability of RFC 2330 metrics, methodologies and measurements to fully isolated, deterministic systems. Moreover, we could extend this to inter-metric dependency which goes far beyond what we expect to happen in wired networks: if the network drops a packet, the instantaneous data rate decreases, possibly resulting in the scheduler to reduce the capacity allocated to the flow. Therefore the delay for all subsequent packets my increase substantially. So we think that it's time to relax the "identical" condition and provide a framework which guides on meaningful stream parameter selection and constraints. Moreover, the framework should point out potential pitfalls and ideally propose tests (metrics) that can assess the quality of measurement results with respect to metric and methodology properties stated in RFC 2330. Finally, development of a stream and sampling framework can help real-time applications to perform better in reactive networks but, most important, beneficially supports some activities which are currently in the focus of attention (LAMP, 802.16.3). Regards Joachim From Joachim.Fabini@tuwien.ac.at Fri Oct 12 03:34:55 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77ED21F8551 for ; Fri, 12 Oct 2012 03:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 xpLcJVjNDPLJ for ; Fri, 12 Oct 2012 03:34:54 -0700 (PDT) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1F921F8545 for ; Fri, 12 Oct 2012 03:34:54 -0700 (PDT) Received: from [128.131.88.241] (priamos.ibk.tuwien.ac.at [128.131.88.241]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id q9CAYrTg007961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2012 12:34:53 +0200 Message-ID: <5077F24A.1070005@tuwien.ac.at> Date: Fri, 12 Oct 2012 12:34:50 +0200 From: Joachim Fabini User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <5077E552.3070002@tuwien.ac.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 10:34:56 -0000 Rüdiger, full agree. One short note on influence: the ideal measurement scenario in reactive networks is to have a real/prototypical application traffic and measure its performance on a specific network. Ideally you can then evaluate metric and methodology properties (repeatability, ...) and infer on network characteristics. Still, the question is (how) can we define prototypical/representative traffic and how sound is it to extend measurement results to other scenarios. The former one is imo not so much an IPPM question although performance depends on it (perhaps focus of LAMP?). regards Joachim Am 12.10.2012 12:14, schrieb Ruediger.Geib@telekom.de: > Joachim, > > thanks, I got most parts of your intents right, I guess. > > I'm having an issue only with the wording may be. Under > otherwise identical conditions, a result must be reproducible. > > No matter which preload etc. there is, this must hold. If the > same flow sees different metric results, it only indicates > that conditions have not been identical. It's a pholosophical > discussion, which events form part of "condition", one of > which may be load history. > > What is new is indeed, that you propose to influence network > conditions by a test stream. This is justified, if the measurement > flow is not deviating significantly from any ordinary customer > network flow, I think. > > Allright, I'll drop out of discussion for some time now. > > Regards, > > Rüdiger > > > > -----Original Message----- > From: Joachim Fabini [mailto:Joachim.Fabini@tuwien.ac.at] > Sent: Friday, October 12, 2012 11:40 AM > To: Geib, Rüdiger > Cc: ippm@ietf.org > Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM > > Ruediger, > > thank you for your comments. The point is that RFC 2330 does neither > consider reactive networks nor preconditions (link history). When it was > written we had deterministic networks (wires), but with on-demand > ressource allocation performance of today's links depends to a large > extent on flow state and history which is typically transparent to the > user, being maintained at layers below IP. > Router queuing is a topic in RFC2330 - but its impact on performance is > minor compared to what current access links do - see below. Main > difference is imo that user-generated traffic typically does not > influence on router queueing strategies. But it does exhibit a huge bias > on measurements in reactive networks, being main reason for huge > performance variations. > > Please find some more detailed responses to your topics inline. > > Am 11.10.2012 09:53, schrieb Ruediger.Geib@telekom.de: >> Joachim, >> >> after reading your and Al's draft, it is not quite clear to me, >> what's the aim of the document as related to IPPM. >> >> RFC 2330 defines the following metric definition criteria: >> + The metrics must be concrete and well-defined, >> + A methodology for a metric should have the property that it is >> repeatable: if the methodology is used multiple times under >> identical conditions, the same measurements should result in the >> same measurements. >> + The metrics must exhibit no bias for IP clouds implemented with >> identical technology, >> + The metrics must exhibit understood and fair bias for IP clouds >> implemented with non-identical technology, >> + The metrics must be useful to users and providers in understanding >> the performance they experience or provide, >> + The metrics must avoid inducing artificial performance goals. >> >> >> I'd expect repeatability of measurements under otherwise identical >> conditions. If this is not given, measurements don't make sense. > > That's the statement of RFC 2330 and from a theory point of view I fully > agree with you. But defining repeatability imo boils down to defining > "identical conditions". My believe after some years in large-scale > mobile network measurements is that in some networks types it is > straight-forward impossible to create identical (pre)conditions. > In particular this applies to measurements in reactive (e.g., mobile 3G) > networks where the impact of external factors (radio provisioning, users > in a cell, instantaneous own traffic and traffic history) outweighs most > of the factors mentioned in RFC 2330 by orders of magnitude. E.g., > depending exclusively on recent load history, the identical measurement > packet can have a more than 100-times variation in one-way delay (20ms > to 5s). > > From a theoretical point of view we could therefore conclude RFC 2330: > measurements in today's 3G or other wireless networks do _never_ make > sense because we can never reproduce identical conditions (except in a > fully isolated environment). Don't think that the LAMP group is happy > with this finding. > > Al and me have started work on this draft considering that it is useful > to relax instead the "identical" condition of RFC 2330 which we can not > satisfy, anyhow. > Our feeling is that it is more important for black-box measurements to > a) determine whether the network under test behaves deterministic or > reactive, b) propose metrics for testing on irregularities which Matt > has questioned (e.g., multi-modal sample distributions are a first > indication of potential reactive network behavior) and c) provide > guidelines and constraints that can help to improve measurement > representativeness and repeatibility. > I think that it is also a highly valuable result to confirm that results > for specific measurement methodologies on a specific link do _not_ > satisfy particular RFC 2330 properties and applications should be > prepared to face non-deterministic link behavior. > >> A measurement obviously captures performance only for the flow tested. > > Yes. But nevertheless most measurements (consider LAMP) intend to obtain > "representative" measurements - whatever this means. My understanding of > LAMP is that they want representative measurements with respect to i) > repeatability (from _user_ perspective this means: comparable results > when a user maintains the parameters constant which he can influence on, > e.g., measures the same flow at the same location using identical > devices), ii) extensibility (e.g.: can (or can't) the user infer from > his existing measurement results on the performance for a packet size > which has not been tested). > > > Your >> proposal seems to be to add more randomisations in measurement flows. So >> far, IPPM recommends randomised inter packet gaps for some metrics. > > That's not really a proposal. In my measurements I have used orthogonal > components of randomization in an attempt to capture a broadest > possible, representative image of a network link's behavior. It's the > point where we can start from in restricting parameters to increase > determinism. > >> Does your document propose to add more randomisations, like eg. packet >> size or payload? You mention addresses as another parameter impacting >> measurement results. Further, the access to the network has an impact >> on results. > > More randomisation might be useful to cover a wider range of possible > network link behavior. However, the document is rather about defining > stream constraints, reasoning about the meaningfulness of measurement > results and discussing parameters which can influence on the result. > > Addresses have been mentioned in the draft to emphasize that we must be > prepared to handle technology changes beyond what's covered in RFC 2330, > which are transparent to the measurements. While in most cases such an > access technology change should be detectable through IP adresss changes > (case in which we could revert to distinct points of > attachment/interfaces as discussed by RFC 2330), it is theoretically > possible for a mobile operator to provide the same IP address after a > device has switched from 2G to 3G or after it has changed the cell. Such > a handover is transparent to the measurement process and significant > effort is required to detect it (AT modem commands typically can help). > >> >> Approaches to characterise expectable performance could be to apply >> different type-p streams and change chracteristics of them step by step. >> >> Or one randomises type-p streams more heavily (randomised inter packet >> gaps, packet sizes, payload, addresses, access type and so on). >> >> The latter will at some stage result in repeatable results only over >> sufficiently long time intervals (that depends on the number of >> randomised parameters). >> >> Could you clarify how you propose to acount for variability of the >> Type-P properties having an impact on performance? > > For giving people focused on core network measurements an impression of > what orders of magnitude we are talking about, please have a look at the > attached x-y scatter plot which depicts HSPA uplink for a continuous > 35-hour end-to-end measurement session: same location, same device, same > session. (Just a kind of worst-case example, don't want to restrict > discussion to mobile networks, although I consider the challenges in > mobile networks to be higher than in wired ones). The measurement uses a > stream based on two independent, uniform distributed random variables, > one for delay (100ms-5000ms) and one for payload size (64 bytes - 1400 > bytes): a random-sized packet is sent at random send time. Any dot in > the figure corresponds to one measurement sample (50K in total). > Depicted are 80% of all samples, the CDF reveals that 20% have delays > higher than 200ms. > To test repeatability we pre-compute and store the so-called measurement > scenario in advance, i.e., we are able to measure the identical data > stream again at a later point in time. > > The figure confirms that the link/network uses _massive_ flow state at > lower layers. The proposed framework should give an overview and > guidelines on how to tailor various stream parameters (which, as you > propose, we plan to constrain incrementally). And if it is not possible > to constrain sufficient parameters (e.g., because the network operator > deploys a time-of-day depending scheduling) to be repeatable then the > draft should provide metrics which can evaluate the results and warn. > Factors which we have noticed so far to improve measurement determinism > and repeatability are, e.g., constant (instantaneous) data rate and > increased data rate. There might be many more for other technologies. > > Summarizing: I consider the requirement for "identical" conditions to be > a major limitation of RFC 2330 with respect to real-life > appropriateness. While being theoretically sound (and avoiding many > complex discussions), this a-priori prevents measurement repeatability > or extensibility in shared access networks with potential on-demand > ressource allocation. Taken verbatim, the term "identical" conditions > restricts the applicability of RFC 2330 metrics, methodologies and > measurements to fully isolated, deterministic systems. > Moreover, we could extend this to inter-metric dependency which goes far > beyond what we expect to happen in wired networks: if the network drops > a packet, the instantaneous data rate decreases, possibly resulting in > the scheduler to reduce the capacity allocated to the flow. Therefore > the delay for all subsequent packets my increase substantially. > > So we think that it's time to relax the "identical" condition and > provide a framework which guides on meaningful stream parameter > selection and constraints. Moreover, the framework should point out > potential pitfalls and ideally propose tests (metrics) that can assess > the quality of measurement results with respect to metric and > methodology properties stated in RFC 2330. > Finally, development of a stream and sampling framework can help > real-time applications to perform better in reactive networks but, most > important, beneficially supports some activities which are currently in > the focus of attention (LAMP, 802.16.3). > > Regards > Joachim > > From Joachim.Fabini@tuwien.ac.at Fri Oct 12 02:39:36 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A99E21F850B for ; Fri, 12 Oct 2012 02:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 IUmj4jjeNm9Z for ; Fri, 12 Oct 2012 02:39:35 -0700 (PDT) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id 60D1521F84E2 for ; Fri, 12 Oct 2012 02:39:34 -0700 (PDT) Received: from [128.131.88.241] (priamos.ibk.tuwien.ac.at [128.131.88.241]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id q9C9dWer024640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2012 11:39:32 +0200 Message-ID: <5077E552.3070002@tuwien.ac.at> Date: Fri, 12 Oct 2012 11:39:30 +0200 From: Joachim Fabini User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------050309090407010301040307" X-Mailman-Approved-At: Fri, 12 Oct 2012 03:38:10 -0700 Cc: ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 09:39:36 -0000 This is a multi-part message in MIME format. --------------050309090407010301040307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ruediger, thank you for your comments. The point is that RFC 2330 does neither consider reactive networks nor preconditions (link history). When it was written we had deterministic networks (wires), but with on-demand ressource allocation performance of today's links depends to a large extent on flow state and history which is typically transparent to the user, being maintained at layers below IP. Router queuing is a topic in RFC2330 - but its impact on performance is minor compared to what current access links do - see below. Main difference is imo that user-generated traffic typically does not influence on router queueing strategies. But it does exhibit a huge bias on measurements in reactive networks, being main reason for huge performance variations. Please find some more detailed responses to your topics inline. Am 11.10.2012 09:53, schrieb Ruediger.Geib@telekom.de: > Joachim, > > after reading your and Al's draft, it is not quite clear to me, > what's the aim of the document as related to IPPM. > > RFC 2330 defines the following metric definition criteria: > + The metrics must be concrete and well-defined, > + A methodology for a metric should have the property that it is > repeatable: if the methodology is used multiple times under > identical conditions, the same measurements should result in the > same measurements. > + The metrics must exhibit no bias for IP clouds implemented with > identical technology, > + The metrics must exhibit understood and fair bias for IP clouds > implemented with non-identical technology, > + The metrics must be useful to users and providers in understanding > the performance they experience or provide, > + The metrics must avoid inducing artificial performance goals. > > > I'd expect repeatability of measurements under otherwise identical > conditions. If this is not given, measurements don't make sense. That's the statement of RFC 2330 and from a theory point of view I fully agree with you. But defining repeatability imo boils down to defining "identical conditions". My believe after some years in large-scale mobile network measurements is that in some networks types it is straight-forward impossible to create identical (pre)conditions. In particular this applies to measurements in reactive (e.g., mobile 3G) networks where the impact of external factors (radio provisioning, users in a cell, instantaneous own traffic and traffic history) outweighs most of the factors mentioned in RFC 2330 by orders of magnitude. E.g., depending exclusively on recent load history, the identical measurement packet can have a more than 100-times variation in one-way delay (20ms to 5s). From a theoretical point of view we could therefore conclude RFC 2330: measurements in today's 3G or other wireless networks do _never_ make sense because we can never reproduce identical conditions (except in a fully isolated environment). Don't think that the LAMP group is happy with this finding. Al and me have started work on this draft considering that it is useful to relax instead the "identical" condition of RFC 2330 which we can not satisfy, anyhow. Our feeling is that it is more important for black-box measurements to a) determine whether the network under test behaves deterministic or reactive, b) propose metrics for testing on irregularities which Matt has questioned (e.g., multi-modal sample distributions are a first indication of potential reactive network behavior) and c) provide guidelines and constraints that can help to improve measurement representativeness and repeatibility. I think that it is also a highly valuable result to confirm that results for specific measurement methodologies on a specific link do _not_ satisfy particular RFC 2330 properties and applications should be prepared to face non-deterministic link behavior. > A measurement obviously captures performance only for the flow tested. Yes. But nevertheless most measurements (consider LAMP) intend to obtain "representative" measurements - whatever this means. My understanding of LAMP is that they want representative measurements with respect to i) repeatability (from _user_ perspective this means: comparable results when a user maintains the parameters constant which he can influence on, e.g., measures the same flow at the same location using identical devices), ii) extensibility (e.g.: can (or can't) the user infer from his existing measurement results on the performance for a packet size which has not been tested). > Your > proposal seems to be to add more randomisations in measurement flows. So > far, IPPM recommends randomised inter packet gaps for some metrics. That's not really a proposal. In my measurements I have used orthogonal components of randomization in an attempt to capture a broadest possible, representative image of a network link's behavior. It's the point where we can start from in restricting parameters to increase determinism. > Does your document propose to add more randomisations, like eg. packet > size or payload? You mention addresses as another parameter impacting > measurement results. Further, the access to the network has an impact > on results. More randomisation might be useful to cover a wider range of possible network link behavior. However, the document is rather about defining stream constraints, reasoning about the meaningfulness of measurement results and discussing parameters which can influence on the result. Addresses have been mentioned in the draft to emphasize that we must be prepared to handle technology changes beyond what's covered in RFC 2330, which are transparent to the measurements. While in most cases such an access technology change should be detectable through IP adresss changes (case in which we could revert to distinct points of attachment/interfaces as discussed by RFC 2330), it is theoretically possible for a mobile operator to provide the same IP address after a device has switched from 2G to 3G or after it has changed the cell. Such a handover is transparent to the measurement process and significant effort is required to detect it (AT modem commands typically can help). > > Approaches to characterise expectable performance could be to apply > different type-p streams and change chracteristics of them step by step. > > Or one randomises type-p streams more heavily (randomised inter packet > gaps, packet sizes, payload, addresses, access type and so on). > > The latter will at some stage result in repeatable results only over > sufficiently long time intervals (that depends on the number of > randomised parameters). > > Could you clarify how you propose to acount for variability of the > Type-P properties having an impact on performance? For giving people focused on core network measurements an impression of what orders of magnitude we are talking about, please have a look at the attached x-y scatter plot which depicts HSPA uplink for a continuous 35-hour end-to-end measurement session: same location, same device, same session. (Just a kind of worst-case example, don't want to restrict discussion to mobile networks, although I consider the challenges in mobile networks to be higher than in wired ones). The measurement uses a stream based on two independent, uniform distributed random variables, one for delay (100ms-5000ms) and one for payload size (64 bytes - 1400 bytes): a random-sized packet is sent at random send time. Any dot in the figure corresponds to one measurement sample (50K in total). Depicted are 80% of all samples, the CDF reveals that 20% have delays higher than 200ms. To test repeatability we pre-compute and store the so-called measurement scenario in advance, i.e., we are able to measure the identical data stream again at a later point in time. The figure confirms that the link/network uses _massive_ flow state at lower layers. The proposed framework should give an overview and guidelines on how to tailor various stream parameters (which, as you propose, we plan to constrain incrementally). And if it is not possible to constrain sufficient parameters (e.g., because the network operator deploys a time-of-day depending scheduling) to be repeatable then the draft should provide metrics which can evaluate the results and warn. Factors which we have noticed so far to improve measurement determinism and repeatability are, e.g., constant (instantaneous) data rate and increased data rate. There might be many more for other technologies. Summarizing: I consider the requirement for "identical" conditions to be a major limitation of RFC 2330 with respect to real-life appropriateness. While being theoretically sound (and avoiding many complex discussions), this a-priori prevents measurement repeatability or extensibility in shared access networks with potential on-demand ressource allocation. Taken verbatim, the term "identical" conditions restricts the applicability of RFC 2330 metrics, methodologies and measurements to fully isolated, deterministic systems. Moreover, we could extend this to inter-metric dependency which goes far beyond what we expect to happen in wired networks: if the network drops a packet, the instantaneous data rate decreases, possibly resulting in the scheduler to reduce the capacity allocated to the flow. Therefore the delay for all subsequent packets my increase substantially. So we think that it's time to relax the "identical" condition and provide a framework which guides on meaningful stream parameter selection and constraints. Moreover, the framework should point out potential pitfalls and ideally propose tests (metrics) that can assess the quality of measurement results with respect to metric and methodology properties stated in RFC 2330. Finally, development of a stream and sampling framework can help real-time applications to perform better in reactive networks but, most important, beneficially supports some activities which are currently in the focus of attention (LAMP, 802.16.3). Regards Joachim --------------050309090407010301040307 Content-Type: application/pdf; name="test-3G-2012-06-14_2-i100-5000-c50000_UL.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test-3G-2012-06-14_2-i100-5000-c50000_UL.pdf" JVBERi0xLjQKJUltUERGLTAuNwolx+yPogo1IDAgb2JqCjw8Ci9TdWJ0eXBlIC9JbWFnZQov Q29sb3JTcGFjZSBbL0luZGV4ZWQgL0RldmljZVJHQiAyNTUgPDg0MTU4MjcwOTJmMzBmNGUx ODgwMzVmMjUzZDRiM2I5OGM0ZDQ5ZDg2MjBlYjBmZTA0Y2I0MWU4ZDM0OTAzMWUwNWU2ODU1 NmY0YzVjMDM0OGQ0NjBhOWUxNjJiMmY0NzkzMDE3OWI0NGNlMGU4ZTJjNzJlY2UxOTM2ZTM3 ZTA4Nzg2MWM5ZTA4Mjc0YWIyYWU2MTdjNmVmYjgwMjlhMzE4NGM2NmY0NDg1NmY1NjcwODJi ZTJkOGVjN2YwNGYzOThhMjVhZjM4YWYzMjY5MTc0MDRiMWFjZDZlMjZkNzc2MmNlM2QwNjcy MjNiMWIzNWNiYzBmNzg4MDA4ZDUyZGUxZjI1ZWZkYjAwZTcwYmFjY2Q2YTkyZjQyNGNlNGU4 MmVmZDFlNTg0OWE1NTc3M2ZiYjVjMzZkMzhjNDU3ODM1MjI1MzFjZjgzNjBhMTdkMzY1OWFi MTU5NzRlMDU5OGUxYmU5ZDMwNDU4OTY5ZjdjNTgyM2Y4ZTFmYzJjZTg0NzI5MTczYWM1ZWFk MDFkZDE2MDI5MDVlYzVhMjQxZTlkN2IxOWU5OGE1Y2EwMWI0OTJkZTE2MjE0YzAzZDNkM2Nh ZDkzZjkxM2QyOGM2ZWZiZTI2NTVjNjg2OTEyYWY3MTNmMzFmMjNkYTk2YjNjMTk4YWM2MGM5 Yzg4MjExMjg3MmFmYmFlY2NkM2JlOTZhYThhMTE0YWMxOTI4Nzg1MWY2N2I3ZWViODNmNjdh ODliZTUwM2UyNDU3NDlkNmFjNDA5YzI5M2E1MWI3MWY1MmIwZThkNDdkYmUyOTg2YzcyNzVk YWM2MTRmODJlODM4YzMxZWVkZmU3ZDNhZjQzMWU0MThkM2RhMGI5YWM3MzEzYTFhMjQzOGFl OWZjZWQ2MjRmZmQzZDQ5NzY3Mzk5ZmZlMWRlYTBkOTYxMzQ5Mzc4Y2Q3NjA2NTdmODI4ODQ1 MDM3NWY1NjFiODg5MDMxZjBkYTRlZDgwNDg5NmU5MmMwOWRmZGMzYWIwYWUxNWMyMDI4ZWNk N2M0NmQ1MWY2NDFkN2RlNTRlMmI1M2JhZjFhOWU4M2Y3NWE2MWM0ZWU2NDBkZWNmOTMyMGY4 ZDdlZGYyNzU2Mjk2MjRhNTA2NWYyNmRkMTRkMzBiNjVjZDk0MDc1NmJkZGI5Y2EyMjM1YTUx MzdjNzIzMWZiMzA0ZmRkYmJiMTU1NTYzMjA0MGM4ZjQ0NTZhNzAzZTdlZDY2OTM0OGNlZWRk MDUxOTVkYjVhZWJmNTkwYzJlNmVjYTQ4Yjc0MTM2ZmYwY2M4NDZlZDI5MGI4Nzk0MjQ4NmRk ZTlhNDEyMTMzNDk3MTQ4ZTFmMTRhMTVjYjFkOGMyOTAzZjQwYjFhZjcwM2M0YzVlZTA1Y2Rm Y2E1NmQ1ZjE5OTY5MGQ2OWVmZTlkZTk3ZDUxZTZlZDkzYWRjYWEyYTQ4NDMxNGNlNThkYzM2 YmU2MGM4NGRjOGJiNzNjNDc5NTFiOWUxODMxMzMwNzM3OWNjNThmNWMyYWE2OTg1OWEzMDhl OTAyYzM1OGMwMDlhOTgxOTQ3ODczYjYxMTcxZDgzNTFmZDM2YmZiODMxNzBiNmEwMjhlZjA2 Y2I2ZDMxZGZmNzk5OTVjZTQ4NWZmNmM2Y2RlMDY2ZTA2YTFlZTY2MjcyMmFjZmIwZmY2ZTk0 ZWYxMTE3YWUyNzlmZTJlMjcwNTQwZmFjYTg0OGRlMzlkN2RhNGViYjYxNjQ0ODI0Yjk4M2Ri M2NlMmNjMzczNjQyNDVkNTYxOGY4ODhjMWY2MWFkZTZiOTA3NTRjOWVjYjU0MzBhMDc0N2I3 ZWRlYzUwMjY2ODkxZjIxN2FhMjlhNWM1YTg5YmU5ODU3YjFiN2Q1OWZmY2E1ODBhMGViMmM2 NmY4ODM1OGZkMDY4OTFlZGViZjNjNmQ1ZGY3ODE5ZGQ1YzE4YmMwOTIwMGEzNGQ1ZDE0Yjhl YTI0ZmUzYzNkNzMxODljYjY3MmFjMDE0M2I5Y2IyM2MwM2Q5MjlhMzZlNDllZGU3MGQ2NTM5 Njg3MjdlNz5dCi9CaXRzUGVyQ29tcG9uZW50IDgKL1dpZHRoIDEyODAKL0hlaWdodCA5MDAK L0hEUEkgOTYKL1ZEUEkgOTYKL0ZpbHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aCA3MTgwMwo+ PgpzdHJlYW0KA3aRLflpTMa028ZheNhWA+vDdvNxKmhCUZXBPbzuJWGZopZA/AwAoAUlAlu6 +psvAiM8wNoyzal7WkZ2QgpTEizZGELH5acdj5Cdc1cKd0HP46RTzVSKSCcgt/pv7SGw5NZn neSlSIc3UOJwmUpZV9tWu47wj3Lf5dRzrPhO97139LKei5Um9oZ9Yd1Da9P4tWVyVTib5TDm BoI7XefwOfqVRrOhJLVp7kJN/NQbd1MOkkWp/Wf3V3oUmmGrhrqjRQIU9nr2spBU2/8zU3Dj nhQMuj34LoHNBdnz4+5tmpVSb/79+wlF31I+fHh4MIoFQf+IPdctN0S3FlL98gMXGQuZFLhF vMyeNukvT9GII2u1gdr2X1PlaZ/8CWUr/zWLa0708vXsr0s475atAzhZ+hUbBc536VZjDB8Y HDBF3QGvNGP4AcSiseTdavfdOJaygIs5sW17gtUfJC1JRBvPzKWnpOhsllcWgZ6MNFGYpvee 8H+BAni/mmlyE0QeDqLHM4K4HyAJTikGfBEds4ZA40HMK0+eHNmhbA1bd4Sbg8TTNfaANLgs bYOqjvLz189tj1x1hMeDZmSFaPS0cCZih0/+hdk0bvB++qv3M8ux0vuZbJJRL1wcpfMphD2a DQbO/wWS88ibBIxoDxGT6pLNR6CODpspsFYZbsD0cEwWQZ8XJWB9xTkzGri8cGMqeHdlouoc Yi7zo+NWzUZVk04M510K2tu9Je/cJWHbI/nXxGEczJGwaKE4c6tHdzocXHtTGGcGh/6e2lWf 6okBmzjGYG1bWiq5jCa4fiVF96Tj8eo3Oyu34o5NeHJDOZ+kQo3ocQLuQN3bhuX8EANtAnRh IJj8kzIO2KCKVXsahZHWk3Gpf+Gr8NSdAnNl8KzwEfVlsi7sysAdiBjdfcHBJsC9qH8MHpCu RaOqDLfF185sEAwEorNSz3/3OPhRA1NzjZdleYCvxX02NCRsIA1o31Sjka4kxSEKS+T6w9L5 z+vbLWGLyW7wwSkbvE1YGvNnrtuMR1Psi/EfhqsMvlbDXIQ1qaPnoWXvJY8CF+k0OzaXVptL P371oU/vtLGs27yNAaVapPUH9OEVFnu5Uv9/zQN7zm6XupbEUWMMKfPIHF7dGml5tvYjMU8B 3WhvgnFCzOIooCjGJbyvCgvQr+jy9xhwUhx2MYxExo9Uk3aG3fuq10vrZrAsJVop6+7xNH5n Tfi+tSDqNigvZNQo4dNGbeShI2wYCpLOShdIWZU9oFZJ0fUG6XicnTv1W2UvhuOJhtI+cwVy h2lMDSHW1HOs9d3OWfJOmum0saWdufpDdpgcifv0/uQetEOWvTUYuqhs9q7He5YugZCyl9jw REa0zI5p31Y+JCuBW7IWSINUl6tiuo3Ndgq9f6FZathNjg5XNfwj3xmU+5BdxgVT9nUlaHJ3 KuXhelvA/rYCcy+NQRtAufZ7Y3nl40hNoI3u47TFcATMg3gvauDI2Aqb8HnEJ76Owu+cZLdE 0TBlY3C1241bOdm4nGy9WGPlb3pXgy/3u1yhZMhVVnQLqfzB3CpHlVbOT2YP5J9lPDmphBCy 439aeVOZ2cm/oLW63RePmbCQzo8FWOGVtRssSkBrw7+dWfDYpaJzlxMN1sMU94hEdg2zVyFi mECtDnT+cvPa7szua6GQEVaBiHCznCNeQ+Kdv2d0B7uli4X7b/fST4fsZ1yOG/brvi1iYRUX fsgxLqsgsoUMs38W8fAdPSW4u3AizSUJ5PVsCfyd6GgH5LU8gLxSLn1B3u2h8PrufDWNTpA+ WUhVXGjKO3+bARzTCXTU+P2PccZdq7ok01Cfqk3zNPMh5ddfTadJimniYtYuEd6KgRdVLAFK N/FQtvXTzypCTKjINb7Wq4EH//p+3KChDLLWDFu4JUfzIE6GV93rfksjjlNN8lrDri1KXa2j eUn1o18sZY4EMcR4c0axXNkEB9MSi5RYUxL2bd4nt3vqlRvfwqIKL20f8A4xwMCwuAl5EiQY W60FBo6IsbZZieo6vvO2qprF3St0on9ygAGmhWvBSNWHidfy8PP4LiiphY89mDM09QPkOZh8 cq1a7BUN2d1pfyQPzD0YleusgYmwMbE+sTmOhEKmwhy0KYCsnkfxfkv1i6GN8cQwN/TYPV2E 9ExzFtfr3YpPnXuDJUFU0wX2GQl3MsPdj+YF9N/ZGbjOkKlfLO8PzXARFBHSdtMZPSXatj6C MHbEs9zq5E8N/vbqcYYI3vx5SUjl1qZgbrYZ/i0qYvqsXjVSs+Erc0GGbTnBIaSLAdJsH2Lv GiVNRO0+5UrPjOC2/M6rQ1oP/tLK/IG3aMPwEZviN15BOnEpRIJmWr83xAwhiztjJG+8Blxt rw6JlcAD8ohuca9tU9cLaegp0MDSiCjcRrFdb0qLfGk0Z/YrwQcQiPiSZ3zvZ4pIEHeH8BPk TZjAaxFLsy9w//2Vm7qc0bGl7ncALkJ+KFEVsEUlj+JuuLQn7B/unPUjBByUzM7O2oJsiyAa p+jyU1aNMFzSbFZ/2BhThoAc5LBuT+rPkUm7HbTT886n6y1RioDqB62lUZ0Pn49uUKK5vt33 ABTQ7zDWqDHmrEd/BfLL9JH+gDkTqmGQ9O+xP1Ifyjv5OkfTKAuBB6uppyssAajC3jSZQsuP ie7/Tqtq8nA4+JVGAkzUXFOkI23zsx6K/RLAcYaEV2SoTzgVOEIVpLgOwpyz88TeaJpWo7PX JG0J47YBIYOVPVaahSeN5E92pn/ioi331XD+FPxneH8J9Baja+6fuD872fFHR/eDmnA5wCL2 NN/jHwHR7OHtSc5sVPvBdSKPjrFHuXIIQc5JXGftnPIwt8RmLstK137V+v71jISYwk22cRdS X/FHNtyzJth+qs1az6EqftsxTqYw2e1w6EVbYZqOTL0e7ngwoIGU6AMGopgWN7J2JfbbBFTV cL/rxSbEtuQZ5sddGWh7uKqQ+o4zV0vUPsoHY+jKl9HPhcEYrHGBCx3rPV5qAtMlQD1+s3Hb 3+fN6EjBCpYT00X8j4IebuPbtyBnG/ryXnZe98hAs2Hiy6KMz4cExDEyRqtP1UTfYbHZUjtB UvyaXe0boT2rZ3uHxt5xftVt+nImLDuBRYOpGDOAMpXccgG8PWZZCfo8pRFgwy2t+WZHXW45 /nree6QAf+woL3vTRiE1c6v8qR15wsD1Mhs5Y/whWhBIro6zv3kEi6ZvVRkyjWh9oetYIW6O GOcWDcMjXt5nNhps4EiJhrdbW/llocfEtDoGtBhiTGX29QNPnvo2gxLhBu4r22Dv1WiCd+OZ RZ3ku0zBh65xVH9UJ6ocucD9VD4zomiBLAv10NqNidn4qwwT0jSBAqsOdhM3N2ERlvwUdShs 3ifQDRyipRUyWCDBxQ1tybcA1yuZtkaZmApQr3m9TueJnfiMhJ6dx/IiBwRvHFvft26z5mbl 3Fr+ZJON466zgWc9RnXqNwvlHMLrYfPEXD76DLPwSb6lABuMeZr7320MEkPjznwDonbAk0m7 eQe0awX1vzDtNMnaxWByvfurvfw+wadV4gIcyCICbt/n2yTKug1G+J5XQyBl0fZ8va2xe4ep 0s8W7rQnyiXklqkXMuGTOkVO8C01t6aqycTIbBo9a8VNpAsFVo/wdoK6XG1ugWpn4OHszX9v uFtAysDtJY1vsn/RwafDJqj8CisX7oJ3ZE2XehwDz+Rdq++aEPK/w6KmszOWft6o6zThLc1Y wuOj7DXsxu5ho40ZxEvOb86pCTA78oL6kuHpw4gg5DjO7XnXhJ2mfH8trA2TYuFHcf1Gf4Fg 4tq9AZBEKgZLdbHvAkyo8GA9gUS8ao5Ume6VSeq2VoUuMt5b90gmndSX6BLmbmAMFIlVG2am Nfo9NDK6DDz6CFwmVOX6zQtGQ/jWjjmixTdRtJiQb7nrHS/p3UedSMgpGFVcChomRspXY/tw xio+gCcqFiFKieTWjfpSX6WUl4Q0arw0325eEyGCcPgZiN1AWsRhooOKwhfqyRKEl7ZUI9r5 JczjCE6Ss5/5Y2aCKSNHzAa0Hjp0cRiAuinV3fp+H4SYxk3vPjTown+1FQUxBUphmz3UF3+H fwSWrtMPQxwd1NKoa3g9MqgB+pEoyrvrIFDlvHEphOpWL6kQwe/HKTj0lJH30Q/JamBYYow+ 2PquO7fvSkUy3sKvaXx/1EVKzoe7QCRaG+tD3xWxFYQVoz5mSJ0VhemnbZYPYmqILAJXzFMV FGbhp4zKHISQtrUfarVfFKixAQiuD2apw5r5No9cn+U49a1EbJedbsYFscE04makKNs4RLl2 /VsQ0pPvNHZ/MsXfOOlqFGttLYFEfXhRPpKtVIVkFbtJ+v5u1m88Cw2fFEniE6kOK1RXA5kj 2YfcpN45ncDgFMSnNz+/POcKps05j83AMSQ8Nb/XcUbZCYVIMAgCSb/6dDFZ0HNctEdVZVPb SEUrggbZwMWC7O0Fv4ZRUx8WY82msTabGrEs1QbGi/YDkiZjOajzAHJ6yuhC7N/A+ZOMsrHu IBzl0yn4uoo79/mZgfAR5kdHcD8oKH6npIUYz7f2t4+zZCgTepOYLhICsTcxMeE834EpFHx4 VzAY6UUf1vy7nbi4CX06QggGR9+VurBbd3uPbAvw5HGI/V+E5XTCm8+7RDCW7DlmA86ADkDP OF+sue4fpAiScEdXadKu1teEoLekM4gHlaN4j2wVG6hjpMgSFzVfLF1NqTuMLOWu2e0wb3nq qL8u4MJ5vEt1Yx1ooqh/l1qyx7dmIhFhsL6ZQr/yWHCQogOPIQQbghoGtAr8VDYYjpOWnJ6f xvOvDsDUApwNGWy3D9S8lRtfOXJalxnavcFcnR4BK6bX4IgoBD1XlGAY9utlAlAaFwangisa SjsZqzBr1stQS64fiprlQgJ9/Y8fuaob7++EgrM6yueJJkci+edhuOcgrkM8wR6PrJHZVSBd 6eN67plu+uMBuF8VoIn10vyaKJ658GgJILsF7vKzKnHNPZ7dfFF7PNYzFEjqGsabciODNDzx B1X9DHpsIXmlsfMvmJVbeqQlIH2PSO5l11sqdeE8PvA96LR14E0iDXsxJCcJYQOoPK/Mig0J gF/WDi522kA48E5WSWdB5A4QidCaf++S3zgxuchONPDPzvrLbE4vXAMyDQKVyXGLkGhT/2ji wZgsAox6PaV31eD2RzmexLELWxkhb+OzsxNcAOASOpldAH4SGIDtczltzwrMJCbyhyVuNzD3 OIikKYG2T/pAnHJ5qJ6EEypJyt87G3TPsv7FtW3l9RuxVs3ODNdF2UriJIbot0fIEf1iAkV7 BA7dB1HsbevRwclGeE8YNnRUx+T7hR/+JH6YgPKknNOU6kczUDd6pus/zCIRD8eMQ1DKXKN/ Uj3TDobR5XtfCo2F/2ea34LBcZUm+IdC80PQRPd3qEYhQuRF6kzlWgWyUw0n8OqOeHO8UIhh /E36K0nhf2SMQRzETpQnU9Ac/vZ1VRHiIrKMb4M3rfu7OXTeB233dsB/DQGtxb3WG3sDnJLC IHRhZkpfu7UbzQCTLVTajIVjceVvQxwGFMYrslKZy0Kv5tSjHQ46DgrGlU2ibINToYdns6Ye ao1oVWvqM9WZVW2ZKgFBiTi9GN/c2y2VN7apFw4rRXzJOaE/01xHTsrE0Vl3FLtSfE3RfQmn N+K7R3jGOy4sWJ49ru3itdDHkWG4D1WJnio/dM3Sxv3lpAaB8pu3phefZoVAY8ycAarq09rZ AjEcJVm53+/YCxCMUj78ZX+6DTKIBT94vE45jkjQ6xIFtAQSYzlvpU6eV9Ka7vGdn34iEAtC 98tWLafIWm4b7n4+URGlIHWbS+/mkoOKLM4ElMPkyCtIpgAR3g+GA25IC3t+jopV/aU17orK FzYYyMa1BzDz20YaXPuO52jShrjknV4UHykTwZ60a++6cNOMX1n6Ph+1/ce+TmHIn6FimrEO HZZIOlvPjMec5RcrRnU5+JS1rm07X1PUvldwfjDSuahwDDHWsmA5I1bZyFCzIHsd7w6rPVzP 812yDKRlXAjFb9aFrlvyimABTV4xxXaIlgBYIQg7HLFqYrdVb1S+yuMqFJTbk3h8o48tSZTW AG4S5ntMNqP8nPo0GigX+3y2Ip2BPbby6XXOKrJlvpvEI5ZSvr76qr5yIjkoEkAFDvucQ0OD SMDwFBIDRPpKwf3b6AHbqYKuIb7BWB4aBx9yPOAFAhPbs8P4VpHUN/RKBk80RWReP1sCxBmw nLgt5uzTo4Q3U3wW0UWcdKVFzFvu8WcMe3amnSf8RnhkAvG35dNfErhBpQpQHLpBW4IKTOCa AGhUkfvG+tB5bJscdXudBrC/KNBphxNRNi6kz8N2dXWox0pvBIFNExIruaT9fCgUBrMaRIpj 4hbZlR42qf3Z7DS9l8BfnPtHUCbh2/GHiVn0SvUh6wXY9hieghwD3Hm9pAe4cor408eYNene gal5jTf6bk92rwUHz55QOTiN7d1UBnqoGzUOVW/YSfLopdI+MATrpPTxu3Gd2tAsciCisIEn Y/mITmLr8jN4wRQMBJubpTf+DZWD/t7h0xEW6wvyCIWMAm13gJDVK6GLXEyjf73qIThaJzMa V0wgieY4Ik0ibhQeYxlx+Bo/qgLYflIv0n/MgmwaE/MidVgb5Gmw1IuNwkAByZQdGHn6KA37 8kSElS3LXg7JXxptIlWftO/BiU3zhCKGkPAOMkOdS9Qjih63+oG4GysquXUn118EPD+gzOL0 tgHZw2kTV9MBebQ9JsMZh3E3nbiL235mib/hK28CrWF+AMTzZuuDCsCxQkY/irrPkxyYWJCE VubMWlBKCnefwWRqoIkywYa/8+r8GALSguce1fDt8hUsM81jgim7eWdhM5yUGlXQZKHNU9ny fIOLQZvmx2h4BSLaW/itWaW2veO6Gvhkte6RMpNiEL3dzR2w93DcXcDrbnVVncuX+viUD7vM 4Na3Wgy/5POqmYGimmqoSJCgWb4xlxAzAH8U6PmAzHLqJ+z8V3Ns4NIonYU8FbjVek8+IZdO 9Y8zCN0tWaAmN/Wlu2y6fj5FNbyzQxDquIN8vzTyaN9Nz7oNCO8FwVaLbJHQbQ9WkAIDvBLk 9w1k90Vwaq8+Gk1FdV8jGq4OymWv0h4ja82BnC7jAzN+KZ5cPoGp4zDzxjTNsiQJL6dAt9F1 HZH/IVTsBUwC9ZCTje46emL6LseBYmxjsixsQUSU2UU/XqTDFDnGII3TlnerLpwMKzkIJIhJ Rqwh+CCgs8R0C2CDJ47jOTukVB2NjQfDA9CMaKaVtiolrNIY/XhKknSQq2swdSQpAc8zZbQk 7HUuQHU2b4OtKlMSDsCmSbUv5Vun+2dIBmZfgdI1h23dzvB+84xfkoplLtbBFT8VRS4O2pZi tdy3tjbYV63KwChAju1oP3Gc6NLl7CKFjvcdJvHHdmyUwSkRypYvqks4eRB/SJqP+AS6AVhK iBAcQ9Fs/EEPOcPKalWSA+cGjKdwZFOil0GLnqNaF9oyReLQX5SVTpJZFQWvs83EooxALh7x cGXGUqV9vDHWxMYXQkf4tL4pF3o+2NwRjpqLFr5NEwLoJpS7eIQCN7Ufj9p1e+tNqWWdUpCr 8v67c9f5uYl0FrK355K/rqiHvra4F50R56M3PNL/u440pFwnWeSooYA5b5p9KBFIdOjnmlJM D/9jkLRe4FtrtmVVDS1SGxewyVGTcUTFu+1K038wF5emXw+8X/eXkwKf/Ves68xEz1EXbtOY IIv1wfs80uvXUJc41vivmF9yUdpZmwsRDck+D8jhwwHXr2Uf63wrNt93fieKcQn1qOAQVKed m/bhxr6msyj4jJbzcrb2u3XjkniFBgPxZfiYXKl33gaScV30ATbZLVWZnN2vv34LxITmG0nt 7PdKFLE98i333nl0HUOqITnC4Wfhfm1C6x37kD3tOT/Y0OctY9LnUqK483LK97dy0MHwMlUY KnE69dPUTmGJh+IaGvRjnK7BXnA63ALRzjso3kZaYiNJ4TPnUW+Fihs/n0qXoKLXzkw0qfLw y7GPLrzkWwCbdw/C6KBS7OHGyehbfTsgBeqT35BNdDpnE1Kupbefif9tCjgm7WEGDwlo2/pw XgG/ZT8iiLElU/xwcw9yUutRL4GPReDBebs4+Ll0a1Fmt0/aH42wUfdtX7D7uK4DM/SXsTSR qAvZWmPnefQ5znU500xLWpkmle7eupYoUSkBADe6Sz0JmDybXeksdbvY4BLBf5RUF4yZtvoO pnSysbUUh4KkIsnnhoxmxvjzzOmazYcH6FGdzxZgIeIVnGTcolauOqvrk8ZqcZFwqvPW2paR zq+lUZqIcIuZ92UyqRViO+aoxcPcp8X3HwoeFE27UK/32aSQwjndSHYuQsTUkG8uawTXcGZm +N206S4lQRYvUaiQuz8/agz7FtFhd7uIMlD2UiUO6NJ3CFMPhGe4NMVu6E+sGaagxQAU44Kp nXiS/W0CB9jwXLlYrM3HsLPSXqvXk0ZVr+4ba86Kj7yY2nu0a5hqL+gKIwILYzahwPp/Wh2z Zsd5ESeboTkb9sPECERYPguYDIZ8DdgXS0xAjibNr6FWJbFvHHU5MODbTS4d5pv8cXz9879I XybmDcP2NLZETnGFFHqUDsrKbRXvmOJ9MmsVfBPYCHErd+bx1yu8lwuCz3fa6YXs7Mr3jkNr awNIA3YLhRCWtaSd/vVkOOQchIDRbjlU3E9UfirmuGgOEX/1DLSAXyBQY6JwQcslLIFFaWeo uVQqmjFn+tTMERJ74OZmBEHk5DNI08VnZLHAFx+6Kgcp+EoCml77oZR43n3V+WixkDa8B+Bg Rb/8ud+El/zY1pYdR/yMS7NT1Fx1WnAXYc5eBaNnKTF841rmA8oczukB7uwQcVKbO0Ic3iw+ VoVRus7v4ENxLsRpGk4uVWkLmloRFowfdqz6pPbRM60rLUKYHs+/exTjaapdWZLmt/UVHUng zOTybTZXQGiQMhLtkh3KM46v+BwRqDLzjm34ji4GHIGU0/lhkPuR4YNy2mic62jVpTIGoXX4 yQEO06jCIalHh+SiK7eXjVJwYWihBunF8d20qc8WC3P1f+mwHDiWt/allfaxBu+LdzqmvU32 27mucYSq4Dl8A0LOfwZLgsQl2JiSGb9+q9jCMrLrxvb/dAYZ6FFHQ32LL7qK+7mWh9w9d5Ow UxRBByji7bHVXILawECe6WTvnrMbiyBXASJXggyFS9CUYMEhQjDARjj7JtnOkyxP44hlt8LJ oyv3LRSs117Ze+ZVK4QQoI0ojS8oJcUVwlWqy6fquz9jLs3fiNQxocCJpXSVOwuuGZdyvM11 N1FL+SiboAkCMfs0R0FNqhLPIwEbs0fbY/gaEj04FX+6c8EvOh5yaSBX4ZbXNlwSnlPyyF1E CkGvNPHH5lz1mlktwj3Tsy1QfZxvfiP+kr9pVqQpl0wsgIkghQRlAXngZAkarWdFzB9T9/xe J9uF70AFGhU7e90NElv2aP4kUoEUsEiKZfgDXvxAwcj0tE/v9e+S3K8Vo7Vq/54x3W+gQq39 YTKI+8iVyiO4Vs3I9luYQ4BNuwZx8IiMn/nWHZ42i1vfX1tg3A5C1ddA43PaokENJEMgUYf7 +npnt1V1H446UzuzEfl74Mgfb2lpZ8bFzxoncA7AbFLlPEneLXA0Z9V3ox8ebwKFtCwIrp0f XywumkRYF/8yIFgNVkhytBSxqMIndSHDm1j5Tb/0qpUv1K625wCkXZJUMKWG5mKhh7hnMWTm LR1L84xtpCuDDiCNYBqmWOdtpcSxT/T3JFzMlhDCjPTwLz8rKH2sosHL9B0rNwYCBJsC/X32 uq+W3riJabCOZ8d1zTLxx8d2QE+EMN++AnptIe2j1kkxTl7CDtdCMVLqG7l8kUpNtNybAfDZ EkiklCFA0b+oJnPjMSFwYkqPlbI796HBJ+EIcIYuogP+KtnztCYYvvuEUfzhWGhef7PbDUj9 ob3CiXebKhbXy7rRsLqncfJKl6VTpKJ3wnF8j7WSIm1USa3hqMZUJ/E7Kpa1H56PteUdGmdH 9QQW1YlvWuvFJ3jMzkJEBoIFfmuc9pbZjyFst41aY5gJ/gHrcwRNPTrTp4FqLm0ntpehju+R tf6bDCbzv5fXoW125Mb7bGNoRU3RjRUhLmXvQ48hijiyjEhceSGCNTENcn0OdBiCeR8myVJy nwYGjhWhpruqcUKPmrJ5zf+mmbKlouKdzGelndqUk4i7TKal9uddeIbVj3SOR4wn80x1LbVV +26uKHGPP/YjEpRiC6PTqQ91KGKA8oMEt2XWiI9ErBy9fk44d1A2tgBFgWh5oz02wgAEebz3 pMwEHUepqtBIrq0ZfpRnC9kaFYXGRLmMzQQaA0eNDnXUnDvsNPZLHumgrTHlp6to2lWGXNmm BHWQjMZEzDTiRcXtadXpe8T93tleXzz9pOClFZFHz2jzYE7chk7WPjSTTd+5PTBoMhgxSBQO 3KTfZ/njgi3FKQU0rufAXXgRssODDHHKy5a1UZltQZT3aRV29G9q6wn1Tn9JO44bg9M65FlL Fnycp5EnGTp4Wfz/dWIn5AHyO26IslEzQUYQHd0KG5B3L3C5rG8qhOlo3gfhkCKn7VRS/nkl k8KDLwJI9FSMNBa4YC6PjaxPmeRGaKwza+lUKPLRm2DqdQ8ojogmJjLc44OrRlofwJYu0It7 iqjjhyz5KISmeJlZKwkD1febv2CzzBjeHf5K1DN6xGL/e21mdMw7V/Hx9QAfvFDNlK4mSDcH gixytIjD1SMw3i4BqaE8QhWf/Jr1EQQ3O899O+RLyJl5mI8HXmybPTo2DZRHveMh376B2W3z PlTi1jq74X558N6XnQa6kSvJDQumfioPyGyhs/UxBQH2ZXtzGJslN/IHIJyzIUtrFULbGTnr 3ILOq5pmLyetsXkcMTja4iSkHZNE/OR4AfIWE/zHbJ68Do6EQrmxWXHWagjN6kQbsZNzTJDE 8HEpou3DnyCkHEs5V4cx97XXh+XeRcAWYEPeFeIngqC2XYkVaxMiZOUE9rRZzx4TUGP97+um Z093i8lXFrRaYGq/CQZgJxcDxKmqQfbFOd4AezP14tLGNQewgDkHBAvXqh7+56CuqzFK4+HQ karicjxFPOLVP5nAE3rZFDoVNERPNeoBSv694GLEuk418X4UTmztwwJT5qNGSASpJ/IbFP3Y C8JFI5f0LhfHdHqbpnSjXiCP4PXQs3JRlmefVlwPgN9OWVxUfbCCJ9py9O9LBTh7R3W46ylo Q9ycLIWd3911BJtWUFU+J0cwdEiPQt3saQoLjrMPV4kdnKbNSk6uLvDvpzMaXSk2heYqiYwJ WRBkRcLIYy3Ef9jhyLKvszOR/cWNSsqjFz/Co+qweVwoQrVWjSXNwxqYc/Yp6sKIyRR7HBBy tn04flQlperubf+1UmtP4w5P73yjNj37/4QdM13IOWZeQStpALi+3zFqwDXZ7ggPnKQ5qpqv Xb13UpS4DeGgZUAXTr4qOpGQ3nlxymHxv2nYIUpqMNqHO0c5eenBpNjmj2YZzVBT4fubOCxh 4luB+Sey95tjGEjCzGjB7/FwIm/VLAeHJWl2it9VSKDLL4LCAqgTViZQcs8TuCXoWBvuKA6V LPupQNPZdNOVxBXkQT0ydgjs849noUaqigcZ0V57Fj/uoPZLbx62yGMKi+otxGaV/Rcd8ck1 IDXBXf91e2dN4JEEQkKCJZSrb+QauXLZQK+Htvp1OTCwmw0/Oy6sV4Qf9X5rS+XnM7r+2bG6 ukDMp797dWiGSa9tLrqIeZxeXJHZJwRvpQONyVABq64rVjCTLo4no27JJD5aC52xGCi8u25y jhxor3ycE/tEG2YMXM1XxAxLw49JK+AGsVI6zvFwgaBQrweF/l9d8jpkGuXppy2pAkurEExN bXIdtM4EgtA8pBVgWXgonUVeCMxzmNlma/vm7LCbvjk49KFksvTftJHjlMrHc3PEnL+nV1sx +BiW+5jMN5sOH7N+6UkzBk3NM/TiyC4masLfS4jFroBL0qyO27UOKDTkVi1ZPJ9jqpQ8QSeo z7XjOBB9ZSrEshj0jz/NU7Hfmgz/wBZSPwHu/Hzbsii7UgUqQrO7gO0eAQaHPg7esAv3Ax0G Cy9u3tvqB9P6elQY4qALTreWx2omkxDKYJIdoU3Zrse6hRzDHMWjUFTQeQRjJx3CngqakUnb T7aLzEBCdd0N9xob226SJXxhN/uegK08+jb6PCOtlnPglIAeaQ4HrBrN08mO1JahmYWk3CUN 2u4JIar8oXL4Mr+YvoSdvi4VND+/1OtVUIfvdGYbXL5FLQROoYfGMbob6zNAdlCFiu0y8xZK RQEo1gY5NHRo0xUI5BCfIyt2L8fpRDtl/GVWro3Zb7YG9kQWHOwdUUX5rhLeJ+xJNDrXvxrb PIV2ZaMqGJf7LOJ7/9Kd9wBg2Xvx8WX/A3u/ykPRjyRAZ+QzgrwnOsoC4OYCoLs6n4QWLBvg 5uEso2tQ9ypzER5mievjiG1usg7rRmItpHqW6sYyGyyBJf6g6WyoeSjKb3tDmH2wrAN37Z9b TXkScYN/RnFadNY3HHL7PxUtCYp35yNpkMxcXi38aIebLIKsLB2+rvM54lWeCTWOCH2bErHk GUD2MdWQ9cg91TXBVrN7fFPwUCvxABx80h8XcCWnFxLw46Ej9NFtT+v38sVbxkfTGF+X5xV6 9ieaSuJT4MUWviRSvENKZMCVFNLxcFN9Wo1FIbtubbtxzyr1egVnp8mhm/5SlozOw5yFUI3G YZZLCvs3QzmuMfwsLQshsYZEISXd4re6YCeAVMfIXTtvMW+AhAobvuiN97zbIDSO6XN3fXmP DFfmsEnnC4exqv2kSvL8IOaCQwUPPh6rvaRUaNNOMdAVn2HB/DF9jTTfRjGiMmnm70Ot0gAL vHDiefKtJsMOhmlLHWD5HOedaErkIrhQ5/QarwgKC/dTdVpP0SYgyWt8V28+JpdZGJnbQDjU //AKPb18DJCy703cPqeAUIlEtwbaUc6Au7Jjte0rGLnhG2rX2TomlhEk0XWzy/q+9tN3PQvZ FojOsyk83OuVTcxJHZ8k367Y6nRGoKNdgPvdTUsPamc9v+c8RzaT+Nw8zL/3ipCM9ayta5Xx 4wj3DWabALXx1/XrDosfZQrdoHYCRzENXT2RPo54yife8altogZsTWtMLymmeZUENOTsY1nj hKatOmVCewRDfAuMkU8PQp5EOjrrUW/tD9wcUcJRX6870JLymbn7KAV+BayqGHTGGihlGZDE OYN9TFFQlMBJI3l68qqoaAB+kaRA+nTAx//TEe6ilXPT4jmVXroHMxL1hFIFQyewAyVUI8uE 5Uc7GNjqPT4TnCzfLjb5+cmgD6gxbApvXrx7GCmrk+s4TERlxRWlAcJmCWKf4Xs5ClFFFgYw RRWxClSe4AGyu/PZICGsKdS8r0p5RcVLhDNkZ1E/++Q5TxKMWtt25qzvBQ9pF92EPcmZILGk Gr8/8FsuVUhyH7dAlz+Kut3qUleMF4uwSukqaJNtNxwV+6hiMpBaUb6KbtZVM3qv5GitkWMK eqGEp+SiTEmnM50MdlHlL+HukrauEB1BTGk0rxv9aOxu67c9bJsdRx/lNd6wuy7wSQsLyf3g 3OOQAoSHrUgTazzfvH5yTR+PzQDNsGxki3OnFj+GYBsOIjd8+2pWuOy/V4Kf4TOzSp0Y2RIr 453OYJoiKhpxYk8bVuBEG73Cuywi8EHlwZ813cSH4NTkFSWDiQXhoghyclivnQIAa0OLoR7l jardinPt/5kuy7QqH3p9sealqiIAjWlZBh9j7BWph4rxSQDxyD9R465fJWNSHiITJG+Y9FbT TDEI73ONoENOTR7yZYCTeC4rISGbY48HI8RjtcdiaaxGkB6EQiPdbxiu4yXyfNQE1HsU7Obk 9Otruxv2Lzlze5o0nPpsIwMfSSZA6/96QsbAgXWvPop3TkgMIyVicOSHxGp6H3zilPwx5Qly fzz0sfADjIlrMIBbbWe1RFlA5NrDci/NlaOvACTwbN5NPLkFzBQAm0yp/eZGTKg0OSsHUa7r ngeSVIoJYKK0GVQ9PjBscV+w9+t0WbM5GTlj4kvEWo+vw+vA20ceiedCjqB13jSKt+1Un3MN tEERwNvKiFwPyKZVryONllMhUchF9nk1AnEOfi4xNA4jCB0TrKSxkDboanJeosZD/35DB9Md 5bK4CxXTTpSau7n0RLvOE1a3wUBpmyhyPOf9tIfc8ramdHpF7yVi7BxoKvotnHjlAAV/gQZt 8upAtGEOf5AC4ayGbFs29lKAC6M8e/oO0jvH1F3ovC0SqO2MhHSziQo8r9U5+y82CSk/oJiB nTWZm0ihdY0IFaSK6SM6ZjlYeaq0Sj/HRcyOjNaOGx2w+lAYjdTmt2JJAl9uBeEnECpJCOMp fxfMRBQg9Cj2IQv/HkH74kwuOtVfdUnvlRO67AXR55bMF3SkkdLiQw8W0cT3QL/3YXA54ySk mTz1mvjC/iGvBkXAZemb6KZlC+FgCR4S4xBLYdn0v1SGw/A3eU3CSuQQkxFFolwzf36jJLy2 3xCbj2+C0TG2+JicfDdJBuCxVSZlaI53VrliXk5igJ0O06z0nEvAL5dKYDhN5LE9khTu4kKD eE21oPDiG/E3wX2NzFx0034ZrGKjQEFrRd/LGBB/WI97pu2yhwnFAWxL/jTVE/txzOgOvvPt tsTza9qnWMT4iA8WCfyQtlfHcf2Vul/aM/NXBRVIkaMWNfnIbI99j279a8o+SZYAmIZXsUyX 1SnEycdRcZcy0+J9nPkY0Pkqdwz82loMCm1+fCg8Lv32yeBE3wcd6NRUVlNDu8Ul9nqZy8uB U5Us+GZb7kVayObjsLLasbNpAYqnNAhm3jevVeLaBeT+SsOUhxSSnBIY8vMqV3D5UGKVSdJg f8hP7P4r5Z8G7NvQsHsWq7RoojqnNu+rKlEM/dgqGUXJU4c6uJEpSNC6c59MlZObbQxXcD0T lqjimTdq6TihRBs++npduR5miHX3RfolMdQuf8ob0mU6BcSgHB+ZuAktvqlZMD8XIRjBauTQ vJ63iUsDkBhDAJHVPRegK7Ogz6Con7vDM1z8mXLO5JWFvduJde5k/M3DJRgpf6Vfs/BYrasN vnp6HHHQxjWDPZEOs3+q96O8tL3WPbCZcOFwGRVI/F/g3VXdTA3PEp78I0Da75D3YkljFUpd ryoqwbU7U0KTAiW4noCnE4IG1RhdUBZKP0mkbU9k2yOtJOI+hZjS+gpa+kWlXkFFR/fSPo0I b/OOnrzxe6OxmHYNcDa401va/7wjHzMi1zrek+2H19+4UtfFxfX1I8cAxY4mXIHavviWaoKv 3ureYtCkXpOax73jttxLg1dOeG/MKrexeb8bD3JdTUiJv56eWUd2kdABlNXFF5wov6Bdra1O FkBYyZQGM5Nm8Ai+Xnkz76muguX4JE4qjWcLADW9g/jMsNTUWsmgjsp+3ukPLdHcc+m5w4GM N8nsZ1Ta7KihhXmLV2GLlt1LOQTZPf5srs+Is/+zkVUJjy4czQwE8GojIoK4eUc+S5p8MI2c xTIL0V0XPaOUhel0s72HoGsgqovdugYBbLg7+IRhuJY734yOX1wDd0dufL4ci2ueUHkRzaZ3 ACSyS1C/LC13Wty+ua34FBxSaK7fl9lPgKvokSvCBY75T92ROLOWWKeVRaXCOjd+JK/B+DBg OUpT5Cxs4J5e4DxAyP7iH6Fkp/U7vgudB3DUbZEXtGGTGE1iiYf2gsYB/wWHTa9qUz8sQyBW fYcnHuAeTDZZE80KnLH08JHHLHdgApPpf20+f0tcyygYcsMKvoP2SrmDP+BVaNdosGopx7+5 Z23kmyufdwCp9uGhW8BZHWqIIIsF03kAK2ngaCc5Ng4NlUd33p68M1mymsy2gXFVpOTiS2hr 8/ZPYXBa8ixcJxbLgKgjwLUCnf1ew+8y7r8orHjMBj5HHSG3KQ0fJbtMZoJoB0JpnNcw46L8 QySvDJN/XmVJhAp4h97vshNyhMdIo6bhGMkvOkjl2J+TDI1sYn2caVpCusWGfIKMdmEQSgQG RTbi8p5lwkZICyywdqcogXw3fvND/WVoj4WQmckDg0aalI3WUe9oDJY/9clqv4gCzXyIX2vw SDAbLFokTMkzS8BdlOoVqs+70ryIYbsWGYljG5dnD1B4p/GYVrtrUNTHsLF7Eyc8L8TRXs5w Y6vhPIckyr9pugoALzrIesSrifATn9T6RQLZ7/w/Ui258KeCN6O6STtA8V/U154TkrYUb5uC 77GD6Z92vSSUozQ0FUMZ4UAzZa08FZVmrAP5eLJIG1ICdzPcoKXFVuFWhhEgxHaUKLglUhld boKD5cRUphC5MfEhhvqMEfDsNc/zrHNj7VnbExGrGoy4zTLnHSI/n/PQZSUBXXfsas2DL/ms spYiDz2NbEZc25I6kBJSeM2xeWKC84be8v/oyTZzM78cTF1Wq0W+FnOS7Hnf1dmmA0lFx5K/ Ab9aoR5/icoE8bX7kRgWK6QSzLb9AsQMwdueQRvup9X767f/J7faFdurCWDmDz5SEVhUhzzS h9FKn1RejkwdqEu2a9LQXandckM7B2v55CDFiKqAwzsZ5BIy4yQuFPZq8yKAml/1CIAfEzx+ DaitSIFF5zhLMle6zSXRmR4BJq9x8uT9Tx7gfJjGcHlYmAwsxtACzNCDZcBkAD8i0WoU+6hx 11q2X+XUIZDLc9IHahSuxNKYh+VPzKIUrzuKitB/GR4YHsnhvxdm1ndHClaw1gNa44khqpaN Pd+OFXdgAIW5U7FBJMduqfWeJBrzHF+yOr6BpYqfIkmkhcqTkRa+v4WL321Ppayqqr4TYSRM u3nFsQazuYsA4b/ibU60nlrFKUvaIr1ToH0R/pvURIQWhKestX5viQVD2AfmZv3moYdlNy9j oHjVdBOg0SecbjtdXIrw+cHxoZuuZljQsuXv4TvadoYpnk/MN6udmA1r8dzPTyHHCxvtWQ7N M5mxMIQfdhAEzm30RQlgoPPBf1zVVzOeVyfOMH3dQvoQcocVHk6/J7WtWHCYCtKp5pnb1lcY FQ+JrQmgmrRKtLISx83DCvK6gLratl0i98S9ryBIHYNZ08c6WicL9+f8Gg6HSk8rfezc0HJG FlMXjQ6lVmYIOkYt3m8wBS93cuRJBu7InN8y5L1hue7Ec6TARJIMzU66UAlRZcxdOphDjJp9 dfckcQM1+A6qdy7nJaYBXdOzyj/+6Xkz0Fb4L4LO/CQipsRFbjgctw5fWTwXFDYCHgFkA121 B7Dwckt+ZG5cawpdiQXgBucVugRAPRGcjtMB4hFHxm1UmkqYVem4lq6gQ2OvWQA7xsg6kqYL aP3z3WHoSYViNstPMPA2pzxqpyPLWqoGHIDnXrGvQK0n9gXNAoJYnhj373314tSDZMdADsjF NkrEkJTR4oVLzo4DdVtgeZyEiONdv5GJmDlbhLnnL9PtnfFRRQ+2t0AcG5R7Hkm73Uaj41Ks zalN5fE1l1Vsic7LaGed6+8SkaiTY76M/IZ6uVG/kDHDORK6Oeb9Y/wBAO12dfYiiA1OvgBS w+nJI6Wush1S6OM/iDH6i8Rr8mdXLq7pFlkHhERKRyc8iI7KhpZKDVKwZtEOJFQxArKmFkG6 J0RJZ7TBZ0xRTlAMm/9i1wkzKnHVo4ErZaZUBCgim2WZh2cT/OzyJR/NiOoBB/OLpfne463L bJt+ManN1fzWSfdfA4LqUQoDtWSr5IfzIHnEvaR7Nqq4+xAtU4Id5jERGEiB84BYJDAK7+5T GT4iH7+l8KEEW0gWfeNqnqroV4s7Y/Egadsf60DgvND+dynNPtbeFoEcqj154N3xNWxPI0Xa dE85MEQLCIH+4WJwFttwYeKbC1JVrBzf6QEmnXwzNQblcrAB1H/cmm8C1+T4vFn+5bDhHNdi LDgXSLldvBsjgKAjNjWCM2UqiRhhRSOzhTcP53A1p4cBRnIgjs7T5hw+pdAwWjA31umKyq9G F3r2ohrlCD1KJWu8n/8gz7LHfavApischgdzR74efIOwVwVTGccy6W53H7TgSweDw3EpeOY2 nA+B0yEE6v/SSWIDPVR3UVcI5hhIe87YRsp9RKUJCUepWbc/Bkpz0RBG8LZH9+qhLVbc1mNG rT+Kj3pD12DLfqtWss1HvAmNEm0HL1ItYnYAZOARyMCPPuqVUrHz4/JPDJYKmly83Or9HCgl oFa9IEElLdkzAqd43yGopOrucy05SmhFC+Ub7TJDtLLmq76J+KAOqOSo874ZjiEl6Cr3hrru bKhDjCl5y905GIcDjSQUlnZat28Rj2/VdVo726fD57Pi55P//ZPNiojtC9Iq0VCoTgEf6fO9 ioggL8aBbwh7UudgKhDiTBL3y/ke2N+/S/JIaRRK4qzvc7P2AEZv23Ma3RHwf9vFg2ebEJmq 8jMMA+VKp701NpBk8iVwLIG58/KmEWPuFc//6ak0CyobuTB28OllvuId6dAxd/DyujjxdGsR xTAl2EJE8HO9fg8VS0T3FYqv5eLYDDZqWefW2bljpczPCV6MFsgHw1b67ZgNTdgrfwTXmxHO E2rZEDdgoKv4e3roB0MX1kl9stfD1AH/zAhRS2SRKzWMRV23YHh+hq2AXxExIJZYUz4+vkXK oVvrMSdiAyUzhD6edmh/Xsxho6VqqQ1EPY2DNq+CgTzqZ0OSnaa/3Ew/x2QmXhRyEqEHeCLh d9h1DXMTuKYCfYa6oC+X1QgZhAAYcfD49mtHmh0i4HAykJI7TARWSzHkxpu9373V3yp+gnKe Ej+TTgdj+FvJSWUhTQNniXvIlVV2DMwzwX+2cDZjIfJoj6MH1UZ7dDAmcZHsIFXlC6tIUvzI 7vfY/iUdYMl8eVzjSOOpeipJk33Cj+ek1X+LIKFhDUjmRmmIXC2ZiYfcU/lmfAfBfjbcu7Ud m7o0c3zsc2Xlmrk1F8Fze8gbkK7QWmAZsXzJqbiBm8b/HXQSfaR3p/6PfMSLrb2R5+NJFCmZ H4JI3H+2r5J082j1XMesF1MaKCJg7yKzKXeiWvhXjAmJ+jjFWnzDmSyR8hcay3v/7KCwOJfh n3xUimgPFqoE3j16lT2oR1TRovNF4MmO+b7gXkibRYbt1tFlhN+QUwzjWjES71ayUlSK7Iqg c/W4TXWvG0/z35Div8efSeMZHidmsoGBUfNe6qmhH5fb4XxYu1Z72avBhDeSseMGK22bbSzV J9sLGJ5hj+OVTeLbY7F2CxZIpDczQhbBN+gF2RUlYhfu+Un5QKqULHL92o8tMq8EuhRmGBe7 Ds4nt2/s7TMU+qkq3whxk2KWuhyDYruao9deC+DGyXaSRrpMdIfezOPksH0EjK2PeYL5VNDh 2ArHdziOwHD/H9r/aF+1bo2Yp94f0Tw5XfJm2B94FllLqWbtlOR65NrXjF6wHnB3ODdz3g21 k3z3SbQeGe70S0QWQX+9BYGmBuuhFCVU37izcI+L/xK2xKJKLgR+zeFiYDyqKWLsvUOKPTtr XLeyTpnkHqVkg3jGfYTLvvEH3b+OY2SUYzhCKMUN5qPMy0Ces82s/4mkUpBhaq3S+bk8Wf03 pfDIuT/TtyYlnxBEscaK3Xl+ShcJTCB2cmM0pdrrE4UMJdryJG8qE3QeP+9yq22VowlVJZBT wYps6PR+H/LB+Z33+wZO3UP1Bw7Bjap2ehsNEQD4WPHjYGRNPgiie2/5Ygi0dZ3037zx5RU+ xNTkAHBJLfaZuu75p/dbDA/VMpI/xpxe5TJElkEuOMHSln9llaU1gIwycIRCJPNf1dwGKekX fDjXF5wfyx7P8TtkKccskHcLnj+OffXDUlENHt1ghQnq+rc8iuu9CdlTQUf7wu8j7ecohB28 xDQeIrlheopub06ymANWp4QhcI3KGNHaXIssEAZsOrCIZ/SYuz1hsBQCPA6eq5QalIe6uUY1 rbx8pYIB9K/UG4sgKbbJWF2c/U3MBDIlryCQEWlrVkfOkDwu0apx6QbO26w3K3MlC0rXMUys byPREUYYKHS05dJyae9N6QwieRew70YhV4KfPyBvJjHeFTGM5c/dwViNMKdS2C4221O9UKxj 9VCt+O59tFOLYZWxQs06vAq0wH48PxOXMKIHb4gFeF5GnQG84awKwQPlb1wosT2pREgYxGfZ LbXpuInfPZ8lJsjGDxLuakall6DcOPR9ts1Su4Ftl6u9QAyaCcn+bPgxbU4Jex5JMgDi/gFo V/WMJilJ/m1fWRPBnyQ1mpM5TD7C7qQRBIDEa/0SfEmfldeyllMacKMjSUyMqBlTx+Mc7SlZ RPwYfa1OM2VQ9MpT0DdvFiSs4w12QaxtX3RCdbp4Sd6UqjYHfe65+iWpnrf0ZTYRe39Kr7WP d/rlHYDFNM5jIJNf5sxJumTjxxMrKuqqrD3cU5/LCs1VVOMoNjpRhlSEt9XuMZtWKOQ6sw/r 6i/iflSe0v63ujkFgjWYb524H6KyUBKEThzVBAa1HiEd8RGOE3EWrvEtDZzC+27Rvx0yBmyv H/oFvPWXhIxTvPYv5BbBrOkw/4RwiWp1fJyR342kZWqLTcLHjW3CY2kVq3dHUBQvk5LStUpl gKke/4drS/LkTXRoHPpUwyBzjO2yt6vSG/+rCmmtKaQGu7gPC5neePojx/q3eNvg9ZByVFLa dO16cwbyf/kxUvkHZ/UfwrXKDOBrPfmVdS6kyC+bTPs7vG+0DDjlISptqNx8Xj1rzJ5NGE+i JpbaKj+YyU1vgUCYb5EbLN45bkrQuNCBLVcHaWHykM13CuMx/Pw0cNCrGVHKt7ZjlSkqc3OW BnbxSI9y7+UlvFjMz7iABM1cyXiosuCpeVI8gn/gTrlL8dDX4yX7sHjKmrVFEeD6z452lltm 3l6o+n6TBn1lVRJrhWbUsL8nPiWk5VOaX8lyC3EtvuoFMX5hk06zIcLsFB88akQO14IS2X6F +whC5d7vKHEzxWsPTGuLp0Rks7ZzsfA9aMTiSU47XhFv4Fgu8TmdGEdX+n8poeHU+16IxDvz irzEaYsHrMlV4jRItMEOvH4KGtXbueUvT9kFR9EX/SwPGYgiFEdpxLf9hSlbKkhbhb2Jk2ma vRo77jYKPrZ2vt33RvBzPFW/XrFgKPdltMmlTrlWQ/GSuZ+NbiNbIAGPmcULz3hBCQznQBnh rRB1KcTiwURRQc137KQxH1qCCKOzQqDz85QK74GC8wAg4JfdUeNOzw43Jcr1LTYGR8+0LDHP v/WNjc3xkFNpQnUi/QJQbCo5eaIlFgs8fW7RBBSHypIO5f66WStqg3F5vXGhTv09H71SwljT SxbIhKunqgRyDG2PsXgphRlDGDxnFiPHqEWnseayvHpe5yf3fE0RB/rYZ3HL++z1gFXvtM+Y 8Q5BChLSSWmauscC5S0ZZVgpnoQa3kl9KG6jRGX+I+9TE+Y/ps5Wzq5IZQBZTHS5E4suyrUt vya728spn5d+iKQNnilmH4zIQAq9dYlsvZZx0fN2WDo0fxuDQGD8QlyIAloYsk6N6WbPYgT1 jZROtqqo1mr/9A0F63kdeUZjO/z7wDEk8HJzaxWIfYS9UmxNcgWgzh9WRTUVPpLQLclzlXg5 CzXAVWCLLQnh/oJlL56adyP6+eykd7eaWEYaoPTKwgT8c6HVus8tYLdBgnmZn7kgnzvQUw5k TUN9aHsd+8Ssq5HJvrs3CDrhkjXxItBgQ6hsc/GZ/r6jEL4kOyp3tiQgbiY3RxyIe6er6s+k H7Iep4wuxRkeViDr4W4Ed9QDjnldclj/6905Qfoa68YoCUWCM5kDQPOUN6WVkLhmZA1FtzGI GlviqUNAKzqqg8Ynkm1x5li7MDd+0Z/VFq/JINZmUU0yZ6FOe37zLy1jxNMyES9ba8CiZRl3 8wm5eFcIedJPxWGcqowH1S/9lT88ArxVXQO0PXtjlaKxN87PGQTeo7tPhwZVRgbsuTgpiUmn JqdQI8JSuEAKIwfMltb7dIS5DWDyN5IgJKcIHu5yHKeou+eD0P2Qg2pCxSN8HS2cjcaIh87o vh26fk9E8nqIkj8gp6jup1hdTc6vHo9QtIUgJtUQR09V/jntiWWL9EYS1TQ7cqYcXDJVe9D5 2cLiC9jnKouRZf8GYVoMbHBPfPAjQagAovet0WiM7xe15CKWxZ2XRaoOVIGGC2S9DVqlIRrl xWtyPvs13AnuE1XWl9oo/IimlsiF6xjmc/v73cRcUbCgrCtHUrsnB2s3YLFRudW0XOv5Od4m GzDYmxoyERDPU26lx1dbW4CjxxXSMgkF8ehXp668L6Q6OJXPmUANpG991OGCLDj6rBSCMMQd oDrIc2IWezYLkMRaQ8SoIwRcOJXKB93DGa29tMxqHacUrFymXCoJWhKhzTqzuH2N/baG07UZ nIWHc2HfDFW7VJCgle0jwWdnUIakxJl2WTSXviIQ3ygnxv8lZsyn5VVt25TjD7cf6R1Ym7Ya aFEx2XSsjlu8MQYdkfa0EcrQMAZaY3Cqp0IdwnqVIB7miSB5GPblbqg+HvOi7eNvbZzOpYTl 5Z/l8d9qI9OD0Bzgy0MhXe+dSWaNX7uMMle03tM1oBkAqFNWH0M4so4tW18bZyZntKoD9Yh8 yEDhR8N1K1XqEYP+mtkyDb7UPitRwhGdhOsHRtlwUhFefumZZCdT0V0XnSE5VMCA8STj5RpT pQRAnneRpaVq1OAV3FTQGgZKY0UFJX95GE4Fz9p+SrxaLmJ8hxzyS44SLk3UrXUFJIrg57mP 2EKsOiOCmfq1rlxI00m9d9zFW/EIuzGX6QN4e1P4+W923fe1z6P20XOMU1EjZ4H50c+QG7xX UDM15jHOpv4taTOOEo77kMOxvX1F6Wrif9n1oG9O2nm21bBR03fYwE3pSPcFydAdlOmmYAGF wzCPs/fGDhlJ+0jHkq7sRWmv1F2zeg5U4eR4PJkyQ5Lq6m4+ESTdwLgY78t7BTSSL0aUPTXS 3YRltWH9bd9ECFvs4AxJVK8wQfMXY0ZSmFGQsc5/UvU+p8+KDFhaZ49m+a3fouGeF6jDl4lD BSgurlhxTdLE7Y4iQlsIFVvySxdfP1G7t4gsVir//kyPjZEPdeIv8JlssAsRcasOagmCq1Fk AvkhcCpuY+uUmWLJFwQOD7Y2sC178RFDCOl9XlcLjMVD1o3BiNy+4iV4KSHHAElSl0Mij/ud v2q7FqTD3hFTp5+8y0ZlQtuqSWyKzECSDnflDo5hDBFYVcalqLBY5eQfWIaPVoVhn4WwfmWT gEcvnV6ODYg+hdJp3bU4MigM/8DTinajMz1ZMRywtBvEo5OEc5t7cwIEQoHaMjTtmAmB02Ev 4ALWCfr8gbvAJGyq5mgU9AzB+a555aFklU85oMghdUBgge6O66Sc/wM4NDZp/pjaQISqqq4o X1ElKpBlxq6JUSseLPDFJ4xyXzFXYllHOkZP2LC6NxXVP/UeBRRoFWjUKecv+wEPxpgCNe0s N3prR5zdIRL0OvJJOwrtJqOKEUqCSwIq3ktsD0c9A5XGpayjsLO4oJv9Cukenq+p22kPYWI+ BpGkuTUjmVB2guA8hOE8Do4x1Pu/lBhX2b9Eyhd0CVJxoQ7xwwofpvGDMdiQCmMzWGAeqM82 uHuMLig+UvcZC/mnFgHu7RL1Q5sd8LbD7AbXClWQbQ7bPL2WyOank2mK6nppG/5wUGf6s8EX bqQtPQZtcVrVGrTFxtslxaQq5RS7OEbL4Mkmx/XVs5LdYFGsBs2pRImk6hbq7yha80gfcZSo M/qL3zUJn8kbmPsXxNufHltu+Eubfgy/U+qMK9goL6GTknRWo3byBBcAlCgl9HD6n4PuUz9C SwuesA6OR065tngIus/ty7zJUEGr61OsFM6XzNAvNLCnsvchAy22/OKLrQ+7yWZ6erNhiQyB qaPgCN0B4+Bcb6eaqUo1gTIqLRdW/sI8kaLM34+WS6XlPgqRXxokGDF+Zdy5sYA9KPWKxO+n zXDjeakAWUxGxbAJ9bGbSlmNOg6tO31qpCVjE5c556bBDvN5ubHLVET9AH//sQSpeDVRWh5Q kmeWJjwKjx3GTX/IXLB9XvuFOqxC3Ww53JkS4fnjXKw/xQye03z+bhbfGAd08X3dR47eQYOW ANjcTTlDvcnaP3Pk7fhe4VuWP02HvmqE7GWOwX6TUy5w2wnupHcAsWcgirbpUbsnFTWOOTt7 5LPOtM1781P8o/xuEIyW24VFDhOymqDcwk3ykihYN2FAfJrl6Nswt506FoXfk0DsewZTFtZA A32DF2cXjeqGYLxRYwDsuQooBotVTaMr5OkTC3lAqvLLa/uyukrPEelA2fY9Hu+GJVLIVT/f 1GG8gzTa2VkA7x/x+Wu6CzyVKio+VP37Nckkm6hVe6Iw449RfoREuHcBstRvn7c4g1pgsMJR EPbBki0QLdBvmI6iD4Pz77IW4SY51cW38Vp1wh0eE0mk0pAqG7a+qnEcPvw+bR2mW/DdtnJ2 +EGpCb+PdV8jvH4XtdK/WZIUFqkBjiqfSR+gi49EK/bVc3RPpuwBL1UlDxGowoAkQ6h7k8a7 VXTEH9TSzOQQ1A3RsOasyBZER+o5zFWoDGatu7+i7d454xImTOEdUqQiDzMZ2KA1FpomFoNW OIZwt0KyYSmCC1SVdhksCLeh+vLEr0qnbbOyr6hoTF7XgtOLjP4xP3vNqwvITAjosy8iQq4k 65v+Y7s+tMJvika6Ig8i0wM4/3pVYPyIk5n3Si+9MfMvvIYuUG6e+0tMUXWUV12eT05jsQZw D9LfdTT/8CFLmZ2I3JNCg8nKPX+v1YCusCxLezo1C1JiaDwgtPlBURyLHknNY7rJCjVvig6R SubbXitRecu1HFHbQYcl2JxwpULgk28UBrFdssEsCCHotBDlEGOLzK8Fq7rO6RDOOZLk/V+1 I79t2uv8BaLsM+Jw2dlKxigGaD3bQdk+wrpK/jZaVGLgU+9+Z21b1BS+gaJAaZlcFQQe6nI8 BkNzW5TNEEH7kayqye7YzXZ8vLh2b/RuDChKYcTXaHaEHHaKxb1TVZI8EcrZwEWUjp6AlaVN wYQi52J8yYZhX2HXOb8RYoKFGgF115SyOjx19WdT8PGd24qGDuiVcAZ4zwq0ApvoE4VbUyoH YkQHOUDWi3vjLLvOLNrBy19rtWt1hXTDA3Fo0alM6S0Vd6FWh2loL6tSHQ5dV1Tb6O5z9N3n WAtHP04i2yXQROFVkFD3j+0h9XoIPDhxawGKKY2Z2tI9dVVlomFtiLWjAh8vSIB2+On1KdNH wDd1poNfmFskFWUBMnlpXHH3Chmt3x5Tv1uQJ3wvT74FECI3UKKIPVxSExd8DzRC2d/qx5ir H4wNUyaKXX2emHQqDgblJHV6qH5Dle1Jna/i/qbpc8qVt6N4SqDChrZF+CnEnT79OUICu2S7 aYQ3/o1U1YBvpRCU4vEXhbmD6QFVwTIDzbpERePI4mgDg4lbmIExivkJmVrxS1FpOzWuzhRT w67eqHoatfozt1qjjXpGrWvxMMjbnaKlajArxfYlTYgcjt21T9cWwgQMMyLlwQHwgsr/LGss ImzHPQeMe69F3ecHDms4h/lpecybd3A2yC2ffkftPmBsJzNFwHZjalP06uUjtiyP9gL86ut1 a+m+0ptWDN4LBQRSUzNqyU3p3yCzPOaKGUzNSmhvAj4dhcTOdbAxMf7r/aC6tr+ffZ1hSI00 GMoMTf2iJ12/prgcEXzyQhZwfQwnRlpYLzxutc0CrfNegmVPpyNIgAHfn08r/gYVJts5mpwU 1L9FXM5cEkvAyCNGH7xfTpAuRv6Le+J//SNsCaZ5gmgyan07Gywxr64htnG9MqBCaS539J9P 1x1wAqV9IPOuS25Henar0AUN6Qc1M0T4gtjagwVmAaPt79sGB5Ayj7kLBkuAIeF6GIp2lqE1 7hr7UNm6f9H9UoNp9tIX/WZ6HTGyy2WYtar+5NkcXL+8eY+d94/E0puDtWopQstimi/Li8ny PS2ctXBIBUVNF3m8o2qPoaBUwjn0/DAzxVPi8ii6nPKaZHKqaLpie/cBlDJGI3t07W2vUrVx Ddug11XpTioHqbjDswYAJ7rrgBZkuIS1SzzDci3luZH+zNlRDr8E79yKPA2NvrSqkV4mZuIb 34Yr0mTLPkkmyTlOU2HDuOIIAkHdEexqEMadQWoTFfJLwYr4H29PFpiH9eDEKW4DJVqH4PoY anb68uX0jQzZJ5tgaLCZgcol5pQmab/44aXmkLqeGoBs0uQlF6Jz6OO55pHfOT5GRd1k9SIF z1vVyU/L4VmAD9C2Jg6AIWEKivz4bkchSFPnIuMCRfuH83NquD21o3bDL8pjqZzxLw0TtwCx R9eDBN1ykiAR36qZhNtwNHV+VtGDbfQbtMn0Kwly2ydcWvQ6rMKuJGL9zCO39Ne3QQYmnXIp ltAYv1dS3TbTsy7xmNpaAa9K7h1kCIf/G2synvvqn7myA0qtzwnQIPLCYVvl1d7CVFIA02r/ X4bjw5uqZKn3l0rVLfLUbHQSMzohJdHrT3noE5Ci9NMd2OoPpdaqNR0kEI2MMO6V27ortQ/c 9wbBl3ygSNrBnHVE9nRD277muRTL/fD2T2rYIaMlEEtiHpZg9yApil92/nqxmNMeZRkLKUDZ 04coFtUdAQVHedtjC7kHTBWy5LYRdiYiUcPSAGvmuUCqfqjEVs0Rh0zpAzTMb7/9ctqoJYkK OXwBzevVmRSNz0NKmu3AznwZf0efOWjh1zu+7WE3Cax74dJullXVfOSiq/uROr20mbERKngO iN6D2lFju0zR0CIOm1LqP5IO5iG9sIxxLU5e/PzPFFPKJKU3JhvfIh/36bBgbFqUHIcyPp3A Jr9pnfao1+Xf8iEAZ6SKCHlXR3GmqEgt9WM3NBalk8RJ+xAG1UcwxHoRNlioPnBZBtjF2jzz R0bB1ccfXGsNNvWMx17To/qLH/cyiQ1O/y9RLIuogoM0J1Uf6gQL6wUQ0S1Gw6EdfcojK1FN m2FvvYanAD1p8WK6ABl4EGMMdH+nrEYpHI7dDqnNtFG3oblV89UKWgJT74DGeQPcwZqXwqsG ghiMHoG954Q27J+iCF66SOdbO/KWwQURate77eBoAva5mkdLfVMhfI/WkmHsTVQwx0UG2YOq A/1BXIaN5z3lWbzO5SieMX6sF0Af5/c7IuMLQ+/0kcrdmWfXoq0L3Httgwp9p+1TU2e/hvE0 AWgN0bGTVnfKD21i4/0rLQou6D7hWZ2dKzGmSrRH8eltFbC2zZxAMw2jrKPjNPRSqeRU0NZQ 88AYYc8lO1pZHgtwb9rkOOpzd6zTx9EXZrONxFRw3qr6SW7rQlEy7rE3v2njdfvmrXE7lBQK rbujHsBVyUTb8MMfLIVTrV7mTsMVlxAxdV6ZI85cMkt+IyxEoR+lsUsrMZdVgj/5Njhp4BQy 0lD6HKpH/5zOapLGpt6waF0pZ4S7yukJA8BXIgiS4Y3Q70pY64+cAnlGuOrf0zZbwbKRSyhw PGZpsydP1MmS0DlBmJJDQkzU/4Co0MU6fyGS5Xg7ok8JOjg8CnjzOYAUisrzFX3PWtJiBrxD lbGEt5l/kKah9v8Da1g6j4Nf2/VPFFEQe10EesSo+Y4Zyms78nV3veHMk046AuYyC6Ppinm5 Bi7XX4ghGSYVXlMMf+royzv30fT3kVd82n+ovW8JctV0fq4DS+Q9MFgtE+oJ2t5ItXjAJzB0 sWeh8ngoE8XLN2xFW6cm7HcRHBAtEC5M5JzUzcJHcUN4lBi/gldJXHlqlVe1mYzXHk7NVMcT WcW0jk42dcuIfeGsrxHqT/gDSBlXYTa3ipOGeCVe1+4pKUYfAqivcwgwbBm1+WORY0RI8oNI FUT8cazSf9sAQHA9Gbfs69CceJp2Cq5CluAr+9SHnFTll9+Hb60HmABWz05j/B4K0zyRXXH6 mxumgGAD17T/SC4T3HU9nbXFAYoPCJG8OJh6Moy4C1yaMZPdC+xonRuzPztONsSPs+6dVJxr Tdpy3tdDS3Eq3b+f0ZaRj9d49Xx6A4/Fgl0MKxjkloUkcjljf4S9jIHbqLjIU4pPchCxXiDM avtcWAZJT+kDjKS/ZPZcyHuuLtM64xapF4DPaZHWM6VKAKSddGGQotj7IC3YUA6C9hf/kBa7 muoyR/iRTlAfU2HW2z6RhYgFtFYugxoIE/Np91iV56af8B4bYMCYH5NnK5xSaWY9nBNrnR1t NsZlDG/dZrO5v2oRkXdv806muez8DewpSkSqooLX/hASX5hVxcK8261frlGfpRYMQIL8Wxv2 9Y4UBUNCYIfQia24LqGSxuWrmp14lDx8gSLuu7Jk/25lIQx0Va2YqnJDVPNJdbz2DTdM67hR Nb/iIceV0AFcPh/Jjpc+V5RDWiYXq134KVquXwIN8LZf494KlPF2f/70oxzOpahkc6CAKHT7 YQuOIYO0fz8uyiITfzbQ5L8EJJyaIjCoUkzpEnpzuMwRNGDDJ++DOHH3CzUTUNTfuA3Fiv/P uSSupsu8Yp0bwJzFvPxjI0DAZEVevUiOWeGDMwiH9tllkjl3rqKHkN3goEg9WXbWIz0F8fru AMzxbC+Yo6wJ+WKLnM6BeSx9VjQKfV5zub5M4RprV0xSOfk0xwmDwK8Vcpd4GaRTziz5lsnf gWg2J1fNeBZBgqzq4eOQtmADtJeoINc7ht4EJ0c5xJ6V7Mj4Yf9qcVitkMS0Hd7JrX881p9v azcx71GoOSqM4ZFmEeSp6q8l9FuXnJRQHWglqyH8014DKmfdSOiNRPSBV1BceDdlzZiJ8jgI UU9zuXcwxbS7/OduPkIhq82BIHKxJtgQTCKTqt4M1yI1VAlq6aPWGj33cMP4/nsKmAx6dR89 b/1F2Nq3AT4u0s7AzckoczpvOQHRkMPTJ/jovo/ighCR4GDH/w4fe985ucuF/YjxWr+ALIHO Gzuh3dX30O941srCLjl9Ftr+Xec9SCbf+hHGJ5esrT9pIbH0q74V+mHNVQA6DNQBe6zBTJpv m1Alspi9Cu3MjXdjxC4xHM80/eaBFBL/8Vx3duUiLjXP5nH+1SjRr2gnwDJHUU+bJ+JfrCKj IsCSExXf2gEqP+8LkMa07GaMlQV/WM2Zp6gnhd1F+HnBkGe9BewBdhBUtxDqNg5V+qy8QdZw PRopUNhrwpEjl5qg4BqpVWajDWmf2lRbRuEbDVgrvkwzD5FSlJ8O4+8Rh4ShiYNXBINLGYil CHMqhK4j1goaxF2e1nJbYQVStXbkaiXnwSMFT21JFKnXrMwQW+H+qpTLlxC+wfdWUXP8Wc6U OJhn8I42G9VfDNaONV1qEhfTI6Y13dLjQe7MJjU4FVwhFI91btr4BnP+XUewSuypxVgoRT1N jDyt7b9UjjrlT6nqpXoJ01p5chn1YEB1QyRkFqPFdkLwS2FboWjnLu9iDFjobERz86cpXSM0 K7t/0v/4gj9UhKHKfdpNKis5SAMnUe4N51dNcUiKzp3eAdsEEiP/x6SiyKD4To2fA/BB8epI umA1EJg36567dfzDTPBcB4RwMdWehb1WIWDzUceJhNEU/gmadq/iMybDfk29GauD8Hl25tOQ 84VT65vtZpQ5XtmppYpaFXXa9aYv9kRuVZvuFaLuQvY+780QLrTvXNWFmbgBaHidyV9qzRYE t12/ngfCGwt5BW2zHPJeJYlqM0UFxiT9dDJP4ZQY0L6PCzmgNFf+1YtFZqMEBsw0q5fP3lLx JPNYRUL8tFgLW1mm9mu44qTvWoa0kvwqGJBZOaFBbViRR2/z7yUXRX1v2UpOM9Emdh9J3mNB iqsZ39zvTedjsRwpIvOjCDJndom6dbaOY2K64VFJdubrrn8jojL39887piy7IWdwe04bL3+s O6JdlcvKOn8U4kDRBqnVzrJRz5dwnYrjT1saVYiuBST6Rnrijz+F1+zKWeGET2x9PEma7J/9 XrB4fTpwQGzidXNYw8v7MIjtFodqa+JZhGcNaHBwbbWqquYKqO3CHDeM3kRo4bXqFpWCS7Lg 9KdmoctGSyLVchN6jDMc2Nmd2CSszpidY0eL9qq2P5+9B4zBb0C1vfhcHxNqJeCUArrRzG6B fldGACQXmuhxi6S4auSmWdKPXLCbzp3+78nvpdV8H3isCd713b5okUvj4CHIoz5sDnAc7kAF XKp9+I6/nuh8HEmRDvW2jtNQesgBSI+J63s47WzNu/5i11y6oR9/chX8+0WXu9VoqzXObGzo B/OxkhpnQbCckl3VPj+xNqe74z058iezW8psUvkLb7Qz+CarLOxd8QlpepHacRHdv9/PPUHJ nox+gyKObz7MFFDk8ZyCYIM28+JC3ZBzA73XAwAaSbxg7zI3unMgia2BQsbPCH9TgnapIdKO FyDnlp20TEIsMChNP5hVZKIk2rBcc1JLy4XFAhuEFRemhNHNThlEbGZo0fGhsqpZILjBcXY2 Js5dIJYIvk33wxt9k3otxdWBFt7e74yFS9BfcY2HIOJ50/GJVhfmrGTKu6YspqboHVaVranJ Tz+7gKwDwLNVBL7VLXnGrVLkrjsTiBg/gt9OvqVp9NAxbAwYtlko2qn7XMS8qPGFxj7vTNdK v/YdatewJIJHxEx8gePlpgYWbmGxwMq7JTcwyY3EA6mI6xG+4BXOA0GiPzIY6zvmLy4mIZXe lRUiA0G8lVqxlCUX1rMTwOfFc5emj3NVIYzMG3BA4EvhNAyjs0+HWKiUufPDVDrkRY0zrAtb Y/UAv/nB/i4ZDFUj2+HSh19lgyWQxG90C3pSc7By3SuiTzqt1VcN5Ulf1RxI29xEGnGUvbhc 9NOgffg5TRHKh5EX4Mmg/YzLTE890Z9slrW2vHt98l93JjhILLP9BPelWZldLwfre1qybEO+ 9jKxiHVtzrMoX88cvNa2/32ahdu05tArcIY/PS8J6O9gKJqXhQn/HvyZfRp1BjMgShzU1Bcx S6y7d0LyLi7LCcp/J5WPQIKZqTUkPK1W9PnLnuruRIit7wwEchyxf6UsiTuVwhes6XS5CYKc Dca9QnX0vNUp29xxRm7ltsuZEhr/skYGi6wVzguetBm4b4WAeUkIZFpd5btGol8qXEIEvb7Z kgQlwSw7qCrNrN763QaAzs983/t1KiP3pEDkDNNp9RP0/GRARd8pFhB+2+ZzluGzldaIh69L Bvvpr5E/pi0x9R0uoXTyxJM5C72GKIkAb9Iz4zZDCy36l/vMACTw7ib7/YWkXiq9q7PNiWQ7 ngNP325sWpMF2GhOAm96uKZTR9FLhqmizEcgmEjSrOehIx0S6qZoCKTsDAEEA+BUTk/dQvW4 5u9qG1Di+cUuply/K5k/YEbpU8xzqcGW6nfML6VOPWOUvljAW9QdQU6fDujporDu3ZDyEO+v Z9G9wneUvDATpDt0DaVNiNa+4KsU2EQUP+rflg6/3UnuRx253FWgAngL76m4c2HvJZUaPxhk mVJ2b7rX5u0nc2d2Ra4K32lMVbAOrU7KEx+CZGrhI/jgo6OXsHcg7z9skC4d3nVVQ/nEV518 nlgXXKp67J6TCf7OV3lt3TvOzIjVdEy2s1d+ouwwvWbhydSanne1QKpohqg9v6/6KdM0HT2G J0EP3VvLmxKNxARX1v+GeaCC5EVwg3bRCZbfmuClMCdBhFQf2sgI/HW0RoCX6zS1UJrqZQYQ dH03NvkYLRhfendoY6W8UlCyTCeNHoLr6DyPYBIt7xTOUXwv/w3K+wL6pJz9hi+iTAy+aqJt L4Z8QvEIY9gL4Zz7Fl792A8nP86bmecSNzmo7TLKosZtkmdoUG2EOGpqcBc+Yd0K1XKKa3zw majwmiQjspWr9yiJVbr+P2V/9LOjToge8L+jmx0u3ZWF4PYoxIqI4WrHOCR02fCLBlCUJiSn xclig2QibhuPVEpEY/5xefW4bYXm4K1638ElD7YLvj2IB3oyGo3on4jOp1ao0+gzsnxwP1x2 ohaxH1kieEs6UsXhZsR5QS627KP0dUQyEzCXXP7v1GyQ8uFghn0R5idSdOf/iWRp2C7s3j5Y la6nwcz7jpLgVbIngpk7QAx6L4zszNMn47Bh/F81JZI3VQ7zDmchKDSX2Zyu4vHCFXfEPA9m 6v5mS7iiRnGvkygwZ7tQ/bF+ftEjIm6fXnyzmKfcdekDXYT2TB68jnM32K2b37iR9f9OvuDa TW+8A/tig4qvgYr673GEHCq1au43Q9fMpKssxlnl1OA7z29uP3MeVvxc3tuepqxf0j+8bcfT yrBqcDmo8F1GHRnmrTcQuyiVit5mVnF1QtjaQj31To/NsFv79hHaKjlCuWIPMmRaZY9Tp5Vi Rpa2IKfWR8ymz8mK4tpFxeBYO3MnV41N4WRWxGSYgPqBVjrEn4PJus2Yg+ZdxLV46l7RHp30 nrKAdddLgkaeeJ04rRrBx/1BXijvKzbKn88NNGAApmtfXVzVqFTrnzNYcgwpcEdRsqF2559z /v9gRgGXLz6YO3DwtpeBecelVtKgK6i7bz2V38gc2+v/Tl3pvVP8A3MvcabZftII7WxgpHGg zpPqW0XcM+S9A3lrYxmhJcVNRRk4BDliCUyFe8FEL//et6YCTGms3vIBw6KBanUBVk3sjNQt C0XOYMIDyO19t//+7ush3VZYGmnwKUP8mauhS+RFnt4A4kSJ76eildFHUR/GoQoPK+PzSHJN 07lgnoDjHMYP/O9ZQtkH4SCwAEQi2ZdOOqaIz9Hu+htCdTrzhqVAwUqhJRFTMtLJ6v1xMbUT F+gl+WD8YC/3NrbtysAEpFzFPTj2/9D0Jb6OEQLmwSdA0uB2ZMTmXkkD1XgdYa5Mse+4fOE5 YEIJaSNAV+9HKGpbX8L0e2XcGdsQXOQoV1/mGldrQ6nXOV9woow/9o9s/rnLWKWpm1EY5F2z U38uDRtljxM0XYk8l76cZMa6zm7rXIgOvWwDc2Q9nZlKeGRTb5mBBt1mDnqd1QlUrcBHHbDi wk91Ptp/JzPek8tODHtBWvwKV5ZoPQXt+O6cyo/UwUXoPdbaG61PoqDbNmGSiOehrVM599T7 /u71lLFJu0wciOaPiDJxUpC/ufaNqc8XeK3LOAhcgkMtMjA4p/KZVD/mSRMFZ/A+xYLG7Zo/ BLCt+G2N7NtkxINjfd3ZldDzahh3aRIYMEo5CJDeT+Y6UPyTsG32lM+4kvU9vIupdqRUNTFx Hn1924v2lelx//gWUVLRtNF30cylpi1WbMJQg/6p00cLd+4U7aBQvFeG+QOo/JV1CYZlBX/l FgtVyyqtiI5l3fNMd8QV82euTIs2x6hOkVlNqjKk8/A6Gr2Ibc4F7eC0EueAXMuebD69sbwO YMUXM9Mo9nyisd2dsYi8BsaSfhbX9JrdfPicfAN/icHJM76tQjBAHingHj2HjNfyA2BE4G/d xWLhtrzs4DeIKi1HweO8x/AbVC9kfozSgkBJyzagTpu/Pms9fJP03Rf9RB+F5dI0Mi8mlohr h5EUr8viqJs1sZD+yTwcOPzbN95aC8Fq974jrb4yADSzRrnPWQlW+ixXjwGVc9TRwBLB68pa 0LlM4a/3Q0mtn+3NLZEGZ9xes+dDvsrN1o7rfsPBhcgCtyTFPnO7LhOCdypjjEg3DRhv32C8 paTIZP7RA/87Y1fBre4M8/gscVX7c/yrs7yAJ6F2FTQcwN5r20YrtSXAECb8AJzmYU78JvhO 6O/t/mM3h9dX0F/pkEadcZKcI2dOIJn63t4txOqafi5QBVw6efZKudB8FbJdhwitjIlhAcGE LwN4deIO+2vOXpNR7OcFecmv1ZBqsHSeXaoRNyjfJDX48muIbI7NJX0jy9ZSpkvRUML4XlCa jJrC39UC09fBZ/aY25vLCcDaYs2WOmbk3r0h4PvpgppjMKDKnG0Jod/oJGyJvwuXIBvuSgrN tzs4oS2qq9dm2cpjnkwIqNecQN4vIuSg07xMKxB5cGrdUQ7jpYSrn594Yx3jRIh7aaRUHBEX SBrV2uFrDk6k2aRn2ZYItMkXfKp5o6FpWLUWqhZ11hYnKQKsWLkLuwzxWl/t/kBAfgeFbMDo maY5+cTJicBoZQSzZK+40on012tpnfgtr2+Xxz92VVolCgL2N/nGOEwNSIa47YhIgTldZQPC kDEBR7kfwd9DK0NBsOzaqWdtRN6AtwJ2ZrbjFPFsBqdvpuq1cdtQ212csC5NevnMSn2XUHdj JatAhhxAtduYpUO6B0lldvsF1oV4qBcJPIgiIlufCbvOyh7TQROeFOHHojzuUP08MPS+CBFz Ms/gXakv1kZp6yQ12zzfQkNui3+7o1hoyz+iSiHH9FUjxDp9+/V0X4U0r247Ikw4GTGgl6eO HmkOexitEyUdkUcIEs70q3iN9RJDrcnzLJPJ/m0Il9Ip3gsLYiDSNreD3m+Xn9grGo4ajdaN I6q/kAu7HCZmsus+41gzcELbYgqqsEPnVralYJb5r4werlxdkpG3gIW6oCBh0IhgL6HAdXJG rdCddYKTbtVGFTceVm+KAIT5oBti/Kr16/ND2L3kcl6JqNM7HeZp2bjO5hkqXL2K+kcOZQLT aLVND7LKTnezsH1epCQ1tUpQ0wFpZSH6gZYbjVvpFfthBrjvKju8/Lc7zFTrKCJ1LoKbJVv0 ep69tWjI/mIucJYVnPPk+o+56WW96dUvN9l7mTwpvA4mWDTgceBql1W7hnhVZ/Smy1WcUIyf widrTWWUBfbpdmH0VtVoYHgQgD8TDEtNY+qNwj8rgV/PfOQhsPTb7eTIcuoGneCIPqdqPgD8 cldpV0rAoRv7QgfUfqCefYh+zkC/ItcwqdwlZLjIvW0xDeGK66wAWhL37Gck2x8pe4N2j76h LB/d3a3RxlHtpcjQO5x4b3FizVoKOEPWBn7NjYZocfea1SvPSUIY18xel4OEmL2Zdhqhil9q omKp/mAJgMRF+WOuSYt9YQRCeDrl/aSI91w+8g6bgbcqSg4qVQjqPvEzexm+IXg6Sxd4KUAw ogsoGphnOXjaCtc12UaTrn58XVDx/7yIT/Caml25ZGfwkoCyMBMntChlOWJmqERFWsB12H+D DHAiLrY7v9zMdVNuwmxxSeVaZj6e/6wMoRKSoxwRa7l4tPLzLZWCnxsrqDJLUp6UWDdF7CLO LptCUJlQqwS7oaYH2WfIJ2PQ0x81jX7ukZYyEksEF4kB5YGZF5cWtFGWWQrnxet7A6X/3hXk h0VdnslCr/E60gEZFLawqYEMpKUoRqKZrykcLkeDbMy+d4gCG9/da4T+DOcjLg8lXmHRGBfl lgkl2DZ5n0t53NR12jTG+pecRzeH1V0fmqUb9yUOrx61dbiLQQoY7p8skgebxks6rdM9YR4m AjksYTjLFr9uFbxIVKXHlp2otOi9T7PZ7FTlZrNeac/4zcimCKf5zQgFAJvqGZubk/XA/3QN kXJLMTTYlUGQDwzL+0liPyLkcCku94uAyf0Wp2BGxe/dKUCJc6s/eg1kDO9CYOXICgIkNfe8 BtdJPYuPH4d33fPJXxW4xKB/JBr1EvLdArB7cy3EePt5SASJyKlYS4iOjfPpPEldpCBfGpUU 5METIo76D3Cf7v0nabiiDpapG8oK8H2j/S6sRf7m4HutotDJsLti08LDQP7CoWGoRVnPBiql ao5GqsgK29z8XAnmCqM1W9k1DQL6HtSHGYYWgk2LZ9Nua8wwA7GSVit3cuFMopVTq1AQ1Z8j nWEe3Ej+B6VTF/vKXcAaLG3J11PbNOfd2y1QjE7R54XczvKio39tsr8jwNcG6F+X0BjRvvLZ 12unbJyYIAXdUsz7f/IulCepnTL3ZCcKKc8t+xizSc0SjAL/eLPl8uRns4zj9wHqFXVA7kg3 M3ll7g9SK+joPPMU6qzud8CzN6JvTgQEw/fri2jOlotrqgecLCbDPSkIuVtSl+OWIjX98Ix/ Z+Yi1cp/A8du1tykVBIrtm8etDnIstjdJD5qNy5YrFA+OAkb+ixFWDdUnpaQYiFXldH0SWvS eU6mfNoP7mfUFIhzZ0+iV2f4e+w0Qhk8Y4lWI6siU5Yphkte1lTY4udGDgWBKoo6Q2BY8JbY zJWYWX7G4tjV1PSaFuyKZaUyoSgI/iYZOTrbql5yxgtbTTeIE72E08+LbgqjO7RUYNnwaB3D PK6fM+ubW+scrnmUXvoLIBPt5TlKaJVJB6zIC49VyypsBKv4rPy193fRyPmN999QpQ2O4bwo mTQHC/+OiX3an6XXE5lvaN4xBsL7oEQGOkgDZLLUT4DT1J1OXv5WqJ2Uf9KG+ENDfOXUdFdj WhR5avZEg3I9YfkibC6Oq2nViGOeHZIokZc5L3PqC735FBfk4xgyoQjE7Jvlwk2+5MGYSicY BrhZdlVObJXnkdRjUjxlr5NhGdeb13s4UTFG3UPtwnFa+GzkXNgCh75fdYZjLa9cji4rbbjN 9wmP1p3vjRp4kPssJYqp+3VQ7+cbJql2ppITDrdxtSy0Jng1WH/lbqj70LGyhsH188OrVV5G xJoGHs3iuR0FZ+d5CaSvXWhTuD5RVFLBLFvD5lzhVRQTint0MTiKu9A7HkuMgbo7UMB9UDU1 GweTKKdBDHDm78y1xwyQ/CLYGkMMSLh10Lfy3ILbiTjWCMe+gvwXxZpj+zJ3frYXwgu7h5Kq JZV3ZXycwjnTyQ3rIbtMJ9tdZKPMfE+g5IjMjEQSSl7q4BvfogHgdL7hl8t8TQFPA/m1iVmP 83AmIsv1eJ/W8WLgprF83SGXx2l6irRsE2s2u6/M3bN+uwnD0JJBl+PAgHL0cK6tChMjnGMj 4EDwmml95rhLqF5EjSzrdETvHiU9ka2swpLiS7DN7fe/AdrH1VRY7iQZJGZ9u99vBpRbXDoa PRrI94a06+q6LPthafzVizcUWsSRDPt0j6z61VmUTEC647atOMrwWb5eHLmu55U6MsPTZ+f/ wUdMWWu2dmylonzjD6yS3KIHIcQZKsHkJIi4VcrH1fGQl0FYTFsgUDw+t6Mc4nvVW+gynvKf D3OekCtOCnAHmjMy8ruzJBDpFnOHukC1NvvMzwszZwqIO35nvgI/NN0oFhJnlY/+JBU6guhe A5Qj778Qxk7cpat6D0ddWqtGfQZHPV88vPmiLWnwqd9n9ElL1BLDDwQEXmsg62c5TfFyzqRC ITGAP3sfOas9HKJYBiyqR5giHWmbesmFtmDoHb0MvGcZrKWCTCumJUVug1za9KsJNZBgcYdB GnxoI3MyCQDg6DOe7Upy1Z4be6XCP/w7yyZ1rkfHrcVP+AJX3r4AOa4Iy7BAZL3uAMOVB8mg DZYF1gmkJAgM//rOrvVkofhRd5TrGkY/VKXbezqqpe3aC+MgN4zYBC4SYJcfgF80nWRVu0sZ 3vr5kA+ENO6trBFHfLiZZDBWpAKe+dx7ll8ne5031wFDmkC/zBSN2M/Vd7wxESxSTfvK1IjN WevuYFienBABDEYmghkrPO5/i/W3viQKKY389JsnapY0RoTPLwfLo80dxpHNZTr/9RzLZiXO GBVXe+vFs4F/4w3OW5APjVyYYoN2IgMTbPUWajCEL5yRcedUdWgHjOAy+GYXQHsOdOobKkwK kfHGU1zKLvfFbBB5W0Ymfn9XzFeyID16/59OIY5kuiKqjRUI8kxEpQZN7WZOf3ZYMmQYZoJL rI6pFg1d5XMXsWvCnpMw6ETBjkeZuNYdVpqTszKoQtW9atWufvpo7g0g/TK5ntezSbtcwmh4 ppRiwj0jcfzfMAWdHhDJBaxJdzYOvInMenVTxp4D33mVN/lYW+WrkA6HdHdlsXv5/ER05cjM gUrvVDAQxfdGi0BsS8RD6Gc2qNfiGag0VJKEaV1kkl7Fmqk+71pvsXhe4gyE9Z7Sg5/6zhD0 w0zEwXYjpldo7md6dmeErgGYzRws7i9qVk9a4ltJ/9By6Zb306WgJ12YpQLQIMKsE3gJZsmS t85yoIMqCb9e9wkT0e2l7r7rTO3sspGMR9xrW1fUt765p5xGrcOdL3VisMbcJI8EpaMbq69u mLp4ABJqFwtUZYOY4+ptUy5t7GccG0QRpglqrBI1rRjUfOLxV21ueVgpa6zvKO08s4l+Qeem +UZRMHncNtTecvcTO5czywyFcmC5GVy9yCeHkK2RhwF93jHEdzusqhs5cbn6gj6tjcN0qOoF 1q/6X4BJIXkSqj6XPTx6QG5pNOTPRUfXCMEQKrjW8p0IQlGQ5iX1lON3MeF3b9BbZQbAzTAR pTNQKZx+R6cK/o/lLOIu91AHwLZNdlcPpxmwKEjup4nqJUBLdhxVWSvhiy3I0dKIT7sI9T06 xX9wimjwJjQCKeg144qEz7JUnPi7piEJHNpUtuEROP7wb43t9pMi2ejDjarEqZBXBsOhUd6h tBknZeQW/dSx6RMGdC050w3ffHb/wb9wG8tYe67KyiN4W1ujMNQt9cNOIenVS145/41pbpeq oNio3vW9fprFLeQi0D+w6xfww63boRIlv3F5DLiNiLouwEiy+ukS0XyoxooQiWeo9aNTk0Ey XBK5kZMPzLael0bsyyd2ImNCst578APLiqWkDIrJrUdICdyZC9svDOT3RwXleQ4Kd/GrobMN MVCwRY5f4toUgAffoEE3ISVD+/xzP7K+qSUlD7AURKxP3BmXOy6H3cQr0jCU5C3a6TrrG5gu lEoWfyX9dmEKXtGF3Ki9S0MrAw6J73UJ8Qqhs9RgDdHxR2NTRZMgSPiVhsBksh0qJxp0BN1v s6i8MoPsxDCWqF2DCrNX5GCgyO68+3RKTuz+XbMT+7AakAFYWXWrvNVynhbtibqdoGG0gMKu HpzVc37D7j9y+jR2iQgTq2QR/GEyw9QycEwyPAlHM6GkOp0kKd7oirzepN6DG3VHy560DvH7 3D+wcAZsBqBnr6U4BMMeU+CqIp31i29a8hRgQfRJ8VffYKquolK0fFuGsEKWkjuc7XOfShcU 71sM4kvrH/u6dDUfUHVA6uW10JHqn7grp7RCeS5IOZDPhqtGBjhS8ADtj0ge2KQPk/gzVJ5M gRsadioHXQKt6JZmUeQpL63xwykYOoy/AcfhnXT6WndqRYo/aDjVS9Sl3KLp/QMC0Xm257Md MsRQmdty0TzbbSJr+r6gxwa91Xbvi+VFQ7TSAYeML3hlnihXwpW9uvHWLn8lbEyzUgkAsjVF j34hq6oMV0Kj68JWTnu3yq9R4MFTXvXxeEC1qlC9r2zJuVw+mWlehBURW6yLjgpZWDt3c7VT 9SKWl13npCrCEDmguVfpfaLU2ORQHGIBZv1MdcdMfPmU7/O4389SM9epfrSuC+fMDZZCIEcc 0zPITsf64N1CvjEemSteW043Xa2nHT/+AgXA7OetTg6J9RusoRRL4b68LITgZV8DHKpis5Da 4AVCRf3hdVjpLmb8zhaVAIT5K2fbGBKLd5TFs9hI34XCmlQnybG2Nh2FWtw1f3aNQ+o454KL ARpA/gthXKhFLvKz1MGyOvQ8ZcRqr2R17ywP1HU6CzhdVKh6SCGH/pBkxn9C9hsQsYMyPJsT CHMKccANGGzEfzCMvOu2XsIccVg7ehlAeFxxGiM3mYVZALl9+nQrXQ2FeTMw9VHoJQtbc0gW lSMcHhIWSGgQFHNLVyDBV/svQjVij3zvLwaY+GqF2/nvIBNMJDCxVn09x3EWUB62dwKK8ASg ckfXJ0+CjwsMRM7S5Z8dmpDCbFU28TBEeh4Twntfo/nhWD+BOF8VeoBVVvaqD5NTFzt0PjFE EyG76PvWngRSfIz9DSgXiG2JgOnmNTD29o37Nen+l/7EhZ6vDp876rYq2Pde2wWmxKnYYLsG R6iuzKjRl7TSyoetQZlH/2//EyvwhSHn0be7hdiCxHkUAkH3zpgIvmoCgBo/hcoKbHquGYzp mnxRRkeFjzLuRghqgEL6ZkclqSB5nBiM/BPNDNnJDrxX4YWYgSnwnJpoXr6RFHF73wwyoIQJ iCJ7rYAUaM0KiJVZ6D2mAP4c+2l+MOB9RbNPwxvIyltFHnEnK06f8Y4ITeEijsPvZs8metS8 pCm/B81TyjNdR6TlqvJSMAmX2UNdYuNNKQ+na3A3eIS1JHkNS6YTnU0OEPFcwJgNtv5zyKdf CBJBlLtaN8iQcsv9z0aTinNMn5WyQTrE0M1rQxytoHuEXsLjIHidMI0S9dvIDjOuxyrBy33C why5D0Q0LNF/ffVpoW6de/5guDF+gGDXTvyeUHamrZwj8dZ+aLfcNbi91sFYGxq1+NDSvwJd ZKYvMFUsmy4x7YB5m6vNFt+IdFepYB0UdERf0fQ/rxa3rP68EdB8GDuKscnvkGOYtqaV+TZv Ka3ZTyBMy1WPspElpxDvznjKxDokRAk9TN3Adp+CKfi/f+Jhm++74ZLlH685QWiJdcxmpBMp Nk+/WuL4sgok5Tm0nW6pkDNrEoZ2FxEjEhKggJrF58LZS6+xzrzS2OAUCqzVJemLhOOMA4PU S7KQar0PfpYFpe+9dOLu0JeBl/xey0pV4DvNCa3RKVj/7mrByiJOMabfrYKKPLczRwulXIKt /nFK96+Z/oKt9v09ilaD4Nb/m8ViZDPViqsGVrHE6qjYAuOr4rigOA14jmFZ5T+658fYXETz x3EpkUWfHp08qxxCTY3fzLsbURebG30qxj2IBIPnZ9A4FgjAF2jfniFIZdkJ8Hw3xipxoozK Yus6XCVXFafuJfCFNw5Xu0okcDH7SVEF/ciFlBO6tWYW+YnKlWNXn5iYK5SGbnJcwAvZi9V2 yjayibL8nEGD3IXYA7nHR6JNojDEHfQIPYd1d95OYjIMNz0o2vFVgjYMQZsBuS6VtXLQt1X2 W+Y1ZaJ2rttxk4/9nNQe5JXitNVd8z4SncZnFg3txLXch/orV4qg7x7vYsjNes6eL6auGPbO LzkbkK4JzKLSn1nMkTkyHAo/F6sqcBjh8i0WMWHIwD0d1gxR6f9zDBrGRrJtkrFNHhDdH7Ck 97bz+XQux+fgytEj28lyvy1HlQwfcTNEqnlozRgSVe/7+UPNyi27faBwkOfZIqa9AICbqp7X DeDUEMvVbhKB8CwbDXJnxUOk9jJKRdfz7J3bWJbUYIYGJmLi/ACnD/Qe4/538AWVLIYSeJ94 LpDMS50ZLSUZlxl6QBtE2JdV7FA/Gc+W7rhn2I1Xa16DXQCFGC6oy5xq1elITWq24vberhLF 74X2WnYoEFPkB5qRRUVVtU4MF3vsS9tb9c+XK+ffuFBSbZ8ZlCHW9oG/ofWcQi6XOdrnq59K qDA9jM7OGH9daZer6NfbJZ4mPb/nRnY6Q3WNwbHT8SJBDtq3/YpUizQ8c/Dc9C2HojF0i4Bm 9CWq2W70YJnb1SAlc42udzuYIuZZyRbXvm1DVbPTOrnki2NKxBRop6aAXLnfX5ZRT2d7bWUS aIo7WZy+SdIv7WeOx5zr56DA970rIVdKW4kMvQl/mHLK6/m2YMlTfjwnRYjeHUfMeAYTxm9T B/7zodNZTkXGL0eMuNGeLhspIGbI7CYBHZ+CtX9/u2WQivmGNNCxJbNElIKFY/+ZSMhq5K6K YgntUyzLDnqh6KHry4hJ3L76OzM7BXsf9t3LP8FgHVA+CU9t3t5HW8Tv/q1fuLrS1nmtHpfN 6m8Hf618qP76mYuh3fjv3ueOdHQm+lheEOuiCcXhcMVOw3Zfl9F6XoleObiXTazo7B3CYpiQ hSCojuGxdbyXqRSeAgUpBOFXKB8+REkyLkjYE24EvwOn76ZNVMY2s3i4IXdZbdzmYF8DMEcH gwvtYVYc1EOW54onsHmyRgOGcyDwYsmKHqmZvhKPRgTtdJ+6d0X6mGctMDNpAEWs08uGWS/5 XMUJxMR5SltgbYTZBhEprlgsHIrSYXTTC8yObNrIVfeiYJO+anejwHRoUTAYXTIYHzBxCcPo HM94/XXjhKovuLLUEkYQWG15lTf4Dqy3n8kV/K9W3vl9x9wT1+ncGhzuUYJnlpQ00YHqq9k+ Sfs6NfpSr0HHMqfPAcGnOK1cN+FwAVwTz+GaxmDmJOUD+Kt5ZHMaBJds6Ksb3vjgIafImnXj 6twPGEZUj3d4KPaNaIom5+Ot7vRBCaURTpjr34Jxj40Xn+CSb72VHbgukAkVaiCxaXVD9i8e VEEtzMbguUeOwtxvz31euaLl39PdX5ZAIlaXhaH16EjGl/7Nap2+KHyjtTzR0ghKIIjiQ57O vlBKILRc3OadBVRrHefypQtN7eQ+scF0PydvVm+5jQqTKBt6kPBPgYVDXW9vYFHU7W1QUIvu FELGJTXhY02GMnPfVKEYcU5k1VbBFHdWfg7HS3JEPKV2aU2/uIy+aYKKHtdXc8kxjjzkRDM3 ++0D+WhZff/MBXWyy+D/CsWzfU0bytes2v5Kv0V6DAnSNdh2hdF7epxadx0yKDfA/3gpHbvi o7d2cqVXIPwdBF2RDwt1hHYAcsc+ICTTW+SJIkhx/TMt6gV6DQ7keXs0H5SBMB8UKFhHF0bw TPhCBtE2L5Gnw+fw/uw971flHxDf4KfMqPW0bo23srTnN8EvSeDJSrPwjy48NpvW9nqBdpOI qGBNB+V/bZJ5kmaTPbHwoi9PARqTuuTnyOlVokksL2YIn1J06X2RA7WtMaFAOGxBtaXLIZ9h PU5rBCwHjVVQDw8adBT3yD6zZ91tP86XL+lrYWH3zvLW8mVJ05Idp/sDNSNuBtx9ERkDKo+E B7PqElQso1/wQQnOugKFwx74B5whpOzYpOp957v1EMXTZgMx/R/PgCI58i9MESIQr/pSIZrR oA7bbnrqwPxlEdk4zYyndvSRDCI8MRon67ZMMKAUUwiT0Oiif4rxI+eJ2FUzA7QVQDfvRr0G CIdNY81I+ZQKQBUET3hQMI4lGJ3Fkjg7Vm3zHkOxajkyc5HeXiXG0lSuLYtmDZ0bq/O4ZAan BjxdPeuqNmWArmiFY8fQiKkjUKLB0t5JDBAjrob4K3KFzhLqHmyxqxSvVpWJ5DLEv3v/oe3J e4KRzva2YtLCFDjDY5ykgAa6VEOeIxihXK/ZKy5L8Gttf1lKBqBQR23i2ijtMxTJE8fwaZWd MRtf9++0jAIm/PA3ReALVOJRJGujC0tBOCn2Swp6g0PqSxmxO56KrLATWizqHsjiqHWIrkhP lgExORtHQqeU+9tmF9N78KWobsztS4lVZNCLY4lJBCXw4y67YlZ3Umncl6Ex7w0/n+/StuYH HUgrUj+z9xDUqQOY4DxfSyII1cqT8eC1YKxk9YwI4F+uYwfYWksSPA9+NWFNUXS61nd3Xd+3 i5aCElccbQKU/DmkKwUdyxVVyXXNScq8/oLlNDqanNQCPpclCPrVx1qK0f6g3JhAcCiRoAmS HLNftaET0PRQLcQoXFjsc/CB1yrf6ZANfcQ/VQrC9fUVzVzv1yu4KLV/EaqI4epH5REqZ6do MWa0BYKqc8P/QbZZIMc6NX6joenDkN6cOBHkEh1dF+9MPa9Dcij/dQefGLOaPplkNby9AJCW vlsFuW3ITq/oGU+kmzwftuDiJphCIxQeTnB9elVB5eOH9C9a466uw9AZSUMF7mHWy/u6GRDM H8mgnj2pOqeYmOhmgvwYGLX4UnuZnf7Bv/tpnMci/Oa8i3kvKm8d692XisvbqmRsWrY4zOvp SqWLBd1l1n9JbPDxp5iucw7Sg6GOKPdWvXViX7tETTvM40jfJokXCFreb33mD8nFKAuRee0H oQ8Y8WCWX5UjwNMmG/ni7wmYsHiz1Oiimh/g0Y8+ZTbPTpJzAWt0jwjoVlESJQ1CcN9cUgL+ BgjKwAvGAlfTZpRlDLEBDuc+ucGrMR4Yqa59rqlVSDtuJ/Kb/KkzeBq52gZYQcZdZtPRMxPO z2RMksjjxJDgfOL55yPrerVgD4dhx7h0VelGxbOkYeeoIiLez1V1/mNz7xq58wgeNud0vej+ a49OSKC42WbC9i96YOD++ROo1chFOCIHflN6BJZa1iVp91NkOALcbX0f71xqUwSnE05Z/wik uKEo/2Wqz4dtNr1cPYltZt/FjBZjlbrFDWs1pSEo26ziQytdZ0ncc9M8DB/FkAEp91AsNKXl WjHru+6R5n53XosqpRJx31aAWPkk0aZTxQ4gj9XXDRrpwxBjVbbzAG8Ls0UUDRcbyzEZsNzO QHDaj4YbIk/e0dUgM6wdcbHCCZu28LM3IiYg45mdC/87zwXwCtGeKZh0liSqk8h/EOuAKsjU oXMZ1x5l1z8V6t7TbaPTADJUo566Sc3CkGsERjonGkj109OJcKtdU4BRGr4548LLzQVmq/hq zpTLp3o41YX48WgL0YClanZhJ9vQOAA2soqtWDEyEl35dcOsazs8UfYk0GxY54ZNj7GwkHqe Ap9NqXk19HY5zasd0jy3edBxO5O7wWkBjw/7fyeuXGuTv61s2hQfS7WkGZIFLwoju3UmUmxx TMPprx2KKhXNSkTBo4YZbVP8PeUs0kfpywMXNRozliuHbjkBEV5LaDdrFmwpxdIUccNXnsG6 sJ7YIDNWQHTSzI1pKcAp2g6bMNnGYIZuUC5bu3eXg8JuPP6EoBfp98oLo3cMIDNGcwDDie5p PCCpwUM6JO4iQhqL7M0/qIKC0oRO+4GXUpjjngnDUUr8A4Sm2WGWhLeh0M+9y8bGxZ9EUiL4 j3zIJFdhprmigqwFyVcze6qXbHKou74frC2r0X6PgOkwNjh6arI2ST3kmkS7A7X3igDa7OaN eGRvm8TUG2d2m1XtzbEdCp1c4Pp8jBlGNln2Nstrn3akfrg83MXtcXL9UoKL2sIszDGEIrP9 oY1bOk0kbDop3cHSsPXrFA895Zwksh89vyVb729a3BTGzWHD6sK/XDuUaDVXwgMMFltxa4BG M29bpD2bpGx5oaxJcRW+fcjTipHJHk5GdMa1IHQlNHf//9bqNAz3bZ4fjnB0YdIbsmMFLRO2 9VgQKxZHmvVNLop5h6PI9lEvA7vpsDjcpSERniC2EYpTiMUWzuNOHCINo1ppDX6Ytc90Q98o cCwm33UIzqEBdIXSy/gerQrOWbvFI6ZDSAWMOvikqH6HhC67r9YucGLOXEx9h7yffrBkOsdm SAyiZ1hhUvznvC3lQ8q2kvQoCRY29uc1ZenMgNyAHVqgi2WeDlwXIVs5NlY/p+qBzbIM7Ins 7yoJc3VMxjDZNcgyQTI5AJKs/NaFE9WCnTW+xvhRTUVJdqn3sG4lVBSIJKbCDkNpgVFngJgC 8DSolHeM2y+yoMJuQh6A7jIZ26imcb7sPqKPaonlGLfkNkfzkW4eJdy6OUwEc5DdfUruE7pJ L3y+SL6eLpgg2V3Ec/PI/eWtXj5SBQSwOIXk/E/3TaH/euIt8Sd4asYdXdh24zZzy2lyoaj6 MF0Xp0nmdph+jQaiihI5LRFYpnAyS5VKfqeqF4UO7zZuZ+wE14bEKky3W4qwFQ3vf1zkuy4G rpkrlcoc0wd+87rBkrVbW5bW9f85YAqjxal3iCjvmVaJJnYMYkkl6c2fBIkdLkuNcvajpKL3 teH+zYpUB5czQjIDX1NjxFaYjjEUbPavW5K+zyGIspLQ8ulg3Nuzih6zYgAjIKaEQPrMDcTb v5hh8mDEH6ksDAOnZj/mxjqYMRg6aB0Ni98Q5yCgyvivTowu0nXH8FkqxtNgyQVnghxjtd1w O1EhciCrA7QP2uzwG9FbEOvAkRXYfiIOk5qwoi048zJRykg0O+xix0VQPE4fsCWPE7V/5BVO kAN7bbqHlfv7lDeKcCbDONJgl7w6roUMvhxWHFZRt3+YZsADcqADiALnqRvTKle2QGuTmE0j RuuiGa6mk9NUDAwUcK3V06pNPJdy6nQ5yaPgQnnKQkwhobuZKncMjdFzAw1Rz9H7q4+WZZEt 3MugGQ2EMuq3ZTSvmIw4pt7cnnvpyr4m4DdvhIpHYiHgyMdW+QfYdwxyuLHEI/51OI+1mvSy gaAjoGr03/N8AkO7QNgvnhKDbZcHb4zDj6u4d8GqM9s6RdyDYE+srpGeqeiBpyeLp00G4h5m uuXDik6mJB/BM15mk64Kj00hAFdEpPeiWQs0K1WvLIvdq9doCFtdjtxBwriw1h+eV+JjXewF zmQZm8yBI0S2kMAD0xdrCilw2mDG5jU1EDQtVN2NL/DOYNqG145KKwg9vBHlqEx9eW0zMFH1 HvH7wuazuX7o6yNY2lF6kRRPbuztZfO0aK0WweZFdDNhubAue8W1Cgk9cKVI9RdvvUwBA6K9 lDz6DKn7Vv8GgkmrTRikxK66dNEhTOq1Fa9uZbZMXEhI4GfnwSphi12ArnVe0w2XK4na/npu I/mKbaptdFhLBCdYXESKU/aL2n77Z9J7N81kctwqIkW7ZbmCimiVIGlr1n+PZ69bobnXbn2w yyvGw2dl2UwnDEfYVxlT3iAVmQp938uxAY0tA6eu1WbuEUbk4dBOEK8xN1B4tXPJRHLLe1Mn ZHAW+e50V82Sr9RcdzS7Dqy3wuaC/0MvgM398vUSFD2iMP1hZlicPN4gZK72Ad6wiCaj7yXJ PyVQV5W7Fd1A72DOrmpBAuUmKeGvo3EVsO2u1LTe61JDnTYl5xPyPZytJsyji/g5BlQpJSz0 tOW1ZqoIqDZ1odynWBvAAbdRtKlK0uEoXq72bZfmGZLGYFZ/nmtGqvyLVbSK2GYX6EJB/Y3a gBm4Fjfc1qgGVQHeGxMFLxPamebkCkz3N+KdPx3r/wvE/QMKCguSM5dKAp/fWjJ14BHNpL8x fYge51dTJtfV66wI8U+dmi4u6l8XY8KB3wmnkRZrXIqrUASid1qgI2mkP9IBu6UU1CRNYIkl 9mP12LjReIGyIZiq/nkQssW0M4N0K1FR/Dbp9gVK0+BeZ+KGjG+S4lU8zhl19TAJpVvkIF2B hicz1eJz59+6XGh4N3vdCCSSuJo7wb9WKl2Koh2Ys0FSY8E0w4b2zwX1CbAHP3exsj3cpfdJ ZmisIpsc7sN4AyRa+oTWUGgWUyBLtUonAGg10Sg3ggVmkn1SaKZXq38uila4t0wAyH4+ckJK C5dCOzHrAnVi3EVmyOQ5WLRbmwb7x0+lVYid2P8z6p5uQh6W2uFulfOxI2eRu5WRtgEgP7aF m9lPu8pwHa/C+fNtqEL4zUs91qUKI6ztKRWZ8M8j3eqIesRTNpK1cMiKF8NMwOJeht3Kld80 fDT5f5PKzvKBl0VOsRqc9SRIB+d8nEfWUWVPGlT/t3i+VDCJmi0URr07JFEuP9bhUh7G/vsd GeCH55saZW5Hv3Yvhi0+7cFS8CdzPMGTuyIP/4YTJwj3+5HgxGzB8two0FWGYyMGd0VL0LbZ CdVt1y78Xyq2DS+iJIy3t7Ve0s5xTTl3XruePyRDbTYhx2naGxcXw+m85b0gH9OjKaRPViZb XCLrr9TP/iLxZzbtH4X69e01O5L/wcGXXgXgF4DB+YFZ/DQhi+qiEBAMfNzq4/UcF6We8wuV a4rS19brUafajX4QqT/Zgpy70dZEUHN4Ot3dgIA8+MMOkIFISk7fxafsnxLYwjYcWI3llNZV tgOcRoMKGp97wC9y1ucnBWzKMXIZ0aAKZ8PuEipM38JHi4uEkxvlgH8gSOe15NijhYB4uBoW 9zi7N3lAt2z73JFujJAkY7IiueOda8X/HIHWowC6wC0SX7qmX5qjbW2GdjnMebD+uDRb2Rqn 02LM4da7LzutS55vghzqXDBmR1cJUX0dL90lsd2Xp96KkfCrcLWZygZhkqPiVrNx4FWy94AO tO70fV1p8I9UulBhSMA5ssK2Ltu+qFsVywVTRxbm/vMtvjQ9VWK849KGQkBq8hv8NIXzuWHX c/fQQxJQMxR3ox525Cwob2f3s55/VIqqYqwmd02Aa/iK72jFP1WdL/aO9ABtpIIw4ClS+1FC T5+ZRJy6Nh4HvFzssQsnRO/ElLtpE9iFI7uNWwpCuyApGHQ1rm3Gn+9p2z7usf4LMoaqnMLL Jith5JUypa8Nf4YRIyAEftJpB3ulSImCVnJ1PjWNwt5fBG4Siwuhznc4UDS6s4gygdgCj0Tj 1VBipEcAkGUhNVG+EbSEIRHQ7MKfMZnuaQJNgwvgmIudxwdBF+72juoiEvRM5Yw4tun+Oxsc rO94QSt9z1fysiWMz2X97vSa+/mbCGTO85IDDQopoJ/BeFUNzO8h5LiUknX3M9p1KlfAUCKv 7kpc7akS3wLqTcLzaLj53saL/8xe+E8x6qYtlpNlRTF4sDfm9wDf4C7krAruSsNtBkqxzS+Z V7cRPc0Jx80RQCWhWB713lo6UcD1UqN/Bf2eDKzqc3udQ8B+rnYcT84rx6ZUacuQQBwQj5nl cNe438FSGZTOAXcDT+jzc7Q0hPdceMDYnhshDQQ+vdJ38KrNHAR9tFAHb9rfh+CW6M0OqSHU QEHgWLgZ8LX06deaEpMpOKFB1BYxAClJtOI+h1qYDHZ6vCvv4rC/48eYUvIg3c2eeTta9egh mx1LUjbiOjyJNPx2ZdgZkOKxn35+/HgpIbakoGxMzxNGd2dVoz/PVE5VMLjL4QGt9JYmia5V Zned+4o3TNJQALueHhVwV8YQaLUQAROFyRBMpZa/p0/T/Jpz2ujLgcbDMBCzyZpLg259PyHB xMgsOUDO4gzYPibTMZfHpCZJQqmyOKD6auBcdHdTlA/OyiDjP29K7bhXFuPkh/4cB0z8VqUr h20rQl2+BNfM71ZeOosJQa5FcoBlq/Bzh+unu3Sdg+TEqO9iPBpTW2WjYmnEgzxlnF+GN9Ut Edgjpy0pDwOmZAJ8kOmaa2xZpA90q01SZZzi1Vmsd9BzEQf8aVh+QIZy2GsVry9ibRK/rQb3 i0vJZJvt0QXOmIHW7jSveLXjVlrJm3U7OvFGC1+Tag/i8aL+7iYzVvPhzqYoTV/+/2mzz8vm fe90xlpTQ/+o1wiTFeDS471e+m0eCuYeUkyP9a2VWferOBfpvPFilxRxiXpn03f0PXEbKvoo hgZHeHuUXf8CIGplz7gSf1gpfj9pOBLa2uDe99dQUnkD1ZPpukpajEyX9XaxJEfQ/i11Bb80 QXX7J4DPlW1GqpPDCbVDZZ469cqSJHh87kJeldVQEzG6PGVI8b6TcfldGGWYzOlEUw5BAl/B Rj61HYIt4oS93QrQX3OTvw3xQjXorJSYCunIT+Kydrep5+tMYES3SmxDHejcnkYJaqWN1Ah5 ddyB33IMgVKuzCqT0vxhHjV9C9CnaVK7GFznm1Em+NhA5exkaq6EdzXRj87uJqzNIhweWHgT 0kqRgaYn0vrx/I7hyD5vZhde0RNc8Eh0vChO9aJzK9XRu1MbXv6L5x/4BKDZXcMWE0jSHj3J TWcDgGxPA95gbx4BkjrQ79qoW6UyaqAu7lNxmrUFoIFLaiJDV1JRYE44G8Bgi9YIaGr5eToY jSTy5kTjFXeX37A9eeqGYKeQyDOrs8lr+34r+VbWC4tPGA0C/pCObqCo0wkdtUhFifkpsYVJ KzcsUyex+RZEFo9DZ0CcDSUPwrln7y/F5+1AHAIAFcB7wkSDTDfkVd0+iIfL8PMmNZ39ZOn1 TgEL2LB5i5j11jgYpy+Mgf5maEBgK3riUxD1ZY+dm8TggX8C0Q/wxw+KA4EcNEFYfeVlKYTm enZC/WrUp1OuiFwgSNdYY46oqR5m5FlzBnb7uN+HTN3ygTjEGB00tBULn5MMPuJJosqoN9bF GiRJjfTVDJIm35W5Q+Cn+83ZiwqV1UqneTPwx2HRU9vISAvB8Vvqb2mcpRAI+Q9mtEjHmvdb iEHc2H6fzN/Ubj52la8JzxSROwqV00QoZ++4l32NI9PMqP9Nh56S/x/eGEC9lGIT91/MO9wR Zh0TCsOjpd9de0y/5CUqKsuUmP6XB81JJ8OuvJ2hsdgvk9Zl0No1JouUfm5tMpwD8GbFY2dZ ac9kT6po9QZGN05PyZkPJMYWTLsRco0uoMJe42Vi0UlIi96LJz41XBAX/90gaGJWOi2aWtWP 6F2zLf6eZNNEBF5Iz3fP6V1sOIucfIWk+BDzchxRr7ZgiyqAcBbDe/zxX9Y3mRWGEqdl5J91 A4WtEJzMJubEkdn/pFeH2HbzRxVcX1gREOnGl9nIfftyWEKvRKHEy9p77OnjtxzdgXVsJmdG cS89bGfgUxeWAKjC4nz61XW04EkVTcywBSVDjqM8Y34hFfdrUE5ciMb2NlwDGeHCurHAaXF/ 9BeLC0WrrGyKuVFw9SSXcePdSnGt8aalH2uo3m27JsIjWrjYQ55kToG8RHUZ8/AuWNp9GjTw cAEc11kPTeQKDLcNQAvgcm5BVSJg1CJiywApFu8GtWZLrfjCOXy2QADh5mr49wtTwODF4wJR NEFpPD8lHRgYx0PzkKZonJG0Nh9zFIWYzk8jz9YXdQH+gXspWgSYLsXY6hA2KoHLtHBSaln7 pIE4/I67oSkrZtmf8dw40t9BepePqnWAKqCFFecxiuaU4VoOFrKiEjMHUeWKgpdsyQ8zmqES rEJkLTvkxBKPPTuAHh89ayMN3sJUo4NfV3M2qNsj4v1Owynghi0Of+Y2cZX+jvu8d4Ynug1U 7z/0fvv8+jSOxj7fW6E4i5zTXJUP1ViX8GTimD/zSIWHmCRxXtWhVad4HQ+fthxLwPwPHZBf /Ywt3K5ARD3GSgv/S+PLRGxIdgX1ASPw0qAagkRn8oot+54Ypo/O4K4dXbnSPAl+u2gkzdOi 26ZRPasAPQvzzj/XV+eHz3Ra38CTAX/kNvU43s7dkAekZXCH7gQYhRmnRi5HGshABnXcL9Qw pBU1W1hhmRXg4qk/CXWVzEq9SsNkik7nP5SS0xXTHTHlNRiZ+dzZaoSScfLLcEiZpgZ6w9T7 XN4xWPWp4JFHOnmZnnVl/vhUU62FwpMy34iNohskct5WBttNITmMCj8CyhUnUXChhiDiai2L busLn22mXwVu63exD6B5Nsgod2eQhUxv14eF6EVVL8ySqyRkDhahhZPS6Va08MPIy93YPAxs uacvfkCTQd1i0ucGTt9/poy3vUsQDlsfryVkj2lkFLb+2ndYLAsgg9/yIhSJzS9HRsTx7MMq Yko+QqE+Vh6LStVbnC9lid3bkXmbxMQLWih/3d49GFrFuGWl+HX6pQLFp3MJBB/wWx6URFrA QIKlQgGhNY3Gtz0Wji2S3qR26qQDSk9RE/l2DiJy38T6zKKyOylVdtjcFCVjUWXkod0cjYnX wXT4nmNEm+cexkjTWbM2SF2CRaVbQ7BHlT8LrhDVEbQZE+6wH5JU83oUr86tmUB4RNDrcvyx KsMBaLA0jj5g/SMYyPuNq8aq5ZktzapcbovtBY0yh9LmURsIYhX9gY8ZiMjxz9HHR7+oHG3c nLBD1Y/cB07Bv6elpp+iOVbzCUTFYeXJjbaLWUSePjDXfmrAIc/AjOQrrnim5ldEPLcVFx2W KvHsKGK1MGjnoludX96gITCIyxbRQL2tjOJ/7XbHp/yTHNx0/+6M8SjIfTDT/5RaW3Wx47UK Jq/9yBNp3vw4NpR8K91br09SVJJbfiCJPZWxaXOEinmiyApf46i59Vuu4oCt5sQLnncK3KCT mVALecW2GHen8IvsDy/l4f1GB4seQDSVkMosZlTNZ1uLZ9mEsg7k4FpqiI83RMOU5g+K45sg h1sepfpSlRK7DJXJyHDrv5e9jj9kocXy7Ooi7poOu39mFymMRzMugS2DXU3WKppkU0aHRSgs BX0HDOLUKEBvmamr8ZR3WLnwlpCbB8vMzm68yxPnhtpjme2DTuLhtJ3CgrHH5I4jGhHnTQK1 8GOUG36BM78F9rQKfidQzbpeUlU/Cy1izqMN8S1Z9D9qnc2hcgPKknVgzpzNV7xg+uYYE20i PTsFv7Oy2ZyQXuB+RKTGcharregGKzXVnF9emqF3fTaAXAkCCJ/NS/PeucO4R9aAFcD8BKkx uyzLxEXSU7Bv4/E+X2PkAHcLWGKzLdz2mhfRRWVhMIdqrOcSsjVPcfSLVd271YAiTZJMGLsx sNM6iu1J6y7iw7Y0sTjRqFRhK6T0Ow+FHRiP8miwGl19dTxlZvVv+BRDR6DpVZu0NvUrPI/p ibq9WMoa/A7LEj9GbExRtt/3Mx7+wTMW6Q5ZTafpxfRLyZ2f5qORlh+toLoiO5EIXGJtbCrB 0fxPeB+l8AT4wCjvGLDEPfSqypvrOgRBQ7U6MbvL65bD243zANDIYLONWlluzELeSx6HDHpx IiI8d4Vrnw4G03uadb4PJx8SJPbbSt9NpXTbABJd1a4IcuTOII8Zd98FU26yWBhTZMJW5K32 qZ/Ib7y+HYoqYAJTDQH7M24Fz4EGnl30Qtt+KkBaYgnvtQGfK/TfjFzv8ER/gAUOAGtTMyCD Cyj7qH0+hILWEwO+pMqC5BRB7puwexR+G5Nu1An1S9D5bEsPHGsxz6ithvHVqAOWe6lWydHd xbJJyEwKaALERAi145RbxmqlEHxCXGN0GTCIxLOeb5UJNGU6Nduz+jmVsQFj+ZY2n18TDkqw V1YjyS3RuOpcv7t45kQaQ8SBPTNYu/yXVRWqbrbQsl6RMq1hmtD2D7TLg93IQbAckIQ7ppV2 fzqChdR0kQ/X1H2Su5n6LBmz8aYb0lXaflbLEZML59toCMwmpfJSu9Wk05EVWPKzGIIK+/Px 9jp9my7eqEpctAXaTvVfH4fSsvL3Tj2IFOSqQoE30FNVezslDEYw2cBgfYd18KsR4rFqrLAB VAOH7C/QpZKIVBequRoCzWROLFpm5u0wf4DPtECTNyFudyu77OLHQprzDZaOX3bt9w6+45ng xHaMUJMq+zu0kfKxBU3ebZaSVRuAX07Ctsb65FDEIIhsHNSz+l7S+5mNnURVc0KGQ8CRaGm+ NYYOBuwh3Xxd37rfhtaCAy+0fQ4KEHHApDyuOMkC/TdLQ7UA97MFBigmSl/sjR2uogpTDokV jR0gqHGoYSJZC5UEs/uMHxlyBQkZd3kuieyhMBggKoZ8jFP4jUsoEPsI28/FTzJQMdjDLi74 lmJ07gOmYMCldnziuABoyyXv9tg3MVY2RVULCOHlRpBeTDf4KNuRontDjh1MxKugp7rpsvF9 5XVNJ3VVxKwFNXFOFCsyL8Pj9ItLjZSelhMRsebuzTvk59HQebp8oG98hBOfeJTnFUAPpItO hJ9pcwNyLvvaymRZII0jCbUaqX5dwstT/Ho+aNklJ/3KZ64X6R1hW05wjpKXyqqVSN9YnaEt u6eApgte8bmQRnsUpqsG4WrKuBKS7X1P9BJYEMUgblFRP9LnkRZ3xrPj5oy1ctjbO/U1imuO pz/BpUYBYqIInUWRlBUGQHtH3eVl3rym3554IJcY6KlOAc+LddRqyfv67GeAWtY83qSLiIOD AB15Hz8K26fRkR4OSBa/eOXIFwqwmiBKsk3zNEgBVRVxiJ3xFei8tDLJb4S+EYDEqgBmw4gy J1pOBQzBRXlc3ZsxSad+cizvf6eNAim7/mPZlLaQBFo5MBK4zL5z1Eiv00hsyEchtKwlRsA0 x1H4OfZ/iANbOWpn7MQHmHqEg1l/OH4tFkW8HfcebK8jyv1TAtfkOXn1+peUOzDU1BvJCK/1 OgPYq4J3uYRwxMrit8RdpgbXMlzYNzV82+O1akLSmuUl+j0hRZbFgiZ48KfvmKpgJXHPxPD3 NJkW3JPpkyt9/PrtWUtEMWef0w6ZY8tCM2js1cH7GFWGmDw9IXpRtsMNSILnHwuY993p0X9n mXwfudmJ8Gu1xx+wfJWuZhPL42KlODA3Vll67ie4tyJ/PllDgpVvcpo1V9R5FNfslwVjLVVN 6XEoBETeFto7CxaPcRIPMMjj8ybXsW6K4mYLs6F20+MqDcroLkX4ljvz8rPcvd3L+SPUa3S9 cGBSMI2BUn8j3xQBhlhjD3yx49xz+hIh0oU38wkcQP8wmqDX0SdHS4jWh/1avTT7a4dKM5YB vPLL1afqojbvgraxvyQdYj9CzhYqHisbVSITlvXQ9yiKNi6OB6LhtIKFD4k3w4dVoN7Xpq/V Ggk5NOQrI5YJYRsN3JKMIG2TChJkp0fu7X2WQ3GNSSSR30rkv4ckpSYrwxq2ib/t/nUYtB2w tJyPaFhxTw4Y57K0y6RtFqBl46BAuOrXZNwhKYZlF945YLM74aEbQRhmqq7kpO9C8heRn20h ZtQI2bQBbpQWnZ9owJECt89NUUOi1vRIB2fF1S2bhl5QGf/Ts2wHLTaU13MTe+RsPG8Hvd+f hXrFm6LcCOnjIMO/U3jaFClIYJN7TJF8piwmh9ykHiSNMDy3FX/s/LzMbSSX/KK/ItiD9K6v 50IlaScJPkU8MOUon8XxPYcifl4xFURcaDe6dwTzMeFmXENZ/yi/KcHkMxBB5G4wAZi1Ozc0 fKNz9mtjp7MZYStvw9eyLGB5avUGT5EHRmFmgXg/6dvLu/y/cyQNJFcEMajhz+1KCrPwB3Mc wH++8+WdpENwkEln+Ez/hysQfn3zcTBPYxMXi1UB/hqP9Pnnlh6OV6BTNADXzAW8Lx3rTG6S 2OIKpqWeoodDCLYBBJACXQRon8In88G5C3TYVTl7CkUE+DFdEJw26nmOtvLdnFeoL2KbUZuS c+dou6j8EB58We2ct+PkMioUOHpjSVFKzqWIbQG33hM52wTN7snQJRRm00gMlE64mM8QlHho DvH1hSweYNRc2KuyWr2WenBqcmvPc16XuD+l/k9bFyhx9d69uI/Zo1wv1PtE+8OE3gNRXv5p 8DGcDUR5KRkfI3yjpf6y18a3eFrWu522reQ6/wqqdVe8AT2sMjjsVnMIAiaTVaL4oGjOrtMF T0pNIAEySSNMokDpevRbTQZH3fxWF3P4n9lvQog1ePjw4mjeffmaVqAS7LAVKNUU/GFfdPtF rIWDJJq/njOYr6kxBRDYq+GNpOlfd3UjdCLeloOsIhRwXQrfVeYqdMWEx8unOJ3ytph6IDo+ ZFOn74J7ADVy+Zp+Ba2K5ZgFypxAgl29Qsv5LBjZom+294k5PfoSx2OtWc+oGkbP6VWMV7E7 M7cVernV7FPuJgGqNnE5htSsrkSLwjNzheuCvWVhs7Rd78bXcLBU6jfpMhmucfkVSzRPs019 xLd3kCvLLomavh/0T6AleALSP5CBl/dFzCqi0EM++C+M8E8BjxLXgnD7ZXk3ZUvVarOFuR+5 nXuWFthdqM6berdczlwx8Wx3EP6MwyLkFRiIFT3CVR+g288m9JCnhaRO4ApgWfT9ddmx/6fw myxQsA0GveXBjEVsnSm2ctPZ15HYq8hELKD2il/qAyaDX3KqgZRc1+uF8iLVAFgbFakEZkj/ Gh5ZGGf3pEClD/cwUZgw1qQrd3MJTQJt6e9dv9mwmTOTRinaREBHwmIMHQeKXsUrExtgSfj2 2nV+qf4f0llPtMb+HsBVNvQuyobV8ePlKcvnHrkAmtxepX6rCZL2NMFkHnyilonHBkb4knlu NSJHtsuKFoC1cKjx+gahdbw/gy9GJnmFdRhUilJANp6LbToAFnQRMYp9+iMcbdfsPFLM1aoW r86whfF6i4JEg5bUOxVHqpzDM4c79b44eTkittG3hUelBeGnTo0lW5FVgXPWrhDOubnJTuvM lJfyCnHQ5autlwA8zNIi5XMk6baxDu7phNqmDpNGunUq273lJQAax2YZ1AUTU48PMwCh/9k8 yl7sMC12X61IS/tcpPGAgjn1CZJM/GWC1clFShK7Mpc+rvD+vQZmbZKSbVPrSbE4Qr9pzIYz 4ODb3wHowMNZOL9O6vrtyP5CF5cfLnREpx2L9cwlfN9ELmOOwYQumb05WrUJwGlAK5fNj6y1 apz2kkq7DOAFMCQ2CFgszmncbTiTqDWd5HaKyrOVaDVHQFYy9Sl3dYwcRaNoT9GHI87jJ0Us lURhJAC0QMKYtU1OKcyF7A/Ca0q3OGYecOhGCJBSVC88lh0Yamp4F9RUAWHfba14zel2pL9H u9+NNUVHr1hVfySd6e52EaKp4aZVAHB3WsR53Ee6KtDjiCpWL9YVb/2psPTUUqN5Be+jdSph /5vb1hPZgEc1PLZ2tLVpSTov7LHJd7IyFtnZed03NirBN2ZFO7FLYRVHyUhMcBhw0rvaeVA+ 0bGi+q50jasDwn60LQADwBfr992URuq/4hcz8i1lfHtJZ1kiO4levB8U0FtegeD4pvqge53w Y+TJZxqhyFxyZMppA7Jet1unJoKeBb9zkRMPgseO6P/o7aDxtmpjFvfi3TW3SPM9fw8PFsdF wrx3IpHLwGYhRgEYsmHenoZTjFDVZigAPYAYCrhuhcDTkCbu1HcwronVAbN0r9N5S0zatWHI PskLQVQy/m+Dknr0vPjvIDcSO62ApCGZfGvRpPiwujoiUAmi9Fa64AldECuaRr2yPLNxZQ8n l2YCzEQ6sNVaBwO1FmTxqW3PGjo351stt0JRsweuMj62n4BD4IfsSnv2p63nFU1xImX8FGWa wvsEzSyQvxDTpPe5oNIzDxkC7K5se5IphE6DwPUWkVXo9vYDvePpNhRf/2oSwKVWm4YOy17i 9EIm0RDJGL+LdRrlSmBhAyQFrlKPL189UfCV624h29sruoBFs2yU+MZ7bPZMpg8vdz9m3fcv PZUkTAl2hLVHTCHGwpreU75CfjWw2CRrvQrNAWQWBOMe8Yu4HelfV7Pzqg90CcEixxnOn7qo Drd73WqrdIS/QDNeNZ+E1Gu7d6lQtcjN/IVn9ucBI+H5G1u6z1pFU7m1Y/biXKatglQsXSmA 4GNR+CQyjsu/CcSbT4gNvL8MkYOoA5Tmx9Jwm0TJeQ7moZdiqpUQzt14brLGTWUK+SGES9Gq ttZGiNcLSj5Vh+PhCTwP5kRasfEYIpGmbzuKzOcSxKaVxujkat4fY1xY8h/1ShvIu549qpCp mtYjoz/+hBXfAFsZvDdJa/pr0BnJpQA+0Y3DW0kAg2AQY04mzeaymfbzry0YV20cLfiPPV/h Y9LqXtgf8h5M0oC0uDTaI2Z4Xwyf4ooXC6pYvalUAQUmsEnbvfGJ7zn7Esg2Ix08DRsn0wFZ nbs4by0biuZuvQKvGL3+2humUdYjCzCYUaj5uu9b79N9gQ9G/OgIodDRcyvHUmIfZ7cB74oc L6cR8bnyLmNRVRfjsPT5ew/9aqj/PeHWqtdmuQlB97FLHIzYq70My3/aSEGw4nNns1wIrqAn N0THLGmyNgowor09+e22reVih7BGlWYeipbe1DMAP4HScCJoFU/4VJu1t5Jz24Oendhd6raq pCOqzgUihnbQoKqROwmy1LxP7ig1K5vZVfU8RDNKPUZMvJPTQ9/QYVk3/FlDuGor+hMOGyy9 xVwgQrdGzquL4t+u40hD1Wsc1O2DAfE7Wys+TWi5McYwNKJtGIK4/ITTTUdnQlBZgy15/bfJ Ojz6xKn7iOdsEW9QwKhch+x4LPa4vmuKX9DE5konsYaR8++6DUid0DkM/I2OXbXzhyz4LNBZ R/m5TU64wJbJX5QFvuWroAhCz04BhqP6suj0e4UL+m2bK4//LLXy76npoZSeQJ4uweOvzQ8+ Blc62RjkJVs2IlxS5XkSAoFJlUZpwc2ZekYf+9yraPUdv/iZe0MEdIUTX2jEk6trPWTt8jHa HOzNZCyVcF60ULhSwRIYz3eT53u7DN4O2ckL8rV1wd977f6u72tRYp6mGHIQ52fVoQIzZD9V quP9s+L02tVw5eCiPax6kOGkmAUq7DltzMbquNEA+DLCNBUubF4wSINxhdLOYqArJUetpRmN ITs1Py1vQLzoVzfZJ6WwFceVAEvdyUzDDh+UjcSSBNv7LHF3IBR57RndF8rFICL0o/CARYsW VgwIFGFaKv96ZDLis1OTDdpvvbNohs/sEeVbJR2aHUmU0nqOW47WmpqltVMnD095KoxUblJJ 6c/YxFJySIW0d7RmD07Y7he6keFRoF/zPIgSLhNL/B9LhL6nEww9U4FhscFFO9dhQVrHckaH 2RT+yGMUYNphukdunSzmDBK+kEjejoQ4D29GvwEXIsKwdd6fcMIU+65UOpPAEkPUw/A9iTWC pgbbfWIAsaM9bgDC3AZdFCAhryy40DA2gFXiGlL3TP5d269g/das7EPzKe2y8Y9eJOjkzVZM 9YacpzLlAXmW/t94YpWpVL/2OcZGLymVX1+eQ28I9OS/8FP9DeHLb4PuluX47hPIZGPq/KBm 1wf9MrQxQV4H+xrMnDRbNpoEDh/FtPN7og/Al8LR4HPzYsqU1y+HaZqsZEgbVD0DpIwyY6FL 9zxpnQFa5TPBSrpXJCI5UZNuHJg5jczpll/BLHe/97ia6MD5N+b4QH9lZA7rDc0x6uxrJyRG pHmgOiTgqnZRYXoJZ/s1/zQ1LwiztUf9YqOYVqoBrXo4fPerm8SX6DOKd2jTb4SZ6oA4rEIJ Z7WWf98Fu3LdPtRzWXiLaN7crSPx9n0H1w/O/TKhM5ThicK2dpmqHPxTC+JnFDDx2um9iF3J b+5KDrfXtAdT3wOzvGcOKhRh/xdu3cBDoVb9NQh7FaPwrQkpuzgXCbce4f20fOjQEgdROaCt 93gNrDY5v6FJCfGgkfuvQm0hvBgDYQikdHlKwSK1+eO6zbY69IZiO62gUTdyIqC49x05N1kr ce1Vdm7A4JOZhhO8baQf/gU/w7fXUnI41KeianHsOexG+9rhDiKFnftEp6o5ugL4RbzzcGUK 0wy/ls8KbIjUVPKCB2WzDfvnz8fdFVGO5t5p9mCweUO4DsOrvubQAaInwCu/RVFojYg5EYCQ Tu1YvZ4IGloLvQJ8M6T5B0opD7A4WW8q4xZfpNYxkFfJDGJ1hROcGMrYQTj32jPNX0BorAtU YG/wHFXrOO8AcUbKEWEPRA4Mm5e+L5S/mE8A2V39XTzXz9qzcHHCeHXizQnX3CyWhmI0A/uU QrAWPSyRaSNJxHVK27vwVajsxyXTuKpEs21qouUUl/PXHd7HswEbwxX3YcjrLZt4Z1QmmS0P rJSh2csdxyCxE6JS8yj/LJNwX18QK4QjIMKZFo/iv37AYkxOuauDI6eft6i668iqyoTyzNJm RX/2H1yjJuEPS5Kyvz9a9IUhG8F8Y4cOSfx4q4+Kct6F8tvxRelpjGuvgAZOcPG92GE90B3j g/xaghK1RSJB3vn3A0ALSlqZBtxOmbjm7hFpD074a5HqQ7RC8tiXIwcO9DUTnk8DqC+Mc8pB wxQyGBR+zezYNix8n1f7K0gHijS0xL1KMhmY4lVnLYHh+W0ktlnA08OYuBnXXekkG5s1zH/n yn6Fk//8JmJKzLiP5tZOFMvCmctdmsJH7gwRND3Xbb/hoJ17HB8bvSo54r8fAmLkzziStZLJ F4QIAIxhRxV3V95lmnECwbU57Wb8tTR5P3exyZq6LMvSopGUhqneDrPJQ73ejjRXk/NmjZke vJwpYv4XkjRZKH8nUUXtRKFOT8TmdWkYWM44H7WzpgEDVuo4a2NFsUanA4PqGTi0yMkr6iAS oFDlPQoABn7Uqq8gwVSze9BRuyrv1nb6QPmRUpACbTcjuwUqiOnDIRTFca51cwaMD+2WejMW wx6mcav4KGGH4LxDU83CCyZJz2epn7xah6VnpHWxHQFXc8nN+b4oZJH2dAM7M/HAmBcqb3fg R38R2fxQ47vVyOZGfooxhYgPNtLwvEplNez9Ki+YkxJLFoZVSBwG07udhs/9q7URLtWDg8Wu /5qCUCWU4cXW38+nUiABscuPBkZb4GEetRRVheORGiGsxXwOq+bSJmdG3W/PR6WD3nxoIvkF cSjPXaiQjd2mMrYqum6e0aaB6fwRwEKJ+QrMlO4m684P5ybuNyWcOAn4oBgbNs1IcnOKNaHR +vnj18EKfi5Xb8ag20og0TK4blYFeiMoYBeV8XmGCxr8L1MoJ2fmsbzelYm4QRvrDYYhmRZm xbtLfqRnMntJpHZmSqfA/Vqul4OxtYoxGJwBJwLsjL5awjP0VibK9Ff3k6+kX4t8IHavpnC4 KTkoM7GGEFF3Zns/WgWq9SbarPyyg0ORhjhPgsZa2JMQSkJK0BVCKm71/Gaww8pQqfdURFIq piNrxQHDbJmZGfoHmaW0Oahiv55to/0nDqVrb9QKkMW4cnOM58qw5+Al642WEO5DXXwNzcPu NSVLiatwNV1VhwxeOdQyUW0MEd2jnUg3nNxNc1VwxngxTaAvK5MG5ZQGl2lopf4lCvQPwe89 kkfGUkH98Dui6eRuBJRxi26Z/Am1TP/W+W1HZYcG+8k/h4b+xyJYFz2mgGH4jaT6pD6tF0X9 we4D2bhJO8Amy9WQyPHA/k9XbK+1BpGduYa/isArNH06A2LSaQBJ6uKVpy1Eq3Q73BH4xvnD dx1mo93KYhekptHmZ3144DszGf6gloSRYZm+21LTnxZh15Xyrbq+qB5vApaNh61PljpIdX1q dCKhVUqh1KgU/gu9+1h/5ers9dYTFi8G3WCUJGytHjku+hHsY+lsqLnJ4LcXHX5XHUYjcDzb AfIABvuDF6D4gngp3HrUFEy+1xiuDSg0DjvrQKFVGyEhOYppm83lZnkue0WwPvPMIc+Nnj2J 4f6XGHtFuBLSNBWnH7DJ81nSYWIXwwU+DG2BG6MTkOJVo30C8X1MtumtKmphuGrGfAVInFC9 gxueaYKzWSZa+6CGnNAHot4J7HVbNMIbNrtVNE8TbmOCuLZYAU6biL5wkus7cumzgODf0uFg x8KIPxwQSTbiIMP0oNQEmh+wxKafzrRqxsT72gWQQJ1FeDl6Xf75oqugvT14OcWV7MZ4620W JDieMNNqfM86YIFU+IxWrTari5wK3DvZMIchWSQ6NaTwjnBZRgXFZzZuRl/HCrUjwy5avx2O jUHKyjU1YK7nmJFnms9ailifTr6nCwRiDK4oynFw2KDWbzAkGsx3w2Y6a6zmbhtl2p2AyNVM kd3SiY9rVWexhEwzgPdKDVxY7tmy5TGhpie/zZL+v6pcIYhQ0RNSUPOPohS0WSrqusm5zmDe iamKYKAWjrlFEzLjOr2nTq1oW9rzNylLd6eg3CydoWKgg2QE4UeKp9ui6pC9k67eMazrDTtH OvgTijsu8DnkNohu8y0c7dClayDdoAk5nJmNDopFm3rqdoe/CqT7vnATBmlrXs4cQwKaMi6N NDQlyoyPmNkDx1VxoGIQpn8qA/5HeE4N9/Q7oVWnXhL5S1X50SVUwCZ/WVvC1Zv0Ax9oiK9f 711OS64bHg4KyapZHieZ1Hxv/0x2Q7oQjWhR7emOAM4teL90bGOJOMwDMA1CRcHJlSMgUVyS 2fMU6S/yBN3TeEbI8Wtbyrm94QgKXL6tE8hPoUVqqq9NS2SFLBeztmHn201HSgVm200vJsr7 APyl095yJceyCA/oIRVfwnW47G5E65/b3ry12jTIOgXyNTu1bWCvBIlDlgLZlLIciJEPBTM4 +QgD5nweemY5OWFFtEX/+LPxZa+HU1HsJxMw7TnrKqqfCp3nEi2LcaU6WnJj9n14J+J1AZG8 CHHdOX2OoAFk9/nGGdzueeXB8qAPw3UFkxZCgQ9t/zoCKsrDed2mMGNh5nldTu913VXE7YQw /FLgYu6EWI0qWtFQiKwVDTCu6n1ICNxoIiy6ARU6vIMqBdTp+Gr/ZJS0Ry95/jzzQE/7r/aA bfyYG66v8K4iKgAJADzuKVPV0My34IkxkH59fqg1bcw+BnxRCz0V6HWXUayn/ciOJfqDOhJy /zrvK9+nH5ctZioj85CS7CpAdhA74EZeQlDf4KsXXF4pThw2mBrrcw1LsXYKePL8x9FnqLGa P7SmWJmH6IVE0gpLMYBpTwL8cBfu+vRIGp3OPkrh7SKX7fQq1Eys+qSpdM5bHmDLwa39HNGT Krd7hSiu6PwePdb4MDcN7ounVYeguyQdCr7n3vuTORIL5QWc+ZGmhp5us/cEGDlGGKTRNXy8 FR5L3U6HTnljof4L1XbxHwwQ+h6uzqw3858UnHmcQRd5A7x6LHZbbRj0f9m5goSFjbA6rLgh DzA5aPUQ5IXxCZysU2rlPhPFzQK9RYPA2V+KMPlJDVzBepDxRp9Us6RHbcQ2nTqWA91MULQ9 pxqSCi+Q1umYlsWzXW/j2aTUII/2JXTlb56eU4L7XCPL3M+jq2b0QQbduXytZPPEiQ/jbbVN OWrndFHUvfBYfNSNLVB3FOrVGVBAIb5KO0wzUNfj6o/rm2NDfeBt1ZWY4gUSxO0VpYa69jLx UpYxMk69f6Nlusmx65WZQ4lD2YxR6Wh8lV3+fr9C+ShRJHod0idZRk/5+C8MMyV9ltCIbLSB W3T1Uilm66aaTrQalOyIUvie/Sbj4gs6ptKZpCDmkuiYRHBi5s8FuwIZKgsyP20uclwjAYbz QUsAPCOWxgM/xaIFmjYniaPA5mvlQ6qN8sNouUD42qC3XVTdWna0fkiNGNsSrOrwuKt4mFkW y1o7LQLju8cXaiWn4mSWvOKHNpT8Gtz6HNegPc2gOxvD7hvMRa24h4zWhbIM9I9HyDSFPdlU cjnr1GBeipj4nNXFs7GviVSjJBpwA6kwap9A7WN0BjG92DZUhDZ8xgj6jyUav4FFcicbxGJB tjdOYhdFi+UElaCovwGPAcdvDIDmMt0EqdkjG/G3Sg+KBOsrJZcArkfkOgCuug0KWwmiLc4x 9mNflyom+wTMJa/s1KyJtHVZTmTVZ91zT/cDwcrdQj4aoV7cMmtwDecbwHYfqDccs0CDkmY3 A4azRKu1nqdytKtX+Hxk4cWG0LdpW9AFSTsKUDZQPta3xn/Od8OCkcg2zp6tOWxg+PoaGTBJ c84W7T02lIzAYkYfDQyNzpyya9A3dc2S4B0AvQtQrLk7Jqz1KRN/ovoIRCJDP+A2gyTZMhLb 1ANWToNH2piCgcZsRGhciv6Jkfr4xOlTyDleGYevyJm0ZRuwx5UuCl3BCdeQLUYHkNgS38MA yBiGUlHsKDJERXDxLP/+N/vwdpk2sGO1JVVxF7FozchGCAS17xD6CIHkqRfTpKjJCnep+lNn /1deC8bUP7HcmYwozSLnox7a+u8b6q4CejvEVhXJTEJGzRkeZosJX0s6pstq5c6NKIB4+1hf Sdr46fPRYWHjIMs/chWihAd7I9URlIao1iACYunEm15cJk0X7kRkFzNXjEmhI6cxthD71rlQ I4QPuVJN1f7Uf0BrJ6j6y7swt3QlMXIDSZs+yIELQ2zFsa73odKqK9idenCfwQios2tKhk9W d2uz6YDjMKXwqsJXGKrmg37okFQycEo3x29w/TWL6KSBpzhGT5V76Nx79cSwsKUvDFhJo+RZ giogXoHCEPxUx/nmTIFSs4X7lQajtAfWDFidq1sJmnDYGwR8IltSyKXrvzx6TjJCnYnSiw9n B5iy62Vz90QJRAnWDq/vCKV+j0jCQT/XK8yh1xWcHIjOayAgm1qpapGAZ18I6OXYlBHG0JhG Qz3ISWjvLfxKoPomo4LUI8ZJF5wlhboZxbkjYu/6sriePPnJw8GJAyXlJYMgCHB7avk/P/+I RvqXs+CzB7iHjujeaph8kg8P0V/ZVvmR7h83nxuC+Q7fYfsYxQIBoRMb1UCFsACAROrHWQkz F7g5iuhfAuwV2e8P8xc5ohjoiXd9Kiv0ewLRtky2Jtu81mSPUz4KOvyxUFVXjSLVrY9J8rgN xMu+Qb8MWKWKU3m6LtoU76dp59Y5oN4eD60Hwi4LHOePkrhksn5PKG0fgDnrJgcptjPUMkr0 Z+62Tb9yeZ9gxpxjCZIpcfc6kR+ILO4XQ6pa0bs27WM+bh+FgkqCTu9G39ASMu3HmVfaXTQ2 jmCd864dlMY88flu7cMHlAJp7I5ZOFY969w3sAn61eBgEgT4J92lUhIxwpVTvhwbf5NL11St LhRxWiKI71p8dL2BIT4iMOr3ClPyGCBt2eJrCt57Hr04lhdRAHTeryhm1b3ebnIfhjxnT78Y Jh/7rf2eg5qWP+rkEcQBiEa3+W8SHo30S/ZYLe4+ZCAUyidLVT4nXEsPGbKdv9AVLPIu78BQ nGrxDxp5RiC98j7EN2TSPGeRqJt1obAyXammEws8YKgb8h6vaheeyPFQIeWLO9bqXhNi4D1I dlZPkvmtsnJkQdsCicBDp9fY9hiCycRjgb9/LAzsQAyanHAvySUyewhG1GY+3WFn3TNebh+F U1ptp+luidNMCdIiPbYjSj29Ypqjtnm9W5lrYOdTLHl1HkwfmZW0aGZYKRAwzAEhCLytghUD bQrzekS99D7IhNbx7Lecoqddg6ri3Z6pxtv8ieSUOon+GET3khbb4W7Jq1fUYkbvnHY16Hz6 Y/56fG+RGgHUbTRRpUUAw1sz1LTrI0m1r5hKlz6Q+VIFoFtLXoSQ+DZ0XrcMXyG1dexd7MKR KEeY1Ahr0QfsPua6HsU6P7J4GEOUutOHj3QznUD68RKBMIQmtkBXQwjnx2n7eNOl1ju22S9r 2TTkctL+WUDfcujj4cco2/GJoAXv9UQIEFv0pyYhj+sneQmcyIavabMdZsVoHz4jyjv930V6 iGYgxfvSkVt8ITFnpqzNHqLlVDvtnH+XUZZXp6b6mlLo8aD577NnaG15rHPNRDdMb/3CVcVy YQS5rIm5870Plde5jUjFJT3XHRtJgt/T03bYJXaLdgKt88Pn0H3TOOtrIOQjjiIzewvHvPMU KHjdqzjJRjE8FuA0PbywO4qyIKUBXPWmhCvu1EwM82tnbnLZD9SkWivSKJJL7EZAoi0Ndqv2 RCHHAhZv6nkf5x+DB262c3oEROh9he7p1AFMPmYfY87I58qrXeqmhUzOXT5VyEyyve4BAXtS qMXmefw22c9htUMmIPgJF5rnmratmcU+o0oxQUZqGdIholgroGOIoUnEn3WFxKqwDlMfK3H6 Tbgkc/XYEpnX4dKyVkxi6+NBcTbGBlkCmCxDkwCrA+b8NqAyHqTFrws0jEPVNCD03VrBNJQ0 cIgjWEGDOz1HPbzEtSVDfBayY4jmnH1gk4zNVVT4ngFyly0ISB1lVMZScDM6KRm1UxXIm+O6 Y4cnWPYxO1CZBtjVNeWV+uYOVdq/HU9sRevlzhmy4M9UKhRg/wduiRda46lq3Zk3x8Yun5R3 KOBcu0HUNYTjELicXzYpofObh4x4NLOncctt8P1ZRupFiK47ruxu9RGSUcVO5Q/gYQgnbwIO YcUfqmui4y7uVCKq90ozQnuWsV0ZXEp8bdD5NIlZzikQw4xDcwf92w8YOUyt1AWWwLbO730X SRLo5GZxztpOX/I7mjnYGZo1qB6+7gC/dA/E9gSv1lUetzyludhzuLeZyXRHovGgP7TnS6Jk 8JyeSoXEL0HPrRe+MZopeyT/+DiJGh9w4TZE/fcLQNWAjqjqg2uXRNnA5vxupjVlazX8Guae pFXDZQ8+rkQME7CRyAl8gYeh8C8/2vwzNSVMlOTAt1rVX7ZZxQ1vtuyfR4blg3wSv0zj3GLT jpc3EejxkIsx9t/+F9WDAoqYBT+VOpQ3A7YGm8/f655OayZJkGlglvCUp7IiDzme8AONEAYf JfZkB27KihyBNaoTtYj7G8we4Sf9AWfDmwvqs2MZzuTm5pdGt05PAlIX2fvlYQSLhuhJsUpS HJopWRwPmVEROGL1yg2FyRoqhoFGfJ+o0hGS0rpJ+zEYRBrxScJp0aoo9PqJilgQeClF6O7r H7HYu9ACVBDAQSZT+V+6mzvm2K6oNP1ewbd+lWKkxnIWUctZbIoHSq5Csnx+DysMsuXoYICE 8OTWjp2XuwG06wTjiu1BFSGK7jvvRT0SgpLy0j+eXgmsPUF5p7tPrdRUQQgSqWEXTJhdHcr0 6Vsz2JmbVkMl4GXiuMWq5XqDNTz1TH02hjOalh7jUB5JTNcBLcD8WU7LaeG3zinOq8ptObSS Y6VANGefV3TiHwGhzZ9PvFQNi5zZt6vi8YJR7INXmbOZxqUPgFUITaHTVCASR6D0ib4PiEr2 Hmx2ONrmhu8FluTynY7D7I57pik2lKmx6eLirhJMDZG/dlhiPiZ8K4qveeKBibT1hlcZq8tr UzCDZrj4QzBmX9t5WDkgGYfKy9dUO7giiI+rSlcsX1Zjd8c2Q5OwtoAdHiMem/1aFFio1a/o a5AB1SCUmMkCHGSYO8MBqh4eRerhqNfKXilpXaFGbZGB/6trUXRKbZTq/dnr5kjd/NXfWfkO UA89PM+VpS5iEhVhgy5obPqQaS3Mp3LpndqgJ3Bb3B7PY+oigSKcIXTApRjRKGmJM2Q2kio/ Pjzrv3VszZWcivwp/M+tfu/gSA5ea9pbp9U8ml4FvHut0JKzf3tCi4kfzGc+4VpQlMfsQxbB h8+w7tPsOIb9d9Ryh+LCHz92CBii9V2E4GQZi9NwGH8SUjcDz/WvB46/IrMVxoxqO/kNRQen w5cgAs034e8QkzrtBR6XWRlDjEoj7I0z2Z0MENx3vus9fe2eHkgtbZEQ3uSaI+rpQ39W/uSZ cOq5L7wxpE4O6Ddc7qCw8cnzJ/ZDf5rpxZr+701NXmrOQCISg6NSOyzW/20ESlJQLKEr0mtz 2AgfVjowzNiYRWsj8KZYk0lUEY3IBXyIFlizyOG1oRp1+tsmevgR7FaWDS8O2gO6fXdQAOIW kkmNUROH8WF5wMCDB9CG3jMSolwyRDy0S9QxCd1wfmrawTaKrJwVM+YIBHA8buK/xHbYri+g aZcBtJ1qpH3lptbSb2njrw61gr8V2PryFanvYRZkSTl5ib5ky9Z/mFY8E+b3O5ya1QffoN1r ZGxpEab/ybRxwAjJjQtW6LMLlcC5ShFR+SvSDJei13uk7I4uRk8ksCe9skapdAb3n4i5jDOH rl4ivk+6eFjSog1TlRK0OOHi+l60ERDLlGAIwX3bA3oKdNiSkLn/hZZAEImN3+2zsiAafI8V vKZZXwJ/69LzjmfZ4IdzMZjP7xzZAJXWDxX0Y5ZSESHXim5AbxdEVAhLvNE1Upa7aQ7/0DNN Z65rZk3tb9P02ycYRW7Ps0VtGxMH84RQyHMB2JGacanHjwSIKogGlMPLkxf6mY6twh4u2OFG bRdd9KnZ3RyU1bnTh0xH3k1At8hbl01CWEBloXIYcNFBKNXBMvSpcJCgKeGLo9MraX4BEh6Q FLEwmZgVnYAbO3k3j/McmEK+oPi1bdqblnwu/+xtiq7o+X6aKdSbULJhOAKesuXAxp+yxpBt z9v82VzdUtlpe3BJ5MBqmRLp0hWfaDGSuUuFhWc5Qr7iI4E1wYz9AyZH9kEUIRi1nt4NwthA tl7D1taku9M2QXa4d7yo+u7hdugDQtOGTf5Hh+tKDf0wB8zDHvkAmzU+HPoiZUKbbmh6Iji0 K7FMKPgHObXBYYyjNlguQ11EPa/Tgv/IYbYKqjNQogIYsUCPD8cpL09OrZSnviWrnFs/4Nbf qI/awbWEBELGZ2tp3aS9s0dXj2eIeoaWLbhxaprYrhspY1t91UCNkl/Kdhk+n1VbrCt/G4bq zeQ511TNu51dD19Dt+nijzhrHmEVJmZCk/gJnfvePSP1CatT2A8khPjlbJmkcrHFEVFDqRA/ wNf7QkNNf38/2JQkJX9VN+XN0Wn8KITSL45Xith+H+8qzLk+hY/3wUDQ+o1a3/XL/N9WRZ8c 5BwU+DQje/PimUAU0vtzbSiH2ja5XosuOWqny2St54f6TU8I/NSVNX4txc3ZRrxDJC519ENS yvEeGbPf1tlwJq4PW0S/nL6xoE4v49COtjaslIMwa6gVh8kH3oLjJ01oEJvqBnNM62oXcydZ vlqNXAvswpAo0Hu6gDvnZZmEdNOXpmnC7vbSd/+WCymBZCISVRHsqERwyO5Q7WTxc8qv8N9d Kw3A7ZfFr8wPdaCF4Ntc2mYUFPO8DnnTIJR58lDC07850amZzcFHJ4RZzCQ9t4mX/IG4YMGU UBsbQOEi2Ghdjx1lCaiu0naY0/EEtE5UMvBOaRicwCU29Z/5HolfnXTiUtXDwcAb5ihuz6k4 aA8jnr/fung8ZJ3HwW7aG+0kxG5Sy+Ad0L8p6fRMysUwoCQeeZi93uW8PQJkR/WDIMcMsl50 hitCufVWyajqOLFtWunJdYMep+nX2U1fkTAvzQARERmKRQ0M/NAbfwbEIT6PECz46pd9IkKA PSoF3w2Q+ICFxrUHou47Nmz2u6ftcuU7Gezh4d6cCErigICVXPjP+vxC7Qb89nfQmh4tDVcT GJSM505YIGeKIVO6KyIxnDkB38A2UzzOIJiwhduo8k9IAZUpH148Fe2vTEI1Pr5NGkRi8Rfr BNX5/CHkjK5yQjkoOgETnJN/SHTjJkFLuIzOaZ6rFe+GEz/rIJnx3nZVUpC3B9V8TvJCk6XE FfG7ZbF9AtMIH/i5a36JzmNBeo51CrUigJi/QuJnM0JdabPNqhkpV+6ObVS7MmPXD92xhHOH ARLpPzcpD9aTloeyMiY5Y75AIYpm1zGRT1kBqvdaJg2447rGGioExBshagOSbXjdwitVScaj RyHQ8nCpQqnhmn3a1tUha3AyVJY7VThB3JfJcehBvOsVCXSGnOsyqbGulINECZiF7XcSl/b4 PQPFx4MN7+1nf78zhmjJ/PbEs96IzSlKgDuPQReiJOV0/T6K0TdrcCW0COjdWfKcR4dhsCdT yizyfZKRLtexWHvk9PwRmsU1Z+7iXpKUUgMUTGfVU5P0/jeOQAgb/fQO4rgBSTzvFuyEka5c n0w+JSxBc7tI/v5BZb/DHET74ry5lfW80r8LLBx3DPLQmkWtxKlFvI4jPLtO+wGcJIXJLoj5 lC2jtiDycj1NFtHNaeZIHCI4ygaaVyddUdiG2VaWPZRHPfSaw4gB67mN9UnD1R3GEZREM+cQ UwcVmkVJ59L5LKsNPSmgL7387DHFoUpnTGZ9qS6EOP4eeZWu3DiIbrWOiAdFG1sywMBeOu52 pVPkMjtHf2ND8+8DoUxOb9Kr/dCD1QouPPu2rsGHa0f+TmM7ZJ1kC3BBnMwqIjhjmLmb5YmK K7pd45DQnJ5wgRUlKgHywTtKyEyxiVCOcvi/+cZSWhMvsWd4BF2hxOVcIqHzSbvZJfwEc3XJ ZQ3SKaFDPcN5y/4RmmdRQBOY4U1e1I89x9gghMZ5aBqaqS64EsAY4VSkkq1U4PrD9g5/URq8 oyUxCzy41HtJp8k/tO1HDhE5kIaGJwTLEVUEP38fvShNfTEWpCkiJpkA5VXeklsD99vRMhb5 suCgWWllkhDqI7dZ0VPtWjRD9btJkxtr1kN3wO61RIPt7HIz1nwiiUiEd3yWXhxoMW3PK6hn jdu+R0P8pwXr7JfkbPUYbPCDp70RwZr5aCTjyqFKgawhQTSeEVb4QPIoM8Q5/M4k+RrCxmpD RqHog2pWfD6J4zPH/YuUe5yZYJQDpK1urGbBJG+eR5kGLVgwE7WmhHp+yvrGxdN/a6tgTFxg +53IyA6lylM6OoLbCgRJjHRgQMoFIoEjyBslTSWM5vGmqAXUKkhA2MyMpioninoe89WyZQkO 1a1lIqkB49fhHqRILGb78yP1oe+1wZPNbihdh51a7EsN84CW/SmPyzSn6kLIi3RHXLzJCGy0 Dy8Vg+FEeQsg4No7mdImPulBopanasp0uAV0COXAalzUmVVCTE2Qee8eBIWlUlPTAIUnivmv vhqZm/Ic0XjVbJC62XKhsG/IO0AboXsTK5PRHMDEhL8SFRSMydVLwuHz7GnlTod7zLJ9MQ02 Yep36PMN4kOTkQc3lPRHPKi/HHWxTBhWZMFaPwFaWIM4F+Gg9V4YsqnxcNwA1Z1cDi7yZXn0 nGamIdQbiMg7jb8rRFPw9OiAilqOlfwW9rkQcgvtQBISPYYkeoQBQg7fLenwAg/E8R3UrHpy /V/nEprLxaJFjzetzBzcAtgJ08iEIPsq2BdEV+kCICKArNjA2xAioSi011qi3sVKxDhMm14V VxuKioor8X+/GxUqGaUjVOVWvJu1ldexMUp9xUV7sw5og2HSXAJZsAP7Mqmw+CMYqpunHHxb 2d4r8Q4X++v6EnQlAgrZToy94Rk2m7pMjM5DI4gb2RWh2jFENIVU1e6ox8M+L4KzpYqtBc6G qU+haISxQca9MpHZCRe1V6ZLHAkfMnaNhG8ILmqL8WvZZScRu7ihXHe9AdUd46jf1X3R264Q 8AhPRhEVpvXKqDwjeSJYULqWsWCTQ0AHQ9QWzgr/Ct0xz+UnDc3e9ATR1TDL7JX5xwXAq9Ae 4zxjM14sKOcZSaycCg2MeXmreoN7DC4cdkrcCrCkcXhI9p68avHmRzkZolQr8v7GHHJfwlqc EIMTyNdYZf/MHqAL/UaHQgcPTEzCVjHE3YxgsXIC1C27+eX2XCQH29SixFKgIBUfytNX0/m2 x75rb2gC7BLhdRxgGHro5fkRU59NgG8lqDESF+01OiH7IpnBjmSKE0x/fqEekFnxO6yiQmle atF+ZEW7Gxj6TeHkT00Wpsp1FNkv306C2ikRwhX7hbUiDhnyPabuD80e6dqYks4xTgOR6FfD v6+3yDLkUBg4IPeydu0Moej7OIpxXxvCpm65pKHroYgCmDSK95nFjqudrDNXFtSCQHbmkLkF vTtZotHr1PafpeNmohKOWSxclU91Q0auO+KYx4BKvFkTrejKRdDkRDX7Fsh7zJb+ZDGmja6T +HGqkEWHumwiDGOF4+1zqY7ynBXIBsoSUo/c1WIjhkwk8y7unhoVacglyRicJ6ytAJ0/T+L6 7TrYIkgPhXP3myHMnxPn1nTe5/vTrsMlQxuGhevqSCC6yLJMvJy66On+ngEVaP4SHI3o2yR9 p/paisB6oTKa3gYzOPnj/ZjBIMnPlqVamLfHvG3ZEtbxPsRTi1QcUuAUvkm7PityjmXF8X6/ ZaLtxNcAS2AyKpQazLlnDWPUqOy5wtYc9dUYPBTDu6ewGkulXBmgy6Z/lIWGo6QhyHFKWbI3 CKeOGY7u7Y/9NgXCx2ek/6GkDgB99kx9YeMQJJuFxgNp9F2vcnFjQEswYirOYv8PHpFGdC2E 79KGjEVpQmOWcJGEaCh7hhzFPvbOyuYHH5vbBdG0gaR2wZLLjX86BrWll2v7lG99kWBGjSFW EmOqFhgS5b1jvYnGdmea0PRvKHQrSAWlkcCAZjby11WCpePcY3CrmSaOIZetRs1f33ENvzpC cjG78+6T9UuMkDJ2LWz2IX5yT0RZHMd5djQprv1YNsl1uiBN427IevpLY7VS9Gpsfo0Zpkgp NcnRy+aNU5ufp4nFhZVear2l15YGoSVTKnHNzHWfMhJTMMunv/vYYjdNd1EIDpQYZFM36FH7 HheQd6HLI9bjn41v94y1Epa7g4O/FoA9mB8e3Mycwj+1x2srmVWEQieiFJKaZQ6tijeiy/sA gSG9zbeHMn6DkcUyb48MyEf78M/gAeyLiRCxvcuDzdqaG6L6m4TPG7xa1vRorvzCj/Km23I/ PYlMJvjmaUWnbRWB9TMSGL1dr109WBnwBkBxn4mzU09rSDW3fuvVKrXjSnT1FaSZgh7LGOvk Z8C7t6bqi1rf0CdjAzmNP1bt5fGW+WGKX++UrJb1jLhYa/phCbRbfdXHnownm53DbkdnSN7l zBfJjSyEfJNMnJPKiE5DmbQsau17h2ZaWL+nn52d+eG4fyK+GmD1GD5GrH5xaTWWBDMTS/JZ qGGeKVbdpgRbI7EexLD05NxRzSUO108rzrQtzcLEBGeLyHWwffulnTlzBi71fCrtSqtCQmyB s71FB0fjndaI9tP32vtSJfE5dIZKRDAmSNU2UV7gvmA26hs22n4KGmyrqaXVCm8z+Q9CzgdS huYnsgvyvKrV8AWACjYFwzV1vlmWup4PohJbWmG6pjm45srvhDhiHlRdsccXZ2efonIKjXPN rLSxnCrqlCjkgJ0zjHHbDDIW+QecTYmrIVzVDHznLvF6q9n8AZpuMIYejKMRSZIUbII3Damy Bz0nN04Llit4ejkBozYdrQQJuZU0yCloh4MYX7dujxp5sKrDuFzOfBasHUDe7PVwSDub39ly r51Wp2ox1QzXRHj0FBRcOL6Di60Oa0l05DV25gzjA4iY08BkKKLkF3gzO0m0xn5TzQiKd3Uj CGduAyg/qL0uqOAlurUWmylkW/NKylKeI92yMK3w/BW+FedPHAJ6J1q+tnuCIJM6elID4aaP 1e5UVEhapy1C35iI2guZmcuBzXjoZ5gf7lmQlIv1IVYz3pcTkFJBP1dp8/ErQ2u7HSH6iWMw aB+iK/JgHYfnFi+iZGGEVYV0sAHI1lZCa9Q9wo5r3+daDXEzUUkFwzWsEiPtzx6v0WnGz2hN Xm2Ro/F4qixAo6WdXOXZ2czm8evhurQn1oSqg+Hh529pHBDosw/w4+RIBElrkxLmnGqVTIaz Tn3QQgppvM4wdR3eqoGxeGdFpQCTcCyYnGP/JWP20sqai5d3GPEGG6U5D3eoqgwTmhMMLB8w U+KDL9C/geGDVViDlTJo2mw0lT5ESbYZ7u7/DS7hCJ/a1COTeWxKiTPmhDA/gDWkymfpKfn7 HzHAjpxjqYP9i7zMMs6xsmH+CHBBAmxolRVV7RyaMpMeVyDxbtW2j/KNfxDq/bKuOexeDq06 vLRJrWIdo89YwER+uSzNyxQkHkw/y2jUR3eTsFw9P7o46hwTMi5A6+H/plEEkpGzv8Z05bkN i9ybci48A7syIovwVfVDHBiP6hTnzElbR7kysX4jn6iij+YCZsw4HUzcfmviz/ICVOCKk389 3/tvCAwyrnAq0q0WH+ZU8bfr9dAwcrW0VI9fIJVQc/ivYvWV4Nkf7tbEXhHvRePzdoQeSOCI nP6oym1aXwpoz/IPiujhGMeLDSgWiIpanhi+MEUBf8Kz69LI9qX5NBPQQpYdXZGokOCwVBoY pYlegZ4gp9Mtqut/cq65EkaqjJ6ihxe7Fyqty07YbhJ9kEfI//1KwTwLmYDet2koNjnyUSd3 qj5vMyvVbSyo0DttamYg/cn9GNvZzIK0ccB75S1RwM0W5BFr0QFcg/V2jVJQg9RpJJpmHx6F nSfJXAbJwgCtEi9U9+l60oGJTO5ZWJx4EMZjpmOYRjFMoj39qMjqygb8MynO8+XgePMoX6xx s/DZPcwAJTyveO0cI4bFCwpzIgy1rJ6CrK46cyBy2mtBiO58Vf0hoiTA/shF8MGLbdZJHYs6 jdPE8J7OUUkJiMjzZ+1yynG0gTeBeVT1Eu/OBkx2ML2RSKrqS3vzRBm215+K46BfqkeiS+y/ 8TvsRgI/aX2fLTGbdQ+Bqb77Nh84NlDSgRUNj70f6C6gaCM2qXZN94DLWjz66HPORPkPO93A IZbEKZj2hEGLDlwWw7kd5uMkAIWo0uzkiCgkx7RC3HqjJpoYVlgI7q8essDfEKJJcb1HV1ga 8j6TLxXaz4K+siPUnkakUZou+BAKTfB1H6HVl9XjlDV5u8oGdAsr8k115Yzgv51Sl2lVocTq 2WpY+kAtxjGKRAv2lbzZyhdgmhuepb0bLKxqfV2f2iElV64R+mPMYo5ixKel1hrPOUp/xOSV TXLrvEQyT2dBD2SXwNL3xO8rVqigomfjW+EJh2wPvLRDbY3hio0w9E9WETtpLtCx50s8EWdl LxwsZHDyVL/7LzVx0j8QnsiUok85BJTW/n7mid0uhNDWpFUBxBKRj9wPo6fieMo5ufxg45j2 WFw1GSXbjAhNXJfbeFsdXJu8yQfdFYSLpnf1MVQGptap+1zm4zoLo4cE7wm6V7djYZV1mikR oCrAJuiGhne+G9fjfkqohAi6kwajKq3JESOLX4WpJGCYJwSUN13XYoCGmqZixMx9GXWejRHx G61QCS/XRuRCzhd707uKLIBWoeGm5Yp0Pnwd5BDBPP4Zk0jReUTv6+M5N4DwE1PDH64hCYQF YKSl/yjlo/QxQkUhmc2071FBCRPGYFx9wXcbGwvgmtiQQXtjIhDTuBndt5fOWLvVSC9Gpzr9 JUasf2iWpdomFhgg4mxXIWdLjy5WURlbCCOWA80QXqWZQIAnF7OgXH842YLkdbFexHd/I/fY 8GOoRFL7D8GpPeUCAESXG3hwISOd1OHWkNebDYalps8VKfHSqGUQwasCq5N2EDBR9JcPI7Fb zhy9OPsFd0Q9/fbgPq7W81YK6ndALWTXz/DVeQo/f+9IWv3QZxCmNWMg1ZV9fuZBkp1+3awr AI4OPIELTeeIEdrKtd9aLLQrJhwHe2neyD7aU7mNdZVQjYFCSgFWMJWVM9e9zjNSnJIh6gbI 1xgOBMEQYgyygj+Hythq73p3BhPs3KeEHTB0VkrmHxhyK3jEeWvViu0kdYBOsNck+PYpSd25 FkGtHMpAvk5sMdfGR/WRLEJ/s3/aBcm/RcyeJbSlmJCc6Z7uOVKtnD8cpsklQGNLAkZei5Nf m9p53igDS0MNL5eP6QzY5BqfblB6XdQL/HC98IG2IJnW86I/SaQr3M/3wsvYAQDa3kJe6V4V nRoeDzAXu4CZia1FMLD67vBxXi5WenvG3Bl7VfvBH/Hqhw9Xp7d9ItY03Zelx6+0SaaHuidy tzzAOg+JX6o6cuGEXLqzH9bIIiO4+RIiQdLynM0kNgP3q6i1w5C+/7hqop5/Gpksmg9R/MHZ DYFLXSvrGgkUyVYYfWByOVhttrpRdTBX9TnVAIp6WIHV2TX7273u+WAC6Y1w39R9iiC6gAk2 /UgAWubx65QlyhvCt2TXmJXoydPs0MfxWAglUXNnJ/nNFaQJzZqt5nAO8613Q/7WC3h2sEv1 NRtonwhAS41KLwHhlwBpxF5aycNjA5vgs9Gt/m1pr33VKPzx7e9aH5grGTQ8vACI2NYlEmv2 uche5td3BOEe5jW5dG0Nlg8YZHk9xbHejWJ2/71T0XGO954nDg9M7UMPgAw5n6qTzs3s+LrU 0BBq66MgzEW8QxYJWe3le+j5ge6NdgjjrVKqw76bEPddXyappYXzIibrV0YdEibMiPAapFBH FMWLZBYuioCiB4K83Ojpxgn/4Ld6yv9Ga5QkjckFvtEv/VsavMLgR0L7PmfOiGDtGbtzb8x6 Cw5cmI2okRWQ8a9DW1kriV5ZEwgbx2orHtbP5aUJ3PyL0SpicQ4HeCC4iz5V5px3B9zo/mqS FoB//UFpJBNr/GqomMg9RPw8mvm99DurvdzJDlkUaNYIF/QSHs0ucinhNLzpVOYhtp5a5iZw vhbCDM8jAm1qpdyId3581Wf9YjAv0Z1ruy4VdPg47E25X1kT42XfftRJP1ij4JHNArYLvh3v id+iYg5j7mam0hZhANOI6cM183XvrVEsNiFnkiPSUMETwTKdismbInwHOPD4QSKtHBOTWTop cuhsSTG7A0gxMgwsZRCehlxl7Kmd1tGgfZue+GKFCtDnMPHPBfi4xmHalazm8Nmabztyq/rG s86xO1lbmC9BloMhYjjwutgQFSpkR8d6wETGH89j4m2u+wsgxTmp/h2u0PZHqE8JgIN0kT8l We2c7y0JCZ0QSMl6uGIjmruX3/Eg8pwDOUGpDjwHZirfRyZnPFinoPRk2IRVq084/27FEeum sajTbaDjyCS2xnOWiwkMRtt5Kxo5vsviip14ionnkuzd6VbkMYz4YkQ6IzZ+gtGhiTXbAFgw jHdBd+9D4dTHVk+buJFkT/Qu1L6Qn4bQ8+Xx5/a22KVjYWTYB/aDg6k5vHoKO+OzlsY7XBwr oCoTKhCha7A5FMAYJCDtz4WFCN0YaNjzFETiIuMr+3+vc4g4qGhzboI0BwFzOXITO1bOdaEo YsMuZFveXis0jFnZjuhDQqlDSAWbpEMJhtMu77qm7xKaIlcfjXNgjidtOSWpqFo+/n1zzgcW zJG3bc7OAnljcW6QgkjS4sSa55mcBMk0OxAA+DYtEwSW8Y4QUcxf+TpqHQhdPFQXs8y8xHv4 u+Rg44Xckt2GFIABZWl1Q3JD+r9O0iycYAx5tl3EOYPIPXUapPAxm1hOYBiJY91A7x/mTre9 hNrcDPzv4HpQYftUrbMM/0PG+xyJCa6bsnunafKWr1NVt0x+z+xLoMpUw1nj83in1a7Rwnm5 jeGWOL3pqZH8cRBaf0vC0i0Ffl9vKWvMySMmFUMmIzRJpswgGiFjQtmtbZKbZpZRpUXGVr/E nenwnoLDgWrfXTA025FhUTg063xV9eynNUrhmBFGKS1RWSvVmF6Mg9M9+GdcljXQ9yII9MJW Wnlf8J2DYROIiQam9XzTJMIci0jS99vjCVxvG3S2kYETHht0J3GCk8AlQlwGiIq4kFpoIprR lsichEYArPqsjIQzth9Go8WuyTmf9vrzOB1RP9QqS7+jZfTmWDBpztNGeJbv2MAUyEhH0klP bPjSGNxXau4atQHyDZTsBVtph1CUL6xnZgAVhCiZLnCqG7Qj8vYbTEa1V1iyDwk40B+KximR W90cr0o7fpZLPcllfyjQSD2N05zW75ziEX5qGQHYZcPKOJr1PArcz1d4R8Auy8HjveK+eOZq i3O0vCF1SEiqUHF6WKrqYF8jJ6CavO99jupqlZ8kg5cadIwTH68QO75m4bmYQMTncoG0Pk6c MEY8nz1bi5T/uRmhxWKKxPXrYdyHq6BKotSe8jrGIMVwNjfZS7Ev8kEA1pzViBnt943m3LC4 7ZrZjcfKIiSIajFcuFcuTeZkfCjVOaHM3r5B+H6aClTnqEUn/d3PIGmEgdOalZxspCk2k6Bz OBdSeRxxcPRvHzOqMHHxN9zdGGk+bCKDjpWLZ2LHKAdksYRtZU9uBDe6LDiw5C5KQetvpB4s MgMuZTvIu3TwTb9jmLwKXGhtgb2VWAHp92Tz+JzAHvyvMogZhD+kRqxCwch0xJ2XWB4ow45E MhbZ1/kWXH3RouIVBGlIPbTcO9vpmEvUcOKbrar+2P7LUMtoitbLZm8HYEMXwsXhtCSsPtU3 JAMh9udgEiDQ5odMVmQBsUmCEAxfrGpEcLEQjvgNrTxoiFB8/Wis9FxlCY9ASeobYVPnCIYb nsRNA213JfrLKY+1maNNt3Qwm20UvjHkPVSZzIDWRGhnY9g87Y0ZNfNtNcpW/WsPg+Vq1Bae oukbRvZFJnzdNjpuTAKlmefc4RFPylh93NmNMo8TOwzcklkENIWBBrZG/NOl9ow7P+azKr3I IUO2RIJUg6FoExGbURVi3KRsg4l8bSbi10LpqJPgFuom52PpGVpdWHsM4PrEpoq2Wvmx7V8k qT6Rdo3GPjLrPYO5kAG/JNFx4YCUnpe1kmyrOWJqaWaWhy41kfafXJxIBvk1MX5xCke8yLgP xgi3iqarMpy/PuTnMWLQSovnDs8a2efvYO2+j5JJW0JFH/GjHDXh4/D8Nz7pXJP+Ib2Tkui+ kBc6BW/0ff4dXyT8XxHZB2PRdKOraGrQzRbccaA26qdsv9+pGKPKZfFjbueLhncRkBY90TEb /PdE3PfLlVOHRK1yYwIvS5zY8/edbNgBQX5XSmGfFmonF5xWpDZmjCIv0W5aiYR8udAMihCz TRmAUesa9MF5pTdkWSQ9+Judmb0HndAX0o0/Gr51XtKuMg8SBOF3AWvYX31c6L6EOVT+IeGG lcnzfeJu54/4q37yPlgTVzEqeL8ww3yDpVYQouRdoQc6RrtVQ1bhzvwBN9343n8Z3rU+z2l8 SzFy15XK/daH13SWxpvyXJCAxEVDg35AS90kIkgi2UMZHRpufxu+TsnBKFAfAQK91rCromY9 kCmwMkQqEqDbm9Jdbp2hW8oCpFx0F/I1Psu0owAzsAgFeDRVooB8NAh+NzrnrI0mvMDxuUWW v9SUMOgnaWDYc96DIei3deedkFfYd5/JS3MG8pXipl6G7svy79rp1Kee1uoJRIPEeO+wKDMs bj1XFR/5DV8mlddqkny60xqBjS5OFrS7TQljo3vZ6fnGpcom8M1NxG0BZhR0d7616WoTAC5B gjVey79jHTX8jQGXyebJIU45Qq096uUQmhQM96wjo2iN7i9z5WPcI/ABcYnOyCRw2EdJM34S 3B1bht9oqz643pTJjdG1SU3hehNPMGtfpk5VaqqKjp9t995AshFLtafBuQkpZ6fquANJYOy+ QfwYieY//r1Ef3veWuAsMo+E0wkTutfnKTeFhltZx9beE6we1wmmSwM3w84MeCCNuqGYF59b J3oWmmYZJHuEtjBQepFFUnzGi6K8r3xsMMlHmVxu37omNxAhlzduak4s0udxzglp4bRSag0w xQ33vm0l/QVWevNaEi9XHQThJ2n6QpxxNTLkGKABDz97POgEHFoxvZbOvOy0muigb5MeT02+ gb+oJJ9z49o+ab0dnKz8E25yAm6DkSJN/ylDt8zAP/Gni+uU/bxDL3Ra2/SE09IaSwfVfvRX wDTvXDpq6Xu/L6vRlFuSG6bw7K6RhQ4wHWbbeI7ss0nmLwonkL9aLL7K3mrGaJM9tJe0oUFc x+cLVRg2/5w5x1gVvqKfpa3VYeNP7N1KVVDRwhad80ll6ZYYxgFCBa6lCJQrvMearIkTIUNb e/4D7b9Kac/pRt00726FA7SWWjWugJTlDosaxdqjXvIYkxsRMsllDrZoiEOcGJRdr6gDpbgG Y5I+uenX07Ey3RcVLcM6/MY8/fne/hFzvOh3Fo9m9KuDMhbSlKixGgh6ZlSyIlchG0+mZggi e2NJcBuX/2o+tCfpWDZmCmhBvAhvsI8T8IBmGYqTWyF/z9G0ox8XZOmXYx+bFcKI802hPU1y uWpkpHRfamBshiSs3OGf3euovhl+kHIcjZz/0dlkaqvmMUQxfu5xM5+sqbNZZ0mGVVy6avQt YFJV06qh0f7TMDcqmw6roA0VH9lN+OY7tIliefugaMFf8UOIbSH67pKHRHAUx4jBjIi9H0pI 0raHMKBExb6RAVgCG7YpKGQ1ELuF0iWkzwFpu7CYIBsqjLxZWI/JjtNpLfCrGnfh4HwJs7lv cBZNYc8GaYPeJbQWYNuMFIm9C3Oan/K0LAiTl4hOaU4oMzgeXP3AuAj2Aw6pOEsU4jJnzNWI L6JBaIqT9GAxs7l22lAS6p96cuEJ9RkLLNes9jPJIY5TBJDzimuEW32v/HCzrIaECGEmMT9z gPqSdiDvSD41p5DvJb8I8f9FYPo6kYJk93nqgFcQlDIX3fJCIP+6C8WtLGJirlRYZ4q/MMag GCpuKKhVk/UYkwkLM+cEnNXQpruTF0PybvKQGgZ1kq6a1JKEto+m+UCZaV+9cvy/VyCm+5Cq QmTn4lfY/PUlkKZTOwL85dZ2oUOQlUF/UxGQXJiAnj/apn0wWNP8gpBxS3TFSZi79hdfC5uS KyGdSjFJxbZzh2PiEakMntnUAahDI6rjFFI9ZDR1xTw2uGrTc5GPQ1ByYThQH+RT5rlk37Pc 3VnAD0FO0LACz8fMvYFGykXyexvZUpTgNlnDKtrGR5AVBM5IySBNBEsr8HV/ETySciIi0t/d gphJxCYAgCn55aKq2E+ey7wXjT8vJMd7/nzenBv445itplWtJg4M7QDB9Bxwmqb0arQNt1fz ybmAggHdQ5fjYIocxZpiVaC1nQACvNAyJ+XUjHsOtW9+3mewKb2uDZnOfzbR1FVUKtpH3Mg6 zZUsHWq//1TH40mLSjNNdREl+I9o1bRAp463SZFKrsBR7aaYbEO5zKY59NOg7rGmNrhu1+0X aZos7oQfZFoi+EieLo8rhtCX3rWco8+1od6gtJRk21kn/EdCl0LEahQUm/6omJVn8qyalHAu LGaTZdyF4SCudQKwNpk6eIm/w9fq98YLMJRmhmPI9zwhSjDNTIByFlGhIpI699C9jhRsp+2q OSdxlPQNRM6T7Sewy7m1AFqVJIxsOf/B5xuXrnt9zrHSoCLKplTEgkyKdKrNHfC2jtId1qE/ bIfOAWkVMtJfgmYRHonlgY5RBH4iaiKZ1LFb5HY2g9iqMObtqbHH9ve8kS6ckKObrE5FGdlx FuWOd5fv8mlcRBDd9IvMitmYS7Hia1GpC4K2ltAtwwpRpv1XJhJQU96kTdyWAfIzdSOHppNW 2McR8guHVO6hlgNqTWIUclp9iRQEf5xCw1vVJA03obR48CKVAdJXHAxGTqmA3s5RDYGZTeTt 9GYvtRxeM+YcTqVLeKJgx8+t2OvSStIEXAIEacdX3/+LKWGLHNNWFN7/KRTbREHOxWkDzmJ8 k16foXDdfcgfvv8hBjWXtYfZDBu8NA1sfaxY4Jlxo80TlYL3om9AhISYQsNe5MRFHheXsepR 3+TKJ6uH9yFWE1d7LSVMma/pLnVnwq7PqyXQP3yndBPRMHqysayyk2Yhg/aEHF/2q9YNfaj2 IkPrwmAkhVtxMyjYiIvmLEZJ2e3gwHmUnRAAvWw7r8mY6sFfFjKUTP8sLyiQAxwUoePlgqvC GFbh6cha8deBmislw2kPLu+ni2QTsvRg3OWRt3x8JdPkf06qDBoR4g/LGtG2noMVWEMFaYu5 WzlRyKRzm2VocmwM54U0twsLOpBmX7agSWncyF6lvEFFONQLqv0pENX6HAEvVvu9jUBdB5Pb qlTWE5v+GGdF0OuxJgTTbDuKRmoCUNx2TjmV290qNWRX7dHvmEzOcxm/Ay6GCUHSTi9NCMGb 8lt8TicuZ8gxN7CUdvxEVwA9J2kulFaWlqBEuTWKME5wj16hvbnHg2L0TT79dRgtR5RzR2H1 EtB/EWztafDFRulWA2yj6TCfvCZz53upmj8ap9nT7fceYWg8N8wI+j3BiNhMR/uP1/l3Lxf1 fDtbiDPAWtcNN0G6x3D5/Q1JvfiCSSFZMMh762XfLbcM27PX8sS64CY4q1xL8Hxy0UULCAmt ufQ4GaDlMZJ53vWMTwychKP2JX/a1x0h9O5gFc5H7QI937n4wuvmvVWNuKHy2xqj176YCUaT FDN0pqB/p78Gp/SNOYU9rk/pG5SD6NbJz11r46ozmu1sLkYuUrzLN7pwAAFv333yie5f95hq qNFtTVl+RD5lmAr4m3ynJc8CR8bdQrSo1BmfDXTyZE7wwqaTgrZ2dvBcXhbViC3FrOrRCzAI 6dHSlgxtGaCxoJ3nSWBiyqZPvptGAhsGLuI+xSftgmzxt+syfchWsb5/rXhLOl62Ad3austB QZqN2dazea4yUfC3L3bofI7pj9aRg93uCQ/G3pjvsQU+dIsfigCLwmeRoq5CCTJipIDbQyXY 52JXO920I0HhBc1BBVX86p18tp16DDzeXwJmPgAlYSLVecpviLNyD9opg8ZoEY10WG4igZQP A2L1w0+tJ7J6x7sajE5EaiRxUenSDG/UZU074nmTnD6gNwHRnG+kASGae9vqy2NmGwLi0XN4 vxWAidd0a8O9MGBxcrYRAolafwYp6ZHMIOch7tTJ/YegXYcofNhwHrIEeEAYzry9Ia9f2105 mf1rNit/ji8RTphzuD6jdLq91wMM66QJQQge2WQuvlPkKVrceQTljXKqTy1heulblyFR0pGK GWZjIyOoNfzwa6Vmy5Ksoaou+0cWRJTQjJ7tuSow8RZR/sVrrlC6aKk6rQoXo/lWZspD9z9w StChk9UMi/MSRVETnSMF49QYw2Ly01UbutHsgCS7sOvQLavPPZXD1Fo10k9Vn0UnKn6V9Unq yJyFACptbgdFAy2GFRLZ/jkT1SLgdFu+SAhdSVpcrmC/0srC88e9VGFyFw9fZd7hdl1e9ZV3 ulpDMws7oPEKySa15IOyaMoE2sugiZIXOtJ80s92wzOY64HAzHDtHsFJdAqfTbAs2SizjdKT 9da54ZIbR8fy5vuccl9fbXK5Fh4KG1cOLU15Wl2t20mFyz65nGVTlZlLAKci0cfWBIBOD7GE nnEQO8NWOoOMX+jQfAKbfszgDFOlHb4PJn5rU7NxILfX2put5O4g4ucr7+a4h9lyNjsMG+Qv WzuGgWBSLPKNp/fHyf0FW4cMWM0uS8ql2N5IcoMhwndNYDWzSlbFJFDx/LSh6WEW9YY2MVg3 nC6gd/PXF6hsQReOsOEpmM85OmqNYpo3RT+ajkUlXb/h8UsC22YRZNBKIMYnMSkh2zebUXxJ WU8IrUdcNeBOjFrwqymGetims9MOXwrPLiVV4wFzGOEmZ8lhrAXGg11q36K9JsRi0nXJTkn/ zWsJifhpwiYSf+1/Lj5y66rIHXA7ZR6f/FX2UgBLUpKZKLm9rw8XbGbsnpGPhgEjpW3OJ0+7 +teimVNlynMBEEHxvld1strNP7z5FvjuaBi78aTMIgaXWdq3+ggkxlz0JUhcu/0Ww94heuUc 2AMuc3Kdy7fKWMwm5lK5cJwlwirQ7Jpi9g+JK3ZaamJ8xPI60Tc6ipUSWa3USioSwRI84Lyq q6stzY2fgj1zX/QTHs0A1HqHLvPGRxxI8eqJ7nc0cFR9F9eG7qSL6K6e7+UeLmqgMN8gXs5A +fI1+M5zEAEK+nMV5QWakPp8beXpdC5LCAQaJarYmoc3LQYzjlVPFKib7geNNh8RxXZNdxOC 2SAJI7Cp2cNM/yqXBpINpUpGzUE9rtv91sdyPopZoUQHPH7ViRI6rTs+GMoxkVuKYbBBOYlL W3gxQz/bNg6/NfLKymgWys6OVmvKyJkUu3sByNzteq5U5gaghY9mk4bWwFvh3GOFi5172rNY UycV7cd7KN4vG01Ya+MAsIaBHuUu+AqTtFKUT77sM3JTs0F9OYfcf2NyGWke8pXzx1Ll47Cm H2TDG6k7SApNffNvm3alpDdW4v2yTEvWljw3SpLnilO9xo+8J9nvteLveJ3/Z/qVZV8VjOGF 19y2Dr15Upm6OzNtI/0UeuM8sHB6ZEa33ZTLDBYShj+UdaMdhm220Q5fE+knPJBfVHNLmGVk PQuPRUsbwsIIIJ9jjaeQVzWBlyRUoGcKbiX6wGJtLsr3Szlt9o8XToJMPdFG2krbV57MLt8g p/irpR8EYI6Znyxn39hzNK36KAyLc9gDexgsWo15B2OLbcFJVihL9PeHJP/igJn7BAOe63JZ jto8HojAjoX/Ffcn9C0qkBRNKUIMYhKoO44OpJk6WF2KA19ckY/LLUrkN5sNDTruNPmkK9e+ CGAnC8A4N9aFOLz+plkHCX6fT+BwiMko+aFXEa1dM+3S+pFR3q+KijhYesXjQYdzn0q0M99K 93WXnPgoYGcR+6WMdP/r1ufe0YQDgvppwzKZan+mPqVnmTIWudS/QaWYBI9Zi8PPVhplXwcp ozo/YtAy/8TA1Bac+hF3SiFuSbAr4yNIDEly1obB6PQyx0V74YoeOpuaFE4wKgQEA7+dyH/p NA/7xV8q+fxdQiJQQ2da4qWq74PvJIQhOnWjHN7yDqioStRTD+LM5fOTYc3hcYPPPWGWRQzI 6eMzIUa5SGs3wvITWH9C9JS1hmuJxvU6eo4UW+JFWtl/bwSEsCDaZsW9aIyfmdNFx1HDQmw7 Qh+JANnJP6BbehJ2PIgpjXDIJtgnk4saJG9ndtiaSR9CC3oGeOktkoY4/S0fe7VWifkoeFEz wUISpVorBPpyeVan8RsAkUiExzv97m2JGP/GUVgQY1l+NoWECRsKq1RNrCJnGkI8EcfI87jx cqRXp5slLEpMrIg/S+ysyd2bdOUIXcgEI6JtTNj3CWTtfok5C5+CSuyD8lvbYKKLa1zLTuz+ y0NBbAuFHa5DgmwIUcLkBLgNL4CLtLsZVOsITpqv9cTXt20conGumi/bfjryKauzSL3rVfMe uJu0qNCyGxEtdkO7rAnkw0vDYY8oMCbpsdVdh00h8XiKLIcWsTzHH62P1M9C0cH4B0LuZYtW krbLTHYOKqlXY2uQ9CWRaaC0QFipeuWqYnrwyeiFhoyQZO3xJ9YgHL1PCDfNasGnz82UN+45 /Zwb9IEADS70/y2gnQ5u1PMhRJNU7yKAbR+HE9YoxbW8VE5t/JMnw6m394P4VDhbS+sBUcR6 bR1sYnQkNRxNLzK9xwWg2bQlRoyIpeWAGEeZt0NsRzrkZK3y7KgPeh0Kp3Dp9goc3Iha3VBX ZPA07yDu+Pkuh6zJq970tY+nPsIMuv9jQhTOuB2G8mY+AFkjveLn6opraQwshldkeKX00iBF oH8YjCrich1kQqjrClH1X2nGN9SVbNpRpmWbtFT8+1ccfMOcIDErk2KR6RNtSnbKK5cSF7OG aLz2Lcr78P1tfWersD7H0ysM3gmOxhGtkd1blj0TDC5fxtcF12knALJZCTpmsDkMcHFfY+Y3 IcN37+IgfETMPTVAQgLamXP0FYs/wlnQPvec3Phfo4mMZH/Qnh9tAzhS6Wq2tDTT9jxwCiGh DMx7qkYz7ye7DtYBxBWx277dXB/TdcBVtOTPpNlmaVAbvvJ1x4jSwj09uf7KMxbxKkmhi1rU VOv5zOtW9NPyS8ioz6aPkQnTV8HrbaNGqDFTU4ZwJPr1nXP2pgtL1BJCsrgEx7iKu+gumHTS W06eNpt1SrmyWmVpxkf9YlMRGzDkBgtEwqD9cqdU1RwW+qSGYCBIo1R7ODgDsL7RqLdh0F4h WdZBlHW7BGMoreZIcurpJaog8Hw5biHaQXZZZOnk8FaVTGAjonM0jW9AwvMac8tP+FJqBbUj EJYQCFtrCtzZTNNulpCNEPOUJLqI4Yi77cDH0rsRXTgJkWIEqXGobj7rGXf7F+Abzqs3YlCq gJV17030PptaAa/tKizb/wY7cu9e8VqsPdlITXyrVj9SVLqET7K5Y3+CH0G95GXEVJ5be2UP oqBtkURIxWyOHyoMD+4EpgCkM3GcNL0Lm83tK2zPDNSEZs6I3ThBLdxKtyVLEsMfLWlQyZZ9 P/MwLv/rLqYmqd30ZDUlsPPkboJjY+xaty594FE6AV4gCEPXHHjeh3Zi75ITiI18nC2UX/As nzbkB4WMsm12GRAVfcoPn6+WnvV/WtvzpBVu7c8e8sRKjbZZAY1c+hkL6mH030aYnjLmq+Ak rnkSLoRTV25Q+wHeiAaFpYiYMut4DeTuwoF7LIX3PLEdUYClfTpT5sW/VIRhjAOY64wcGsMk fjwDoAq1vmTgc5gUO7YzOolFtQnrITIN4xZi7PWQuG6AxsrBqOWyBPxxZfKPUpEdSL8mglTu 7vYo/tFSJWvyKvrrNwBY4T83BBcPFCj0wmB5SJySRbeqGwaSoiJ2xDBnaN/nS5N+wrGA5rup QmANwOH2mAoUlzZea0I4bOQNPyIlg1Vtpp+kGEK59a1qTu/KwiQl7pjcxBfCHSyade7jLq+p 4+xx8OnjY79gE/hcUdK3Byipd5fREnExCrncAOgYgGR/T4KyxYUgBqz8FvoxYQ2nruHEFnoV G+hzH94Dr8/0pq61HjehLDgGGFMoyPQFK/SMLIyK0VFjPYgV8KJ/5vrMkRtGZzZpX2vlTsXQ NMZWd0amkQCnNQigG5K0U7Ke4qltgoFNdrcPToLyRbqWIVf5L7Cz6WxzZFwu6OlPodf7bpwX 5EG2Z8pA28rDTXjgXCB9AtMmP41VWIaqf2N/QR0GOCf1DcjzNBwjWWol/G0tC4sljcK5NYsk 2fATc79w5HkH41JWqA+y2azhzXWeS01HmWSftpa18grwCIj6XYXKSuu0Vjw4S33oqSXmV0uX gAjEswwL7acvq2CDHMmcMPX92uJQxbp7E4ITKKGDKzduvN5elpm0dJrqc7rj5dkHvngN0UM2 d0uot4HSMK5l5ZSQWFDWN+L+CTITXB+yu6f2rsJ7lNtp8poEOCL+0vvOlh/FA50FiVpsByEM LNmSniZs3pb1tRkySsls+nTbQJu4JXDlAbko65080S7rAxMMNn72EiR0hqxPX+uu1kpk+DRL NNoi+fKAcHgN+gYojfG1TnpUXBEFG8u5QnM1rYzQDiv0tue/OxJdv986U2UpFsUYXhG+f942 +I2H05d6jIweJlwzum9W+rbQpJTI1zB95wwmdjH0a0TZuoNnFhLqeaOoKLB+tk/OFg93lH0d azx+YjPM3TeUUkowFwBnwXZ96qo6QeJ+TjFcwM4B1iO1Z5VWiexfRkcVkmYbwBBHMfDnMO3l bKhkWVyR8C4N3uPAxED/otShUiFcwjNo4mbiwSsZpFxg/QU+3cv8HtIpOFmxS+GEJouVPU1u 1Wv9uOAM4bOI116Lwlf9s6/BOI1+UjJbif/OY/cIRcVnTF23nNnvY3SbX7XG5N3c5bd+Yn6M UJQXM+zZ3zFc93a4h5LSCKXoHumiZ86IVdsbPiDQB709mXrwneQQH3ovzEvFagqgxUfT6kol VQjViQCkfn4UxMbSuPxqkn8nTx9+nVfJH8yE4K0HpclulwSx7E58R8UempQQdGZLCldrl9cn +9IiQSNOBTzC9o8X5ERBCLoueIA2p3k+hOuE+lGUGNOQV5YGyWlq91to3MGONv3m/HMxlEEM nU+ZuiF4oZUDZfUJAHHqJXbrEOZTNb8t5zQYN+itixkG4mMfC9F7l8QJk9f+KMiLORWepSLZ evTfIGRMRb5bzH+UjOmvdoBDro/G+k2fM7aXDmuKLQrpSyFK/Rx4zbKuTRx54Lv9NTERSh0i B04TqV8WzF0IysqoPZP4+/bcoHk2dXHqriMDZBpYRv951ul8cYLp3H4jJ4y18dGhQpdF+yeS ZOt7/LTblhIKy9maYmoEB/JivTB4ivX6ERi/LWuvC4Em0fzdXH4Gn/l5jPbXjfGbAJtEqYoY o9DYUmUGinFTNEY1qjcUrd3JRdL3ibxdu9owPhZZT0m+Zj+frgxWH0MoZwu0eHm3SsqwrYOY S0lDHE4rvd6cP5IaKH8v4fCmOjugrg9ylYgqKmo48E3wXSfdkQY8ld0vnFJYIEI2KYh+KMS8 Skknj+8SMCePmfUCazK63P+rKjLUpp05ObrDlgEI1GFuwmv8CxijfbESOWXafuLy5PgxWk1J TTgsY6/BueU6m6Mbnx3o32wJ1tJvwVPag5lmXKS9dk6TTI3WLBaXqePOH0Du43zS9ovFeua8 BqSY4jtRwPgVz3DZ3mKeOKHhWr3Ez8rVIDKFs5tkwgl9MfzL5rSyVF90ArMF7UND89JPs+kQ 4uCB0uAAdqAQyHxOCK9za25Cg/xfJX5Pyg65KtArPx3uQCgYLIq8RlXvUvCP+rB5nF+x1XHn CJauiZly8tfpgulc2tTOSQKCq1qhpOG2UeA1hwIpzSN81knqOx1qCRfcFmP9RYV4H4RsbHHM GTqC2NuZX41b9VZgvotrVw3ARJkvNYeImmUzPLDFGBBgVSF46dEAwifwvM5DTrPpnpY+1hYV DqmDuZOOrDrAWfJKXv1+iPDSx8mH4fnfdxv69TL3OfRb0BxPxl/TqNlCcFU7RFkKfEqp6bO6 eH+2Pdv69pwx00jhMaS2RoNZcceL9cBd6UblyR8wkOVc2t/YFtbFBBC5VsCU7gPmceiYPh08 Uwd4jFwhr9IdgywwPJa43kMAVLSU1s+voDS3uCWkdoe26uWL2SXaqiYlTO8DaMEB1J7JWtT4 Q5KRl9KWVvzYjlneTk7eM7rzl+SwsCm/vx1Ek9Fd7pf5knjDI46t10BGGUethb3Mr8qRr7gy +6fYnbwAXpijuph49NQ46SwW+oPyLYbcu8Sfb/bSkEZYHpy9o8Bj+PB48cblduE+g3YrtuBC 9bYeZDD9dIM/MfyHUIMpetrZPU/gmU9MsgSWM2uqSOM01SzHUUsuAFHqq60qMoVMryF9KiAJ cLrAHpcx2Go7udxrymPESJG+UZmmfsN1j9A3QqPJTELSD++NEF/bFcpRKStDhDH6kpgFuMbv JvSHdzoC+5Whgdp7hOi/GkmOufAw0ZYCLHbVQdHW+j24iu5tHmTL/mxy9mXnmwLxSqXjRzQe STipXgWw3t5p4yIyIKnB8hSSsJClZQ4rVeEnMU2QMOliiw6xgmpGhejjulH0qMALBRv8dim6 AY7omxdtr4w9Nw3k1VfrT7nY1g9S1p9LgK8mMyMLzU5+CKZb8BTjdcu5/pc1JAlDvvrLTajZ 0iEC+pKaL51/mr/sa1nAaFUscFsQ0U2T6rjmLzhzpYSObLM3n17NFepGXSU/bi8R4jlaZqJt EUpfFSoDVgXBX4I8WEWMIoSQuY8JatVrz8RabO/gYX6qSXOejyyXixUuhLrLhWOxOMPDzLIJ l7Jgy3Ys1XHgU6730t/QeIpMaJyhw7bXb2I1WVcIrRm3R36gmsap3gxNkQZTh1r3KYb3HxI5 ifKkQv2aVpT3l5ZyespiZw5AQxBRPS5er6iEf3Anh9T3ElxhHc2GQrJtcc/s4IkJ8neJ8ACl P/9mjjZRgXIKlLhyQLUMvDlS6M/VGFmFMxCLIRJyLJFQMviXRgNcO2KBohsxywOXQg7i00Ei a5Gxa7muex+QJHoEEF3AOcLrf/qK8XAqt7wxoXQJxXW2K5bNGN+zXZXPbjGgKL5I214JPe73 4TTPBjqROrPFJwwtSXQW1PJgd5rWOf85JNc7lnW/3QFLoIxwtU5vRPYC1/va9mCcDkI0tJEi 6bG+Xz77/U25hVuIz7cB026V5s2OvXEVnaFVLqMetLBoh9GQqg6wRGcxDI2x6E0/D6e/P26N evqBLXJBvkSD1wLiX2tY8k28f3uCMYFELgrdLptK9JR90Kd1Yzs4ipPoQO2EfMFNL/z6CYKN qRx1LNgcLAbkW57MUoDWBNPtUtoaAvRJAcQIUfjAUWcgReCogpjFVyI4FhQ4x3rvKjRNTR9W YZcJzVl730t09cgbgSHpd4f3kKH7zLw2FnKXZsehRySBDzS6hOJv5/uisCUkm9FIFPa7dZvF Yz8sYEMippwBpucIhREjcMER0Oc9DTk4NYWAhgPMgkDNM7U7PrGpWb2FDqGohZT+eJWRwqgJ 0otQT0ZHWdsIzuUROLt1FCPPH1zkRc/6zS3iHjhYNcdFqljLmNEqHAAkaHMit+7K1r4obBWJ 9nPTCH3MRgb9LEKSkq0pKlClZOzEuGsDmUdI8w2vod8magVKwQrrn9FY05Y8UoFWunICZBxu zkN6jNR9TPLd/jPk+cbWHRh4FMEncmSzHtQu9KCol88sG2FDP47hWRF2DPZUOt5kSxqbJP5E HnewMVzTgSyWvK902j/PnYT73TWDdC2C48/1rj5DbPmvK62CshB7VKCRKX01rxgGIuTwQ3I0 cc4B5WGQpqX8DM6+WS2trP6fyKgyoOE/g6KnU04Q4uKzqmAE4om6DLSyjMrnsDo0SPQWNxrH 62GVyS10dBrIU8C/4nKGzlKhy//X6jcuturgkzccYBOLa2QE3sJKEtv9VVS6WEBWMOgcxbMf 69JB2pc0xBSYS8L/ingriFiRhkWV7NrLUfowkOyoIhHu1Qj/kys3gtSSSbOKhNrQ2lrcJ0fa 8rzComs5a/QSydaGEo5RHU+ZLSAI3Wps2HOltfehVOjyUP/GjUhZc96YCqCS8i3w3x8BKp4R 548daMRTX7pNvMHhEMgjp1K83slbGZ44A4KcX4KMYlI2vg2E3TdEi9xU2256L7sI26L9crb6 TE1ima4//b1NGTN9D/LHyHZq07lY5CiLppKibAxXF1lEFCvlTEOV6pw+tWjnipTscD0ffWIX LRdSfdeQYuEhf84Mg9eyrIkYO8y7VrU8UH3Yb6WxGxgXMUNL2evFNi1wcA/OvpjaqwvMXeOW uMPSZRYOpjJFYPtb5dXnt1KQyAhooIo50zHHVa37ZjnEEnEo1ExGNhbaAyJb2p9T3B8TEfnN M73bFEPEb+wVKl6eyk/DPeC0QzgPIKQOEl02oxOqofmviDBM6k9M5VgC6FI0Tagl+cLj968b 8mSVao1M4qvytM+kGZRo3akam2KLvfpxUqOYk0ez5Yt8P6+KtYzPnHwqYbPRvzwTZ2AXJ9zy dyeUteYFazQaUCez/4s9qQ2f8RTtQNz+QcRZlQjSMemBFLO87D1D+MGSFljFuHMRLUudUKVf nKGmYy41MgqGs40FQ5AihBVxhz5ZZHGBSgShGJmZgzmbyO4iH9Kr9e8gbMJ1ifzGpcgWfmNn h701BR8De8aYbL2wS7NFgTcclrATrQiw5rt6kqz43P6JbHcOBREGH77DAitoW4fMD8T4NqlX hU1fz+krrbYLSk4+A+ToMbOTNwrsXH95NgpqZkSdvK0/PzXYO9ToAYSotbbtfd24QJwB77yJ tRHTVyaH4DeaDuChlKEof/M5oNWPE6nNGUXVmHbBujRExDyWh/eJGpqIzC12QBc0G5uupJvx 0hd+kWzHuaoDwxQUSBvQDbowzXKp+nrYRnnWV1yuNa1ESTOa1VfRDKif0F/wS9I5ynjKZBh9 3TK9w3e5xb04wvpv2uELdn6HhbIA5Rym/L4HAUjqCOWfPB/jU3qRt1kusNRcCEs2JsLsPUsG JMhejdGZan7Xi/+NiYjYNI1awQH/A4tmO2l6HHEnkH0HDsn8D0gGOVn+TzqNb/5mUE+gyiMY +8yIQpcs0WaMIelBpUtpIco3oVECHx952Kro+fXXBavx0R+q4vOVoN5ysRh226ug34gDkKk/ JJz9HDAG54pKd9LknaaixSH3RCgGnLSFnJWdEp8s/HnUEteMEcKLArX9Aapn/LpOAKaj2B3F KXe2iMaN9y14pgHEQciX5oGkhKxyT1jwiJZ54aP/EBfEaACFp4umTMPpyQn0c+yB2bAXGKZa MFKy6mQ0AO5uvjgrjEjD4ZRQL0zVFoAJTopUJrQRzPC9s/m5ZKf1QG8GkFoMnjNAXAl1LOcy B7RKbwM+uyXQygHSWWvrLFMxU0/kd8a1/E+UrwvFr/+YHht670M8Ew7WiUoEBJ/VhFgIBf8H RgWNij3VuML7wi7huvvzUTOlF0N73Xt5X0s+2SFKszZgk9b8PEcCmSA2ZSltOG1mWkvYrNDZ u1C+YZ92uEjRrXC5eAOka6NgC+5bq9DiIihlpKAdDJ8SBnAfeFZ+s5r9nLt/TWBDPhF33a9q RzmMxjkRvyC61fashvYWfOdfpN+VA8vF4x8S2b2F0SbC7NeqAkrEaQdleFz9G3QFM41lFXak cokJ81ekUh0PaN+tnDRWDdSz3NjNjQDD646gZLikvx1OA2XxAGwUlo4rlTpHkYwfOAq+k1J0 yzJywusdGqWkKq8r6yHU4qb3GRYAoT/3aOIh4dKVbPH3HSQIeqfiV96wCzULvR7x27/sWG24 nw0VDRD6Qmp2brQMRmHV6qLSjNJYEN6yRnC2SsmpWpNEA5SD4k31pb11nD/fpbm/iIAlVjWc RfbIIWCi5MbySSyw68H4oVxY4u7V/3EpODoqRTCT8A+nY5iOcQI/+gKklADprpG3OAm+7LER 7MoZKxjs/qMSk9af57diZ9VIVWMf/XgdjZA6VqhtLznPuhxtJS26gnj519AYDAT+DQbkTADT RVpGjiOwJgElhf0V8d8ASHuVEZq4F4T7LBTBX5Gs7rGavsE5wlYbu1WGhBEJv3T6XphzR72H 5wZqKPmHE2sFT6lVnab4AyC59cNljDZs/miUdUY/2xbFU5MFSivaQW+paCdAN8kxvLi/qimy w1+igfdpOYZHU5CJfiJ6Gnz/F/rAoVZnrD38fFGg7IJxfcgG/qFJWS1BlMLThZ5O+uAfxPC3 O87yjXS+E4d87gq9SW3FaMc8blez5iuAWpgZouu9p0659jV3dYLRDEzFRLCi/fibhAxxWdAB BHQD8RK/T9/ivC1BidzbAocG8A+x9lfv1SRZPfpYBGc22MLkId+0d+Ovjq64Qh4klOZfT1JD i+SlC/NFlHen24ruLpPyO04EKXveQfa38skKMdz8rbGlbQ14sDvns7Av6WIsbOvukOmWf4tO z+k5R8Jc3eF2PitW3xxZ8bCIyPB4MRwU/y+Yun8YWfa+YHZr4etN7EluxgNAdGKXoJBWvxJk 1LQVTGCVjivKQ0/GToY1m6PskmvkAPgGCGRSAqQvbwYnNMmogRa2dB3+DqaXQT3X2CbaRx9T 9DEDPRKBDqBHH1f5oz4+cTtuoAj9qmZHwsDeulREsc9xXPIz7kILbcQ+KdYfY5u6ZGLaBvZ6 usx9RWNW/FFoluv2CEV7ykzJ/JqQXixx75LQ4d6kDEWwppVAbGuFH0jcQ56ORWSffc1TK5HW ZBxsiZSgMwkxtkJPzWVWUB1J419biRG52iahtlLbX4/JaPZvyWcP/hGDfCHD7gseCbkL2mzr arSbLC1P35JJBYfbjV9FJaMos123BPa92G//Ap9QYZmO9ODYq3ENjowrCwpAE7/pFAPo8oWg Vgn2qGivnlg/0B4sbRJY4MSw11f2uj+Z1iH/FtpPTaan6D+a52X8jHw/HNxuayvES7Y1+FTH jsL1A03RDlnwCbRw2uKzQuyx/tFRRcwWHeD4WQhL7j17zHyDhIR0GtGTZ6VaLACC19TYqeEA UAbcQjCjE8s8ThpEssVF2GnH//hwmVVlLumdjvgKsSTLyycEkRoiI5As5O0WOPdyicoM/NOI IimlIIuQ6fXceCOPCXIuOR8X2U04VoDainf1mBx1PXTM/GDtGB8naCkblhS4mQ7PVFQWr6DB dtkYJerm9Vs5VHF+Q6tVYLT0cFkXX2FhNS0EcQ2euG5zBc7MjQR3ccgtqf1tlXpJZBcAYAyw e5Pk0zuHkqMRxfshFPjpOoGodVjV1K4OCEdZSHdVLemSL7h0aI4P/W0hJ4Jcg9OB0jLWfXYQ VULOZShe4a5EWNcuHPJ7ZZlt26YaJTiz1OCH3aG8HXuILfAOw2qlUi4Ym/2bJmmqtfQOO51r ptj1VNGXQUBMf0M/+kh/jxTHgPMIUSe746qHRSVez2x2uMKo1k6ci2eY7SnGPlLwWQ1sPbU8 5kyCZA2hC8rEu3O4vEcY3w/3WeZSrWQlp4x/asdqjLtokaZsFlCsgBa8xahtv5CeyOwf8GWZ uuiB6DO1VFPOs9QR4LVOenDinTNArZ0rM0Z0ANS723IL0Q89VbRFG6FsTLvP8DIehKaiQPNR SguqMmFARVgPNY6Nakd602ai6gzf69h9p126Etl5Dg/7Bnuf2axVBFARt88bcrimrmBGodB0 YSsDOhZ6x3y4tdJADl4TgleSwqh1sroxUEe437iIq+djOn/3Dz0Q6i623ryYepyx8Q1y90lb PK9wbprR+4zZ3ubfp1IvXg2ann1Dht3ifCS+Wf1BtRdWDlb7njTcIXJhLKFBdlNmsuJw1Pi+ yp/tZtuGmb/4H5zLKPlgtYlrmtWL+9cAF0rHTHokZQ8FjBoZ2vm8JMvYQXt4CltodoH5bo5D Dz96Q7XtNNI9dz/CYZbZUtidR6/wdMlRsth007uemB3cFJQoaznXJYDrRmYcZQTMRNO/Hue0 yqQI4z2U7c/j7tgdb32oxmaoDkgIjE+bY3JwCnNXCANH02YKHtb0u/8fwEbsOPvcqmAkDVBR I1dj6HrngqbizZLVlSW8ZsvtrT7jExVsGY+muK0BtbrBTJ5LsMwDIMBzpHhkxSENDJyBqrAS am4ynetgvwXD2KcX1FaCAOBJr/TvlhwEFrd+bMmaUtwrNak3UlsNzpEd7Mby4nXj0bVJyki0 lFkDdViF7B1d3LwOVYdNi69qFi5GHXfERFh2nFk9K6ICubRJnCVtmbQuSpa3MwrVQMrAa7Wp 2kvQx8Oxr40FQ6RuY4BYltNfrZTmx/XUW68WuFYbDfMcrOdXuKjC6N/Yvh82OTmw7f7Hz9sa /yPZLP3YY0mpqsMPhVt3ppC/yrZBibweMaZv/YEDLnFOEc0uwiSHox4sCdziqM1eiLwnxdJW AHAVNakJmz4oSo6rCl9xjc6sDSXBOTVQM4SQFHnp529oPU+G6OVW/BZMHTyobKmfzvyCwNTt b5sl5dtADdLFcQiaWfBech1Q8hU5UV4YRhb5bDGxCyYOGNDE3wx6EFZ+E62bE+g7lxsEACzf tbhhE7k5QLRyyMJ8AC4fi9cgh3jE69ziYoYQVjYRLhsZHz5KJc/+22gRvDXqfzQ+TLRpIR9I YhRQ8uhGkeVAwfwhgiPwwrW9B8nKdM4CHQfgiwBJHMWQILbMwTCUqANXKVCOUABU222T48/j mwkhARsXx4eWfM5PGcK0gqxpXNI40jiv8SwHfx6XJ8zTiarY6NIqtShtJ13JQbPxGUGU1/i9 HW7+Oihh2Ydk3SS/+zK9VQWCcFF4t7RuzpoegF/cKCv5oLXBCcFywaiLNX38Cb1Vptp7FvRA VfDc5DeJrnnQq9AS9Nwh2myBPu+hV6dQ218+q+Aja22FA1d+6/oL37jz8erM7rkqdUTHuzii 33MMf0J1UK5CKMU1E+HX3X5Jnb5pvwVNU9A1fGnzU9AGv65Gv8YdHxqB/zeU+Ud710cc5gnX e4bTFoE71sB4j8KMhG2djL3ECCLG1C2sU5D9Cj4Z1+lsxuiHlMEntg4QNmmsIblvXjHNulQy aHc75g+C/jECqrpnVzlRntNOl1VRlNxGWUNcP2v6sE/l19iomcmIkhweIiL1OjeQ5NIUgCEJ cPSn02nlAKhblssY1/D+JUP8rg5usJrE17taeSoYe8JqXkJ1KKOq8xqkwfzEkcfxi5zj863O koVxNXYgDWovaOBoH3L8DSJpy5SdgHiJvi6wP/xfAjsBa7dxq1Hr7VNvbQHjxF0oaHuIYSEG +6qhzY9D0Fc7VgDAaEursmfoO1x7x7J5oFhmOuhEjFlOemBlBgu0cZGXEM9EMwY+jAilYwpz ssrh3bfp/heN4UGD8pyDECrCw3emY6J5tydKp0NiFDg56dwwzA8b2rJ1K2ATv4P6tjrf8PQe Nbja+t+1k4rtVT/8f9Uut8Q8n2zaCAOK9UvQYq68rJKNT5sk15W8C/kU+Zr+ZN3bWUhgTHQP rSznadtoZGZI8ruEtUIUp20q/L66ABmccoOHkfPQtC3itYxKyb8iOtnEG3AlfEGrjJOwa6BP wInhVIheOWDWiY1JpvstRjVxU2pZsHuhveK2Q4v+arfn4AOb5MEE1DM4KEEyYSAdrgwHBrcg ONGqdzYtWlmKTITesqJTQMV5s203+yrbwhDZf79pdd5qtKga3dOoq4T7BMya8x3syxplYF2m 3OEvl6fguzSgCf6DV1v0KkVlc73vKpxSrG8uUBv6xUCoeKwcXO1L5p6Ia9bqmgshEQ38zmDp JMstf1eEk7btTRFjpdU8i1B4oqrlsrHmYqtrOySe6uSVKfxnzHaFdAV8LxQW7zPle4yDfQHq R6zoyZ5vpUQubUvEFWGMO3YozVjuJ/8DpArLY8YtbNiT25GLNDXLtSwKq8v32nQS2NQ+c97u pnuJ1s54ZBhF18PGiHHLzxUN5IDWqgPRBExzMx/6jZ4M13gtMRK2H8teuty5abPCkk6W5EN6 0k9c/+bOc3pwWezkg7SrHsMJV2QeH8yvHGAfJ67Oe04y7lCdZqI/5EUYwU2xvw4RY+TnglTb px5GNv/HnnhmkJ+RwMSA/J3DSTFI7Va3vzxiuDkWV+w5OjQi07f3dLPhAJzPlNp95bmvAHx7 fkPqKwbFyERe//93TPgjytkt5gkvd5ClUBZDq6UhjQ6RgVQJ4vE3pAW8tk7OTVZ6ckmEdRcO d+Q88Q5GJemNCDF9XcYJK9WfbhiQvyOMNlnYQEpitRRE/xgJNoJ/u85jBdV2M/Dbk4GOrrW+ 3+A7M+IrpaFI3HhyQkMbhLYexgZMs8CEX0lAFipoIqk/QfjFCwRcyCFawAwvgdQ0ri/qqSjK cdxCQ9Pvunx3O4u66uZ0Hnp4fr8XjGY3s1uUi44ZshDfEios7IDBqOsP++Px+gplbmRzdHJl YW0KZW5kb2JqCjYgMCBvYmoKPDwKL1I1IDUgMCBSID4+CmVuZG9iago3IDAgb2JqCjw8Ci9M ZW5ndGggNjIKPj4Kc3RyZWFtCvZyN3nUAE8P5TnVkbPEJ+iEPM6jYZ8x5FmRsgpPGMlG0EcP QMOJMp99kOwsTp45wzoQVCmd9A9wUWoCn7e+CmVuZHN0cmVhbQplbmRvYmoKOCAwIG9iago8 PAovVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9NZWRpYUJveCBbIDAgMCA5NjAgNjc1IF0K L1Jlc291cmNlcyA8PAovUHJvY1NldCBbIC9QREYgXQovWE9iamVjdCA2IDAgUiA+PgovQ29u dGVudHMgWyA3IDAgUiBdCj4+CmVuZG9iago0IDAgb2JqCjw8Ci9GaWx0ZXIgL1N0YW5kYXJk Ci9WIDIKL1IgMwovTGVuZ3RoIDEyOAovTyA8MzY0NTFCRDM5RDc1M0I3QzFEMTA5MjJDMjhF NjY2NUFBNEYzMzUzRkIwMzQ4QjUzNjg5M0UzQjFEQjVDNTc5Qj4KL1UgPEVDMDk4OTNGNzhE RUM2QkQ5MkQ0N0YyRDdERTFBRDFDMkUyRTAwQjZEMDY4M0U4MDJGMENBOUZFNjQ1MzY5N0E+ Ci9QIC00NAo+PgplbmRvYmoKMyAwIG9iago8PAovVHlwZSAvUGFnZXMKL0tpZHMKWwo4IDAg UgpdCi9Db3VudCAxCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMAo+PgplbmRv YmoKMiAwIG9iago8PAovQXV0aG9yICgV+kAHPOckKQovVGl0bGUgKAv5UhF4ulxu8I+SPNsC FkVcXGItB17xCILwfPHQXHJ2aZBgsv7t3o/u7e8pCi9DcmVhdG9yICg27kcEO98kuMopCi9J bVBERiA8PAovSW1hZ2VzIDw8Ci9UeXBlIC9JbWFnZXMgL0tpZHMgWyA1IDAgUiBdCi9Db3Vu dCAxID4+Ci9MYXlvdXQgPDwKPj4KL1RpbGVzIDw8Ci9Gb3JtYXQgMCA+PgovQ29tcHJlc3Np b24gPDwKL1JHQiAzIC9JbmRleGVkIDEgL0dyYXkgMyAvQlcgMiA+Pgo+PgovUHJvZHVjZXIg KDzzTDYk/Cyv2IJEhH9iNVEfcDoevRPK4DrsywV/KQovQ3JlYXRpb25EYXRlICg7phNVZLt8 7YyQPdAbE0dAeFwpakvsUZQpCi9Nb2REYXRlICg7phNVZLt87YyQPdAbE0dAeFwpakvsUZQp Cj4+CmVuZG9iagoxIDAgb2JqCjw8Ci9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUiA+Pgpl bmRvYmoKeHJlZgowIDkKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDc0NTMxIDAwMDAwIG4g CjAwMDAwNzQxNDUgMDAwMDAgbiAKMDAwMDA3NDA1MiAwMDAwMCBuIAowMDAwMDczODQ0IDAw MDAwIG4gCjAwMDAwMDAwMjYgMDAwMDAgbiAKMDAwMDA3MzU1OCAwMDAwMCBuIAowMDAwMDcz NTg5IDAwMDAwIG4gCjAwMDAwNzM3MDEgMDAwMDAgbiAKdHJhaWxlcgo8PAovU2l6ZSA5Ci9S b290IDEgMCBSCi9JbmZvIDIgMCBSCi9FbmNyeXB0IDQgMCBSCi9JRCBbPEQ0MUQ4Q0Q5OEYw MEIyMDRFOTgwMDk5OEVDRjg0MjdFPjxENDFEOENEOThGMDBCMjA0RTk4MDA5OThFQ0Y4NDI3 RT5dCj4+CnN0YXJ0eHJlZgo3NDU4MAolJUVPRgo= --------------050309090407010301040307-- From acmorton@att.com Fri Oct 12 06:44:20 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F7721F847A for ; Fri, 12 Oct 2012 06:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.707 X-Spam-Level: X-Spam-Status: No, score=-104.707 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neFCtxG8qBYc for ; Fri, 12 Oct 2012 06:44:19 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB8121F8443 for ; Fri, 12 Oct 2012 06:44:19 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 2be18705.0.1885184.00-443.5272721.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 12 Oct 2012 13:44:19 +0000 (UTC) X-MXL-Hash: 50781eb30d209bf0-32d17af3d0da4a135ae30da7b068aabf345bb4da Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9CDiIbe001179 for ; Fri, 12 Oct 2012 06:44:18 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9CDi8FQ001033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Oct 2012 06:44:13 -0700 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor) for ; Fri, 12 Oct 2012 06:43:54 -0700 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9CDhs85022951 for ; Fri, 12 Oct 2012 09:43:54 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9CDhbR0022274 for ; Fri, 12 Oct 2012 09:43:46 -0400 Received: from lt-hp1044652.att.com (vpn-130-10-101-53.vpn.swst.att.com[130.10.101.53](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121012134237gw100r2c1le>; Fri, 12 Oct 2012 13:42:39 +0000 X-Originating-IP: [130.10.101.53] Message-Id: <7.0.1.0.0.20121012085911.04d2dc58@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 12 Oct 2012 09:43:25 -0400 To: Joachim Fabini , Matt Mathis , Ruediger.Geib@telekom.de From: Al Morton In-Reply-To: <5077BAD0.7080908@tuwien.ac.at> References: <5072F59A.50507@tuwien.ac.at> <5077BAD0.7080908@tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=LaGLHEji c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=laZDOc_PjGAA:10 a=psMl90NyQcoA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=n6WoLlRB] X-AnalysisOut: [BTQA:10 a=48vgC7mUAAAA:8 a=cOT4Sc1-aq1Z33Urs18A:9 a=wPNLvf] X-AnalysisOut: [GTeEIA:10 a=_W_S_7VecoQA:10 a=V3I2Wy5VfsnCoTtP:21 a=7qKoID] X-AnalysisOut: [bnVJRlP6bc:21 a=ycbqkcrO8Xlr9NzV:21] Cc: ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 13:44:20 -0000 R=FCdiger and Matt,

Thanks for your review and comments so far.
I'll just add two points below (one to help define
"actionable" in the way that I think of it).

regards,
Al

At 02:38 AM 10/12/2012, Joachim Fabini wrote:
On 12.10.2012 04:35, Matt Mat= his wrote:
I think this is a really good start.

Thank you.
+1, we've had this in-progress for months, great to get feedback now.

...
One other item for 2330: in t= he list of metric criteria, we failed to
include "actionable" - some of the existing metrics don't provide any
guidance for somebody who is unhappy with the results.   Although
"actionable" might be considered to be a sub item of "meaningful",
some existing metrics don't do so well, even though they have well
defined meanings.

RFC 2330 defines extensibility, which (combined with repeatability) imo fits pretty much what you describe as "actionable". The solution which we are currently preferring is to find/define a set of metrics which can assess a) repeatability and b) extensibility of a measurement methodology. E.g., using measurement samples of one or two subsequent measurement scenarios (metric & methodology) as input, these metrics should provide hints if 1) there is a likelihood of repeatability and 2) we can extend measurement results to other scenarios/parameters - in the sense of metric linearity for a specific methodology.
Perhaps even more important and easier to realize is a metric output that properties 1) and 2) are NOT fulfilled.

We (network operators) always have "actionable" as a goal,
meaning that the measurement results combined with some interpretation
should lead the design or maintenance forces to their next steps
(to improve performance or repair a problem). We move a long
way toward the goal by selecting the right metrics from the start.

All of our/user packet streams are influenced by a growing number of
reactive network components, maintaining and changing state.
It's matter-of-fact for most user flows.  In reactive nets we can use
discovery, characterization, and with on-going measurements, expectation,
to help determine if there is a fault or other undesirable condition
and what network elements may be involved. If the measurements really
help to narrow-down the problem space, they are considered "actionable".

So, I agree this is a useful consideration to add-in/update RFC 2330.

As Joachim mentioned, this expansion of the stream framework is
intended to address various forms of reactive networks, and certainly
includes wired networks today. The concept of pre-load (as Matt called it)
is important to any test path that includes a firewall. This
aspect is an important consideration in the LMAP requirements:
http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00
and probably also  the project described in IEEE 802.16 Liaison:
https://datatracker.ietf.org/liaison/1195/
There is almost certainly some overlap between our draft and
the intent of latter project.
From acmorton@att.com Sat Oct 13 06:44:39 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3FA21F8513 for ; Sat, 13 Oct 2012 06:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.896 X-Spam-Level: X-Spam-Status: No, score=-105.896 tagged_above=-999 required=5 tests=[AWL=0.703, 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 1XLGJWVcaWmy for ; Sat, 13 Oct 2012 06:44:38 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 199CE21F8503 for ; Sat, 13 Oct 2012 06:44:37 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 54079705.0.2258897.00-436.6277119.nbfkord-smmo06.seg.att.com (envelope-from ); Sat, 13 Oct 2012 13:44:38 +0000 (UTC) X-MXL-Hash: 507970465db9d1ed-09774cd3afe86231c4eb247c65c1a0f29b0bdaee Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9DDiaW0025816 for ; Sat, 13 Oct 2012 06:44:36 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9DDiQ4r025732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Oct 2012 06:44:33 -0700 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint03.pst.cso.att.com (RSA Interceptor) for ; Sat, 13 Oct 2012 06:44:13 -0700 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9DDiAnc005473 for ; Sat, 13 Oct 2012 09:44:11 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9DDi4ol005127 for ; Sat, 13 Oct 2012 09:44:06 -0400 Received: from lt-hp1044652.att.com (vpn-135-70-178-82.vpn.mwst.att.com[135.70.178.82](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121013134304gw100r2c2de>; Sat, 13 Oct 2012 13:43:05 +0000 X-Originating-IP: [135.70.178.82] Message-Id: <7.0.1.0.0.20121013091948.04b1e628@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 13 Oct 2012 09:43:50 -0400 To: Brian Trammell , ippm@ietf.org From: Al Morton In-Reply-To: <65974042-2522-4E12-8CFD-1236DF60CF74@tik.ee.ethz.ch> References: <20121012083122.13716.29945.idtracker@ietfa.amsl.com> <65974042-2522-4E12-8CFD-1236DF60CF74@tik.ee.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=erZoOPVX c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=_prrHr-Vt1IA:10 a=lWr1GoxcmDkA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=zXfgDLiO] X-AnalysisOut: [K7IA:10 a=48vgC7mUAAAA:8 a=3U4DEcwipvtZGRC01hwA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Subject: Re: [ippm] draft-trammell-ippm-hybrid-ps-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 13:44:39 -0000 At 04:38 AM 10/12/2012, Brian Trammell wrote: >I've just posted a very short draft on hybrid measurement, more a >meta-requirements list and motivation than anything else, as a >starting point for discussion at the Atlanta meeting. Hi Brian, I like the idea of specifying a framework for passive measurement in the context of hybrid passive-active, because the comparisons between the different techniques are quite useful. Your effort is well-timed too, with both active and passive measurement requirements appearing in the first draft of lmap requirements: http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 With this obvious synergy, I look forward to discussing this in Atlanta. I noted one point to consider as you develop the specification: > The proposed specification entails: > >... > > o Definition of methods for spatial and temporal composition of > active and passive metrics together allowing for estimated > uncertainty. One of IPPM's earlier projects updated and expanded RFC 2330 section 9 http://tools.ietf.org/html/rfc2330#section-9 and defined three forms of metric composition and aggregation in RFC 5835: http://tools.ietf.org/html/rfc5835#section-5 I think the definitions you seek above are what Steven and I called spatial and temporal aggregation. These are the two aspects that we didn't complete for active measurements (IPPM has a spec for spatial composition of active measurements, http://tools.ietf.org/html/rfc6049 , where we mentioned passive measurements at several appropriate points in a low-key overrun of IPPM's active-only charter...). Just pointing out the past work that might help the new effort! regards, Al From fabio.ricciato@gmail.com Sat Oct 13 07:26:05 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132F421F84DC for ; Sat, 13 Oct 2012 07:26:05 -0700 (PDT) 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 WRG3F1y3Q-xH for ; Sat, 13 Oct 2012 07:26:03 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEC3121F84CE for ; Sat, 13 Oct 2012 07:26:03 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4905788vcb.31 for ; Sat, 13 Oct 2012 07:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=0I2iIYwl5c1Kko1QdloBH4qSSK6UeFpQbaWvCZM4ar8=; b=ou3rjMkT/epJldQB0mode32XjUJT3aN0ymJjzOys7OBEAd+KVxOGUa7LMZF8sWxTXn y3wy90s5FdyMRgNfpTFDVmHwBw5MeViOIzuCp2K9mpxy5hhCdWfnSJ7AJtpX7B6YQqmD MgEMyMN4sBG+VrZlCHYhkkZmTfhT2waUUXu1hIctS+qeTm/T3VEklPqnUmgBYRgpu1MQ x2LuPwg6by5j9O+jbybcX/FnG+wd34Y9r6qcTe/vcUdp3rqO8R8euZh8DqqlDOeBhmr4 QikUOInGMgPpMBJD1U0hAqy9yixugssRtjtxGNRob/ZDXIIcGfAe65Cey9NW6LbXfr2v LSvw== MIME-Version: 1.0 Received: by 10.52.94.108 with SMTP id db12mr3355321vdb.119.1350138363177; Sat, 13 Oct 2012 07:26:03 -0700 (PDT) Received: by 10.52.137.161 with HTTP; Sat, 13 Oct 2012 07:26:03 -0700 (PDT) Date: Sat, 13 Oct 2012 16:26:03 +0200 Message-ID: From: fabio ricciato To: Brian Trammell Content-Type: multipart/alternative; boundary=20cf307abcf988eab604cbf1951f Cc: ippm@ietf.org Subject: [ippm] On hybrid measurements X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 14:26:05 -0000 --20cf307abcf988eab604cbf1951f Content-Type: text/plain; charset=ISO-8859-1 Dear Brian, all I'm new to the list, so I might have missed something, but I have a general comment about the hybrid measurements. Generally speaking, I see two possible approaches to marrying Active MEasurements (AM) and PAssive Measurements (PM). * Type I : coordinate one AM tool/techique (with test traffic generated end2end) and one PM one (sniffing real user traffic, not test traffic) that are run separately (with some level of mutual coordination) and make sense jointly of their results. * Type II: generate test traffic, as in AM, and capture it also inside the network with additional PM probes. I.e., it's about the passive capturing of test traffic. I think it makes sense to make an explicit distinction between these two approaches, and perhaps to address both of them in a single draft (?). We have been using the term "hybrid measurement" (HM) to refer specifically to Type II approach (see e.g. this paper on LTE one-way delays: M. Laner et al. A Comparison Between One-Way Delays in Operating HSPA and LTE Networks, 8th Int'l workshop on Wireless Network Measurements (WINMEE'12), Pedeborn, Germany, 18 May 2012. ) As far as I understand, you are addressing primarily Type I techniques, is that correct ? I'm not sure whether it is preferable to keep the term "hybrid" for both approaches, and then use Type I vs. Type II labeling for discriminating them, or instead use different terms, e.g. use "combined" or "coordinated" AM/PM for Type I and reserve "hybrid" for Type II. I personally think that Hybrid Measurements of Type II have a very interesting potential that is still to be developed. Basically, under many respect they merge the advantages of both AM and PM. I can develop more the concept on this mailing list if other are interested, and perhaps we could consider to address both Type I and Type II in a single draft. What do you think ? ciao fabio On Fri, Oct 12, 2012 at 10:38 AM, Brian Trammell wrote: > Greetings, all, > > I've just posted a very short draft on hybrid measurement, more a > meta-requirements list and motivation than anything else, as a starting > point for discussion at the Atlanta meeting. > > Best regards, > > Brian > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-trammell-ippm-hybrid-ps-00.txt > > Date: October 12, 2012 10:31:22 AM GMT+02:00 > > To: trammell@tik.ee.ethz.ch > > > > > > A new version of I-D, draft-trammell-ippm-hybrid-ps-00.txt > > has been successfully submitted by Brian Trammell and posted to the > > IETF repository. > > > > Filename: draft-trammell-ippm-hybrid-ps > > Revision: 00 > > Title: Hybrid Measurement using IPPM Metrics > > Creation date: 2012-10-12 > > WG ID: Individual Submission > > Number of pages: 4 > > URL: > http://www.ietf.org/internet-drafts/draft-trammell-ippm-hybrid-ps-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-trammell-ippm-hybrid-ps > > Htmlized: > http://tools.ietf.org/html/draft-trammell-ippm-hybrid-ps-00 > > > > > > Abstract: > > Hybrid measurement is the combination of metrics derived from passive > > and active measurement to produce a measurement result. This > > document discusses use cases for hybrid measurement using metrics > > defined within the IPPM framework > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --20cf307abcf988eab604cbf1951f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Brian, all

I'm new to the list, so I might have missed some= thing, but I have a general comment about the hybrid measurements.

G= enerally speaking, I see two possible approaches to marrying Active MEasure= ments (AM) and PAssive Measurements (PM).

* Type I : coordinate one AM tool/techique (with test traffic generated= end2end) and one PM one (sniffing real user traffic, not test traffic) tha= t are run separately (with some level of mutual coordination) and make sens= e jointly of their results.

* Type II: generate test traffic, as in AM, and capture it also inside = the network with additional PM probes. I.e., it's about the passive cap= turing of test traffic.


I think it makes sense to make an explic= it distinction between these two approaches, and perhaps to address both of= them in a single draft (?).

We have been using the term "hybrid measurement" (HM) to refe= r specifically to Type II approach (see e.g. this paper on LTE one-way dela= ys:=A0 M. Laner et al. A Comparison Between One-Way Delays in Operating HSPA and LTE Net= works, 8th Int'l workshop on Wireless Network Measurements (WINMEE'12),=20 Pedeborn, Germany, 18 May 2012. )

As far as I understand, you are addressing primarily Type I techni= ques, is that correct ?

I'm not sure whether it is preferable t= o keep the term "hybrid" for both approaches, and then use Type I= vs. Type II labeling for discriminating them, or instead use different ter= ms, e.g. use "combined" or "coordinated" AM/PM for Type= I and reserve "hybrid" for Type II.

I personally think that Hybrid Measurements of Type II have a very inte= resting potential that is still to be developed. Basically, under many resp= ect they merge the advantages of both AM and PM. I can develop more the con= cept on this mailing list if other are interested, and perhaps we could con= sider to address both Type I and Type II in a single draft.

What do you think ?

ciao
fabio









On Fri, Oct 12, 2012 at 10:38 AM, B= rian Trammell <trammell@tik.ee.ethz.ch> wrote:
Greetings, all,

I've just posted a very short draft on hybrid measurement, more a meta-= requirements list and motivation than anything else, as a starting point fo= r discussion at the Atlanta meeting.

Best regards,

Brian

Begin forwarded message:

> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-trammell-ippm-hybrid-ps-00= .txt
> Date: October 12, 2012 10:31:22 AM GMT+02:00
> To: trammell@tik.ee.ethz.ch=
>
>
> A new version of I-D, draft-trammell-ippm-hybrid-ps-00.txt
> has been successfully submitted by Brian Trammell and posted to the > IETF repository.
>
> Filename: =A0 =A0 =A0draft-trammell-ippm-hybrid-ps
> Revision: =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hybrid Measurement using IPPM M= etrics
> Creation date: =A0 =A0 =A0 =A0 2012-10-12
> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 4
> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ie= tf.org/internet-drafts/draft-trammell-ippm-hybrid-ps-00.txt
> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.or= g/doc/draft-trammell-ippm-hybrid-ps
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dra= ft-trammell-ippm-hybrid-ps-00
>
>
> Abstract:
> =A0 Hybrid measurement is the combination of metrics derived from pass= ive
> =A0 and active measurement to produce a measurement result. =A0This > =A0 document discusses use cases for hybrid measurement using metrics<= br> > =A0 defined within the IPPM framework
>
>
>
>
> The IETF Secretariat

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

--20cf307abcf988eab604cbf1951f-- From trammell@tik.ee.ethz.ch Mon Oct 15 03:16:32 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C7421F8697 for ; Mon, 15 Oct 2012 03:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.742 X-Spam-Level: X-Spam-Status: No, score=-6.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 an3xgvDUN+6t for ; Mon, 15 Oct 2012 03:16:31 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F115321F8687 for ; Mon, 15 Oct 2012 03:16:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9942BD9308; Mon, 15 Oct 2012 12:16:27 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tBFFIGh1TLAC; Mon, 15 Oct 2012 12:16:27 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-121-161.antanet.ch [80.75.121.161]) (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 44759D9307; Mon, 15 Oct 2012 12:16:27 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: Date: Mon, 15 Oct 2012 12:16:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4CF99CAD-DD44-4716-97C2-830D0350AF38@tik.ee.ethz.ch> References: To: fabio ricciato X-Mailer: Apple Mail (2.1283) Cc: ippm@ietf.org Subject: Re: [ippm] On hybrid measurements 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, 15 Oct 2012 10:16:32 -0000 Hi, Fabio, all, Thanks for your comments, and welcome to IPPM. Comments inline.... On Oct 13, 2012, at 4:26 PM, fabio ricciato wrote: > Dear Brian, all >=20 > I'm new to the list, so I might have missed something, but I have a = general comment about the hybrid measurements. >=20 > Generally speaking, I see two possible approaches to marrying Active = MEasurements (AM) and PAssive Measurements (PM). >=20 > * Type I : coordinate one AM tool/techique (with test traffic = generated end2end) and one PM one (sniffing real user traffic, not test = traffic) that are run separately (with some level of mutual = coordination) and make sense jointly of their results. >=20 > * Type II: generate test traffic, as in AM, and capture it also inside = the network with additional PM probes. I.e., it's about the passive = capturing of test traffic. The power of these (Type II) approaches comes from the fact that you get = multiple observations of the same (known, active) test traffic, yes? > I think it makes sense to make an explicit distinction between these = two approaches, and perhaps to address both of them in a single draft = (?). >=20 > We have been using the term "hybrid measurement" (HM) to refer = specifically to Type II approach (see e.g. this paper on LTE one-way = delays: M. Laner et al. A Comparison Between One-Way Delays in = Operating HSPA and LTE Networks, 8th Int'l workshop on Wireless Network = Measurements (WINMEE'12), Pedeborn, Germany, 18 May 2012. ) >=20 > As far as I understand, you are addressing primarily Type I = techniques, is that correct ?=20 Correct: while there's nothing in particular that would keep the problem = statement from applying to Type II approaches, and indeed it seems that = formalizing the comparability of active and passive measurement = techniques for defined metrics could be used to improve the fidelity of = these Type II measurements, I had only Type I approaches in mind. > I'm not sure whether it is preferable to keep the term "hybrid" for = both approaches, and then use Type I vs. Type II labeling for = discriminating them, or instead use different terms, e.g. use "combined" = or "coordinated" AM/PM for Type I and reserve "hybrid" for Type II.=20 Hm. On the one hand, I like the use of "hybrid" for both Type I and Type = II, because both meld active and passive measurements together to = generate new information not available with either alone. On the other = hand, I prefer descriptive terminology to numbered taxonomy, and I do = think it's important to distinguish the two approaches. How about something like "combined hybrid" for type I, as it is = concerned by combination and comparison of active with passive at the = metric level; and "concurrent hybrid" for type II, as it is concerned = with the concurrent passive measurement of actively generated test = traffic? > I personally think that Hybrid Measurements of Type II have a very = interesting potential that is still to be developed. Basically, under = many respect they merge the advantages of both AM and PM. I can develop = more the concept on this mailing list if other are interested, I'd definitely be interested in this, especially seeing how it = integrates with IPPM metrics. > and perhaps we could consider to address both Type I and Type II in a = single draft. Please do contribute. :) An overview, problem statement, and = requirements draft (which is what I see -hybrid-ps developing into) = should definitely address both approaches. That said, I would like to = keep this work a bit scoped, primarily toward the application of = existing IPPM metrics to either or both types of hybrid measurement, in = order to have a draft that can be finished in a reasonable amount of = time. Many thanks, best regards, Brian =20 >=20 > On Fri, Oct 12, 2012 at 10:38 AM, Brian Trammell = wrote: > Greetings, all, >=20 > I've just posted a very short draft on hybrid measurement, more a = meta-requirements list and motivation than anything else, as a starting = point for discussion at the Atlanta meeting. >=20 > Best regards, >=20 > Brian >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Subject: New Version Notification for = draft-trammell-ippm-hybrid-ps-00.txt > > Date: October 12, 2012 10:31:22 AM GMT+02:00 > > To: trammell@tik.ee.ethz.ch > > > > > > A new version of I-D, draft-trammell-ippm-hybrid-ps-00.txt > > has been successfully submitted by Brian Trammell and posted to the > > IETF repository. > > > > Filename: draft-trammell-ippm-hybrid-ps > > Revision: 00 > > Title: Hybrid Measurement using IPPM Metrics > > Creation date: 2012-10-12 > > WG ID: Individual Submission > > Number of pages: 4 > > URL: = http://www.ietf.org/internet-drafts/draft-trammell-ippm-hybrid-ps-00.txt > > Status: = http://datatracker.ietf.org/doc/draft-trammell-ippm-hybrid-ps > > Htmlized: = http://tools.ietf.org/html/draft-trammell-ippm-hybrid-ps-00 > > > > > > Abstract: > > Hybrid measurement is the combination of metrics derived from = passive > > and active measurement to produce a measurement result. This > > document discusses use cases for hybrid measurement using metrics > > defined within the IPPM framework > > > > > > > > > > The IETF Secretariat >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >=20 From trammell@tik.ee.ethz.ch Mon Oct 15 03:16:37 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5288121F86BE for ; Mon, 15 Oct 2012 03:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.724 X-Spam-Level: X-Spam-Status: No, score=-6.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 rXvkZ5bIl1he for ; Mon, 15 Oct 2012 03:16:36 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2F221F86B6 for ; Mon, 15 Oct 2012 03:16:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C8C8FD9308; Mon, 15 Oct 2012 12:16:35 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6sQUXFyKayHS; Mon, 15 Oct 2012 12:16:35 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-121-161.antanet.ch [80.75.121.161]) (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 87F71D9307; Mon, 15 Oct 2012 12:16:35 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <7.0.1.0.0.20121013091948.04b1e628@att.com> Date: Mon, 15 Oct 2012 12:16:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2BD26307-1A04-46CC-9F09-749F15ECD0E6@tik.ee.ethz.ch> References: <20121012083122.13716.29945.idtracker@ietfa.amsl.com> <65974042-2522-4E12-8CFD-1236DF60CF74@tik.ee.ethz.ch> <7.0.1.0.0.20121013091948.04b1e628@att.com> To: Al Morton X-Mailer: Apple Mail (2.1283) Cc: ippm@ietf.org Subject: Re: [ippm] draft-trammell-ippm-hybrid-ps-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 10:16:37 -0000 Hi, Al, all, Thanks for your comments; comments inline... On Oct 13, 2012, at 3:43 PM, Al Morton wrote: > At 04:38 AM 10/12/2012, Brian Trammell wrote: >> I've just posted a very short draft on hybrid measurement, more a = meta-requirements list and motivation than anything else, as a starting = point for discussion at the Atlanta meeting. >=20 > Hi Brian, >=20 > I like the idea of specifying a framework for passive measurement > in the context of hybrid passive-active, because the comparisons > between the different techniques are quite useful. Your effort is > well-timed too, with both active and passive measurement requirements > appearing in the first draft of lmap requirements: > http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 > With this obvious synergy, I look forward to discussing this in > Atlanta. Yep... I specifically hope this work will prove useful in the context of = the LMAP effort, by granting more flexibility to combine measurements = from different sources. > I noted one point to consider as you develop the specification: >=20 >> The proposed specification entails: >>=20 >> ... >>=20 >> o Definition of methods for spatial and temporal composition of >> active and passive metrics together allowing for estimated >> uncertainty. >=20 > One of IPPM's earlier projects updated and expanded RFC 2330 section 9 > http://tools.ietf.org/html/rfc2330#section-9 > and defined three forms of metric composition and aggregation in RFC = 5835: > http://tools.ietf.org/html/rfc5835#section-5 >=20 > I think the definitions you seek above are what Steven and I called > spatial and temporal aggregation. Indeed; well, I think this covers half of it. In the baseline-comparison = case, temporal aggregation could be applied to the (passive) baseline in = order to improve the fidelity of the baseline while reducing storage = requirements. Then there's the comparison step I suppose you could also = model as "subtractive aggregation"; I still don't really have a firm = grasp on how these two operations work together. You're right, though, in that what I really mean with this point is = aggregation as defined in IPPM, not composition; will change in the next = rev.=20 > These are the two aspects that > we didn't complete for active measurements (IPPM has a spec for > spatial composition of active measurements, > http://tools.ietf.org/html/rfc6049 , where we mentioned passive > measurements at several appropriate points in a low-key overrun of > IPPM's active-only charter...). >=20 > Just pointing out the past work that might help the new effort! Many thanks; I'd remembered the spatial composition work (and, IIRC, = some initial work on temporal composition), but hadn't (re-) read yet to = see what applies where. Best regards, Brian From bixiaoyu@huawei.com Mon Oct 15 19:17:18 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6416F1F0C8F for ; Mon, 15 Oct 2012 19:17:18 -0700 (PDT) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hx5zidMq9Jww for ; Mon, 15 Oct 2012 19:17:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D1D781F0C8D for ; Mon, 15 Oct 2012 19:17:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKQ20010; Tue, 16 Oct 2012 02:17:14 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 16 Oct 2012 03:16:40 +0100 Received: from SZXEML447-HUB.china.huawei.com (10.82.67.185) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 16 Oct 2012 03:17:10 +0100 Received: from SZXEML547-MBS.china.huawei.com ([169.254.6.70]) by szxeml447-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.01.0323.003; Tue, 16 Oct 2012 10:17:05 +0800 From: Bixiaoyu To: "henk@DOMAIN.HIDDEN" Thread-Topic: Re: [ippm] Fwd: Draft Working Group agendas due by 2012-10-24 (Wednesday) Thread-Index: Ac2rRFI8LmMaUzR3R1u7QRubVDOoIA== Date: Tue, 16 Oct 2012 02:17:04 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.64.254] Content-Type: multipart/alternative; boundary="_000_E0E37EC5F4816A4A829BC9B437801B422C852B2Fszxeml547mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 16 Oct 2012 00:43:17 -0700 Cc: "ippm@ietf.org" Subject: Re: [ippm] Fwd: Draft Working Group agendas due by 2012-10-24 (Wednesday) 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, 16 Oct 2012 02:17:18 -0000 --_000_E0E37EC5F4816A4A829BC9B437801B422C852B2Fszxeml547mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Henk I'd like request 5-10 minutes for a new draft Network Performance Measureme= nt for IPsec (draft-bi-ippm-ipsec-00) which has been send already. Best Regards, Emily Bi --_000_E0E37EC5F4816A4A829BC9B437801B422C852B2Fszxeml547mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Henk

 

I’d like request 5-10 min= utes for a new draft Network Performance Measurement for IPsec (draft-bi-ip= pm-ipsec-00) which has been send already.

 

Best Regards,=

 

Emily Bi

--_000_E0E37EC5F4816A4A829BC9B437801B422C852B2Fszxeml547mbschi_-- From lishunsun@gmail.com Tue Oct 16 19:45:07 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42A221F877E for ; Tue, 16 Oct 2012 19:45:07 -0700 (PDT) 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 inP+V1hbFWK7 for ; Tue, 16 Oct 2012 19:45:07 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13EE821F8611 for ; Tue, 16 Oct 2012 19:45:07 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id g10so2009611ghb.31 for ; Tue, 16 Oct 2012 19:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MsyhDxaQRE4WM+QsmPcEE46W47f+S06ybOEXft2Ppvo=; b=EuiO6wkkGwX4NbvqsVJXjEO+fUruCUOdARmmJ1TC07XNZndg6Ig/K5B3MhnVEhnrbL NNB2Mo8pAyGJhsEpIhC9Nyi/+GF887oHNdQoQ4uCGjaQ+ACNAiz22u4qsdb5TeIXxBkg m25Y225IXzZdbpzeo3bWOzpGrigbE2fQIsSwIYm7MTB93o/AMwutiUNczdYTB1posWGX tj8tys63sSMXilL8Kinr8HhkBeRkm9yUmF3XhXE+o9/SEyapWOyt0+VuvN5XgX+nxIGA nUvVj5NRrQOd7oUI3gKQa9wIz52pN1nCpLICyYChkT4yRLua3k1bjljmJSMekfTnxI8r 3HPQ== MIME-Version: 1.0 Received: by 10.58.161.41 with SMTP id xp9mr4325646veb.56.1350441906511; Tue, 16 Oct 2012 19:45:06 -0700 (PDT) Received: by 10.52.27.100 with HTTP; Tue, 16 Oct 2012 19:45:06 -0700 (PDT) Date: Wed, 17 Oct 2012 10:45:06 +0800 Message-ID: From: McGrady Sun To: ippm@ietf.org Content-Type: multipart/alternative; boundary=047d7b6dc9aa209df404cc38427c Subject: [ippm] :draft-sun-ippm-flowbased-pm-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: Wed, 17 Oct 2012 02:48:39 -0000 --047d7b6dc9aa209df404cc38427c Content-Type: text/plain; charset=ISO-8859-1 Dear all, Last week we posted a new draft based on http://datatracker.ietf.org/doc/draft-sun-tsvwg-flowbased-pm/?include_text=1 . The following modifications were made. 1. A detailed description of the problem statement is contained, including both the motivation and scenarios of the proposed method. Also, a use case is attached. 2. Describes how the IPPM metrics are supported by the proposed flow-based performance measurement. 3. The description of the measurement procedure is also revised. We would like to thank Al Morton and Andreas Johnsson for their comments and suggestions on the original version. Best Regards, Lishun Sun ---------- Forwarded message ---------- From: Date: 2012/10/12 Subject: New Version Notification for draft-sun-ippm-flowbased-pm-00.txt To: lishunsun@gmail.com Cc: wdwang@bupt.edu.cn, grace.yufang@huawei.com A new version of I-D, draft-sun-ippm-flowbased-pm-00.txt has been successfully submitted by Lishun Sun and posted to the IETF repository. Filename: draft-sun-ippm-flowbased-pm Revision: 00 Title: Flow-based Performance Measurement Creation date: 2012-10-12 WG ID: Individual Submission Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-sun-ippm-flowbased-pm-00.txt Status: http://datatracker.ietf.org/doc/draft-sun-ippm-flowbased-pm Htmlized: http://tools.ietf.org/html/draft-sun-ippm-flowbased-pm-00 Abstract: The performance measurements of service flow are becoming significant important for administrators monitoring the fitness of the network. This memo defines an end-to-end flow-based performance measurement method, which is achieved by generating synthetic measurement packets, injecting them to the network and analyzing the statistics carried in the measurement packets.This measurement method can measure flow characteristics such as delay, ipdv (IP Packet Delay Variation) and packet loss. The IETF Secretariat --047d7b6dc9aa209df404cc38427c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear all,

=A0=A0=A0= Last week we posted a new draft=A0based on=A0http://datatra= cker.ietf.org/doc/draft-sun-tsvwg-flowbased-pm/?include_text=3D1.=A0The following modifications were made.

=A0=A0=A0= 1. A detailed description of the problem statement is contained, including= both the motivation and scenarios of the proposed method. Also, a use case= is attached.

=A0=A0=A0= 2. Describes how the IPPM metrics are supported by the proposed flow-based= performance measurement.

=A0=A0=A0 3. The description of the measurement = procedure is also revised.=A0

=A0=A0=A0= We would like to thank Al Morton and Andreas Johnsson for their comments a= nd suggestions on the original version.


Best Regards,

Lishun Sun


--------= -- Forwarded message ----------
From: <internet-drafts@ietf.org>
= Date: 2012/10/12
Subject: New Version Notification for draft-sun-ippm-fl= owbased-pm-00.txt
To: lishunsun@gmail.com
Cc: <= a href=3D"mailto:wdwang@bupt.edu.cn">wdwang@bupt.edu.cn, grace.yufang@huawei.com



A new version of I-D, draft-sun-ippm-flowbased-pm-00.txt
has been successfully submitted by Lishun Sun and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sun-ippm-flowbased-pm
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Flow-based Performance Measurement
Creation date: =A0 2012-10-12
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 21
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/= internet-drafts/draft-sun-ippm-flowbased-pm-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/d= raft-sun-ippm-flowbased-pm
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-sun-= ippm-flowbased-pm-00


Abstract:
=A0 =A0The performance measurements of service flow are becoming significan= t
=A0 =A0important for administrators monitoring the fitness of the network.<= br> =A0 =A0This memo defines an end-to-end flow-based performance measurement =A0 =A0method, which is achieved by generating synthetic measurement
=A0 =A0packets, injecting them to the network and analyzing the statistics<= br> =A0 =A0carried in the measurement packets.This measurement method can
=A0 =A0measure flow characteristics such as delay, ipdv (IP Packet Delay =A0 =A0Variation) and packet loss.




The IETF Secretariat


--047d7b6dc9aa209df404cc38427c-- From acmorton@att.com Sun Oct 21 10:40:56 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B034621F889B for ; Sun, 21 Oct 2012 10:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.225 X-Spam-Level: X-Spam-Status: No, score=-105.225 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ythsJHwfAMiI for ; Sun, 21 Oct 2012 10:40:56 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id B209821F8BEC for ; Sun, 21 Oct 2012 10:40:55 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 7a334805.0.58034.00-463.155754.nbfkord-smmo05.seg.att.com (envelope-from ); Sun, 21 Oct 2012 17:40:55 +0000 (UTC) X-MXL-Hash: 508433a7542f8ce9-ad2eae26a579cd832cab36fae0b31fda96b0b441 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9LHesZu010738 for ; Sun, 21 Oct 2012 10:40:54 -0700 Received: from fflint02.pst.cso.att.com (fflint02.pst.cso.att.com [150.234.39.62]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9LHekZl010543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 21 Oct 2012 10:40:51 -0700 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint02.pst.cso.att.com (RSA Interceptor) for ; Sun, 21 Oct 2012 10:40:31 -0700 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9LHdMLC023290 for ; Sun, 21 Oct 2012 13:39:22 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q9LHdHdX023201 for ; Sun, 21 Oct 2012 13:39:19 -0400 Received: from lt-hp1044652.att.com (vpn-135-70-245-245.vpn.east.att.com[135.70.245.245](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121021173806gw100r2c9ee>; Sun, 21 Oct 2012 17:38:11 +0000 X-Originating-IP: [135.70.245.245] Message-Id: <7.0.1.0.0.20121021133400.04d02c48@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 21 Oct 2012 13:38:18 -0400 To: ippm@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=JO6MRb2b c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=q8pr4KV0rikA:10 a=vB2bY3ZYAhEA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=2WiePQzr] X-AnalysisOut: [Eu8A:10 a=48vgC7mUAAAA:8 a=CO0uU8qm741it1JjjWEA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=_W_S_7VecoQA:10 a=jM_x9b4JT8QA:10 a=lZB815dzVv] X-AnalysisOut: [QA:10 a=4QXCWFOmMqTknyL4:21] Cc: Matthew J Zekauskas Subject: [ippm] Fwd: I-D Action: draft-morton-ippm-2679-bis-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: Sun, 21 Oct 2012 17:40:56 -0000 IPPM,

Following-up on the consensus reflected in
http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2679-03

we have the RFC 2679 bis text now available.

regards,
Al


A New Internet-Draft is available from the on-line Internet-Drafts directories.


         Title           : A One-Way Delay Metric for IPPM
         Author(s)       : Guy Almes
                          Sunil Kalidindi
                          Matt Zekauskas
                          Al Morton (ed.)
         Filename        : draft-morton-ippm-2679-bis-01.txt
         Pages           : 24
         Date            : 2012-10-21

Abstract:
   This memo (RFC 2679 bis) defines a metric for one-way delay 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.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-morton-ippm-2679-bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-morton-ippm-2679-bis-01

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


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
From Ruediger.Geib@telekom.de Mon Oct 22 03:38:43 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829D221F8906 for ; Mon, 22 Oct 2012 03:38:43 -0700 (PDT) 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=[AWL=-0.000, 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 iUTv+g+Z3UTV for ; Mon, 22 Oct 2012 03:38:42 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 73CD321F887B for ; Mon, 22 Oct 2012 03:38:41 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 22 Oct 2012 12:38:39 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 22 Oct 2012 12:38:39 +0200 From: To: , , Date: Mon, 22 Oct 2012 12:38:37 +0200 Thread-Topic: [ippm] Advanced Stream and Sampling Framework for IPPM Thread-Index: Ac2of8gn5w25opFkSy2xpEC4tGLWmQHwCb3w Message-ID: References: <5072F59A.50507@tuwien.ac.at> <5077BAD0.7080908@tuwien.ac.at> <7.0.1.0.0.20121012085911.04d2dc58@att.com> In-Reply-To: <7.0.1.0.0.20121012085911.04d2dc58@att.com> 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_CA7A7C64CC4ADB458B74477EA99DF6F59DABD617HE111643EMEA1CD_" MIME-Version: 1.0 Cc: ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 10:38:43 -0000 --_000_CA7A7C64CC4ADB458B74477EA99DF6F59DABD617HE111643EMEA1CD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Al, Joachim and Matt, it just came to my mind, whether we need to narrow down "reactive network b= ehaviour" or whether it stays undefined. reactive could a network behave: - based on the history of and current local load conditions - on user behaviour # in terms of load in general # in terms of visited online content # in terms of payload contents To be more precise, active bandwidth throtteling or flow suppression may be= regarded as "reactive network behaviour" too. Regards, R=FCdiger ________________________________ From: Al Morton [mailto:acmorton@att.com] Sent: Friday, October 12, 2012 3:43 PM To: Joachim Fabini; Matt Mathis; Geib, R=FCdiger Cc: ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM R=FCdiger and Matt, Thanks for your review and comments so far. I'll just add two points below (one to help define "actionable" in the way that I think of it). regards, Al At 02:38 AM 10/12/2012, Joachim Fabini wrote: On 12.10.2012 04:35, Matt Mathis wrote: I think this is a really good start. Thank you. +1, we've had this in-progress for months, great to get feedback now. ... One other item for 2330: in the list of metric criteria, we failed to include "actionable" - some of the existing metrics don't provide any guidance for somebody who is unhappy with the results. Although "actionable" might be considered to be a sub item of "meaningful", some existing metrics don't do so well, even though they have well defined meanings. RFC 2330 defines extensibility, which (combined with repeatability) imo fit= s pretty much what you describe as "actionable". The solution which we are = currently preferring is to find/define a set of metrics which can assess a)= repeatability and b) extensibility of a measurement methodology. E.g., usi= ng measurement samples of one or two subsequent measurement scenarios (metr= ic & methodology) as input, these metrics should provide hints if 1) there = is a likelihood of repeatability and 2) we can extend measurement results t= o other scenarios/parameters - in the sense of metric linearity for a speci= fic methodology. Perhaps even more important and easier to realize is a metric output that p= roperties 1) and 2) are NOT fulfilled. We (network operators) always have "actionable" as a goal, meaning that the measurement results combined with some interpretation should lead the design or maintenance forces to their next steps (to improve performance or repair a problem). We move a long way toward the goal by selecting the right metrics from the start. All of our/user packet streams are influenced by a growing number of reactive network components, maintaining and changing state. It's matter-of-fact for most user flows. In reactive nets we can use discovery, characterization, and with on-going measurements, expectation, to help determine if there is a fault or other undesirable condition and what network elements may be involved. If the measurements really help to narrow-down the problem space, they are considered "actionable". So, I agree this is a useful consideration to add-in/update RFC 2330. As Joachim mentioned, this expansion of the stream framework is intended to address various forms of reactive networks, and certainly includes wired networks today. The concept of pre-load (as Matt called it) is important to any test path that includes a firewall. This aspect is an important consideration in the LMAP requirements: http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 and probably also the project described in IEEE 802.16 Liaison: https://datatracker.ietf.org/liaison/1195/ There is almost certainly some overlap between our draft and the intent of latter project. --_000_CA7A7C64CC4ADB458B74477EA99DF6F59DABD617HE111643EMEA1CD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Al, Joachim and Matt,
 
it just came to my mind, whether we need to narr= ow down=20 "reactive network behaviour" or whether
it stays undefined.
 
reactive could a network behave:
- based on the history of and current = local=20 load conditions
- on user behaviour
  # in terms of load in=20 general
  # in terms of visited online=20 content
  # in terms of payload=20 contents
 
To be more precise, active bandwidth throtteling= or=20 flow suppression may be regarded as "reactive
network behaviour" too.
 
Regards,
 
R=FCdiger

From: Al Morton [mailto:acmorton@att.co= m]=20
Sent: Friday, October 12, 2012 3:43 PM
To: Joachim Fab= ini;=20 Matt Mathis; Geib, R=FCdiger
Cc: ippm@ietf.org
Subject:= Re:=20 [ippm] Advanced Stream and Sampling Framework for IPPM

R=FCdiger and Matt,

Thanks for your review and comments s= o=20 far.
I'll just add two points below (one to help define
"actionable"= in=20 the way that I think of it).

regards,
Al

At 02:38 AM=20 10/12/2012, Joachim Fabini wrote:
On 12.10.2012 04:35, Matt = Mathis=20 wrote:
I think this is a really= good=20 start.

Thank you.
+1, we've had this in-pro= gress for=20 months, great to get feedback now.

...
One other item for 2330:= in the=20 list of metric criteria, we failed to
include "actionable" - some of= the=20 existing metrics don't provide any
guidance for somebody who is unha= ppy=20 with the results.   Although
"actionable" might be conside= red=20 to be a sub item of "meaningful",
some existing metrics don't do so = well,=20 even though they have well
defined meanings.

RFC 233= 0=20 defines extensibility, which (combined with repeatability) imo fits prett= y=20 much what you describe as "actionable". The solution which we are current= ly=20 preferring is to find/define a set of metrics which can assess a)=20 repeatability and b) extensibility of a measurement methodology. E.g., us= ing=20 measurement samples of one or two subsequent measurement scenarios (metri= c=20 & methodology) as input, these metrics should provide hints if 1) the= re is=20 a likelihood of repeatability and 2) we can extend measurement results to= =20 other scenarios/parameters - in the sense of metric linearity for a speci= fic=20 methodology.
Perhaps even more important and easier to realize is a me= tric=20 output that properties 1) and 2) are NOT fulfilled.

W= e=20 (network operators) always have "actionable" as a goal,
meaning that the= =20 measurement results combined with some interpretation
should lead the de= sign=20 or maintenance forces to their next steps
(to improve performance or rep= air a=20 problem). We move a long
way toward the goal by selecting the right metr= ics=20 from the start.

All of our/user packet streams are influenced by a=20 growing number of
reactive network components, maintaining and changing= =20 state.
It's matter-of-fact for most user flows.  In reactive nets w= e can=20 use
discovery, characterization, and with on-going measurements,=20 expectation,
to help determine if there is a fault or other undesirable= =20 condition
and what network elements may be involved. If the measurements= =20 really
help to narrow-down the problem space, they are considered=20 "actionable".

So, I agree this is a useful consideration to add-in/u= pdate=20 RFC 2330.

As Joachim mentioned, this expansion of the stream framewo= rk=20 is
intended to address various forms of reactive networks, and=20 certainly
includes wired networks today. The concept of pre-load (as Mat= t=20 called it)
is important to any test path that includes a firewall.=20 This
aspect is an important consideration in the LMAP requirements:
<= A=20 href=3D"http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00">= http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00
an= d=20 probably also  the project described in IEEE 802.16 Liaison:
https://datatracker.ietf.org/liaison/1195/
There= is=20 almost certainly some overlap between our draft and
the intent of latte= r=20 project.
--_000_CA7A7C64CC4ADB458B74477EA99DF6F59DABD617HE111643EMEA1CD_-- From a.botta@unina.it Mon Oct 22 04:11:09 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F85B21F8B72 for ; Mon, 22 Oct 2012 04:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.33 X-Spam-Level: **** X-Spam-Status: No, score=4.33 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_AFFORDABLE=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MSGID_MULTIPLE_AT=1.449] 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 HXtHjuAQf6fA for ; Mon, 22 Oct 2012 04:11:08 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4CF21F8B7C for ; Mon, 22 Oct 2012 04:11:07 -0700 (PDT) Received: from Ilva ([143.225.229.192]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id q9MBB3i4007369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 22 Oct 2012 13:11:04 +0200 From: "Alessio Botta" To: References: <4FFA94E0.7050504@unina.it> In-Reply-To: Date: Mon, 22 Oct 2012 13:10:36 +0200 Message-ID: <04fb01cdb045$dce83590$96b8a0b0$@botta@unina.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1drArECwSlSTc+RfyokykRJFQA2hQO/D+AAJcIbSAAAC4cgA== Content-Language: it Subject: [ippm] 1st IEEE Workshop on Traffic Identification and Classification for Advanced Network Services and Scenarios (TRICANS): CFP X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:11:09 -0000 [Our apologies if you receive multiple copies of this CFP] ------------------------------------------------------------- 1st IEEE Workshop on Traffic Identification and Classification for = Advanced Network Services and Scenarios (TRICANS): CALL FOR PAPER - First announcement ------------------------------------------------------------- 1st IEEE Workshop on Traffic Identification and Classification for = Advanced Network Services and Scenarios (TRICANS) http://www.grid.unina.it/TRICANS2013 * Workshop Description * TRICANS workshop will provide an excellent international forum for = sharing state-of-the-art advances and experiences in scientific research on = Internet traffic identification and classification and their associated = applications on advanced network scenarios and novel network services. TRICANS will explicitly consider traffic identification and classification as well as management issues related to very hot and challenging scenarios such as content-centric networks (CCN), Software Defined Networks (SDN), cloud computing systems and data centers, virtual networks, and the like. The ever-growing network link speeds have reached hundreds of Gbps and they = are quickly approaching to Tbps in the core network. In order to support accurate network profiling of users and services, ISPs have been relying = on Deep Packet Inspection (DPI), flow-based techniques, or other behavioral analysis of the Internet traffic. However, there are still a number of challenges in this field. On one hand, new networked applications come = daily into play bringing massive amounts of traffic data to be processed in real-time. Such traffic volume keeps pushing industry and academia researchers to develop affordable yet efficient traffic identification = and classification systems. To this end, there are demands for = high-performance distributed and parallel traffic classification systems for both = commodity or special-purposed hardware platforms. On the other hand, in the = long-term, such solutions for traffic profiling will become part of the network management tools and techniques portfolio available for advanced network services. Also, new architectures and their supporting technologies, = such as information- and content -centric networking architectures, cloud = computing and network virtualization, and the like, will require network profiling services to enable robust and dynamic networking services capabilities. = To address these research challenges, this workshop will focus on theory, tools, techniques, and applications of traffic identification and classification systems to enable advanced support for next-generation network architectures, services, and scenarios. The topics covered by the workshop include, but are not limited to, the following: - Measurement and modeling of Internet traffic for advanced networked services - Network and system troubleshooting through DPI technologies - Lightweight technologies for DPI in routers and middle-boxes - Network profiling of users and networked applications - Security and privacy in traffic identification and classification mechanisms - DPI technologies support for virtual networks and cloud computing management - Profiling network traffic in data center networks and cloud computing systems - Inferring and assessing Quality of Experience (QoE) of users and = services - Novel visualization techniques for traffic classification and analysis - Packet processing support in operating systems for novel line-rate = network services - Management of large network traffic data sets - SDN approaches for network performance monitoring - Traffic classification in SDN network elements and controllers - Traffic Classification and Identification of Cloud services - Traffic Classification and Identification for Internet Security - Classification and Identification of Botnet * Submission Guidelines * Prospective authors are encouraged to submit a full paper (5 pages) for review. Only original papers that have not been published or submitted for publication elsewhere will be considered. These submissions should = follow the IEEE ICC 2013 formatting guidelines, templates for which are = available at the main conference web page. The maximum paper length is of five (5) pages.=20 Submission website: https://edas.info/N13453?c=3D13453 * Important Dates * - 4th of January 2013, registration of abstracts - 11th of January 2013, paper submission deadline - 22th of February 2013, notification deadline - 8th of March, camera ready - Workshop date: Week of ICC, 2013 * Workshop General Chairs * - Stenio Fernandes, Federal University of Pernambuco, Recife, Brazil - Antonio Pescap=E9, University of Napoli ''Federico II'', Napoli, Italy - G=E9za Szab=F3, Ericsson Traffic Laboratory, Budapest, Hungary -- Alessio Botta, PhD Dipartimento di Informatica e Sistemistica Universit=E0 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 henk@uijterwaal.nl Mon Oct 22 04:16:31 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE721F876B for ; Mon, 22 Oct 2012 04:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 uyp3IFWLJ73t for ; Mon, 22 Oct 2012 04:16:28 -0700 (PDT) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1459021F851B for ; Mon, 22 Oct 2012 04:16:27 -0700 (PDT) Received: from geir.local (hlms-net-99-034.holmes.nl [195.169.99.34]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9MBFoJF090469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Oct 2012 13:15:56 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <50852AE4.2060907@uijterwaal.nl> Date: Mon, 22 Oct 2012 13:15:48 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: IETF IPPM WG X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [ippm] Draft agenda for IETF85 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:16:31 -0000 IPPM Group, Please see below, comments welcome before Wednesdag morning (UTC). Henk - - - - Draft Agenda for IPPM @ IETF 85. ================================ 0. Administrativia (10') 1. Advanced Stream and Sampling Framework. (10') Al Morton, Joachim Fabini draft-morton-ippm-2330-update-00.txt 2. Passive and Hybrid Measurements using IPPM Metrics (15') Brian Trammell draft-trammell-ippm-hybrid-ps-00.txt 3. Model Based Internet Performance Metrics (10') Matt Mathis draft-mathis-ippm-model-based-metrics-00.txt 4. Curating Internet Measurement Data (10') Matt Mathis draft-mathis-ippm-data-curation-00.txt 5. Network Performance Measurements for IPsec (10') Emily Bi draft-bi-ippm-ipsec-00.txt 6. Flow-based Performance Measurement (10') Yu Fang draft-sun-ippm-flowbased-pm-00.txt 7. RESERVED (10') 8. AOB Speakers: please submit slides before the meeting. Note that the timeslot includes time for discussion afterwards, that is, if you have 10 minutes, prepare to speak for about 7 and leave 3 for questions and answers. -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ Read my blog at http://www.uijterwaal.nl/henks_hands.html From mattmathis@google.com Mon Oct 22 09:08:05 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44F421F89D4 for ; Mon, 22 Oct 2012 09:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E17ID-+Rw+Db for ; Mon, 22 Oct 2012 09:08:04 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 59C7A21F8417 for ; Mon, 22 Oct 2012 09:08:04 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id fm10so1639733wgb.1 for ; Mon, 22 Oct 2012 09:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=P1jWshvNHPRMNX583vkYla43lWff/yXWMZW8HiY98zY=; b=Ig6wt+pzNeNYjizZkDE876cSRp5F7LEnjfeeomZ7FGY7RI2jwSwz+9ZFX2ATXdUI6G 1iApw2TNrzRDD1qQDVdlzMG0gh/1rspZw+ggko6vPXDtIijeQ1JC5mPKXEvyhj83k2Gt slNFdF8mh7bml7uCqDjehQdkYkjY4vckioD6ErPqDsvl1OyIe/Rh9zJ/XNI35HQF0b2C S5L9IE2dnApkyyvKKVw0clCR5+E27dE1R6PQ+HWHz48ypDzX/mF5Wxt+4mPBRjv3CTqq AIPrQGBTzIA7EoTgB0oxrNLO2QzbulqyTpglAF67uDmoaXX096ewDZDnDnWAsVF8kDIV H0vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=P1jWshvNHPRMNX583vkYla43lWff/yXWMZW8HiY98zY=; b=Gz+3GBg8k+2pb7Zsr8XF0KYB6++2+K3stoqyfCy0qEnoPWJl6G0zD8AzvOKtx4DeuH EqULGSM9GOm8aJsyG4XN72UF68UQiX1eXZXHzNn6voQTYhIWNWNKrILuA81ceqlDY5xb FMumt4/m88RmPpJa5wm/+8VvDwAtmszCRtsN7ERxRYt4ilrdKVu4XnO+Dez3fPLgRHLQ gjlpgTK9bIDCAuwdH09NMoV5d6Xk+HsDEQMhryG36vivGZ0vQvc+zQy+inZj3bMs9VfZ T+avlT+ZsmSgXay9k3pNZEeiGHgk9ANhBmVMHoZhySmoiO75ZzJygUgE3A3722eKw74u 90eQ== MIME-Version: 1.0 Received: by 10.180.85.99 with SMTP id g3mr22351531wiz.5.1350922082072; Mon, 22 Oct 2012 09:08:02 -0700 (PDT) Received: by 10.194.37.97 with HTTP; Mon, 22 Oct 2012 09:08:01 -0700 (PDT) In-Reply-To: References: <5072F59A.50507@tuwien.ac.at> <5077BAD0.7080908@tuwien.ac.at> <7.0.1.0.0.20121012085911.04d2dc58@att.com> Date: Mon, 22 Oct 2012 09:08:01 -0700 Message-ID: From: Matt Mathis To: Ruediger.Geib@telekom.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmBwkuXRXvLgbqelfAS6NV9PCfe2nLWNEIF/FzW2ukasw3GtP7itp5l9+hish/PLZ8zRnwPjnsBc8+B1FM8w3Sw4XO/gVsrmRzjdMN9O3vRo9LmoK1VU75nlGvGndjTj6wZChMdF8RwknYnt9C5MzBIT+JYDLXKzgPdnazn0SR+8oeQY0Ax86H0nn/8F4/JmmDm4n7f Cc: acmorton@att.com, ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:08:05 -0000 Good question. I hadn't considered poor performance as a possible penalty for "bad surfing behavior", but it certainly is. I think we can keep the longer timescale issues in mind, but the real point is to improve measurement repeatability at shorter timescales e.g. session history. A slightly different question is over what timescale do things shift? If I transition from idle to heavy use, how long does it take to transition into a "power user" policy bin? (Put another way, what is the averaging timescale?) Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, Oct 22, 2012 at 3:38 AM, wrote: > Al, Joachim and Matt, > > it just came to my mind, whether we need to narrow down "reactive network > behaviour" or whether > it stays undefined. > > reactive could a network behave: > - based on the history of and current local load conditions > - on user behaviour > # in terms of load in general > # in terms of visited online content > # in terms of payload contents > > To be more precise, active bandwidth throtteling or flow suppression may = be > regarded as "reactive > network behaviour" too. > > Regards, > > R=FCdiger > > ________________________________ > From: Al Morton [mailto:acmorton@att.com] > Sent: Friday, October 12, 2012 3:43 PM > To: Joachim Fabini; Matt Mathis; Geib, R=FCdiger > > Cc: ippm@ietf.org > Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM > > R=FCdiger and Matt, > > Thanks for your review and comments so far. > I'll just add two points below (one to help define > "actionable" in the way that I think of it). > > regards, > Al > > At 02:38 AM 10/12/2012, Joachim Fabini wrote: > > On 12.10.2012 04:35, Matt Mathis wrote: > > I think this is a really good start. > > > Thank you. > > +1, we've had this in-progress for months, great to get feedback now. > > ... > > One other item for 2330: in the list of metric criteria, we failed to > include "actionable" - some of the existing metrics don't provide any > guidance for somebody who is unhappy with the results. Although > "actionable" might be considered to be a sub item of "meaningful", > some existing metrics don't do so well, even though they have well > defined meanings. > > > RFC 2330 defines extensibility, which (combined with repeatability) imo f= its > pretty much what you describe as "actionable". The solution which we are > currently preferring is to find/define a set of metrics which can assess = a) > repeatability and b) extensibility of a measurement methodology. E.g., us= ing > measurement samples of one or two subsequent measurement scenarios (metri= c & > methodology) as input, these metrics should provide hints if 1) there is = a > likelihood of repeatability and 2) we can extend measurement results to > other scenarios/parameters - in the sense of metric linearity for a speci= fic > methodology. > Perhaps even more important and easier to realize is a metric output that > properties 1) and 2) are NOT fulfilled. > > > We (network operators) always have "actionable" as a goal, > meaning that the measurement results combined with some interpretation > should lead the design or maintenance forces to their next steps > (to improve performance or repair a problem). We move a long > way toward the goal by selecting the right metrics from the start. > > All of our/user packet streams are influenced by a growing number of > reactive network components, maintaining and changing state. > It's matter-of-fact for most user flows. In reactive nets we can use > discovery, characterization, and with on-going measurements, expectation, > to help determine if there is a fault or other undesirable condition > and what network elements may be involved. If the measurements really > help to narrow-down the problem space, they are considered "actionable". > > So, I agree this is a useful consideration to add-in/update RFC 2330. > > As Joachim mentioned, this expansion of the stream framework is > intended to address various forms of reactive networks, and certainly > includes wired networks today. The concept of pre-load (as Matt called it= ) > is important to any test path that includes a firewall. This > aspect is an important consideration in the LMAP requirements: > http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 > and probably also the project described in IEEE 802.16 Liaison: > https://datatracker.ietf.org/liaison/1195/ > There is almost certainly some overlap between our draft and > the intent of latter project. From Joachim.Fabini@tuwien.ac.at Mon Oct 22 14:02:57 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D9F1F0C5C for ; Mon, 22 Oct 2012 14:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.28 X-Spam-Level: X-Spam-Status: No, score=-4.28 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MANGLED_DEALS=2.3, 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 CoC7S+89S5u7 for ; Mon, 22 Oct 2012 14:02:56 -0700 (PDT) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id 129981F041C for ; Mon, 22 Oct 2012 14:02:55 -0700 (PDT) Received: from [128.131.88.241] (priamos.ibk.tuwien.ac.at [128.131.88.241]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id q9ML2nTu017976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 23:02:49 +0200 Message-ID: <5085B474.7030705@tuwien.ac.at> Date: Mon, 22 Oct 2012 23:02:44 +0200 From: Joachim Fabini User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <5072F59A.50507@tuwien.ac.at> <5077BAD0.7080908@tuwien.ac.at> <7.0.1.0.0.20121012085911.04d2dc58@att.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ippm@ietf.org, acmorton@att.com, mattmathis@google.com Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 21:02:57 -0000 Rüdiger, thank you, very good point. Straight ahead I'd prefer to include an exact definition of what we mean by "reactive network behavior" to delimit the document's scope - unless this turns out to be a huge limiting factor (with respect to framework generality or applicability) in the long run. However I fully agree with you that it is challenging to draw a clear line between reactive and "normal" behavior. And perhaps we can isolate other properties which make networks behave different from wires with respect to measurements? Common examples for reactive network behavior include on-demand capacity allocation or flow capacity which depends on some layer 2 or 1 flow state (history). A delicate topic in this context is (content-specific?) traffic shaping which might lead to reactive behavior in some cases. However, radio channel modifications or content compression in a wireless network segment might also generate effects which are reactive by nature. Trying to not lose focus (and still doing so), "reactive behavior" is imho very tightly coupled to measurement repeatability - which, as you have pointed out, in its philosophical dimension is difficult to handle for real measurements. My opinion is that today's networks (systems) are too complex to guarantee repeatability. So perhaps it is worth to consider replacing this purely theoretical concept of RFC2330-repeatability by a weakened term, e.g., "p-repeatability", which is conditioned by a set of internal and external parameters (load, history, etc.). In this context RFC2330's Packet-Type-P would be replaced by a Stream-Type-P configuring specific stream constraints (referencing a set of Packet-Type-P's with their temporal ordering) or a Measurement-Type-P, adding some explicit measurement parameter settings to stream definitions. Becoming philosophical, too, we could use systems theory (networks are complex systems) to differentiate between system-internal and system-external measurement parameters (and system/flow state) and integrate the relevant ones into the Type-P-stream definition. The huge benefit of such a solution is to make explicit the amount of uncertainty which is associated with a measurement sample set. What I perceive as highly useful in practice is a set of explicit parameters (internal stream constraints, methodologies, external parameters), which can help measurement engineers to obtain repeatable measurements (or, at least, a high likelihood of repeatability) for specific metrics and link types. The new framework could support this, e.g., by also defining metrics and methodologies to test two sample sets on repeatability for specific measurement parameters. Going even further, we could try to develop meta-metrics to test sample sets on other properties like extensibility. So I fully agree with you that the term "reactive behavior" must be clarified. But my feeling is that one main target we should aim at is to act on "repeatability" as of RFC 2330. Perhaps we can collect a useful list of network link properties (like "reactive") and propose metrics and methodologies to test sample sets on these properties? Any feedback is warmly welcome! Thanks again, regards Joachim Am 22.10.2012 12:38, schrieb Ruediger.Geib@telekom.de: > Al, Joachim and Matt, > it just came to my mind, whether we need to narrow down "reactive > network behaviour" or whether > it stays undefined. > reactive could a network behave: > - based on the history of and current local load conditions > - on user behaviour > # in terms of load in general > # in terms of visited online content > # in terms of payload contents > To be more precise, active bandwidth throtteling or flow suppression may > be regarded as "reactive > network behaviour" too. > Regards, > Rüdiger > > ------------------------------------------------------------------------ > *From:* Al Morton [mailto:acmorton@att.com] > *Sent:* Friday, October 12, 2012 3:43 PM > *To:* Joachim Fabini; Matt Mathis; Geib, Rüdiger > *Cc:* ippm@ietf.org > *Subject:* Re: [ippm] Advanced Stream and Sampling Framework for IPPM > > Rüdiger and Matt, > > Thanks for your review and comments so far. > I'll just add two points below (one to help define > "actionable" in the way that I think of it). > > regards, > Al > > At 02:38 AM 10/12/2012, Joachim Fabini wrote: >> On 12.10.2012 04:35, Matt Mathis wrote: >>> I think this is a really good start. >> >> Thank you. > +1, we've had this in-progress for months, great to get feedback now. > >> ... >>> One other item for 2330: in the list of metric criteria, we failed to >>> include "actionable" - some of the existing metrics don't provide any >>> guidance for somebody who is unhappy with the results. Although >>> "actionable" might be considered to be a sub item of "meaningful", >>> some existing metrics don't do so well, even though they have well >>> defined meanings. >> >> RFC 2330 defines extensibility, which (combined with repeatability) >> imo fits pretty much what you describe as "actionable". The solution >> which we are currently preferring is to find/define a set of metrics >> which can assess a) repeatability and b) extensibility of a >> measurement methodology. E.g., using measurement samples of one or two >> subsequent measurement scenarios (metric & methodology) as input, >> these metrics should provide hints if 1) there is a likelihood of >> repeatability and 2) we can extend measurement results to other >> scenarios/parameters - in the sense of metric linearity for a specific >> methodology. >> Perhaps even more important and easier to realize is a metric output >> that properties 1) and 2) are NOT fulfilled. > > We (network operators) always have "actionable" as a goal, > meaning that the measurement results combined with some interpretation > should lead the design or maintenance forces to their next steps > (to improve performance or repair a problem). We move a long > way toward the goal by selecting the right metrics from the start. > > All of our/user packet streams are influenced by a growing number of > reactive network components, maintaining and changing state. > It's matter-of-fact for most user flows. In reactive nets we can use > discovery, characterization, and with on-going measurements, expectation, > to help determine if there is a fault or other undesirable condition > and what network elements may be involved. If the measurements really > help to narrow-down the problem space, they are considered "actionable". > > So, I agree this is a useful consideration to add-in/update RFC 2330. > > As Joachim mentioned, this expansion of the stream framework is > intended to address various forms of reactive networks, and certainly > includes wired networks today. The concept of pre-load (as Matt called it) > is important to any test path that includes a firewall. This > aspect is an important consideration in the LMAP requirements: > http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 > and probably also the project described in IEEE 802.16 Liaison: > https://datatracker.ietf.org/liaison/1195/ > There is almost certainly some overlap between our draft and > the intent of latter project. From Joachim.Fabini@tuwien.ac.at Mon Oct 22 14:42:51 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0D21F041C for ; Mon, 22 Oct 2012 14:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 TR2aF+22YjPq for ; Mon, 22 Oct 2012 14:42:51 -0700 (PDT) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id 900541F0C49 for ; Mon, 22 Oct 2012 14:42:50 -0700 (PDT) Received: from [128.131.88.241] (priamos.ibk.tuwien.ac.at [128.131.88.241]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id q9MLgkWc023184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 23:42:46 +0200 Message-ID: <5085BDD1.2040705@tuwien.ac.at> Date: Mon, 22 Oct 2012 23:42:41 +0200 From: Joachim Fabini User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Matt Mathis References: <5072F59A.50507@tuwien.ac.at> <5077BAD0.7080908@tuwien.ac.at> <7.0.1.0.0.20121012085911.04d2dc58@att.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: acmorton@att.com, ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 21:42:52 -0000 Matt, if I get you right, this relates somehow to the point-of-view topic (RFC 6703). Developing this scenario: consider a VoIP media connection over mobile networks. When measuring high end-to-end delay, VoIP clients might infer on network overload and re-negotiate their codec to reduce bandwidth. In networks with on-demand capacity allocation this is the worst decision, as it likely reduces allocated capacity and increases delay (and voice quality) even more. Again, it's the question of user view and perception vs. system view, optimization and configuration. Concerning your specific question about transition duration: in some evaluated HSPA networks, depending on the specific state and precondition, it takes some hundreds of miliseconds (it's basically a matter of one or several round-trips). As an example, we have done some measurements with respect to VoIP SIP signaling: using 5-10 seconds inter-arrival times, effective HSPA round-trip delay (400-800 bytes payload) increases from an optimum of 40-50ms (at much higher data rate) to 800ms and stays there. thanks, regards Joachim Am 22.10.2012 18:08, schrieb Matt Mathis: > Good question. I hadn't considered poor performance as a possible > penalty for "bad surfing behavior", but it certainly is. I think we > can keep the longer timescale issues in mind, but the real point is to > improve measurement repeatability at shorter timescales e.g. session > history. > > A slightly different question is over what timescale do things shift? > If I transition from idle to heavy use, how long does it take to > transition into a "power user" policy bin? (Put another way, what is > the averaging timescale?) > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat > privacy and security as matters of life and death, because for some > users, they are. > > > On Mon, Oct 22, 2012 at 3:38 AM, wrote: >> Al, Joachim and Matt, >> >> it just came to my mind, whether we need to narrow down "reactive network >> behaviour" or whether >> it stays undefined. >> >> reactive could a network behave: >> - based on the history of and current local load conditions >> - on user behaviour >> # in terms of load in general >> # in terms of visited online content >> # in terms of payload contents >> >> To be more precise, active bandwidth throtteling or flow suppression may be >> regarded as "reactive >> network behaviour" too. >> >> Regards, >> >> Rüdiger >> >> ________________________________ >> From: Al Morton [mailto:acmorton@att.com] >> Sent: Friday, October 12, 2012 3:43 PM >> To: Joachim Fabini; Matt Mathis; Geib, Rüdiger >> >> Cc: ippm@ietf.org >> Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM >> >> Rüdiger and Matt, >> >> Thanks for your review and comments so far. >> I'll just add two points below (one to help define >> "actionable" in the way that I think of it). >> >> regards, >> Al >> >> At 02:38 AM 10/12/2012, Joachim Fabini wrote: >> >> On 12.10.2012 04:35, Matt Mathis wrote: >> >> I think this is a really good start. >> >> >> Thank you. >> >> +1, we've had this in-progress for months, great to get feedback now. >> >> ... >> >> One other item for 2330: in the list of metric criteria, we failed to >> include "actionable" - some of the existing metrics don't provide any >> guidance for somebody who is unhappy with the results. Although >> "actionable" might be considered to be a sub item of "meaningful", >> some existing metrics don't do so well, even though they have well >> defined meanings. >> >> >> RFC 2330 defines extensibility, which (combined with repeatability) imo fits >> pretty much what you describe as "actionable". The solution which we are >> currently preferring is to find/define a set of metrics which can assess a) >> repeatability and b) extensibility of a measurement methodology. E.g., using >> measurement samples of one or two subsequent measurement scenarios (metric & >> methodology) as input, these metrics should provide hints if 1) there is a >> likelihood of repeatability and 2) we can extend measurement results to >> other scenarios/parameters - in the sense of metric linearity for a specific >> methodology. >> Perhaps even more important and easier to realize is a metric output that >> properties 1) and 2) are NOT fulfilled. >> >> >> We (network operators) always have "actionable" as a goal, >> meaning that the measurement results combined with some interpretation >> should lead the design or maintenance forces to their next steps >> (to improve performance or repair a problem). We move a long >> way toward the goal by selecting the right metrics from the start. >> >> All of our/user packet streams are influenced by a growing number of >> reactive network components, maintaining and changing state. >> It's matter-of-fact for most user flows. In reactive nets we can use >> discovery, characterization, and with on-going measurements, expectation, >> to help determine if there is a fault or other undesirable condition >> and what network elements may be involved. If the measurements really >> help to narrow-down the problem space, they are considered "actionable". >> >> So, I agree this is a useful consideration to add-in/update RFC 2330. >> >> As Joachim mentioned, this expansion of the stream framework is >> intended to address various forms of reactive networks, and certainly >> includes wired networks today. The concept of pre-load (as Matt called it) >> is important to any test path that includes a firewall. This >> aspect is an important consideration in the LMAP requirements: >> http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 >> and probably also the project described in IEEE 802.16 Liaison: >> https://datatracker.ietf.org/liaison/1195/ >> There is almost certainly some overlap between our draft and >> the intent of latter project. > > From mattmathis@google.com Mon Oct 22 15:40:05 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C2221F85D5 for ; Mon, 22 Oct 2012 15:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJmK4pQFk+HX for ; Mon, 22 Oct 2012 15:39:54 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D909211E80F6 for ; Mon, 22 Oct 2012 15:39:53 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1817318wgb.13 for ; Mon, 22 Oct 2012 15:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=aBBlQ2IUt0Ge2HECkHmNqW1yC79/aVwaZQr6WW+K3/E=; b=C0OJvAVRNTQGVzAwJVp3ThUZyq+o084OCBUQA//fKlj/o9HzQa/2tQSp7P9O/f39kh EhIjjppjiZZIS7vOsdT4JNWtayOVe6fSf06+He0+OprXGH81vto6tZIhZ1MEN5PaTmuo qJbxEuQv+OIDjFS4Xgar2nBblccghMjvmLBk5gDbkNMo9AeTvHtXNXumMkxxOE23Rhyx XxJPLFQ9uAYWSBoWayiNaUQZlwpd55xLO0EptMBiJsxeLOytCbMsR525qmftjgbb2t1Z ZsT/qPp5sVehUXKcmF1vlUtcGoioulxzGywmb1GxZ0NfafkkpvomfzfPOVFqi0lTFHvu UGCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=aBBlQ2IUt0Ge2HECkHmNqW1yC79/aVwaZQr6WW+K3/E=; b=KmfA6TZySWulJnenM3aUic1xILX9GzPXYmOJCaLbsi8kjWIethyQ1DkbvugixW6GqF qF/lQS6MdMqy1lX65Ca1RVTM//A2WYlMWG98PG3GuV4SJtdUhz1+pTnia33Ae8sF+mAu 7WO28zKokUCYIH4Q2HkmOjIDSdKAEmeLlxmMSMTgKX+XsFeGsZCiiCdFgHHifAGpLEkO +nEX+DB+y04IOcaxeLHfyTQ6xe7MiptDurs+abGz0QM5XNcufo2ARzQLD+PTEl7qX0RY /ZW7ZtMfO1mp4bz58SKeGBrW+ak4bJ8rCGULc/p1sjAasrqSzqO+FhDJadKM44/6rNFf ZpJA== MIME-Version: 1.0 Received: by 10.216.214.209 with SMTP id c59mr6127111wep.214.1350945592854; Mon, 22 Oct 2012 15:39:52 -0700 (PDT) Received: by 10.194.37.97 with HTTP; Mon, 22 Oct 2012 15:39:52 -0700 (PDT) In-Reply-To: <5085BDD1.2040705@tuwien.ac.at> References: <5072F59A.50507@tuwien.ac.at> <5077BAD0.7080908@tuwien.ac.at> <7.0.1.0.0.20121012085911.04d2dc58@att.com> <5085BDD1.2040705@tuwien.ac.at> Date: Mon, 22 Oct 2012 15:39:52 -0700 Message-ID: From: Matt Mathis To: Joachim Fabini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnXYTpjO+orJGGRziT8HhcIrcFdZKs/sGfJ/BklOgryVM4uFQQ/W3qsZ7osHAETeMbubzUiVJVYsDbZu6EVwIoDfQ1qWnIeBNrU6NnNvCMULOMnYlvm8DIR2NsUcSY7DXY/xKVXwj805vtpS3oOzOnVuZNogg27aY8p/iqyn6Jayh8XLjnW+uA/aIrMUxzGhY5LZ65Q Cc: acmorton@att.com, ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:40:06 -0000 I was thinking about two cases very different than yours... Probably important to include in scope: Systems based on RFC 6057, which in a general sense enforces average fair share over a longer time interval. It has the property that for "small" users, the network looks under loaded (user get "full rate" for a short time), then as users transition to a "High Consumption State" they get 1/N of the capacity allocated to the big users. My impression is that the thresholds are units of Mbytes and tens of seconds. Note that in this case the performance shift is in the opposite direction than it is for HSPA. For both HSPA and RFC 6057 it is easy to test the "high utilization" state if you know how hard you have to pre-load the network to get it there. A harder problem is measuring the low utilization state, when it may not be easy to tell when you trigger the state transition. We really should to be able to address this case too. (e.g. Must perform measurement in under X bytes/packets/etc) Note that it might also make sense to run 6057 over HSPA.... Probably not in scope: With non-encrypted traffic to some geo locations, typing certain queries into search engines causes "interesting" changes in network properties. http://www.nytimes.com/2012/06/02/world/asia/google-to-alert-users-to-chine= se-censorship.html But the point remains: *arbitrary* events in the past can influence measured performance over a whole range of timescales. We want to manage a bunch of them as best we can, and to think carefully about picking the largest possible tractable scope. (And my apologies to our Chinese subscribers, who probably will not see this message). Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, Oct 22, 2012 at 2:42 PM, Joachim Fabini wrote: > Matt, > > if I get you right, this relates somehow to the point-of-view topic (RFC > 6703). Developing this scenario: consider a VoIP media connection over > mobile networks. When measuring high end-to-end delay, VoIP clients might > infer on network overload and re-negotiate their codec to reduce bandwidt= h. > In networks with on-demand capacity allocation this is the worst decision= , > as it likely reduces allocated capacity and increases delay (and voice > quality) even more. Again, it's the question of user view and perception = vs. > system view, optimization and configuration. > > Concerning your specific question about transition duration: in some > evaluated HSPA networks, depending on the specific state and precondition= , > it takes some hundreds of miliseconds (it's basically a matter of one or > several round-trips). As an example, we have done some measurements with > respect to VoIP SIP signaling: using 5-10 seconds inter-arrival times, > effective HSPA round-trip delay (400-800 bytes payload) increases from an > optimum of 40-50ms (at much higher data rate) to 800ms and stays there. > > thanks, > regards > Joachim > > > > Am 22.10.2012 18:08, schrieb Matt Mathis: > >> Good question. I hadn't considered poor performance as a possible >> penalty for "bad surfing behavior", but it certainly is. I think we >> can keep the longer timescale issues in mind, but the real point is to >> improve measurement repeatability at shorter timescales e.g. session >> history. >> >> A slightly different question is over what timescale do things shift? >> If I transition from idle to heavy use, how long does it take to >> transition into a "power user" policy bin? (Put another way, what is >> the averaging timescale?) >> >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >> >> Privacy matters! We know from recent events that people are using our >> services to speak in defiance of unjust governments. We treat >> privacy and security as matters of life and death, because for some >> users, they are. >> >> >> On Mon, Oct 22, 2012 at 3:38 AM, wrote: >>> >>> Al, Joachim and Matt, >>> >>> it just came to my mind, whether we need to narrow down "reactive netwo= rk >>> behaviour" or whether >>> it stays undefined. >>> >>> reactive could a network behave: >>> - based on the history of and current local load conditions >>> - on user behaviour >>> # in terms of load in general >>> # in terms of visited online content >>> # in terms of payload contents >>> >>> To be more precise, active bandwidth throtteling or flow suppression ma= y >>> be >>> regarded as "reactive >>> network behaviour" too. >>> >>> Regards, >>> >>> R=FCdiger >>> >>> ________________________________ >>> From: Al Morton [mailto:acmorton@att.com] >>> Sent: Friday, October 12, 2012 3:43 PM >>> To: Joachim Fabini; Matt Mathis; Geib, R=FCdiger >>> >>> Cc: ippm@ietf.org >>> Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM >>> >>> R=FCdiger and Matt, >>> >>> Thanks for your review and comments so far. >>> I'll just add two points below (one to help define >>> "actionable" in the way that I think of it). >>> >>> regards, >>> Al >>> >>> At 02:38 AM 10/12/2012, Joachim Fabini wrote: >>> >>> On 12.10.2012 04:35, Matt Mathis wrote: >>> >>> I think this is a really good start. >>> >>> >>> Thank you. >>> >>> +1, we've had this in-progress for months, great to get feedback now. >>> >>> ... >>> >>> One other item for 2330: in the list of metric criteria, we failed to >>> include "actionable" - some of the existing metrics don't provide any >>> guidance for somebody who is unhappy with the results. Although >>> "actionable" might be considered to be a sub item of "meaningful", >>> some existing metrics don't do so well, even though they have well >>> defined meanings. >>> >>> >>> RFC 2330 defines extensibility, which (combined with repeatability) imo >>> fits >>> pretty much what you describe as "actionable". The solution which we ar= e >>> currently preferring is to find/define a set of metrics which can asses= s >>> a) >>> repeatability and b) extensibility of a measurement methodology. E.g., >>> using >>> measurement samples of one or two subsequent measurement scenarios >>> (metric & >>> methodology) as input, these metrics should provide hints if 1) there i= s >>> a >>> likelihood of repeatability and 2) we can extend measurement results to >>> other scenarios/parameters - in the sense of metric linearity for a >>> specific >>> methodology. >>> Perhaps even more important and easier to realize is a metric output th= at >>> properties 1) and 2) are NOT fulfilled. >>> >>> >>> We (network operators) always have "actionable" as a goal, >>> meaning that the measurement results combined with some interpretation >>> should lead the design or maintenance forces to their next steps >>> (to improve performance or repair a problem). We move a long >>> way toward the goal by selecting the right metrics from the start. >>> >>> All of our/user packet streams are influenced by a growing number of >>> reactive network components, maintaining and changing state. >>> It's matter-of-fact for most user flows. In reactive nets we can use >>> discovery, characterization, and with on-going measurements, expectatio= n, >>> to help determine if there is a fault or other undesirable condition >>> and what network elements may be involved. If the measurements really >>> help to narrow-down the problem space, they are considered "actionable"= . >>> >>> So, I agree this is a useful consideration to add-in/update RFC 2330. >>> >>> As Joachim mentioned, this expansion of the stream framework is >>> intended to address various forms of reactive networks, and certainly >>> includes wired networks today. The concept of pre-load (as Matt called >>> it) >>> is important to any test path that includes a firewall. This >>> aspect is an important consideration in the LMAP requirements: >>> http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 >>> and probably also the project described in IEEE 802.16 Liaison: >>> https://datatracker.ietf.org/liaison/1195/ >>> There is almost certainly some overlap between our draft and >>> the intent of latter project. >> >> >> > From Ruediger.Geib@telekom.de Tue Oct 23 00:00:06 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8819E1F0C49 for ; Tue, 23 Oct 2012 00:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2DO9s4BhOMm for ; Tue, 23 Oct 2012 00:00:05 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id ACD3221F8459 for ; Tue, 23 Oct 2012 00:00:03 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 23 Oct 2012 08:59:56 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 23 Oct 2012 08:59:56 +0200 From: To: Date: Tue, 23 Oct 2012 08:59:54 +0200 Thread-Topic: [ippm] Advanced Stream and Sampling Framework for IPPM Thread-Index: Ac2wb3oKviYkh0ZxRFum3MUNyGVe6wAd/+Ig Message-ID: References: <5072F59A.50507@tuwien.ac.at> <5077BAD0.7080908@tuwien.ac.at> <7.0.1.0.0.20121012085911.04d2dc58@att.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: acmorton@att.com, ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM 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, 23 Oct 2012 07:00:06 -0000 Matt, whether or not the behaviour I've heard of is caused by a power user, I don't know. I think, families having access to the Internet may be regarded as power users, if consumption of streaming content grows. And that's a present trend for sure. I quote from a blog: Reactive part 1: Since a few days, the customer of a cable provider sees a packet-burst and then nothing for a second (TCP dump). The author claims neither to be a file sharer, nor to be consuming more than the daily maximum byte budget given by the contract. Reactive part 2: The author plays around, once hitting a URL containing "/speedtest/". It's a 100 MB file download. While this runs, a different parallel download increases from 300 kB/s to 1,2 MB/s. Once the speedtest finishes, the parallel download is back to 300 kB/s again. The author further claims to have seen reports from other companies behaving similar. End of quote. I'm not interested in metrics to detect the above reactive behaviour. I'm interested in metrics capturing the standard performance as perceived by end-systems. That seems to be a reasonable way to compare things. A consequence, if any, may be to avoid easy detection of measurements. Regards, R=FCdiger -----Original Message----- From: Matt Mathis [mailto:mattmathis@google.com] Good question. I hadn't considered poor performance as a possible penalty for "bad surfing behavior", but it certainly is. I think we can keep the longer timescale issues in mind, but the real point is to improve measurement repeatability at shorter timescales e.g. session history. A slightly different question is over what timescale do things shift? If I transition from idle to heavy use, how long does it take to transition into a "power user" policy bin? (Put another way, what is the averaging timescale?) Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, Oct 22, 2012 at 3:38 AM, wrote: > Al, Joachim and Matt, > > it just came to my mind, whether we need to narrow down "reactive network > behaviour" or whether > it stays undefined. > > reactive could a network behave: > - based on the history of and current local load conditions > - on user behaviour > # in terms of load in general > # in terms of visited online content > # in terms of payload contents > > To be more precise, active bandwidth throtteling or flow suppression may = be > regarded as "reactive > network behaviour" too. > > Regards, > > R=FCdiger > > ________________________________ > From: Al Morton [mailto:acmorton@att.com] > Sent: Friday, October 12, 2012 3:43 PM > To: Joachim Fabini; Matt Mathis; Geib, R=FCdiger > > Cc: ippm@ietf.org > Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM > > R=FCdiger and Matt, > > Thanks for your review and comments so far. > I'll just add two points below (one to help define > "actionable" in the way that I think of it). > > regards, > Al > > At 02:38 AM 10/12/2012, Joachim Fabini wrote: > > On 12.10.2012 04:35, Matt Mathis wrote: > > I think this is a really good start. > > > Thank you. > > +1, we've had this in-progress for months, great to get feedback now. > > ... > > One other item for 2330: in the list of metric criteria, we failed to > include "actionable" - some of the existing metrics don't provide any > guidance for somebody who is unhappy with the results. Although > "actionable" might be considered to be a sub item of "meaningful", > some existing metrics don't do so well, even though they have well > defined meanings. > > > RFC 2330 defines extensibility, which (combined with repeatability) imo f= its > pretty much what you describe as "actionable". The solution which we are > currently preferring is to find/define a set of metrics which can assess = a) > repeatability and b) extensibility of a measurement methodology. E.g., us= ing > measurement samples of one or two subsequent measurement scenarios (metri= c & > methodology) as input, these metrics should provide hints if 1) there is = a > likelihood of repeatability and 2) we can extend measurement results to > other scenarios/parameters - in the sense of metric linearity for a speci= fic > methodology. > Perhaps even more important and easier to realize is a metric output that > properties 1) and 2) are NOT fulfilled. > > > We (network operators) always have "actionable" as a goal, > meaning that the measurement results combined with some interpretation > should lead the design or maintenance forces to their next steps > (to improve performance or repair a problem). We move a long > way toward the goal by selecting the right metrics from the start. > > All of our/user packet streams are influenced by a growing number of > reactive network components, maintaining and changing state. > It's matter-of-fact for most user flows. In reactive nets we can use > discovery, characterization, and with on-going measurements, expectation, > to help determine if there is a fault or other undesirable condition > and what network elements may be involved. If the measurements really > help to narrow-down the problem space, they are considered "actionable". > > So, I agree this is a useful consideration to add-in/update RFC 2330. > > As Joachim mentioned, this expansion of the stream framework is > intended to address various forms of reactive networks, and certainly > includes wired networks today. The concept of pre-load (as Matt called it= ) > is important to any test path that includes a firewall. This > aspect is an important consideration in the LMAP requirements: > http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 > and probably also the project described in IEEE 802.16 Liaison: > https://datatracker.ietf.org/liaison/1195/ > There is almost certainly some overlap between our draft and > the intent of latter project. From cuiyang@huawei.com Tue Oct 23 01:10:21 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDAD21F85BB for ; Tue, 23 Oct 2012 01:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omQIRdfe5l3c for ; Tue, 23 Oct 2012 01:10:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAAB21F8470 for ; Tue, 23 Oct 2012 01:10:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKW00978; Tue, 23 Oct 2012 08:10:01 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 09:09:53 +0100 Received: from SZXEML442-HUB.china.huawei.com (10.82.67.180) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 09:09:59 +0100 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.236]) by szxeml442-hub.china.huawei.com ([10.82.67.180]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 16:08:45 +0800 From: Cuiyang To: "ippm@ietf.org" Thread-Topic: New Version Notification for draft-bi-ippm-ipsec-00.txt Thread-Index: AQHNqpP60ruK6MkKlE+i716aqbQd1pfGkt0w Date: Tue, 23 Oct 2012 08:08:45 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE216368713F3@SZXEML508-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.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Bixiaoyu , Konstantinos Pentikousis Subject: [ippm] FWD: New Version Notification for draft-bi-ippm-ipsec-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, 23 Oct 2012 08:10:21 -0000 RGVhciBBbGwsDQoNClRoZSBmb2xsb3dpbmcgaXMgYSBuZXcgZHJhZnQgb24gbmV0d29yayBtZWFz dXJlbWVudCB1c2luZyBJUHNlYywgd2hpY2ggaXMgbm90IHN1cHBvcnRlZCBieSBjdXJyZW50IE8v VFdBTVAuDQoNCkkgd2lsbCBwcmVzZW50IHRoaXMgZHJhZnQgYXQgQVRMIGluIHBsYWNlIG9mIEVt aWx5IEJpLg0KQ29tbWVudHMgYXJlIHdlbGNvbWUsIHRoYW5rcyBpbiBhZHZhbmNlLg0KDQpCZXN0 IFJlZ2FyZHMsDQpZYW5nDQo9PT09PT09PT09PT09PT09PT0NCiBZYW5nIEN1aSwgIFBoLkQuDQog SHVhd2VpIFRlY2hub2xvZ2llcw0KIGN1aXlhbmdAaHVhd2VpLmNvbQ0KDQotLS0tLemCruS7tuWO n+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTLlubQxMOaciDE15pel IDEzOjE1DQrmlLbku7bkuro6IEJpeGlhb3l1DQrmioTpgIE6IEN1aXlhbmc7IEtvbnN0YW50aW5v cyBQZW50aWtvdXNpcw0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWJpLWlwcG0taXBzZWMtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJp LWlwcG0taXBzZWMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEVt aWx5IEJpIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkg ZHJhZnQtYmktaXBwbS1pcHNlYw0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgTmV0d29yayBQZXJm b3JtYW5jZSBNZWFzdXJlbWVudCBmb3IgSVBzZWMNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTEwLTE1 DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTMNClVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt YmktaXBwbS1pcHNlYy0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1iaS1pcHBtLWlwc2VjDQpIdG1saXplZDogICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpLWlwcG0taXBzZWMtMDANCg0KDQpBYnN0cmFj dDoNCiAgIElQc2VjIGlzIGEgbWF0dXJlIHRlY2hub2xvZ3kgd2l0aCBzZXZlcmFsIGludGVyb3Bl cmFibGUNCiAgIGltcGxlbWVudGF0aW9ucy4gIEluZGVlZCwgdGhlIHVzZSBvZiBJUHNlYyB0dW5u ZWxzIGlzIGluY3JlYXNpbmdseQ0KICAgZ2FpbmluZyBwb3B1bGFyaXR5IGluIHNldmVyYWwgZGVw bG95bWVudCBzY2VuYXJpb3MsIG5vdCB0aGUgbGVhc3QgaW4NCiAgIHdoYXQgdXNlZCB0byBiZSBz b2xlbHkgYXJlYXMgb2YgdHJhZGl0aW9uYWwgdGVsZWNvbW11bmljYXRpb24NCiAgIHByb3RvY29s cy4gIFdpZGVyIGRlcGxveW1lbnQgY2FsbHMgZm9yIG1lY2hhbmlzbXMgYW5kIG1ldGhvZHMgdGhh dA0KICAgZW5hYmxlIHR1bm5lbCBlbmQtdXNlcnMsIGFzIHdlbGwgYXMgb3BlcmF0b3JzLCB0byBt ZWFzdXJlIG9uZS13YXkgYW5kDQogICB0d28td2F5IG5ldHdvcmsgcGVyZm9ybWFuY2UuICBVbmZv cnR1bmF0ZWx5LCBob3dldmVyLCBzdGFuZGFyZCBJUA0KICAgcGVyZm9ybWFuY2UgbWVhc3VyZW1l bnQgbWVjaGFuaXNtcyBjYW5ub3QgYmUgcmVhZGlseSB1c2VkIHdpdGggSVBzZWMuDQogICBUaGlz IGRvY3VtZW50IG1ha2VzIHRoZSBjYXNlIGZvciBlbXBsb3lpbmcgSVBzZWMgdG8gcHJvdGVjdCBP L1RXQU1QDQogICBhbmQgcHJvcG9zZXMgYSBtZXRob2Qgd2hpY2ggY29tYmluZXMgSUtFdjIgYW5k IE8vVFdBTVAgYXMgZGVmaW5lZCBpbg0KICAgUkZDIDQ2NTYgYW5kIFJGQyA1MzU3LCByZXNwZWN0 aXZlbHkuICBUaGlzIHNwZWNpZmljYXRpb24gYWltcywgb24gdGhlDQogICBvbmUgaGFuZCwgdG8g ZW5zdXJlIHRoYXQgTy9UV0FNUCBjYW4gYmUgc2VjdXJlZCB3ZWxsLCB3aGlsZSBvbiB0aGUNCiAg IG90aGVyIGhhbmQsIGl0IGV4dGVuZHMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgTy9UV0FNUCB0byBu ZXR3b3JrcyB0aGF0DQogICBoYXZlIGFscmVhZHkgZGVwbG95ZWQgSVBzZWMuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From henk@uijterwaal.nl Wed Oct 24 00:23:09 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC85C21F8D2F for ; Wed, 24 Oct 2012 00:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 v07texw382UT for ; Wed, 24 Oct 2012 00:23:09 -0700 (PDT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by ietfa.amsl.com (Postfix) with ESMTP id BC6B521F8D0D for ; Wed, 24 Oct 2012 00:23:08 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9O7MZH7040395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Oct 2012 09:22:37 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <5087973A.3030400@uijterwaal.nl> Date: Wed, 24 Oct 2012 09:22:34 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: IETF IPPM WG X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [ippm] Draft agenda X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 07:23:09 -0000 IPPM group, Below is the draft agenda for Atlanta. Comments welcome. Please note that we have a very full agenda so stick to the assigned times. I'm looking for a note-taker. Henk - - - - - - Draft Agenda for IPPM @ IETF 85. ================================ 0. Administrativia (5') 1. Advanced Stream and Sampling Framework. (10') Al Morton, Joachim Fabini draft-morton-ippm-2330-update-00.txt 2. Passive and Hybrid Measurements using IPPM Metrics (15') Brian Trammell draft-trammell-ippm-hybrid-ps-00.txt 3. Model Based Internet Performance Metrics (10') Matt Mathis draft-mathis-ippm-model-based-metrics-00.txt 4. Curating Internet Measurement Data (10') Matt Mathis draft-mathis-ippm-data-curation-00.txt 5. Network Performance Measurements for IPsec (10') Yang Cui draft-bi-ippm-ipsec-01.txt 6. Flow-based Performance Measurement (10') Yu Fang draft-sun-ippm-flowbased-pm-00.txt 7. Rate Measurement Problem statement draft (5') Al Morton draft-… 8. RFC 2679-bis (10') Al Morton 9. AOB (5') Speakers: please submit slides before the meeting. Note that the timeslot includes time for discussion afterwards, that is, if you have 10 minutes, prepare to speak for about 7 and leave 3 for questions and answers. -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ Read my blog at http://www.uijterwaal.nl/henks_hands.html From zurawski@internet2.edu Mon Oct 22 09:21:13 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D91521F8B45 for ; Mon, 22 Oct 2012 09:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCujStWejCHJ for ; Mon, 22 Oct 2012 09:21:11 -0700 (PDT) Received: from int-proxy02.merit.edu (int-proxy02.merit.edu [207.75.116.231]) by ietfa.amsl.com (Postfix) with ESMTP id F216C21F8B46 for ; Mon, 22 Oct 2012 09:21:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy02.merit.edu (Postfix) with ESMTP id 9D49A120444 for ; Mon, 22 Oct 2012 12:21:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at int-proxy02.merit.edu Received: from int-proxy02.merit.edu ([127.0.0.1]) by localhost (int-proxy02.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28dnfVfTSBhg for ; Mon, 22 Oct 2012 12:21:10 -0400 (EDT) Received: from [172.19.131.138] (unknown [199.106.165.91]) by int-proxy02.merit.edu (Postfix) with ESMTPSA id 06EC8120448 for ; Mon, 22 Oct 2012 12:21:09 -0400 (EDT) From: Jason Zurawski Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 22 Oct 2012 12:21:01 -0400 To: ippm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) X-Mailman-Approved-At: Thu, 25 Oct 2012 08:03:18 -0700 Subject: [ippm] CFP: IEEE Communications Magazine - Monitoring and Troubleshooting Multi-domain Networks using Measurement Federations X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:21:13 -0000 [Apologies if you receive multiple copies of this CFP] ------------------------------------------------------------- IEEE Communications Magazine - Monitoring and Troubleshooting = Multi-domain Networks using Measurement Federations CALL FOR PAPERS - First announcement ------------------------------------------------------------- = http://www.comsoc.org/files/Publications/Magazines/ci/cfp/cfpcommag1113.ht= m Aims and Scope In both the scientific and corporate worlds, users, resources, and data = are often physically distributed, making networks increasingly important = for all operations. Enormous progress has been made in increasing the = capacity and accessibility of networking infrastructures, which in turn = has fostered wider adoption of Cloud and Grid environments. = Unfortunately, these advances have not directly translated into improved = performance for all applications and users; instead, network performance = problems become even more subtle and detrimental as the capacity of the = network increases, and troubleshooting them on multi-domain network = paths is highly challenging. These problems may be as benign as = congestion from other network users, or as serious as packet loss caused = by one or more intermediate-domain infrastructure and architectural = flaws. Troubleshooting performance problems on multi-domain networks requires a = great deal of effort and expertise, as well as measurement policy = agreements that mutually benefit domains within measurement federations. = Novel approaches are needed to foster wider adoption of explicit = measurement federations such as perfSONAR, SamKnows, Grenouille and = M-Lab involving co-operating agents in collaborating vendor = organizations as well as user communities. These approaches may also be = suitable for implicit measurement federations seen in content-delivery = networks involving multiple service providers that co-operate to reduce = operating costs, while providing satisfactory end-user experience. = Building upon current end-to-end measurement federation related = standards-development efforts - at Open Grid Forum (OGF), IETF IP = Performance Metrics (IPPM), IEEE 802.1 ag, ITU-T Y.1731, and Metro = Ethernet Forum (MEF) - can benefit the interoperability and = sustainability of explicit and implicit measurement federations. In addition, sophisticated tools are required to monitor multi-domain = networks and to detect, localize and diagnose performance problems in = real-time. As networks increase in capacity, and new paradigms such as = Software Defined Networking emerge to aid in traffic management, = performance monitoring tools must be scalable and capable of detecting = performance issues in a timely manner. The monitoring and diagnosing = tools must comply with measurement federation policies, and aid network = operators when troubleshooting perceived abnormalities, as well as help = network middleware and intelligent applications to work around problems, = ultimately minimizing the impact to end users. This special issue will cover novel techniques and standardization = efforts in the area of monitoring and troubleshooting of multi-domain = networks using measurement federations. Topics to be covered include, = but are not limited to: =E2=80=A2 Algorithms and Techniques for Automated Network = Troubleshooting =E2=80=A2 Architectures for Federated Measurement Collection and = Sharing =E2=80=A2 Intra and Inter Domain Monitoring Strategies =E2=80=A2 Measurement Federation related Standards-development = Efforts =E2=80=A2 Monitoring of Software Defined, Content-delivery and = Overlay Networks =E2=80=A2 Troubleshooting of Hybrid Packet and Circuit Networks =E2=80=A2 Network-aware Middleware for High Speed Networks =E2=80=A2 Measurements from Cloud and Grid Environments =E2=80=A2 Security and Policy Considerations for Federated = Measurements =E2=80=A2 New Policy-based Network Monitoring/Analysis Tools and = Paradigms =E2=80=A2 End-to-End ("Disk-to-Disk") Performance Problem = Troubleshooting =E2=80=A2 Scalability of Measurement Methods and Infrastructures =E2=80=A2 Embedded Active Monitoring based Collaborative = Management =E2=80=A2 Case Studies of End-to-End or Network Performance = Troubleshooting =E2=80=A2 Federations to jointly troubleshoot Home-area and = Wide-area Networks Submission Guidelines=20 Articles should be tutorial in nature and written in a style = comprehensible to readers outside the specialty of the article. Authors = must follow the IEEE Communications Magazine's guidelines for = preparation of the manuscript. Complete guidelines for prospective = authors can be found at = http://www.comsoc.org/commag/paper-submission-guidelines. It is very = important to note that the IEEE Communications Magazine strongly limits = mathematical content, and the number of figures and tables. Paper length = should not exceed 4,500 words. All articles to be considered for = publication must be submitted through the IEEE Manuscript Central = (http://mc.manuscriptcentral.com/commag-ieee) by the deadline. Select = "November 2013/Monitoring and Troubleshooting Multi-domain Networks = using Measurement Federations" from the drop down menu. Important Dates=20 Manuscript Submission Due: March 1, 2013 Acceptance Notification: July 1, 2013 Final Manuscript Due: September 1, 2013 Publication: November 2013 Guest Editors=20 Constantine Dovrolis - Georgia Institute of Technology - = dovrolis@cc.gatech.edu Prasad Calyam - Ohio Supercomputer Center/OARnet, The Ohio State = University - pcalyam@osc.edu Raj Kettimuthu - Argonne National Laboratory - kettimut@mcs.anl.gov Brian Tierney - Energy Sciences Network - bltierney@es.net Jason Zurawski - Internet2 - zurawski@internet2.edu Loki Jorgenson - NooCore Technology Consulting - ljorgenson@noocore.com ----- Jason Zurawski, Senior Research Engineer Internet2 zurawski@internet2.edu office: [+1-202-331-5354] mobile: [+1-703-981-2494] fax: [+1-202-872-4318] TIP2013, University of Hawaii M=C4=81noa January 13 - January 17, 2013, Honolulu, HI http://events.internet2.edu/2013/tip/ From iesg-secretary@ietf.org Thu Oct 25 08:08:27 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437AD21F9170; Thu, 25 Oct 2012 08:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 87Mrswy8nDqX; Thu, 25 Oct 2012 08:08:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD9821F9178; Thu, 25 Oct 2012 08:08:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121025150826.24645.45483.idtracker@ietfa.amsl.com> Date: Thu, 25 Oct 2012 08:08:26 -0700 Cc: ippm mailing list , ippm chair , RFC Editor Subject: [ippm] Document Action: 'Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track' to Informational RFC (draft-ietf-ippm-testplan-rfc2679-03.txt) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:08:27 -0000 The IESG has approved the following document: - 'Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track' (draft-ietf-ippm-testplan-rfc2679-03.txt) as Informational RFC This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ippm-testplan-rfc2679/ Technical Summary This memo proposes to advance a performance metric RFC along the standards track, specifically RFC 2679 on One-way Delay 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 2679. Working Group Summary The normal WG process was followed and the document has been discussed for about 2 years. The document as it is now, reflects WG consensus, with nothing special worth noticing. Document Quality There are relevant implementations as the document describes actual work done with those implementations. Personnel Henk Uijterwaal is the document shepherd, and the responsible AD is Wes Eddy. From lishunsun@gmail.com Thu Oct 25 22:54:05 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B469421F84C7 for ; Thu, 25 Oct 2012 22:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=0.215, 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 h+tnTOqlO9H9 for ; Thu, 25 Oct 2012 22:54:05 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2BF221F84A6 for ; Thu, 25 Oct 2012 22:54:04 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so61080qao.10 for ; Thu, 25 Oct 2012 22:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dku99UtYOYGgBf/00O6jvxNl2nqH1riqhEp/yzpzekU=; b=BIu7hYfND2iYsAvSynVR7Eziw0dWFPxMHP7oAkUXvVoraITeea2PDDVq5U/MKgZXuT Z5t/UEYFYo5GWePaR1RfQ+4vkkiJYXMkCiygjlNGv8BUzZA2zD1wKNSaG2a+OXeyxRT1 MLxONjOX1qRN4MwRPB1MGRQIYfKCbhnrPffJcq+aRwJmb/s1J+XSUvzLxksNsQIESD6G KV+H9goyzt3LqXuk01iCpzgN7KbZn1e2jYNrZkbKcsMltfqr71nrI1K7XTETwHFxseXm uGiweiuIiygdHQbr+YBy0kqsxJdcibtlxIZnjLYaS/TuaiqCLLrldFNJVB4x4TpK1Sx5 +7Rg== MIME-Version: 1.0 Received: by 10.49.4.168 with SMTP id l8mr12747061qel.57.1351230844285; Thu, 25 Oct 2012 22:54:04 -0700 (PDT) Received: by 10.49.75.129 with HTTP; Thu, 25 Oct 2012 22:54:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Oct 2012 13:54:04 +0800 Message-ID: From: McGrady Sun To: ippm@ietf.org Content-Type: multipart/alternative; boundary=047d7bb04f227bb1b604cceff27b Subject: Re: [ippm] :draft-sun-ippm-flowbased-pm-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, 26 Oct 2012 05:54:05 -0000 --047d7bb04f227bb1b604cceff27b Content-Type: text/plain; charset=ISO-8859-1 Hi, While TWAMP works well in most situations, it has some problems in application flow measurement. For such considerations FPM is proposed. It is necessary to real-time measure application flows in some cases: network needs to real-time monitor application flows, and take actions such as resource allocation or congestion control in time according to measurement results. TWAMP has to copy a flow similar to data flow in network in order to get more accurate results if it wants to support real-time measurement of application flows. However, it will increase network load, and has bad effects on the performance of online applications. FPM measurement proposed here can address the problem above well: it injects small number of test packets in application flows, and carries flow-related information in test packets to track and record states of each flow. In this way it can work well to real-time measure application flows with little effect on them. regards, Lishun Sun 2012/10/17 McGrady Sun > Dear all, > > Last week we posted a new draft based on > http://datatracker.ietf.org/doc/draft-sun-tsvwg-flowbased-pm/?include_text=1 > . The following modifications were made. > > 1. A detailed description of the problem statement is contained, > including both the motivation and scenarios of the proposed method. Also, a > use case is attached. > > 2. Describes how the IPPM metrics are supported by the proposed > flow-based performance measurement. > > 3. The description of the measurement procedure is also revised. > > We would like to thank Al Morton and Andreas Johnsson for their > comments and suggestions on the original version. > > > Best Regards, > > Lishun Sun > > ---------- Forwarded message ---------- > From: > Date: 2012/10/12 > Subject: New Version Notification for draft-sun-ippm-flowbased-pm-00.txt > To: lishunsun@gmail.com > Cc: wdwang@bupt.edu.cn, grace.yufang@huawei.com > > > > A new version of I-D, draft-sun-ippm-flowbased-pm-00.txt > has been successfully submitted by Lishun Sun and posted to the > IETF repository. > > Filename: draft-sun-ippm-flowbased-pm > Revision: 00 > Title: Flow-based Performance Measurement > Creation date: 2012-10-12 > WG ID: Individual Submission > Number of pages: 21 > URL: > http://www.ietf.org/internet-drafts/draft-sun-ippm-flowbased-pm-00.txt > Status: > http://datatracker.ietf.org/doc/draft-sun-ippm-flowbased-pm > Htmlized: http://tools.ietf.org/html/draft-sun-ippm-flowbased-pm-00 > > > Abstract: > The performance measurements of service flow are becoming significant > important for administrators monitoring the fitness of the network. > This memo defines an end-to-end flow-based performance measurement > method, which is achieved by generating synthetic measurement > packets, injecting them to the network and analyzing the statistics > carried in the measurement packets.This measurement method can > measure flow characteristics such as delay, ipdv (IP Packet Delay > Variation) and packet loss. > > > > > The IETF Secretariat > > > --047d7bb04f227bb1b604cceff27b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=A0While TWAMP wor= ks well in most situations, it has some problems in application flow measur= ement. For such considerations FPM is proposed.

=A0It is necessary to real-time measure application flows in some cases:= network needs to real-time monitor application flows, and take actions suc= h as resource allocation or congestion control in time according to measure= ment results.

=A0TWAMP has to copy a flow similar to data flow in network in order to = get more accurate results if it wants to support real-time measurement of a= pplication flows. However, it will increase network load, and has bad effec= ts on the performance of online applications.

=A0FPM measurement proposed here can address the problem above well: it = injects small number of test packets in application flows, and carries flow= -related information in test packets to track and record states of each flo= w. In this way it can work well to real-time measure application flows with= little effect on them.

regards,

Lishun Sun


2012/= 10/17 McGrady Sun <lishunsun@gmail.com>

Dear all,

=A0=A0=A0 Last week we po= sted a new draft=A0based on=A0http://datatracker.ietf.org/doc/draft-sun-tsvw= g-flowbased-pm/?include_text=3D1.=A0The following modifi= cations were made.

=A0=A0=A0 1. A detailed d= escription of the problem statement is contained, including both the motiva= tion and scenarios of the proposed method. Also, a use case is attached.

=A0=A0=A0 2. Describes ho= w the IPPM metrics are supported by the proposed flow-based performance mea= surement.

=A0= =A0=A0 3. The description of the measurement procedure is also revised.=A0<= /span>

=A0=A0=A0 We would like t= o thank Al Morton and Andreas Johnsson for their comments and suggestions o= n the original version.


Best Regards,

Lishun S= un


---------- Forwarded mes= sage ----------
From: <internet-drafts@ietf.org<= /a>>
Date: 2012/10/12
Subject: New Version Notification for= draft-sun-ippm-flowbased-pm-00.txt
To: lishunsun@gmai= l.com
Cc: wd= wang@bupt.edu.cn, grace.yufang@huawei.com



A new version of I-D, draft-sun-ippm-flowbased-pm-00.txt
has been successfully submitted by Lishun Sun and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sun-ippm-flowbased-pm
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Flow-based Performance Measurement
Creation date: =A0 2012-10-12
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 21
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/= internet-drafts/draft-sun-ippm-flowbased-pm-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/d= raft-sun-ippm-flowbased-pm
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-sun-= ippm-flowbased-pm-00


Abstract:
=A0 =A0The performance measurements of service flow are becoming significan= t
=A0 =A0important for administrators monitoring the fitness of the network.<= br> =A0 =A0This memo defines an end-to-end flow-based performance measurement =A0 =A0method, which is achieved by generating synthetic measurement
=A0 =A0packets, injecting them to the network and analyzing the statistics<= br> =A0 =A0carried in the measurement packets.This measurement method can
=A0 =A0measure flow characteristics such as delay, ipdv (IP Packet Delay =A0 =A0Variation) and packet loss.




The IETF Secretariat



--047d7bb04f227bb1b604cceff27b-- From yuehuid@gmail.com Thu Oct 25 23:06:02 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F261821F863F for ; Thu, 25 Oct 2012 23:06:01 -0700 (PDT) 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 4Njfiy1heJj5 for ; Thu, 25 Oct 2012 23:06:01 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB08521F8630 for ; Thu, 25 Oct 2012 23:06:00 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1020742bkc.31 for ; Thu, 25 Oct 2012 23:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xjRyNoO4esrVRP8ULJ5/WoRIcS6/dHkjZbqovtTV54Q=; b=zVtWlhmLoVqn31tJVUwz/AZOQUWqlTEm+O0KeaZDKBouAtJtCpxYEFZNdN4BC/OMwv Eqdm3Q36JSJJDg1hRxDgR0n0dDF+mc8om/NSJtHwYtft1OE6mH1oD3qXEMsT+koHntaP RS5Uv0QgsuAK8glg9hXxxH2F3FqdI9eTDLRT9wTV5UdlrJh+HSog6eT5ZzdkLdzMqTqu ve2BlgMj+XOijaZeQ8KZjHk1iRhstzUtLTI6hLS3LlLWux672gS5HYQzCQLI/k3HfOPw XVN0M1jmEFQZxcEFuIr6NBTdmW24YW5v8PV7NLbSz7hi22t0GwWyXF41IX4bYFgxV+3S iolA== MIME-Version: 1.0 Received: by 10.204.4.75 with SMTP id 11mr6720164bkq.96.1351231559745; Thu, 25 Oct 2012 23:05:59 -0700 (PDT) Received: by 10.205.39.74 with HTTP; Thu, 25 Oct 2012 23:05:59 -0700 (PDT) Date: Fri, 26 Oct 2012 14:05:59 +0800 Message-ID: From: Yuehui Ding To: ippm@ietf.org Content-Type: multipart/alternative; boundary=0015174beaea20bf6c04ccf01d9b Subject: [ippm] test 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, 26 Oct 2012 06:08:15 -0000 --0015174beaea20bf6c04ccf01d9b Content-Type: text/plain; charset=ISO-8859-1 This is a test, pls just ignore it. --0015174beaea20bf6c04ccf01d9b Content-Type: text/html; charset=ISO-8859-1 This is a test, pls just ignore it. --0015174beaea20bf6c04ccf01d9b-- From suruagy@cin.ufpe.br Fri Oct 26 07:59:02 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6709B21F864A for ; Fri, 26 Oct 2012 07:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, 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 TjsncbLPzTtK for ; Fri, 26 Oct 2012 07:59:01 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4443721F84C6 for ; Fri, 26 Oct 2012 07:58:59 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2760244lam.31 for ; Fri, 26 Oct 2012 07:58:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=I+VEQVH3Hc2qDaaK0ESSUP5VPR5CtbROL5zzO4d9e04=; b=AzTLuBGsENa2J1unH0rcyn0S6OztGFEdfStUN8FXwn9cxU5M7szb4SXInweWLCoWch LJ8bc8eCev9htkOCSR+/ZgIKfHxkw2OLKCah8uMdqs9gcxXTxKBw4RoDS+6pT0adTghb WYLCyn7iiJ9gXBRhncOg/XUlWghUXpaeTSp0IT7layTskPIhv9+mjdMoD6sGM2L4ucL3 Ov3HcDBgr/YHid2Buj8hP9dy6D4wwYJYNiYlfjh6VCpUYhBUfiw2Z9xM19MOp/wJC3ax Nig4FQ8D1u/iH9Cwl2ioSp0wa4Zpbd0qSCkmr86BJRLOqtmVjVyA0p817zirlBthL+Jk UHCw== MIME-Version: 1.0 Received: by 10.152.123.103 with SMTP id lz7mr20603754lab.21.1351263536997; Fri, 26 Oct 2012 07:58:56 -0700 (PDT) Received: by 10.112.7.37 with HTTP; Fri, 26 Oct 2012 07:58:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Oct 2012 11:58:56 -0300 Message-ID: From: Jose Augusto Suruagy Monteiro To: ippm@ietf.org, imrg@irtf.org Content-Type: multipart/alternative; boundary=f46d042ef4471ee55b04ccf78ff7 X-Gm-Message-State: ALoCoQluZDHKdmKSkm+FaUymndaTi1pCwHwVeKnkg6tPg9BpxNNagu6/h7mVpeawiDvXXfIlbPCa Subject: [ippm] CFP - SBRC 2013 - 31st Brazilian Symposium on Computer Networks and Distributed Systems 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, 26 Oct 2012 14:59:02 -0000 --f46d042ef4471ee55b04ccf78ff7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D *** CALL FOR PAPERS --- SBRC 2013 *** Brasilia (Brazil) -- May 6-10, 2013 http://sbrc2013.unb.br/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D PRESENTATION The Brazilian Symposium on Computer Networks and Distributed Systems (SBRC) is an annual event promoted by the Brazilian Computer Society (SBC) and by the National Computer Networks Laboratory (LARC). SBRC has become the most important scientific event on computer networks and distributed systems in Latin America. Its importance can be attested by the large number of attendees and submissions it has received for several years. In its 31st edition, the symposium will take place in Brasilia, DF, from May 6-10, 2013. It is being organized by the Departments of Computer Science (CIC) and Electrical Engineering (ENE) of Universidade de Brasilia (UnB). The symposium features not only technical sessions, but also panels, several workshops, a tools demonstration session as well as invited talks and tutorials presented by internationally acclaimed researchers. Specific calls to the several activities during SBRC will be announced later. Authors of the best papers selected for publication and presentation in SBRC 2013 will be invited to submit an extended version of their work to the Brazilian Journal of Computer Networks and Distributed Systems (RB-RESD). TOPICS OF INTEREST Prospective authors are invited to submit full papers containing novel results from scientific or technological research. Each paper will be reviewed by at least three experts. A non-exhaustive list of topics of interest includes: - Ad hoc networks - Address and location management - Autonomic distributed systems - Autonomic networks - Broadband access and technologies - Capacity Planning - Cloud computing - Cognitive radio networks - Context-aware computing - Cross-layer optimization - Delay/disruption-tolerant networks - Detection and prevention of anomalies and attacks - Digital TV - Distributed algorithms and applications - Distributed multimedia systems - Distributed operating systems - Distributed real-time systems - Future Internet - Green Networking - Grid computing - Infrastructured wireless networks - Network management and operation - Middleware - Mobile computing - Mobile networks - Mobility - Network architecture - Network measurement and monitoring - Network analysis and project - Network simulation and emulation - Networks and protocols for RFID - Networks and services characterization - Online social networks - Optical networks - P2P networks and systems - Performance, scalability, and reliability - Protocols - Quality of Experience (QoE) - Quality of Service (QoS) - Real-time distributed systems - Resilience and fault tolerance - Routing, switching and addressing - Security in networks and distributed systems - Self-organizing networks - Sensor networks - Service-oriented computing - Software defined networks - Specification, validation, and verification - Tools and software environments for distributed systems - Traffic engineering and control - Ubiquitous computing - Vehicular networks - Virtualization - Web services AUTHORS INFORMATION The submission of papers will be exclusively online, through the JEMS conferencing system. Authors should access https://jems.sbc.org.br/sbrc2013. Papers may be written in Portuguese or English, and must be in PDF format. Each paper is limited to 14 pages, including abstract, figures, tables, references, and appendices. Papers must follow the SBC format, available at http://www.sbc.org.br/index.php?option=3Dcom_jdownloads&Itemid=3D195&task= =3Dview.download&catid=3D32&cid=3D38 . IMPORTANT DATES Paper registration: November 26, 2012 Paper upload: December 03, 2012 Notification of results: March 13, 2013 Camera-ready version: March 22, 2013 ORGANIZING COMMITTEE * General Chairs Jacir Luiz Bordim (UnB) Rafael Tim=F3teo de Sousa J=FAnior (UnB) William Ferreira Giozza (UnB) * Technical Program Committee Chairs Carlos Andr=E9 Guimar=E3es Ferraz (UFPE) Jos=E9 Augusto Suruagy Monteiro (UFPE) * International Talks and Tutorials Chair Nelson Luis Saldanha da Fonseca (UNICAMP) * Panels Chair Lisandro Zambenedetti Granville (UFRGS) * National Tutorials Chair Joni da Silva Fraga (UFSC) * Workshops Chair Francisco Vilar Brasileiro (UFCG) * Tools Demonstration Chair Gustavo Sousa Pavani (UFABC) PROMOTION Brazilian Computer Society (SBC) http://www.sbc.org.br National Computer Networks Laboratory (LARC) http://www.larc.org.br ORGANIZATION Universidade de Brasilia (UnB) http://www.unb.br/ --=20 Jos=E9 Augusto Suruagy Monteiro Universidade Federal de Pernambuco - UFPE Centro de Inform=E1tica - CIn Av. Jornalista Anibal Fernandes, s/n - Cidade Universit=E1ria 50.740-560, Recife, PE, Brazil FAX: +55 81 2126-8438 PHONE: +55 81 2126-8430 (ext. 4329) SKYPE: jasuruagy --f46d042ef4471ee55b04ccf78ff7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
*** CALL FOR PAPERS --- SBRC 2013 ***
Brasilia (Brazil) -- May 6-10, 2013
http:= //sbrc2013.unb.br/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

PRESENTATION

The Brazilian Symposium on Computer= Networks and Distributed Systems (SBRC) is an annual event promoted by the= Brazilian Computer Society (SBC) and by the National Computer Networks Lab= oratory (LARC). SBRC has become the most important scientific event on comp= uter networks and distributed systems in Latin America. Its importance can = be attested by the large number of attendees and submissions it has receive= d for several years.

In its 31st edition, the symposium = will take place in Brasilia, DF, from May 6-10, 2013. It is being organized= by the Departments of Computer Science (CIC) and Electrical Engineering (E= NE) of Universidade de Brasilia (UnB). The symposium features not only tech= nical sessions, but also panels, several workshops, a tools demonstration s= ession as well as invited talks and tutorials presented by internationally = acclaimed researchers. Specific calls to the several activities during SBRC= will be announced later. Authors of the best papers selected for publicati= on and presentation in SBRC 2013 will be invited to submit an extended vers= ion of their work to the Brazilian Journal of Computer Networks and Distrib= uted Systems (RB-RESD).

TOPICS OF INTEREST

Prospective authors are invited to = submit full papers containing novel results from scientific or technologica= l research. Each paper will be reviewed by at least three experts.
A non-exhaustive list of topics of = interest includes:

- Ad hoc networks
- Address and location management
- Autonomic distributed systems
- Autonomic networks
- Broadband access and technologies
- Capacity Planning
- Cloud computing
- Cognitive radio networks
- Context-aware computing
- Cross-layer optimization
- Delay/disruption-tolerant networks
- Detection and prevention of anomalies and attacks
- Digital TV
- Distributed algorithms and applications
- Distributed multimedia systems
- Distributed operating systems
- Distributed real-time systems
- Future Internet
- Green Networking
- Grid computing
- Infrastructured wireless networks
- Network management and operation
- Middleware
- Mobile computing
- Mobile networks
- Mobility
- Network architecture
- Network measurement and monitoring
- Network analysis and project
- Network simulation and emulation
- Networks and protocols for RFID
- Networks and services characterization
- Online social networks
- Optical networks
- P2P networks and systems
- Performance, scalability, and reliability
- Protocols
- Quality of Experience (QoE)
- Quality of Service (QoS)
- Real-time distributed systems
- Resilience and fault tolerance
- Routing, switching and addressing
- Security in networks and distributed systems<= br style=3D"color:rgb(34,34,34);font-size:12.727272033691406px;font-family:= arial,sans-serif"> - Self-organizing networks
- Sensor networks
- Service-oriented computing
- Software defined networks
- Specification, validation, and verification - Tools and software environments for distributed syst= ems
- Traffic engineering and control
- Ubiquitous computing
- Vehicular networks
- Virtualization
- Web services

AUTHORS INFORMATION

The submission of papers will be ex= clusively online, through the JEMS conferencing system.
Authors should access=A0https://jems.sbc.or= g.br/sbrc2013.
Papers may be written in Portuguese or English, and mu= st be in PDF format. Each paper is limited to 14 pages, including abstract,= figures, tables, references, and appendices. Papers must follow the SBC fo= rmat, available at=A0http://www.sbc.org.br/ind= ex.php?option=3Dcom_jdownloads&Itemid=3D195&task=3Dview.download&am= p;catid=3D32&cid=3D38.
IMPORTANT DATES

Paper registration: November 26, 20= 12
Paper upload: December 03, 2012
Notification of results: March 13, 2013
Camera-ready version: March 22, 2013

ORGANIZING COMMITTEE

* General Chairs
Jacir Luiz Bordim (UnB)
Rafael Tim=F3teo de Sousa J=FAnior (UnB)
William Ferreira Giozza (UnB)

* Technical Program Committee Chair= s
Carlos Andr=E9 Guimar=E3es Ferraz (UFPE)
Jos=E9 Augusto Suruagy Monteiro (UFPE)

* International Talks and Tutorials= Chair
Nelson Luis Saldanha da Fonseca (UNICAMP)

* Panels Chair
Lisandro Zambenedetti Granville (UFRGS)

* National Tutorials Chair Joni da Silva Fraga (UFSC)

* Workshops Chair
Francisco Vilar Brasileiro (UFCG)

* Tools Demonstration Chair<= br style=3D"color:rgb(34,34,34);font-size:12.727272033691406px;font-family:= arial,sans-serif"> Gustavo Sousa Pavani (UFABC)


PROMOTION

Brazilian Computer Society (SBC)
http:/= /www.sbc.org.br

National Computer Networks Laborato= ry (LARC)
http:= //www.larc.org.br

ORGANIZATION

Universidade de Brasilia (UnB)
http://www= .unb.br/



--
Jos=E9 Augusto Suruagy Mo= nteiro

Universidade Federal de Pernambuco - UFPE
Centro de Inform= =E1tica - CIn
Av. Jornalista Anibal Fernandes, s/n - Cidade Universit=E1= ria
50.740-560, Recife, PE, Brazil
FAX: +55 81 2126-8438
PHONE: +55 81 21= 26-8430 (ext. 4329)
SKYPE: jasuruagy
--f46d042ef4471ee55b04ccf78ff7-- From Maha.Abdallah@lip6.fr Sat Oct 27 21:30:40 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F5021F86B9 for ; Sat, 27 Oct 2012 21:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 BWzIzpnGCMyw for ; Sat, 27 Oct 2012 21:30:40 -0700 (PDT) Received: from isis.lip6.fr (isis.lip6.fr [IPv6:2001:660:3302:283c::2]) by ietfa.amsl.com (Postfix) with ESMTP id CBEC721F86B8 for ; Sat, 27 Oct 2012 21:30:39 -0700 (PDT) Received: from poleia.lip6.fr (mailtwo.desir.lip6.fr [132.227.205.24]) by isis.lip6.fr (8.14.5/lip6) with ESMTP id q9S4UYiK001955 for ; Sun, 28 Oct 2012 05:30:37 +0100 (CET) X-pt: isis.lip6.fr Received: by poleia.lip6.fr (Postfix, from userid 33) id 962711467DF; Sun, 28 Oct 2012 05:30:29 +0100 (CET) Received: from 50.0.89.80 (SquirrelMail authenticated user abdallah) by mailtwo.lip6.fr with HTTP; Sun, 28 Oct 2012 05:30:29 +0100 Message-ID: Date: Sun, 28 Oct 2012 05:30:29 +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]); Sun, 28 Oct 2012 05:30:37 +0100 (CET) X-Scanned-By: MIMEDefang 2.73 on 132.227.60.2 Subject: [ippm] NetGames 2012 - Call for Participation (Nov. 22-23 - Venice, Italy) 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, 28 Oct 2012 04:30:40 -0000 CALL FOR PARTICIPATION *********************************************************************** * NetGames 2012 * * The 11th Annual Workshop on Network and Systems Support for Games * * November 22-23, 2012 * * Venice, Italy * * * * In co-operation with ACM SIGCOMM and ACM SIGMM * * Technically sponsored by IEEE Communications Society * * * * Early registration deadline: Nov 4, 2012 * * http://netgames2012.lip6.fr/ * *********************************************************************** We would like to cordially invite you to attend the 11th Annual Workshop on Network and Systems Support for Games (NetGames 2012), which will be held on November 22-23, 2012 in Venice, Italy, in the facilities of the Venice International University (VIU), an international higher education and research center on the island of San Servolo. OVERVIEW ======== The NetGames workshop is a major annual international workshop that brings together researchers and visionaries from academia, research labs, and industry to present new research in understanding networked games of today and in enabling the next generation of them. NetGames has become a recognized venue for Promoting exciting discussions among its participants in all areas related to online games and Virtual environments. Two keynotes addresses, a panel discussion, and a total of 19 research papers, posters and demos spanning various topics related to networked games will be presented and discussed. We cordially invite you to attend the workshop and share with us your feedback, thoughts, and experience. Further details can be found at: http://netgames2012.lip6.fr/ REGISTRATION ============ Early registration deadline: November 4, 2012 Online registration site: http://netgames2012.lip6.fr/registration.html ACCEPTED PAPERS =============== A. Full papers: ------------ Adaptive Delta-Causality Control Scheme with Dynamic Control of Prediction Time in Networked Haptic Game Yusuke Hara (Nagoya Institute of Technology, Japan); Yutaka Ishibashi (Nagoya Institute of Technology, Japan); Norishige Fukushima (Nagoya Institute of Technology, Japan); Shinji Sugawara (Nagoya Institute of Technology, Japan) OGRE: A Cloud Platform for Seamless Wide Area Migration of Networked Games Virajith Jalaparti (University of Illinois, Urbana Champaign, USA); Matthew Caesar (University of Illinois at Urbana-Champaign, USA); Seungjoon Lee (AT&T Labs Research, USA); Jeffrey Pang (AT&T Labs - Research, USA); Jacobus Van der Merwe (University of Utah, USA) Thin to Win? Network Performance Analysis of the OnLive Thin Client Game System Mark Claypool (Worcester Polytechnic Institute, USA); David Finkel (Worcester Polytechnic Institute, USA); Alexander Grant (Worcester Polytechnic Institute, USA); Michael Solano (Worcester Polytechnic Institute, USA) The Game Trace Archive Yong Guo (Delft University of Technology, The Netherlands); Alexandru Iosup (Delft University of Technology, The Netherlands) Are All Games Equally Cloud-Gaming-Friendly? An Electromyographic Approach Yeng-Ting Lee (National Taiwan University, Taiwan); Kuan-Ta Chen (Academia Sinica, Taiwan); Han-I Su (Institute of Information Science, Academia Sinica, Taiwan); Chin-Laung Lei (National Taiwan University, Taiwan) Generation of Synthetic Workloads for Peer-to-Peer Gaming Benchmarks Tonio Triebel (University of Mannheim, Germany); Max Lehn (Technische Universitat Darmstadt, Germany); Robert Rehner (Technische Universitat Darmstadt, Germany); Benjamin Guthier (University of Mannheim, Germany); Stephan Kopf (University of Mannheim, Germany); Wolfgang Effelsberg (University of Mannheim, Germany) Secure Peer-to-Peer Trading for Multiplayer Games Chris GauthierDickey (University of Denver, USA); Craig Ritzdorf (University of Denver, USA) The Brewing Storm in Cloud Gaming: A Measurement Study on Cloud to End-User Latency Sharon Choy (University of Waterloo, Canada); Bernard Wong (University of Waterloo, Canada); Gwendal Simon (Institut Telecom - Telecom Bretagne, France); Catherine Rosenberg (University of Waterloo, Canada) Foretelling Online Game Addictveness Jing-Kai Lou (National Taiwan University, Taiwan); Kuan-Ta Chen (Academia Sinica, Taiwan); Hwai-Jung Hsu (Academia Sinica, Taiwan); Chin-Laung Lei (National Taiwan University, Taiwan) B. Short Papers (Posters & Demos): ------------------------------- Managing Power for Closed-Source Android OS Games by Lightweight Graphics Instrumentation Benedikt Dietrich (Technical University of Munich, Germany); Samarjit Chakraborty (Technical University of Munich, Germany) Reducing Server Load in MMOG via P2P Gossip Emanuele Carlini (IMT, Italy); Laura Ricci (University of Pisa, Italy); Massimo Coppola (CNR, Italy) QoE Assessment of Fairness between Players in Networked Game with Olfaction Yutaka Ishibashi (Nagoya Institute of Technology, Japan); Sosuke Hoshino (Nagoya Institute of Technology, Japan); Qi Zeng (Nagoya Institute of Technology, Japan); Norishige Fukushima (Nagoya Institute of Technology, Japan); Shinji Sugawara (Nagoya Institute of Technology, Japan) Follow the Mob: an Innovative Approach for Roaming Characters in MMO Games Dario Maggiorini (University of Milano, Italy); Samuele Panzeri (University of Milano, Italy); Laura Anna Ripamonti (University of Milano, Italy) Towards a scalable refereeing system for online gaming Maxime Veron (LIP6, University of Pierre and Marie Curie, France); Olivier Marin (Lip6 - Inria, France); Sebastien Monnet (University of Pierre and Marie Curie, France); Zahia Guessoum (LIP6, , France) Satisfying the Hunger for Mobile Online Games: Providing Quality Time in Vehicular Scenarios Jose Saldana (University of Zaragoza, Spain); Gustavo Marfia (University of Bologna, Italy); Marco Roccetti (University of Bologna, Italy) Massively Multiplayer Online Games on Unreliable Resources Vlad Nae (University of Innsbruck, Austria); Lukas Kopfle (University of Innsbruck, Austria); Radu Prodan (University of Innsbruck, Austria); Alexandru Iosup (Delft University of Technology, The Netherlands) An empirical study of Cloud Gaming Marc Manzano (University of Girona, Spain); Jose Alberto Hernandez (Universidad Carlos III de Madrid, Spain); Manuel Uruena (Universidad Carlos III de Madrid, Spain); Eusebi Calle (University of Girona, Spain) The Revolution of StarCraft Network Traffic Choong-Soo Lee (Gustavus Adolphus College, USA) Success Factors of Events in Virtual Worlds - A Case Study in Second Life Michael Steurer (Graz University of Technology, Austria); Christoph Trattner (Graz University of Technology, Austria) From henk@uijterwaal.nl Mon Oct 29 07:29:21 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754D121F8553 for ; Mon, 29 Oct 2012 07:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 o7wLq8sqRXU6 for ; Mon, 29 Oct 2012 07:29:20 -0700 (PDT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8CD21F8526 for ; Mon, 29 Oct 2012 07:29:20 -0700 (PDT) Received: from geir.local ([80.187.201.44]) (authenticated bits=0) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9TESigi091643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Oct 2012 15:28:48 +0100 (CET) (envelope-from henk@uijterwaal.nl) Message-ID: <508E929A.6050408@uijterwaal.nl> Date: Mon, 29 Oct 2012 15:28:42 +0100 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: IETF IPPM WG References: <5087973A.3030400@uijterwaal.nl> In-Reply-To: <5087973A.3030400@uijterwaal.nl> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [ippm] Draft agenda 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, 29 Oct 2012 14:29:21 -0000 IPPM group, > Below is the draft agenda for Atlanta. Comments welcome. Please note that we > have a very full agenda so stick to the assigned times. I'm looking for a > note-taker. There have been no comments so this agenda is now final. I'm still looking for a note-taker and a jabber scribe. Also, neither one of the chairs can make it to Atlanta, so I'm looking for somebody who can chair the meeting as well. Henk > > Henk > > - - - - - - > > > Draft Agenda for IPPM @ IETF 85. > ================================ > > 0. Administrativia (5') > > 1. Advanced Stream and Sampling Framework. (10') > Al Morton, Joachim Fabini > draft-morton-ippm-2330-update-00.txt > > 2. Passive and Hybrid Measurements using IPPM Metrics (15') > Brian Trammell > draft-trammell-ippm-hybrid-ps-00.txt > > 3. Model Based Internet Performance Metrics (10') > Matt Mathis > draft-mathis-ippm-model-based-metrics-00.txt > > 4. Curating Internet Measurement Data (10') > Matt Mathis > draft-mathis-ippm-data-curation-00.txt > > 5. Network Performance Measurements for IPsec (10') > Yang Cui > draft-bi-ippm-ipsec-01.txt > > 6. Flow-based Performance Measurement (10') > Yu Fang > draft-sun-ippm-flowbased-pm-00.txt > > 7. Rate Measurement Problem statement draft (5') > Al Morton > draft-… > > 8. RFC 2679-bis (10') > Al Morton > > 9. AOB (5') > > Speakers: please submit slides before the meeting. Note that the timeslot > includes time for discussion afterwards, that is, if you have 10 minutes, > prepare to speak for about 7 and leave 3 for questions and answers. > -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ Read my blog at http://www.uijterwaal.nl/henks_hands.html From mattmathis@google.com Mon Oct 29 18:53:03 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0956821F8540 for ; Mon, 29 Oct 2012 18:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.118 X-Spam-Level: X-Spam-Status: No, score=-101.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxMp5w0icQub for ; Mon, 29 Oct 2012 18:53:02 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A7EFF21F84BF for ; Mon, 29 Oct 2012 18:53:01 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2933258wgb.13 for ; Mon, 29 Oct 2012 18:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=T3c0G+WXVQjz8VykSehpDcLOS0wpw2s5zwPiAf+uMic=; b=chW/vd43ktP3Fee2by6clPA50oQi5L3lmKkg8/ychdfa7mVgJFZrg6Kd+gla66iGL8 V1+b3u41j2mwKg2thw5NSUVudh7DP46e4ELd3sq00CCnTZOnfv0OjDBUJzg4dzw/G4pB CfDBwMrkBF7Ao3+Jj2NKcBBbBDr+L3Cg6IDxXtLweudXtS4TnpA4wgT2093fffP+rvv6 Y3p43jTn77L4F+Lr6vcSvfLBVS26A8HTruNAnDGWG/ttiMvWEiPO65NsFqsnqgKQH7qg duzsx0shodMUB5o/vuHHB74QUMNNEXLZQI8IYewTZ9afsm0kZtW4PEi51oZtohQyO3aT C1Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=T3c0G+WXVQjz8VykSehpDcLOS0wpw2s5zwPiAf+uMic=; b=S82jGTLYKQHoSBSIZNtu0jjLs9M8ioQtsX66JBiRhnNNLuSdx3WwYtELcIPt7Zvk+Q e5hfnJD1KIjF2UBN/qMRSF237jEObkuYHnittRjJbFLYPC9ERlq6/bO+fdiP2u4jfPqx 5d5CkA6sAmICGhcXbuoFN/wFQwfx0W2Otj9fALjQUQhMnHq7m5g3ZgoLSXrXlkjIihdT 3QphmWrsUvA03GgwQWvoG2GUJrqx8uGWOuy2qUJulQCSsGrGHAh1BhtwQD5lXS1NosEt wpMx7vzHlvvV4tgijCxlboLg6HFivfGgH2ZvkQwpE/HhZC7xwqxLQEbhbqyxNlrEJGbq byXQ== MIME-Version: 1.0 Received: by 10.216.214.209 with SMTP id c59mr16471492wep.214.1351561980675; Mon, 29 Oct 2012 18:53:00 -0700 (PDT) Received: by 10.194.37.97 with HTTP; Mon, 29 Oct 2012 18:53:00 -0700 (PDT) In-Reply-To: References: <5072F59A.50507@tuwien.ac.at> <5077BAD0.7080908@tuwien.ac.at> <7.0.1.0.0.20121012085911.04d2dc58@att.com> Date: Mon, 29 Oct 2012 18:53:00 -0700 Message-ID: From: Matt Mathis To: Ruediger.Geib@telekom.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQl85IOXLm2EdhGROwwOlrStdJ00Otut+TXIhTnJWPpLHfmkab4yWvcbqbkUke0bGTmOEr44Hl0HasAYDJgrub2TWCatZtmVlIwjBih0X75NFApMuA9epLQ8PFcwGC5CAtt6jBTGNVNOEFaqh/3WFdjYZKSBSEtaVamA0gIA47nmTuwgIiy5ra0ujcqgU8R05PtH94q1 Cc: acmorton@att.com, ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM 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, 30 Oct 2012 01:53:03 -0000 Can you provide more information about your Item #2? I am aware of a small number of examples of technical problems (i.e. bugs) that causes this sort of symptom, but it could also be premeditated white listing. (Consider device that tries to batch packets but has an inappropriate dwell timer when there are not enough for a full batch. Adding a little more traffic can cause a phase transition from one (short) batch on each timer tick to a more continuous streaming mode. I bet there are some DOCIS failure modes that resemble this as well. ) Yes your point is true: more stealthy active measurement would be good, as would ongoing passive measurement of real content delivery. This is why I work so hard on RFC 4898. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, Oct 22, 2012 at 11:59 PM, wrote: > Matt, > > whether or not the behaviour I've heard of is caused by a power user, > I don't know. I think, families having access to the Internet may > be regarded as power users, if consumption of streaming content > grows. And that's a present trend for sure. > > I quote from a blog: > > Reactive part 1: > Since a few days, the customer of a cable provider sees a packet-burst > and then nothing for a second (TCP dump). The author claims neither > to be a file sharer, nor to be consuming more than the daily maximum > byte budget given by the contract. > > Reactive part 2: > The author plays around, once hitting a URL containing "/speedtest/". > It's a 100 MB file download. While this runs, a different parallel > download increases from 300 kB/s to 1,2 MB/s. Once the speedtest > finishes, the parallel download is back to 300 kB/s again. > > The author further claims to have seen reports from other > companies behaving similar. > > End of quote. > > I'm not interested in metrics to detect the above reactive behaviour. > I'm interested in metrics capturing the standard performance as > perceived by end-systems. That seems to be a reasonable way to > compare things. A consequence, if any, may be to avoid > easy detection of measurements. > > Regards, > > R=FCdiger > > > -----Original Message----- > From: Matt Mathis [mailto:mattmathis@google.com] > > Good question. I hadn't considered poor performance as a possible > penalty for "bad surfing behavior", but it certainly is. I think we > can keep the longer timescale issues in mind, but the real point is to > improve measurement repeatability at shorter timescales e.g. session > history. > > A slightly different question is over what timescale do things shift? > If I transition from idle to heavy use, how long does it take to > transition into a "power user" policy bin? (Put another way, what is > the averaging timescale?) > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat > privacy and security as matters of life and death, because for some > users, they are. > > > On Mon, Oct 22, 2012 at 3:38 AM, wrote: >> Al, Joachim and Matt, >> >> it just came to my mind, whether we need to narrow down "reactive networ= k >> behaviour" or whether >> it stays undefined. >> >> reactive could a network behave: >> - based on the history of and current local load conditions >> - on user behaviour >> # in terms of load in general >> # in terms of visited online content >> # in terms of payload contents >> >> To be more precise, active bandwidth throtteling or flow suppression may= be >> regarded as "reactive >> network behaviour" too. >> >> Regards, >> >> R=FCdiger >> >> ________________________________ >> From: Al Morton [mailto:acmorton@att.com] >> Sent: Friday, October 12, 2012 3:43 PM >> To: Joachim Fabini; Matt Mathis; Geib, R=FCdiger >> >> Cc: ippm@ietf.org >> Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM >> >> R=FCdiger and Matt, >> >> Thanks for your review and comments so far. >> I'll just add two points below (one to help define >> "actionable" in the way that I think of it). >> >> regards, >> Al >> >> At 02:38 AM 10/12/2012, Joachim Fabini wrote: >> >> On 12.10.2012 04:35, Matt Mathis wrote: >> >> I think this is a really good start. >> >> >> Thank you. >> >> +1, we've had this in-progress for months, great to get feedback now. >> >> ... >> >> One other item for 2330: in the list of metric criteria, we failed to >> include "actionable" - some of the existing metrics don't provide any >> guidance for somebody who is unhappy with the results. Although >> "actionable" might be considered to be a sub item of "meaningful", >> some existing metrics don't do so well, even though they have well >> defined meanings. >> >> >> RFC 2330 defines extensibility, which (combined with repeatability) imo = fits >> pretty much what you describe as "actionable". The solution which we are >> currently preferring is to find/define a set of metrics which can assess= a) >> repeatability and b) extensibility of a measurement methodology. E.g., u= sing >> measurement samples of one or two subsequent measurement scenarios (metr= ic & >> methodology) as input, these metrics should provide hints if 1) there is= a >> likelihood of repeatability and 2) we can extend measurement results to >> other scenarios/parameters - in the sense of metric linearity for a spec= ific >> methodology. >> Perhaps even more important and easier to realize is a metric output tha= t >> properties 1) and 2) are NOT fulfilled. >> >> >> We (network operators) always have "actionable" as a goal, >> meaning that the measurement results combined with some interpretation >> should lead the design or maintenance forces to their next steps >> (to improve performance or repair a problem). We move a long >> way toward the goal by selecting the right metrics from the start. >> >> All of our/user packet streams are influenced by a growing number of >> reactive network components, maintaining and changing state. >> It's matter-of-fact for most user flows. In reactive nets we can use >> discovery, characterization, and with on-going measurements, expectation= , >> to help determine if there is a fault or other undesirable condition >> and what network elements may be involved. If the measurements really >> help to narrow-down the problem space, they are considered "actionable". >> >> So, I agree this is a useful consideration to add-in/update RFC 2330. >> >> As Joachim mentioned, this expansion of the stream framework is >> intended to address various forms of reactive networks, and certainly >> includes wired networks today. The concept of pre-load (as Matt called i= t) >> is important to any test path that includes a firewall. This >> aspect is an important consideration in the LMAP requirements: >> http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 >> and probably also the project described in IEEE 802.16 Liaison: >> https://datatracker.ietf.org/liaison/1195/ >> There is almost certainly some overlap between our draft and >> the intent of latter project. From Ruediger.Geib@telekom.de Tue Oct 30 00:48:04 2012 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E7F21F841A for ; Tue, 30 Oct 2012 00:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKVSyQCUa+m1 for ; Tue, 30 Oct 2012 00:48:03 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 5B79A21F84A0 for ; Tue, 30 Oct 2012 00:48:02 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 30 Oct 2012 08:47:01 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 30 Oct 2012 08:46:54 +0100 From: To: Date: Tue, 30 Oct 2012 08:46:52 +0100 Thread-Topic: [ippm] Advanced Stream and Sampling Framework for IPPM Thread-Index: Ac22QVu8cOKSf3SbTLGOlCQfPG+LvAALqVPg Message-ID: References: <5072F59A.50507@tuwien.ac.at> <5077BAD0.7080908@tuwien.ac.at> <7.0.1.0.0.20121012085911.04d2dc58@att.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: acmorton@att.com, ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM 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, 30 Oct 2012 07:48:04 -0000 Matt, the information was translated from a German Blog (the author is not related to me personally). There's little to add: The blog starts with "since a few days my download rates broke down". The author performed the speedtest with a speed limit on it (10 kB/s and 100 kB/s), but the download bandwidth increase of the parallel download was less significant then. The blog is about one cable provider. A second one is mentioned and a third company, which is a city provider. I don't know whether the latter two behave exactly like the former. I also don't know whether the city provider runs DOCSIS. All in all, the blog has just 20 lines. Regards, R=FCdiger -----Original Message----- From: Matt Mathis [mailto:mattmathis@google.com] Sent: Tuesday, October 30, 2012 2:53 AM To: Geib, R=FCdiger Cc: acmorton@att.com; Joachim.Fabini@tuwien.ac.at; ippm@ietf.org Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM Can you provide more information about your Item #2? I am aware of a small number of examples of technical problems (i.e. bugs) that causes this sort of symptom, but it could also be premeditated white listing. (Consider device that tries to batch packets but has an inappropriate dwell timer when there are not enough for a full batch. Adding a little more traffic can cause a phase transition from one (short) batch on each timer tick to a more continuous streaming mode. I bet there are some DOCIS failure modes that resemble this as well. ) Yes your point is true: more stealthy active measurement would be good, as would ongoing passive measurement of real content delivery. This is why I work so hard on RFC 4898. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, Oct 22, 2012 at 11:59 PM, wrote: > Matt, > > whether or not the behaviour I've heard of is caused by a power user, > I don't know. I think, families having access to the Internet may > be regarded as power users, if consumption of streaming content > grows. And that's a present trend for sure. > > I quote from a blog: > > Reactive part 1: > Since a few days, the customer of a cable provider sees a packet-burst > and then nothing for a second (TCP dump). The author claims neither > to be a file sharer, nor to be consuming more than the daily maximum > byte budget given by the contract. > > Reactive part 2: > The author plays around, once hitting a URL containing "/speedtest/". > It's a 100 MB file download. While this runs, a different parallel > download increases from 300 kB/s to 1,2 MB/s. Once the speedtest > finishes, the parallel download is back to 300 kB/s again. > > The author further claims to have seen reports from other > companies behaving similar. > > End of quote. > > I'm not interested in metrics to detect the above reactive behaviour. > I'm interested in metrics capturing the standard performance as > perceived by end-systems. That seems to be a reasonable way to > compare things. A consequence, if any, may be to avoid > easy detection of measurements. > > Regards, > > R=FCdiger > > > -----Original Message----- > From: Matt Mathis [mailto:mattmathis@google.com] > > Good question. I hadn't considered poor performance as a possible > penalty for "bad surfing behavior", but it certainly is. I think we > can keep the longer timescale issues in mind, but the real point is to > improve measurement repeatability at shorter timescales e.g. session > history. > > A slightly different question is over what timescale do things shift? > If I transition from idle to heavy use, how long does it take to > transition into a "power user" policy bin? (Put another way, what is > the averaging timescale?) > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat > privacy and security as matters of life and death, because for some > users, they are. > > > On Mon, Oct 22, 2012 at 3:38 AM, wrote: >> Al, Joachim and Matt, >> >> it just came to my mind, whether we need to narrow down "reactive networ= k >> behaviour" or whether >> it stays undefined. >> >> reactive could a network behave: >> - based on the history of and current local load conditions >> - on user behaviour >> # in terms of load in general >> # in terms of visited online content >> # in terms of payload contents >> >> To be more precise, active bandwidth throtteling or flow suppression may= be >> regarded as "reactive >> network behaviour" too. >> >> Regards, >> >> R=FCdiger >> >> ________________________________ >> From: Al Morton [mailto:acmorton@att.com] >> Sent: Friday, October 12, 2012 3:43 PM >> To: Joachim Fabini; Matt Mathis; Geib, R=FCdiger >> >> Cc: ippm@ietf.org >> Subject: Re: [ippm] Advanced Stream and Sampling Framework for IPPM >> >> R=FCdiger and Matt, >> >> Thanks for your review and comments so far. >> I'll just add two points below (one to help define >> "actionable" in the way that I think of it). >> >> regards, >> Al >> >> At 02:38 AM 10/12/2012, Joachim Fabini wrote: >> >> On 12.10.2012 04:35, Matt Mathis wrote: >> >> I think this is a really good start. >> >> >> Thank you. >> >> +1, we've had this in-progress for months, great to get feedback now. >> >> ... >> >> One other item for 2330: in the list of metric criteria, we failed to >> include "actionable" - some of the existing metrics don't provide any >> guidance for somebody who is unhappy with the results. Although >> "actionable" might be considered to be a sub item of "meaningful", >> some existing metrics don't do so well, even though they have well >> defined meanings. >> >> >> RFC 2330 defines extensibility, which (combined with repeatability) imo = fits >> pretty much what you describe as "actionable". The solution which we are >> currently preferring is to find/define a set of metrics which can assess= a) >> repeatability and b) extensibility of a measurement methodology. E.g., u= sing >> measurement samples of one or two subsequent measurement scenarios (metr= ic & >> methodology) as input, these metrics should provide hints if 1) there is= a >> likelihood of repeatability and 2) we can extend measurement results to >> other scenarios/parameters - in the sense of metric linearity for a spec= ific >> methodology. >> Perhaps even more important and easier to realize is a metric output tha= t >> properties 1) and 2) are NOT fulfilled. >> >> >> We (network operators) always have "actionable" as a goal, >> meaning that the measurement results combined with some interpretation >> should lead the design or maintenance forces to their next steps >> (to improve performance or repair a problem). We move a long >> way toward the goal by selecting the right metrics from the start. >> >> All of our/user packet streams are influenced by a growing number of >> reactive network components, maintaining and changing state. >> It's matter-of-fact for most user flows. In reactive nets we can use >> discovery, characterization, and with on-going measurements, expectation= , >> to help determine if there is a fault or other undesirable condition >> and what network elements may be involved. If the measurements really >> help to narrow-down the problem space, they are considered "actionable". >> >> So, I agree this is a useful consideration to add-in/update RFC 2330. >> >> As Joachim mentioned, this expansion of the stream framework is >> intended to address various forms of reactive networks, and certainly >> includes wired networks today. The concept of pre-load (as Matt called i= t) >> is important to any test path that includes a firewall. This >> aspect is an important consideration in the LMAP requirements: >> http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 >> and probably also the project described in IEEE 802.16 Liaison: >> https://datatracker.ietf.org/liaison/1195/ >> There is almost certainly some overlap between our draft and >> the intent of latter project.