From Michael.K.Bugenhagen@centurylink.com Mon Feb 3 13:35:58 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEAF1A0218 for ; Mon, 3 Feb 2014 13:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_72=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gPjz8Hvq3LB for ; Mon, 3 Feb 2014 13:35:56 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9C48F1A01EE for ; Mon, 3 Feb 2014 13:35:56 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s13LZq2M017874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 15:35:52 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E10E51E007D; Mon, 3 Feb 2014 14:35:46 -0700 (MST) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 64B1D1E004E; Mon, 3 Feb 2014 14:35:46 -0700 (MST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s13LZjYd016194; Mon, 3 Feb 2014 15:35:45 -0600 (CST) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s13LZjaG016146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 15:35:45 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Mon, 3 Feb 2014 15:35:44 -0600 From: "Bugenhagen, Michael K" To: "'philip.eardley@bt.com'" , "'jason.weil@twcable.com'" , "'lmap@ietf.org'" Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-03.txt Thread-Index: AQHPF6lkpKaRO52wi06xG76zWW/L+ZqUKP8AgA/2p7A= Date: Mon, 3 Feb 2014 21:35:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:35:58 -0000 Phil, I don't see the 2 critical actions detailed out at in this draft that = =20 1) Would get the MA the "in use" information from the Line 2) Would get the current speed profile / state of the service from the ISP= . =20 Is the intent to add those API / Interfaces later - I thought that would= be part of the larger framework vs. smaller details that would come later = in the game. Thanks, Mike -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Friday, January 24, 2014 5:46 AM To: jason.weil@twcable.com; lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framew= ork-03.txt Jason, Thanks for your comments and careful reading In-line phil > -----Original Message----- > From: Weil, Jason [mailto:jason.weil@twcable.com] > Sent: 22 January 2014 19:37 > To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-=20 > framework-03.txt >=20 > Phil et al, >=20 > Overall I think the document is coming together nicely. I have 3=20 > comments after reading the latest version with chair hat removed: >=20 > Section 5.1 - It is not clear what role and scope the Initial=20 > Controller plays. Is this a new device type/function - does it need to=20 > be described somewhere other than a cursory glance that is presented=20 > here - or does this represent a device that is part of the bootstrap=20 > operation that is out of scope? It is not very clear here. Maybe=20 > rename to Bootstrap Controller instead? I think you're right that this section isn't very clear.=20 To my mind, we're simply trying to say that the bootstrap process isn't one= we're going to define but it needs to get the MA-id, maybe a group-id and = details of the various channels. And here are some options about how to get= the info on the MA. i think it would be better to scrap the picture - as i= t will be read as implying we're defining things that we aren't. One other possibility that we should mention: The bootstrapping information might be configured on the MA.=20 (Marcelo mentioned this during our editing, sorry I forgot to include it)=20 >=20 > Section 5.2.1 & 5.3 These sections seem to contradict each other=20 > slightly. > Suppression seems to imply that the Controller is capable of actively=20 > managing the MA. This includes the challenges stated in Section 6.2.2. > I am wondering if we should state optional or if required contingent=20 > on transport protocol operation? Section 5.3 then goes on to say that=20 > the MA acts autonomously once it receives the Measurement and Report=20 > Schedules from the Controller. This sentence seems to contradict 5.2.1=20 > operation. You're right that the MA "acts autonomously" should have a supplement "unti= l it gets a new Instruction (including perhaps an Instruction about Measure= ment Suppression)"=20 I don't think suppression should be optional (to implement). It seems a ver= y useful capability.=20 I agree that if the MA is behind a NAT, then that presents issues for how l= map operates over the transport protocol - but I don't think they're differ= ent for suppression & the ordinary instruction.=20 >=20 > Section 6.2 - "A single site (home, branch office etc.) that is=20 > participating in a measurement could make use of one or multiple=20 > Measurement Agents in a single measurement." > This concept needs more details if it is going to be included I=20 > believe. > How does a measurement task employ multiple MAs for a single test? > Which MA is responsible for reporting the results? Is there some kind=20 > of master/slave function implied here or is Group-ID tie these devices=20 > together? Would all the MAs participating in this test group need to=20 > be associated with the same controller and does that controller need=20 > to be aware of the group? Does the Collector need to be aware of the=20 > test group as well? I think that's a mistake. It shouldn't mention the possibility of multiple = MAs.=20 If I remember a discussion quite a while ago, we agreed that if you want a = multi agent test, then it would be up to you to define two Measurement Task= s and schedule them at the same time - but that wouldn't be a concern of lm= ap. Thanks! phil >=20 >=20 > Thanks, >=20 > Jason >=20 >=20 > On 1/21/14 10:00 AM, "philip.eardley@bt.com" > wrote: >=20 > >We submitted a new version of the framework document. > > > >http://tools.ietf.org/html/draft-ietf-lmap-framework > > > >Here's a summary of the changes: > > o alignment with the Information Model > > [I-D.burbridge-lmap-information-model] as this is agreed as a WG > > document > > > > o One-off and periodic Measurement Schedules are kept separate, so > > that they can be updated independently > > > > o Measurement Suppression in a separate sub-section. Can now > > optionally include particular Measurement Tasks &/or Schedules > to > > suppress, and start/stop time > > > > o for clarity, concept of Channel split into Control, Report and > MA- > > to-Controller Channels > > > > o numerous editorial changes, mainly arising from a very detailed > > review by Charles Cook > > > >best wishes, > >phil, al, marcelo, trevor, paul, aamer > > > >_______________________________________________ > >lmap mailing list > >lmap@ietf.org > >https://www.ietf.org/mailman/listinfo/lmap >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable=20 > proprietary information, which is privileged, confidential, or subject=20 > to copyright belonging to Time Warner Cable. This E-mail is intended=20 > solely for the use of the individual or entity to which it is=20 > addressed. If you are not the intended recipient of this E-mail, you=20 > are hereby notified that any dissemination, distribution, copying, or=20 > action taken in relation to the contents of and attachments to this E-=20 > mail is strictly prohibited and may be unlawful. If you have received=20 > this E-mail in error, please notify the sender immediately and=20 > permanently delete the original and any copy of this E-mail and any=20 > printout. _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From dromasca@avaya.com Wed Feb 5 02:37:38 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C211A00D3 for ; Wed, 5 Feb 2014 02:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frOw5sjoIfSA for ; Wed, 5 Feb 2014 02:37:36 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE831A00CB for ; Wed, 5 Feb 2014 02:37:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8IABQU8lKHCzI1/2dsb2JhbABZgkgjIThXqEKWAYELFnSCJwEBAxILEF4BDAkVViYBBBsah2MBDJ4ahFKrehMEjkQtgjoPZoEUBJ8bizGDLYIq X-IronPort-AV: E=Sophos;i="4.95,786,1384318800"; d="scan'208,217";a="41743142" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Feb 2014 05:37:34 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 05 Feb 2014 05:24:36 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 5 Feb 2014 11:37:13 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: lmap wg meeting at ietf-89 - call for agenda items Thread-Index: Ac8iXjpOU7HXH/+9TjC/y6Fd8yxEBg== Date: Wed, 5 Feb 2014 10:37:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E3EC7C9@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7C9AZFFEXMB04globa_" MIME-Version: 1.0 Subject: [lmap] lmap wg meeting at ietf-89 - call for agenda items X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 10:37:38 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7C9AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The preliminary agenda at https://datatracker.ietf.org/meeting/89/agenda.tx= t shows the WG meeting scheduled for Friday 3/7 in the 900-1130 meeting slo= t. Note that this scheduling is subject to change. If you plan to present and discuss your work at the meeting please send us = your agenda request including the topic, name of the relevant I-D or I-Ds a= nd the estimated time. Items which are part of the WG charter have higher p= riority, non-chartered items will be included if time allows. Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7C9AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The preliminary agenda at https://datatracker.ietf.org/meeting/89/agenda.txt shows the WG meeting= scheduled for Friday 3/7 in the 900-1130 meeting slot. Note that this sche= duling is subject to change.

 

If you plan to present and discuss your work at the = meeting please send us your agenda request including the topic, name of the= relevant I-D or I-Ds and the estimated time. Items which are part of the W= G charter have higher priority, non-chartered items will be included if time allows.

 

Thanks and Regards,

 

Jason and Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7C9AZFFEXMB04globa_-- From charles.cook2@centurylink.com Wed Feb 5 09:40:59 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A101A0137 for ; Wed, 5 Feb 2014 09:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnKU_7dDezOR for ; Wed, 5 Feb 2014 09:40:55 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4C42F1A0122 for ; Wed, 5 Feb 2014 09:40:55 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s15Henk4017064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Feb 2014 11:40:50 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 65A341E0069; Wed, 5 Feb 2014 11:40:44 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 11B311E0073; Wed, 5 Feb 2014 11:40:44 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s15Hegq1011621; Wed, 5 Feb 2014 11:40:43 -0600 (CST) Received: from [10.188.235.119] (x1069818.dhcp.intranet [10.188.235.119]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s15Hecqw011528; Wed, 5 Feb 2014 11:40:38 -0600 (CST) Message-ID: <52F27795.5040108@centurylink.com> Date: Wed, 05 Feb 2014 10:40:37 -0700 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: philip.eardley@bt.com References: <20140121145650.5390.63718.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/mixed; boundary="------------040908070909070104050301" X-CFilter-Loop: Reflected Cc: lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: charles.cook2@centurylink.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 17:40:59 -0000 This is a multi-part message in MIME format. --------------040908070909070104050301 Content-Type: multipart/alternative; boundary="------------070702020300000102080201" --------------070702020300000102080201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phil, I like the improvements over the previous version. I did not have many additional comments on this draft. Attached is my marked up review. The main comments I had are as follows In summary: * *Conflict Resolution: * If two or more Measurement Tasks overlap in their schedule, how should the MA behave? If two or more Measurement Tasks are scheduled to start at the same time, the first one listed in the set of Measurement Schedules can be run first. When complete, the conflicting Measurement Task can be run. If the Measurement Schedules overlap, but are not scheduled to start at the same time, run the one scheduled to start first to completion, and then run the overlapping Measurement Schedule. The Results Report should contain a start and stop time stamp that can be used in post processing. Note: Some Measurement Tasks may be able to run in parallel without impacting the Results of other Measurement Tasks. In this case, scheduling conflicts are not an issue. But these will need to be will defined ahead of time. * *MA Performing Pre-processing:* I don't think that the MA should perform pre-processing unless specifically instructed to do so in a Measurement Method. The MA should provide enough detail in the Measurement Result to enable post processing. Any Measurement Methods with pre-processing will need to be very carefully constructed to ensure that the results are repeatable/comparable. * *MP Registration and Suppression:* MPs also need to Register with the Controller so that the Controller knows they exist. The Controller will also need to know the capabilities of the MP, and also have the ability to Suppress/Unsuppress the MP as needed. I didn't see this in the draft. We just need to add it. * *Underlying Transport Protocol:* Push and/or Pull: The LMAP Framework identifies Push and Pull as possible underlying transport protocols, but does not specify a requirement. A discussion is needed to determine if one or both of these are required for the Framework. It sounds like Push is preferred in general, but Pull may be needed in order to perform a Measurement Task when the MA or MP is behind a NAT. Additional details are needed. For example should a Controller, in addition to Pushing out Instructions, provide a mechanism for an MA to Pull an Instruction if the MA is behind a NAT? If a MA or MP is behind a NAT, should it execute a keep-alive so that the Controller knows where it is at? Great work. Charles On 1/21/2014 8:00 AM, philip.eardley@bt.com wrote: > We submitted a new version of the framework document. > > http://tools.ietf.org/html/draft-ietf-lmap-framework > > Here's a summary of the changes: > o alignment with the Information Model > [I-D.burbridge-lmap-information-model] as this is agreed as a WG > document > > o One-off and periodic Measurement Schedules are kept separate, so > that they can be updated independently > > o Measurement Suppression in a separate sub-section. Can now > optionally include particular Measurement Tasks &/or Schedules to > suppress, and start/stop time > > o for clarity, concept of Channel split into Control, Report and MA- > to-Controller Channels > > o numerous editorial changes, mainly arising from a very detailed > review by Charles Cook > > best wishes, > phil, al, marcelo, trevor, paul, aamer > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com --------------070702020300000102080201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phil,

I like the improvements over the previous version.  I did not have many additional comments on this draft.  Attached is my marked up review. 

The main comments I had are as follows In summary:
  • Conflict Resolution:   If two or more Measurement Tasks overlap in their schedule, how should the MA behave?  If two or more Measurement Tasks are scheduled to start at the same time, the first one listed in the set of Measurement Schedules can be run first.  When complete, the conflicting Measurement Task can be run.  If the Measurement Schedules overlap, but are not scheduled to start at the same time, run the one scheduled to start first to completion, and then run the overlapping Measurement Schedule.  The Results Report should contain a start and stop time stamp that can be used in post processing.  Note:  Some Measurement Tasks may be able to run in parallel without impacting the Results of other Measurement Tasks.  In this case, scheduling conflicts are not an issue.  But these will need to be will defined ahead of time. 
  • MA Performing Pre-processing:  I don't think that the MA should perform pre-processing unless specifically instructed to do so in a Measurement Method.  The MA should provide enough detail in the Measurement Result to enable post processing.  Any Measurement Methods with pre-processing will need to be very carefully constructed to ensure that the results are repeatable/comparable.
  • MP Registration and Suppression:  MPs also need to Register with the Controller so that the Controller knows they exist.  The Controller will also need to know the capabilities of the MP, and also have the ability to Suppress/Unsuppress the MP as needed.  I didn't see this in the draft.  We just need to add it.
  • Underlying Transport Protocol:  Push and/or Pull:  The LMAP Framework identifies Push and Pull as possible underlying transport protocols, but does not specify a requirement.  A discussion is needed to determine if one or both of these are required for the Framework.  It sounds like Push is preferred in general, but Pull may be needed in order to perform a Measurement Task when the MA or MP is behind a NAT.  Additional details are needed.  For example should a Controller, in addition to Pushing out Instructions, provide a mechanism for an MA to Pull an Instruction if the MA is behind a NAT?  If a MA or MP is behind a NAT, should it execute a keep-alive so that the Controller knows where it is at?

Great work.

Charles


On 1/21/2014 8:00 AM, philip.eardley@bt.com wrote:
We submitted a new version of the framework document.

http://tools.ietf.org/html/draft-ietf-lmap-framework 

Here's a summary of the changes:
   o  alignment with the Information Model
      [I-D.burbridge-lmap-information-model] as this is agreed as a WG
      document

   o  One-off and periodic Measurement Schedules are kept separate, so
      that they can be updated independently

   o  Measurement Suppression in a separate sub-section.  Can now
      optionally include particular Measurement Tasks &/or Schedules to
      suppress, and start/stop time

   o  for clarity, concept of Channel split into Control, Report and MA-
      to-Controller Channels

   o  numerous editorial changes, mainly arising from a very detailed
      review by Charles Cook

best wishes,
phil, al, marcelo, trevor, paul, aamer

_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap


-- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
charles.cook2@centurylink.com
--------------070702020300000102080201-- --------------040908070909070104050301 Content-Type: application/msword; name="draft-ietf-lmap-framework-03_cc.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-lmap-framework-03_cc.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAEAAAAlwEAAAAA AAAAEAAAmQEAAAEAAAD+////AAAAAJMBAACUAQAAlQEAAJYBAAD///////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEABYAJBAAA8BK/AAAAAAAAEAAAAAAACAAA v7ABAA4AYmpialfZV9kAAAAAAAAAAAAAAAAAAAAAAAAJBBYANIwCADWzAQA1swEAMZsBAAAA AAAAAAAAAAAAAI0NAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAALcAAAAAAMgMAAAAAAAAyAwAAAsaAAAAAAAACxoAAAAAAAA1GgAA 8AIAALEeAABgAAAAER8AABQAAAAAAAAAAAAAAP////8AAAAAJR8AAAAAAAAlHwAAAAAAACUf AAAAAAAAJR8AADwAAABhHwAANAMAACUfAAAAAAAAG2MAAKYBAACVIgAAAAAAAJUiAAAAAAAA lSIAAAAAAACVIgAAAAAAAJUiAAAAAAAAcCMAAAAAAABwIwAAAAAAAHAjAAAAAAAAZGIAAAIA AABmYgAAAAAAAGZiAAAAAAAAZmIAAAAAAABmYgAAAAAAAGZiAAAAAAAAZmIAACQAAADBZAAA ogIAAGNnAAB6AAAAimIAABUAAAAAAAAAAAAAAAAAAAAAAAAACxoAACoAAABwIwAADgEAAAAA AAAAAAAAAAAAAAAAAABwIwAAAAAAAHAjAAAAAAAAfiQAALQAAAAyJQAAXAAAAIpiAAAAAAAA AAAAAAAAAAALGgAAAAAAAAsaAAAAAAAAlSIAAAAAAAAAAAAAAAAAAJUiAADbAAAAn2IAAEAA AAA6YQAAAAAAADphAAAAAAAAOmEAAAAAAACOJQAAQAkAAAsaAAAAAAAAlSIAAAAAAAALGgAA AAAAAJUiAAAAAAAAZGIAAAAAAAAAAAAAAAAAADphAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcCMAAAAAAABkYgAAAAAAAAAAAAAAAAAA OmEAAAAAAAAAAAAAAAAAADphAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOmEAAAAAAACVIgAA AAAAAP////8AAAAA4CMsvJMizwEAAAAAAAAAACUfAAAAAAAAzi4AAD4yAAA6YQAAAAAAAAAA AAAAAAAAUGIAABQAAADfYgAAPAAAABtjAAAAAAAAOmEAAAAAAADdZwAAAAAAAAxhAAAuAAAA 3WcAAAAAAAA6YQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6YQAANgAAAN1nAAAAAAAAAAAAAAAAAAAlHQAA jAEAAHBhAADgAAAAcCMAAAAAAABwIwAAAAAAADphAAAAAAAAcCMAAAAAAABwIwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcCMAAAAAAABwIwAAAAAAAHAjAAAAAAAA imIAAAAAAACKYgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOmEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAjAAAAAAAAcCMAAAAAAABwIwAA AAAAABtjAAAAAAAAcCMAAAAAAABwIwAAAAAAAHAjAAAAAAAAcCMAAAAAAAAAAAAAAAAAAP// //8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAA AAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAN1nAAAAAAAAcCMAAAAAAABwIwAA AAAAAHAjAAAAAAAAcCMAAAAAAABwIwAAAAAAAHAjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwIwAAAAAAAHAjAAAAAAAA cCMAAAAAAADIDAAACQwAANEYAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFAuIEVhcmRsZXkNSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEJUDUludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEEuIE1vcnRvbg1FeHBpcmVzOiBKdWx5IDI1LCAyMDE0ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBVCZUIExhYnMNICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBN LiBCYWdudWxvDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgVUMzTQ0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBULiBCdXJicmlkZ2UNICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEJUDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFAuIEFpdGtlbg0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBBa2h0ZXINICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBDaXNjbyBTeXN0ZW1zDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMSwgMjAxNA0NDSAgICAgICAgQSBmcmFtZXdv cmsgZm9yIGxhcmdlLXNjYWxlIG1lYXN1cmVtZW50IHBsYXRmb3JtcyAoTE1BUCkNICAgICAg ICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDMNDUFic3RyYWN0 DQ0gICBNZWFzdXJpbmcgYnJvYWRiYW5kIHNlcnZpY2Ugb24gYSBsYXJnZSBzY2FsZSByZXF1 aXJlcyBhIGRlc2NyaXB0aW9uDSAgIG9mIHRoZSBsb2dpY2FsIGFyY2hpdGVjdHVyZSBhbmQg c3RhbmRhcmRpc2F0aW9uIG9mIHRoZSBrZXkgcHJvdG9jb2xzDSAgIHRoYXQgY29vcmRpbmF0 ZSBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGUgY29tcG9uZW50cy4gIFRoZSBkb2N1bWVudA0g ICBwcmVzZW50cyBhbiBvdmVyYWxsIGZyYW1ld29yayBmb3IgbGFyZ2Utc2NhbGUgbWVhc3Vy ZW1lbnRzLiAgSXQgYWxzbw0gICBkZWZpbmVzIHRlcm1pbm9sb2d5IGZvciBMTUFQIChsYXJn ZS1zY2FsZSBtZWFzdXJlbWVudCBwbGF0Zm9ybXMpLg0NU3RhdHVzIG9mIFRoaXMgTWVtbw0N ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5j ZSB3aXRoIHRoZQ0gICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5Lg0NICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5n aW5lZXJpbmcNICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGUNICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt RHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0NICAgRHJhZnRzIGlzIGF0 IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uDQ0gICBJbnRl cm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IHNpeCBtb250aHMNICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xl dGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNICAgbWF0ZXJpYWwg b3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0NICAg VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKdWx5IDI1LCAyMDE0Lg0NQ29w eXJpZ2h0IE5vdGljZQ0NICAgQ29weXJpZ2h0IChjKSAyMDE0IElFVEYgVHJ1c3QgYW5kIHRo ZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDSAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwg cmlnaHRzIHJlc2VydmVkLg0NDQ0NDUVhcmRsZXksIGV0IGFsLiAgICAgICAgICAgRXhwaXJl cyBKdWx5IDI1LCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0NSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICBMTUFQIEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFudWFy eSAyMDE0DQ0NICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhl IElFVEYgVHJ1c3QncyBMZWdhbA0gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9j dW1lbnRzDSAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVm ZmVjdCBvbiB0aGUgZGF0ZSBvZg0gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAg UGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMNICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRl c2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0DSAgIHRv IHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBk b2N1bWVudCBtdXN0DSAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0gICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlz aW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMNICAgZGVzY3JpYmVk IGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLg0NVGFibGUgb2YgQ29udGVudHMNDSAg IDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgMw0gICAyLiAgT3V0bGluZSBvZiBhbiBMTUFQLWJhc2VkIG1lYXN1 cmVtZW50IHN5c3RlbSAuIC4gLiAuIC4gLiAuIC4gLiAgIDUNICAgMy4gIFRlcm1pbm9sb2d5 IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4 DSAgIDQuICBDb25zdHJhaW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMQ0gICAgIDQuMS4gIE1lYXN1cmVtZW50IHN5c3RlbSBpcyB1 bmRlciB0aGUgZGlyZWN0aW9uIG9mIGEgc2luZ2xlDSAgICAgICAgICAgb3JnYW5pc2F0aW9u ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMQ0gICAg IDQuMi4gIEVhY2ggTUEgbWF5IG9ubHkgaGF2ZSBhIHNpbmdsZSBDb250cm9sbGVyIGF0IGFu eSBwb2ludCBpbg0gICAgICAgICAgIHRpbWUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTINICAgNS4gIExNQVAgUHJvdG9jb2wgTW9k ZWwgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyDSAgICAg NS4xLiAgQm9vdHN0cmFwcGluZyBwcm9jZXNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxMw0gICAgIDUuMi4gIENvbnRyb2wgUHJvdG9jb2wgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTUNICAgICAgIDUuMi4xLiAgTWVhc3Vy ZW1lbnQgU3VwcHJlc3Npb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4DSAg ICAgNS4zLiAgU3RhcnRpbmcgYW5kIHN0b3BwaW5nIE1lYXN1cmVtZW50IFRhc2tzIC4gLiAu IC4gLiAuIC4gLiAuICAxOQ0gICAgIDUuNC4gIFJlcG9ydCBQcm90b2NvbCAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjANICAgICA1LjUuICBPcGVyYXRp b24gb2YgTE1BUCBvdmVyIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBwcm90b2NvbCAgIDIy DSAgICAgNS42LiAgSXRlbXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgTE1BUCBQcm90b2Nv bCBNb2RlbCAuIC4gLiAuICAyMw0gICAgICAgNS42LjEuICBFbmR1c2VyLWNvbnRyb2xsZWQg bWVhc3VyZW1lbnQgc3lzdGVtIC4gLiAuIC4gLiAuIC4gLiAgMjQNICAgNi4gIERlcGxveW1l bnQgY29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDI0DSAgICAgNi4xLiAgQ29udHJvbGxlciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAyNA0gICAgIDYuMi4gIE1lYXN1cmVtZW50IEFnZW50IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjUNICAgICAgIDYuMi4x LiAgTWVhc3VyZW1lbnQgQWdlbnQgZW1iZWRkZWQgaW4gc2l0ZSBnYXRld2F5ICAuIC4gLiAu IC4gIDI2DSAgICAgICA2LjIuMi4gIE1lYXN1cmVtZW50IEFnZW50IGVtYmVkZGVkIGJlaGlu ZCBzaXRlIE5BVCAvRmlyZXdhbGwgICAyNg0gICAgICAgNi4yLjMuICBNZWFzdXJlbWVudCBB Z2VudCBpbiBhIG11bHRpLWhvbWVkIHNpdGUgLiAuIC4gLiAuIC4gLiAgMjcNICAgICA2LjMu ICBNZWFzdXJlbWVudCBQZWVyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDI3DSAgIDcuICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNw0gICA4LiAgUHJpdmFjeSBDb25zaWRlcmF0 aW9ucyBmb3IgTE1BUCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjgNICAgICA4 LjEuICBDYXRlZ29yaWVzIG9mIEVudGl0aWVzIHdpdGggSW5mb3JtYXRpb24gb2YgSW50ZXJl c3QgLiAuIC4gIDI5DSAgICAgOC4yLiAgRXhhbXBsZXMgb2YgU2Vuc2l0aXZlIEluZm9ybWF0 aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyOQ0gICAgIDguMy4gIEtleSBEaXN0aW5j dGlvbiBCZXR3ZWVuIEFjdGl2ZSBhbmQgUGFzc2l2ZSBNZWFzdXJlbWVudA0gICAgICAgICAg IFRhc2tzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMzANICAgICA4LjQuICBQcml2YWN5IGFuYWx5c2lzIG9mIHRoZSBDb21tdW5pY2F0 aW9ucyBNb2RlbHMgLiAuIC4gLiAuIC4gIDMxDSAgICAgICA4LjQuMS4gIE1BIEJvb3RzdHJh cHBpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzMQ0gICAgICAg OC40LjIuICBDb250cm9sbGVyIDwtPiBNZWFzdXJlbWVudCBBZ2VudCAgLiAuIC4gLiAuIC4g LiAuIC4gLiAgMzINICAgICAgIDguNC4zLiAgQ29sbGVjdG9yIDwtPiBNZWFzdXJlbWVudCBB Z2VudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMzDSAgICAgICA4LjQuNC4gIE1lYXN1cmVt ZW50IFBlZXIgPC0+IE1lYXN1cmVtZW50IEFnZW50ICAuIC4gLiAuIC4gLiAuICAzMw0gICAg ICAgOC40LjUuICBQYXNzaXZlIE1lYXN1cmVtZW50IEFnZW50IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMzQNDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1 bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQ1JbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIw MTQNDQ0gICAgICAgOC40LjYuICBTdG9yYWdlIGFuZCBSZXBvcnRpbmcgb2YgTWVhc3VyZW1l bnQgUmVzdWx0cyAgLiAuIC4gLiAgMzUNICAgICA4LjUuICBUaHJlYXRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM1DSAgICAgICA4LjUu MS4gIFN1cnZlaWxsYW5jZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAzNg0gICAgICAgOC41LjIuICBTdG9yZWQgRGF0YSBDb21wcm9taXNlICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzYNICAgICAgIDguNS4zLiAgQ29ycmVsYXRpb24g YW5kIElkZW50aWZpY2F0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM2DSAgICAgICA4 LjUuNC4gIFNlY29uZGFyeSBVc2UgYW5kIERpc2Nsb3N1cmUgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAzNw0gICAgIDguNi4gIE1pdGlnYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzcNICAgICAgIDguNi4xLiAgRGF0YSBNaW5p bWlzYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM3DSAgICAg ICA4LjYuMi4gIEFub255bWl0eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAzOA0gICAgICAgOC42LjMuICBQc2V1ZG9ueW1pdHkgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzkNICAgICAgIDguNi40LiAgT3RoZXIg TWl0aWdhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM5DSAg IDkuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA0MA0gICAxMC4gQWNrbm93bGVkZ21lbnRzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDANICAgMTEuIEhpc3RvcnkgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQx DSAgICAgMTEuMS4gIEZyb20gLTAwIHRvIC0wMSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA0MQ0gICAgIDExLjIuICBGcm9tIC0wMSB0byAtMDIgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDENICAgICAxMS4zLiAgRnJv bSAtMDIgdG8gLTAzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDQyDSAgIDEyLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA0Mg0gICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDQNDTEuICBJbnRyb2R1 Y3Rpb24NDSAgIFRoZXJlIGlzIGEgZGVzaXJlIHRvIGJlIGFibGUgdG8gY29vcmRpbmF0ZSB0 aGUgZXhlY3V0aW9uIG9mIGJyb2FkYmFuZA0gICBtZWFzdXJlbWVudHMgYW5kIHRoZSBjb2xs ZWN0aW9uIG9mIG1lYXN1cmVtZW50IHJlc3VsdHMgYWNyb3NzIGEgbGFyZ2UNICAgc2NhbGUg c2V0IG9mIGRpdmVyc2UgZGV2aWNlcy4gIFRoZXNlIGRldmljZXMgY291bGQgYmUgc29mdHdh cmUgYmFzZWQNICAgYWdlbnRzIG9uIFBDcywgZW1iZWRkZWQgYWdlbnRzIGluIGNvbnN1bWVy IGRldmljZXMgKGUuZy4gYmx1LXJheQ0gICBwbGF5ZXJzKSwgc2VydmljZSBwcm92aWRlciBj b250cm9sbGVkIGRldmljZXMgc3VjaCBhcyBzZXQtdG9wIHBsYXllcnMNICAgYW5kIGhvbWUg Z2F0ZXdheXMsIG9yIHNpbXBseSBkZWRpY2F0ZWQgcHJvYmVzLiAgSXQgaXMgZXhwZWN0ZWQg dGhhdA0gICBzdWNoIGEgc3lzdGVtIGNvdWxkIGVhc2lseSBjb21wcmlzZSAxMDBrIGRldmlj ZXMuICBTdWNoIGEgc2NhbGUNICAgcHJlc2VudHMgdW5pcXVlIHByb2JsZW1zIGluIGNvb3Jk aW5hdGlvbiwgZXhlY3V0aW9uIGFuZCBtZWFzdXJlbWVudA0gICByZXN1bHQgY29sbGVjdGlv bi4gIFNldmVyYWwgdXNlIGNhc2VzIGhhdmUgYmVlbiBwcm9wb3NlZCBmb3IgbGFyZ2UtDSAg IHNjYWxlIG1lYXN1cmVtZW50cyBpbmNsdWRpbmc6DQ0gICBvICBPcGVyYXRvcnM6IHRvIGhl bHAgcGxhbiB0aGVpciBuZXR3b3JrIGFuZCBpZGVudGlmeSBmYXVsdHMNDSAgIG8gIFJlZ3Vs YXRvcnM6IHRvIGJlbmNobWFyayBzZXZlcmFsIG5ldHdvcmsgb3BlcmF0b3JzIGFuZCBzdXBw b3J0DSAgICAgIHB1YmxpYyBwb2xpY3kgZGV2ZWxvcG1lbnQNDSAgIEZ1cnRoZXIgZGV0YWls cyBvZiB0aGUgdXNlIGNhc2VzIGNhbiBiZSBmb3VuZCBhdA0gICBbSS1ELmlldGYtbG1hcC11 c2UtY2FzZXNdLiAgVGhlIExNQVAgZnJhbWV3b3JrIHNob3VsZCBiZSB1c2VmdWwgZm9yDSAg IHRoZXNlLCBhcyB3ZWxsIGFzIG90aGVyIHVzZSBjYXNlcyB0aGF0IHRoZSBMTUFQIFdHIGRv ZXNuJ3QNICAgY29uY2VudHJhdGUgb24sIHN1Y2ggYXMgdG8gaGVscCBlbmQgdXNlcnMgcnVu IGRpYWdub3N0aWMgY2hlY2tzIGxpa2UNICAgYSBuZXR3b3JrIHNwZWVkIHRlc3QuDQ0gICBU aGUgTE1BUCBmcmFtZXdvcmsgaGFzIGZvdXIgYmFzaWMgZWxlbWVudHM6IE1lYXN1cmVtZW50 IEFnZW50cywNICAgTWVhc3VyZW1lbnQgUGVlcnMsIENvbnRyb2xsZXJzIGFuZCBDb2xsZWN0 b3JzLg0NDQ0NDUVhcmRsZXksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI1LCAy MDE0ICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0NSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICBMTUFQIEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE0DQ0NICAg TWVhc3VyZW1lbnQgQWdlbnRzIChNQXMpIHBlcmZvcm0gTWVhc3VyZW1lbnQgVGFza3MsIHBl cmhhcHMgaW4NICAgY29uanVuY3Rpb24gd2l0aCBNZWFzdXJlbWVudCBQZWVycy4gIFRoZXkg YXJlIHBpZWNlcyBvZiBjb2RlIHRoYXQgY2FuDSAgIGJlIGV4ZWN1dGVkIGluIHNwZWNpYWxp emVkIGhhcmR3YXJlIChoYXJkd2FyZSBwcm9iZSkgb3Igb24gYSBnZW5lcmFsLQ0gICBwdXJw b3NlIGRldmljZSAobGlrZSBhIFBDIG9yIG1vYmlsZSBwaG9uZSkuICBBIGRldmljZSB3aXRo IGENICAgTWVhc3VyZW1lbnQgQWdlbnQgbWF5IGhhdmUgbXVsdGlwbGUgaW50ZXJmYWNlcyAo V2lGaSwgRXRoZXJuZXQsIERTTCwNICAgZmlicmUsIGV0Yy4pIGFuZCB0aGUgTWVhc3VyZW1l bnQgVGFza3MgbWF5IHNwZWNpZnkgYW55IG9uZSBvZiB0aGVzZS4NICAgTWVhc3VyZW1lbnQg VGFza3MgbWF5IGJlIEFjdGl2ZSAodGhlIE1BIG9yIE1lYXN1cmVtZW50IFBlZXIgZ2VuZXJh dGVzDSAgIEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljKSwgUGFzc2l2ZSAodGhlIE1BIG9i c2VydmVzIHVzZXIgdHJhZmZpYyksDSAgIG9yIHNvbWUgaHlicmlkIGZvcm0gb2YgdGhlIHR3 by4gIEZvciBBY3RpdmUgTWVhc3VyZW1lbnQgVGFza3MsIHRoZSBNQQ0gICAob3IgTWVhc3Vy ZW1lbnQgUGVlcikgZ2VuZXJhdGVzIEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIGFuZA0g ICBtZWFzdXJlcyBzb21lIG1ldHJpYyBhc3NvY2lhdGVkIHdpdGggaXRzIHRyYW5zZmVyIG92 ZXIgdGhlIHBhdGggdG8NICAgKG9yIGZyb20pIGEgTWVhc3VyZW1lbnQgUGVlci4gIEZvciBl eGFtcGxlLCBvbmUgQWN0aXZlIE1lYXN1cmVtZW50DSAgIFRhc2sgY291bGQgYmUgdG8gbWVh c3VyZSB0aGUgVURQIGxhdGVuY3kgYmV0d2VlbiB0aGUgTUEgYW5kIGEgZ2l2ZW4NICAgTWVh c3VyZW1lbnQgUGVlci4gIE1BcyBtYXkgYWxzbyBjb25kdWN0IFBhc3NpdmUgTWVhc3VyZW1l bnQgVGFza3MNICAgdGhyb3VnaCB0aGUgb2JzZXJ2YXRpb24gb2YgdHJhZmZpYy4gIFRoZSBN ZWFzdXJlbWVudCBUYXNrcyB0aGVtc2VsdmVzDSAgIG1heSBiZSBvbiBJUHY0LCBJUHY2LCBh bmQgb24gdmFyaW91cyBzZXJ2aWNlcyAoRE5TLCBIVFRQLCBYTVBQLCBGVFAsDSAgIFZvSVAs IGV0Yy4pLg0NICAgVGhlIENvbnRyb2xsZXIgbWFuYWdlcyBvbmUgb3IgbW9yZSBNQXMgYnkg aW5zdHJ1Y3RpbmcgaXQgd2hpY2gNICAgTWVhc3VyZW1lbnQgVGFza3MgaXQgc2hvdWxkIHBl cmZvcm0gYW5kIHdoZW4uICBGb3IgZXhhbXBsZSBpdCBtYXkNICAgaW5zdHJ1Y3QgYSBNQSBh dCBhIGhvbWUgZ2F0ZXdheTogIk1lYXN1cmUgdGhlICdVRFAgbGF0ZW5jeScgd2l0aCB0aGUN ICAgTWVhc3VyZW1lbnQgUGVlciBtcC5leGFtcGxlLm9yZzsgcmVwZWF0IGV2ZXJ5IGhvdXIg YXQgeHguMDUiLiAgVGhlDSAgIENvbnRyb2xsZXIgYWxzbyBtYW5hZ2VzIGEgTUEgYnkgaW5z dHJ1Y3RpbmcgaXQgaG93IHRvIHJlcG9ydCB0aGUNICAgTWVhc3VyZW1lbnQgUmVzdWx0cywg Zm9yIGV4YW1wbGU6ICJSZXBvcnQgcmVzdWx0cyBvbmNlIGEgZGF5IGluIGENICAgYmF0Y2gg YXQgNGFtIi4gIFdlIHJlZmVyIHRvIHRoZXNlIGFzIHRoZSBNZWFzdXJlbWVudCBTY2hlZHVs ZSBhbmQNICAgUmVwb3J0IFNjaGVkdWxlLg0NICAgVGhlIENvbGxlY3RvciBhY2NlcHRzIFJl cG9ydHMgZnJvbSB0aGUgTUFzIHdpdGggdGhlIFJlc3VsdHMgZnJvbQ0gICB0aGVpciBNZWFz dXJlbWVudCBUYXNrcy4gIFRoZXJlZm9yZSB0aGUgTUEgaXMgYSBkZXZpY2UgdGhhdCBnZXRz DSAgIEluc3RydWN0aW9ucyBmcm9tIHRoZSBDb250cm9sbGVyLCBpbml0aWF0ZXMgdGhlIE1l YXN1cmVtZW50IFRhc2tzLA0gICBhbmQgcmVwb3J0cyB0byB0aGUgQ29sbGVjdG9yLg0NICAg VGhlcmUgYXJlIGFkZGl0aW9uYWwgZWxlbWVudHMgdGhhdCBhcmUgcGFydCBvZiBhIG1lYXN1 cmVtZW50IHN5c3RlbSwNICAgYnV0IHRoYXQgYXJlIG91dCBvZiB0aGUgc2NvcGUgZm9yIExN QVAuICBXZSBwcm92aWRlIGEgZGV0YWlsZWQNICAgZGlzY3Vzc2lvbiBvZiBhbGwgdGhlIGVs ZW1lbnRzIGluIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudC4NDSAgIFRoZSBkZXNpcmFibGUg ZmVhdHVyZXMgZm9yIGEgbGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnQgc3lzdGVtcyB3ZSBhcmUN ICAgZGVzaWduaW5nIGZvciBhcmU6DQ0gICBvICBTdGFuZGFyZGlzZWQgLSBpbiB0ZXJtcyBv ZiB0aGUgTWVhc3VyZW1lbnQgVGFza3MgdGhhdCB0aGV5DSAgICAgIHBlcmZvcm0sIHRoZSBj b21wb25lbnRzLCB0aGUgZGF0YSBtb2RlbHMgYW5kIHByb3RvY29scyBmb3INICAgICAgdHJh bnNmZXJyaW5nIGluZm9ybWF0aW9uIGJldHdlZW4gdGhlIGNvbXBvbmVudHMuICBBbW9uZ3N0 IG90aGVyDSAgICAgIHRoaW5ncywgc3RhbmRhcmRpc2F0aW9uIGVuYWJsZXMgbWVhbmluZ2Z1 bCBjb21wYXJpc29ucyBvZg0gICAgICBtZWFzdXJlbWVudHMgbWFkZSBvZiB0aGUgc2FtZSBt ZXRyaWMgYXQgZGlmZmVyZW50IHRpbWVzIGFuZA0gICAgICBwbGFjZXMsIGFuZCBlbmFibGVz IHRoZSBvcGVyYXRvciBvZiBhIG1lYXN1cmVtZW50IHN5c3RlbSB0byBidXkNICAgICAgdGhl IHZhcmlvdXMgY29tcG9uZW50cyBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzLiAgVG9kYXkncyBz eXN0ZW1zDSAgICAgIGFyZSBwcm9wcmlldGFyeSBpbiBzb21lIG9yIGFsbCBvZiB0aGVzZSBh c3BlY3RzLg0NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjUs IDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQ1JbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQNDQ0g ICBvICBMYXJnZS1zY2FsZSAtIFtJLUQuaWV0Zi1sbWFwLXVzZS1jYXNlc10gZW52aXNhZ2Vz IE1lYXN1cmVtZW50DSAgICAgIEFnZW50cyBpbiBldmVyeSBob21lIGdhdGV3YXkgYW5kIGVk Z2UgZGV2aWNlIHN1Y2ggYXMgc2V0LXRvcC1ib3hlcw0gICAgICBhbmQgdGFibGV0IGNvbXB1 dGVycy4gIEl0IGlzIGV4cGVjdGVkIHRoYXQgYSBtZWFzdXJlbWVudCBzeXN0ZW0NICAgICAg Y291bGQgZWFzaWx5IGVuY29tcGFzcyBhIGZldyBodW5kcmVkIHRob3VzYW5kIE1lYXN1cmVt ZW50IEFnZW50cy4NICAgICAgRXhpc3Rpbmcgc3lzdGVtcyBoYXZlIHVwIHRvIGEgZmV3IHRo b3VzYW5kIE1BcyAod2l0aG91dCBqdWRnaW5nDSAgICAgIGhvdyBtdWNoIGZ1cnRoZXIgdGhl eSBjb3VsZCBzY2FsZSkuDQ0gICBvICBEaXZlcnNpdHkgLSBhIG1lYXN1cmVtZW50IHN5c3Rl bSBzaG91bGQgaGFuZGxlIGRpZmZlcmVudCB0eXBlcyBvZg0gICAgICBNZWFzdXJlbWVudCBB Z2VudCAtIGZvciBleGFtcGxlIE1lYXN1cmVtZW50IEFnZW50cyBtYXkgY29tZSBmcm9tDSAg ICAgIGRpZmZlcmVudCB2ZW5kb3JzLCBiZSBpbiB3aXJlZCBhbmQgd2lyZWxlc3MgbmV0d29y a3MsIGhhdmUgZGlmZmVyZW50IE1lYXN1cmVtZW50IFRhc2sgY2FwYWJpbGl0aWVzLAUgYW5k IGJlIG9uDSAgICAgIGRldmljZXMgd2l0aCBJUHY0IG9yIElQdjYgYWRkcmVzc2VzLg0NMi4g IE91dGxpbmUgb2YgYW4gTE1BUC1iYXNlZCBtZWFzdXJlbWVudCBzeXN0ZW0NDSAgIEZpZ3Vy ZSAxIHNob3dzIHRoZSBtYWluIGNvbXBvbmVudHMgb2YgYSBtZWFzdXJlbWVudCBzeXN0ZW0s IGFuZCB0aGUNICAgaW50ZXJhY3Rpb25zIG9mIHRob3NlIGNvbXBvbmVudHMuICBTb21lIG9m IHRoZSBjb21wb25lbnRzIGFyZSBvdXRzaWRlDSAgIHRoZSBzY29wZSBvZiBMTUFQLiAgSW4g dGhpcyBzZWN0aW9uIHdlIHByb3ZpZGUgYW4gb3ZlcnZpZXcgb2YgdGhlDSAgIHdob2xlIG1l YXN1cmVtZW50IHN5c3RlbSwgYW5kIHdlIGludHJvZHVjZSB0aGUgbWFpbiB0ZXJtcyBuZWVk ZWQgZm9yDSAgIHRoZSBMTUFQIGZyYW1ld29yay4gIFRoZSBuZXcgdGVybXMgYXJlIGNhcGl0 YWxpemVkLiAgSW4gdGhlIG5leHQNICAgc2VjdGlvbiB3ZSBwcm92aWRlIGEgdGVybWlub2xv Z3kgc2VjdGlvbiB3aXRoIGEgY29tcGlsYXRpb24gb2YgYWxsDSAgIHRoZSBMTUFQIHRlcm1z IGFuZCB0aGVpciBkZWZpbml0aW9uLiAgVGhlIHN1YnNlcXVlbnQgc2VjdGlvbnMgc3R1ZHkN ICAgdGhlIExNQVAgY29tcG9uZW50cyBpbiBtb3JlIGRldGFpbC4NDSAgIEEgTWVhc3VyZW1l bnQgVGFzayBtZWFzdXJlcyBzb21lIHBlcmZvcm1hbmNlIG9yIHJlbGlhYmlsaXR5IE1ldHJp YyBvZg0gICBpbnRlcmVzdC4gIEFuIEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrIGludm9sdmVz IGVpdGhlciBhIE1lYXN1cmVtZW50DSAgIEFnZW50IChNQSkgaW5qZWN0aW5nIEFjdGl2ZSBN ZWFzdXJlbWVudCBUcmFmZmljIGludG8gdGhlIG5ldHdvcmsNICAgZGVzdGluZWQgZm9yIGEg TWVhc3VyZW1lbnQgUGVlciwgYW5kL29yIGEgTWVhc3VyZW1lbnQgUGVlciBzZW5kaW5nDSAg IEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIHRvIGEgTUE7IG9uZSBvZiB0aGVtIG1lYXN1 cmVzIHNvbWUNICAgcGFyYW1ldGVyIGFzc29jaWF0ZWQgd2l0aCB0aGUgdHJhbnNmZXIgb2Yg dGhlIHBhY2tldChzKS4gIEEgUGFzc2l2ZQ0gICBNZWFzdXJlbWVudCBUYXNrIGludm9sdmVz IG9ubHkgYSBNQSwgd2hpY2ggc2ltcGx5IG9ic2VydmVzIGV4aXN0aW5nDSAgIHRyYWZmaWMg LSBmb3IgZXhhbXBsZSwgaXQgY291bGQgc2ltcGx5IGNvdW50IGJ5dGVzIG9yIGl0IG1pZ2h0 DSAgIGNhbGN1bGF0ZSB0aGUgYXZlcmFnZSBsb3NzIGZvciBhIHBhcnRpY3VsYXIgZmxvdy4N DSAgIEl0IGlzIHZlcnkgdXNlZnVsIHRvIHN0YW5kYXJkaXNlIE1lYXN1cmVtZW50IE1ldGhv ZHMgKGEgTWVhc3VyZW1lbnQNICAgTWV0aG9kIGlzIGEgZ2VuZXJhbGlzYXRpb24gb2YgYSBN ZWFzdXJlbWVudCBUYXNrKSwgc28gdGhhdCBpdCBpcw0gICBtZWFuaW5nZnVsIHRvIGNvbXBh cmUgbWVhc3VyZW1lbnRzIG9mIHRoZSBzYW1lIE1ldHJpYyBtYWRlIGF0DSAgIGRpZmZlcmVu dCB0aW1lcyBhbmQgcGxhY2VzLiAgSXQgaXMgYWxzbyB1c2VmdWwgdG8gZGVmaW5lIGEgcmVn aXN0cnkNICAgZm9yIGNvbW1vbmx5LXVzZWQgTWV0cmljcyAFW0ktRC5iYWdudWxvLWlwcG0t bmV3LXJlZ2lzdHJ5LWluZGVwZW5kZW50XQ0gICBzbyB0aGF0IGEgTWVhc3VyZW1lbnQgTWV0 aG9kIGNhbiBiZSByZWZlcnJlZCB0byBzaW1wbHkgYnkgaXRzDSAgIGlkZW50aWZpZXIgaW4g dGhlIHJlZ2lzdHJ5LiAgVGhlIE1lYXN1cmVtZW50IE1ldGhvZHMgYW5kIHJlZ2lzdHJ5DSAg IHdpbGwgaG9wZWZ1bGx5IGJlIHJlZmVyZW5jZWQgYnkgb3RoZXIgc3RhbmRhcmRzIG9yZ2Fu aXNhdGlvbnMuDQ0gICBJbiBvcmRlciBmb3IgYSBNZWFzdXJlbWVudCBBZ2VudCBhbmQgYSBN ZWFzdXJlbWVudCBQZWVyIHRvIGV4ZWN1dGUgYW4NICAgQWN0aXZlIE1lYXN1cmVtZW50IFRh c2ssIHRoZXkgZXhjaGFuZ2UgQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMuDSAgIFRoZSBw cm90b2NvbHMgdXNlZCBmb3IgdGhlIEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIGlzIGFy ZSBvdXQgb2YgdGhlDSAgIHNjb3BlIG9mIHRoZSBMTUFQIFdHIGFuZCBmYWxscyB3aXRoaW4g dGhlIHNjb3BlIG9mIG90aGVyIElFVEYgV0dzDSAgIHN1Y2ggYXMgSVBQTS4NDQ0NDUVhcmRs ZXksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI1LCAyMDE0ICAgICAgICAgICAg ICAgICBbUGFnZSA1XQ0NSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBMTUFQIEZyYW1l d29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE0DQ0NICAgRm9yIE1lYXN1cmVtZW50 IFJlc3VsdHMgdG8gYmUgdHJ1bHkgY29tcGFyYWJsZSwgYXMgbWlnaHQgYmUgcmVxdWlyZWQN ICAgYnkgYSByZWd1bGF0b3IsIG5vdCBvbmx5IGRvIHRoZSBzYW1lIE1lYXN1cmVtZW50IE1l dGhvZHMgbmVlZCB0byBiZQ0gICB1c2VkIGJ1dCBhbHNvIHRoZSBzZXQgb2YgTWVhc3VyZW1l bnQgVGFza3Mgc2hvdWxkIGZvbGxvdyBhIHNpbWlsYXINICAgTWVhc3VyZW1lbnQgU2NoZWR1 bGUgYW5kIGJlIG9mIHNpbWlsYXIgbnVtYmVyIChpbiB0aGUgY2FzZSB3aGVuIG11bHRpcGxl IGl0ZXJhdGlvbnMgb2YgdGhlIHNhbWUgTWVhc3VyZW1lbnQgVGFzayBhcmUgYXZlcmFnZWQg dG9nZXRoZXIgdG8gZm9ybSBhIE1lYXN1cmVtZW50IFJlc3VsdCkuICBUaGUgZGV0YWlscyBv ZiBzdWNoIGENICAgY2hhcmFjdGVyaXNhdGlvbiBwbGFuIGFyZSBiZXlvbmQgdGhlIHNjb3Bl IG9mIHdvcmsgaW4gSUVURiBhbHRob3VnaA0gICBjZXJ0YWlubHkgZmFjaWxpdGF0ZWQgYnkg SUVURidzIHdvcmsuDQ0gICBUaGUgbmV4dCBjb21wb25lbnRzIHdlIGNvbnNpZGVyIGFyZSB0 aGUgTWVhc3VyZW1lbnQgQWdlbnQgKE1BKSwNICAgQ29udHJvbGxlciBhbmQgQ29sbGVjdG9y LiAgVGhlIG1haW4gd29yayBvZiB0aGUgTE1BUCB3b3JraW5nIGdyb3VwIGlzDSAgIHRvIGRl ZmluZSB0aGUgQ29udHJvbCBQcm90b2NvbCBiZXR3ZWVuIHRoZSBDb250cm9sbGVyIGFuZCBN QSwgYW5kIHRoZQ0gICBSZXBvcnQgUHJvdG9jb2wgYmV0d2VlbiB0aGUgTUEgYW5kIENvbGxl Y3Rvci4gIFNlY3Rpb24gNCBvbndhcmRzDSAgIGNvbnNpZGVycyB0aGUgTE1BUCBjb21wb25l bnRzIGluIG1vcmUgZGV0YWlsOyBoZXJlIHdlIGludHJvZHVjZSB0aGVtLg0NICAgVGhlIENv bnRyb2xsZXIgbWFuYWdlcyBhIE1BIGJ5IGluc3RydWN0aW5nIGl0IHdoaWNoIE1lYXN1cmVt ZW50IFRhc2tzDSAgIGl0IHNob3VsZCBwZXJmb3JtIGFuZCB3aGVuLiAgRm9yIGV4YW1wbGUg aXQgbWF5IGluc3RydWN0IGEgTUEgYXQgYQ0gICBob21lIGdhdGV3YXk6ICJSdW4gdGhlICdk b3dubG9hZCBzcGVlZCB0ZXN0JyB3aXRoIHRoZSBNZWFzdXJlbWVudA0gICBQZWVyIGF0IHRo ZSBlbmQgdXNlcidzIGZpcnN0IElQIHBvaW50IGluIHRoZSBuZXR3b3JrOyBpZiB0aGUgZW5k IHVzZXINICAgaXMgYWN0aXZlIHRoZW4gZGVsYXkgdGhlIHRlc3QgYW5kIHJlLXRyeSAxIG1p bnV0ZSBsYXRlciwgd2l0aCB1cCB0byAzDSAgIHJlLXRyaWVzOyByZXBlYXQgZXZlcnkgaG91 ciBhdCB4eC4wNSArIFVuaWYFWzAsMTgwXSBzZWNvbmRzIi4gIFRoZQ0gICBDb250cm9sbGVy IGFsc28gbWFuYWdlcyBhIE1BIGJ5IGluc3RydWN0aW5nIGl0IGhvdyB0byByZXBvcnQgdGhl DSAgIE1lYXN1cmVtZW50IFJlc3VsdHMsIGZvciBleGFtcGxlOiAiUmVwb3J0IHJlc3VsdHMg b25jZSBhIGRheSBpbiBhDSAgIGJhdGNoIGF0IDRhbSArIFVuaWZbMCwxODBdIHNlY29uZHM7 IGlmIHRoZSBlbmQgdXNlciBpcyBhY3RpdmUgdGhlbg0gICBkZWxheSB0aGUgcmVwb3J0IDUg bWludXRlcyIuICBUaGVzZSBhcmUgY2FsbGVkIHRoZSBNZWFzdXJlbWVudCBhbmQNICAgUmVw b3J0IFNjaGVkdWxlLiAgQXMgd2VsbCBhcyBwZXJpb2RpYyBNZWFzdXJlbWVudCBUYXNrcywg YSBDb250cm9sbGVyDSAgIGNhbiBpbml0aWF0ZSBhIG9uZS1vZmYgKG5vbi1yZWN1cnJpbmcp IE1lYXN1cmVtZW50IFRhc2sgKCJEbw0gICBtZWFzdXJlbWVudCBub3ciLCAiUmVwb3J0IGFz IHNvb24gYXMgcG9zc2libGUiKS4NDSAgIFRoZSBDb2xsZWN0b3IgYWNjZXB0cyBhIFJlcG9y dCBmcm9tIGEgTUEgd2l0aCB0aGUgcmVzdWx0cyBmcm9tIGl0cw0gICBNZWFzdXJlbWVudCBU YXNrcy4gIEl0IG1heSBhbHNvIGRvIHNvbWUgcG9zdC1wcm9jZXNzaW5nIG9uIHRoZQ0gICBy ZXN1bHRzLCBmb3IgaW5zdGFuY2UgdG8gZWxpbWluYXRlIG91dGxpZXJzLCBhcyB0aGV5IGNh biBzZXZlcmVseQ0gICBpbXBhY3QgdGhlIGFnZ3JlZ2F0ZWQgcmVzdWx0cy4NDSAgIEZpbmFs bHkgd2UgaW50cm9kdWNlIHNldmVyYWwgY29tcG9uZW50cyB0aGF0IGFyZSBvdXQgb2Ygc2Nv cGUgb2YgdGhlDSAgIExNQVAgV0cgYW5kIHdpbGwgYmUgcHJvdmlkZWQgdGhyb3VnaCBleGlz dGluZyBwcm90b2NvbHMgb3INICAgYXBwbGljYXRpb25zLiAgVGhleSBhZmZlY3QgaG93IHRo ZSBtZWFzdXJlbWVudCBzeXN0ZW0gdXNlcyB0aGUNICAgTWVhc3VyZW1lbnQgUmVzdWx0cyBh bmQgaG93IGl0IGRlY2lkZXMgd2hhdCBzZXQgb2YgTWVhc3VyZW1lbnQgVGFza3MNICAgdG8g cGVyZm9ybS4NDSAgIFRoZSBNQSBuZWVkcyB0byBiZSBib290c3RyYXBwZWQgd2l0aCBpbml0 aWFsIGRldGFpbHMgYWJvdXQgaXRzDSAgIENvbnRyb2xsZXIsIGluY2x1ZGluZyBhdXRoZW50 aWNhdGlvbiBjcmVkZW50aWFscy4gIFRoZSBMTUFQIFdHDSAgIGNvbnNpZGVycyB0aGUgYm9v dHN0cmFwIHByb2Nlc3MsIHNpbmNlIGl0IGFmZmVjdHMgdGhlIEluZm9ybWF0aW9uDSAgIE1v ZGVsLiAgSG93ZXZlciwgaXQgZG9lcyBub3QgZGVmaW5lIGEgYm9vdHN0cmFwIHByb3RvY29s LCBzaW5jZSBpdCBpcw0gICBsaWtlbHkgdG8gYmUgdGVjaG5vbG9neSBzcGVjaWZpYyBhbmQg Y291bGQgYmUgZGVmaW5lZCBieSB0aGUNICAgQnJvYWRiYW5kIEZvcnVtLCBDYWJsZUxhYnMg b3IgSUVFRSBkZXBlbmRpbmcgb24gdGhlIGRldmljZS4gIFBvc3NpYmxlDSAgIHByb3RvY29s cyBhcmUgU05NUCwgTkVUQ09ORiBvciAoZm9yIEhvbWUgR2F0ZXdheXMpIENQRSBXQU4gTWFu YWdlbWVudA0gICBQcm90b2NvbCAoQ1dNUCkgZnJvbSB0aGUgQXV0byBDb25maWd1cmF0aW9u IFNlcnZlciAoQUNTKSAoYXMNICAgc3BlY2lmaWVkIGluIFRSLTA2OSkuDQ0NDQ1FYXJkbGV5 LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSnVseSAyNSwgMjAxNCAgICAgICAgICAgICAg ICAgW1BhZ2UgNl0NDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTE1BUCBGcmFtZXdv cmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNA0NDSAgIEEgU3Vic2NyaWJlciBwYXJh bWV0ZXIgZGF0YWJhc2UgY29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGxpbmUsDSAg IHN1Y2ggYXMgdGhlIGN1c3RvbWVyJ3MgYnJvYWRiYW5kIGNvbnRyYWN0IChwZXJoYXBzIDIs IDQwIG9yIDgwTWIvcyksDSAgIHRoZSBsaW5lIHRlY2hub2xvZ3kgKERTTCBvciBmaWJyZSks IHRoZSB0aW1lIHpvbmUgd2hlcmUgdGhlIE1BIGlzDSAgIGxvY2F0ZWQsIGFuZCB0aGUgdHlw ZSBvZiBob21lIGdhdGV3YXkgYW5kIE1BLiAgVGhlc2UgcGFyYW1ldGVycyBhcmUNICAgYWxy ZWFkeSBnYXRoZXJlZCBhbmQgc3RvcmVkIGJ5IGV4aXN0aW5nIG9wZXJhdGlvbnMgc3lzdGVt cy4gIFRoZXkgbWF5DSAgIGFmZmVjdCB0aGUgY2hvaWNlIG9mIHdoYXQgTWVhc3VyZW1lbnQg VGFza3MgdG8gcnVuIGFuZCBob3cgdG8NICAgaW50ZXJwcmV0IHRoZSBNZWFzdXJlbWVudCBS ZXN1bHRzLiAgRm9yIGV4YW1wbGUsIGEgZG93bmxvYWQgdGVzdA0gICBzdWl0YWJsZSBmb3Ig YSBsaW5lIHdpdGggYW4gODBNYi9zIGNvbnRyYWN0IG1heSBvdmVyd2hlbG0gYSAyTWIvcw0g ICBsaW5lLg0NICAgQSByZXN1bHRzIHJlcG9zaXRvcnkgcmVjb3JkcyBhbGwgTWVhc3VyZW1l bnQgUmVzdWx0cyBpbiBhbiBlcXVpdmFsZW50DSAgIGZvcm0sIGZvciBleGFtcGxlIGFuIFNR TCBkYXRhYmFzZSwgc28gdGhhdCB0aGV5IGNhbiBlYXNpbHkgYmUNICAgYWNjZXNzZWQgYnkg dGhlIGRhdGEgYW5hbHlzaXMgdG9vbHMuICBUaGUgZGF0YSBhbmFseXNpcyB0b29scyBhbHNv DSAgIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgU3Vic2NyaWJlcidzIHNlcnZpY2UgaW5mb3Jt YXRpb24sIGZvciBleGFtcGxlDSAgIHRoZSBicm9hZGJhbmQgY29udHJhY3QuDQ0gICBUaGUg ZGF0YSBhbmFseXNpcyB0b29scyByZWNlaXZlIHRoZSByZXN1bHRzIGZyb20gdGhlIENvbGxl Y3RvciBvciB2aWENICAgdGhlIFJlc3VsdHMgcmVwb3NpdG9yeS4gIFRoZXkgbWlnaHQgdmlz dWFsaXNlIHRoZSBkYXRhIG9yIGlkZW50aWZ5DSAgIHdoaWNoIGNvbXBvbmVudCBvciBsaW5r IGlzIGxpa2VseSB0byBiZSB0aGUgY2F1c2Ugb2YgYSBmYXVsdCBvcg0gICBkZWdyYWRhdGlv bi4gIFRoaXMgaW5mb3JtYXRpb24gY291bGQgaGVscCB0aGUgQ29udHJvbGxlciBkZWNpZGUg d2hhdA0gICBmb2xsb3ctdXAgTWVhc3VyZW1lbnQgVGFzayB0byBwZXJmb3JtIGluIG9yZGVy IHRvIGRpYWdub3NlIGEgZmF1bHQuDQ0gICBUaGUgb3BlcmF0b3IncyBPQU0gKE9wZXJhdGlv bnMsIEFkbWluaXN0cmF0aW9uLCBhbmQgTWFpbnRlbmFuY2UpIHVzZXMNICAgdGhlIHJlc3Vs dHMgZnJvbSB0aGUgdG9vbHMuDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDUVhcmRsZXks IGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI1LCAyMDE0ICAgICAgICAgICAgICAg ICBbUGFnZSA3XQ0NSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBMTUFQIEZyYW1ld29y ayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE0DQ0NICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeDSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBY3RpdmUgICAgICAg ICAgICAgICAgICAgICAgIElQUE0NICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsg IE1lYXN1cmVtZW50ICstLS0tLS0tLS0tLS0tKyAgICBTY29wZQ0gICAgICArLS0tLS0tLT58 IE1lYXN1cmVtZW50ICAgfDwtLS0tLS0tLS0tLS0+fCBNZWFzdXJlbWVudCB8ICAgIHYNICAg ICAgfCAgICAgICAgfCAgIEFnZW50ICAgICAgIHwgICBUcmFmZmljICAgIHwgICAgIFBlZXIg ICAgfCAgICBeDSAgICAgIHwgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLSsgICAgfA0gICAgICB8ICAgICAgICAgICAgICBeICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNICAgICAgfCAgSW5zdHJ1Y3Rp b24gfCAgICAgIHwgIFJlcG9ydCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DSAgICAg IHwgICAgICAgICAgICAgIHwgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAg ICAgICAgfA0gICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgIHwNICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgIHYgICAgICAgICAgICAgICAgICBMTUFQDSAgICAgIHwgICAgICAgICAr LS0tLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tKyAgICAgICAgU2NvcGUN ICAgICAgfCAgICAgICAgIHwgQ29udHJvbGxlciB8ICAgICAgICAgICAgIHwgIENvbGxlY3Rv ciB8ICAgICAgICB8DSAgICAgIHwgICAgICAgICArLS0tLS0tLS0tLS0tKyAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tKyAgICAgICAgdg0gICAgICB8ICAgICAgICAgICAgICAgIF4gICBe ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIF4NICAgICAgfCAgICAgICAg ICAgICAgICB8ICAgfCAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8DSAg ICAgIHwgICAgICAgICAgICAgICAgfCAgICstLS0tLS0tLS0tKyAgICAgICAgICAgIHwgICAg ICAgICAgICAgfA0gICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAg ICAgICAgICB2ICAgICAgICAgICAgIHwNICAgKy0tLS0tLS0tLS0tLSsgICArLS0tLS0tLS0t LSsgICAgKy0tLS0tLS0tKyAgICArLS0tLS0tLS0tLSsgICB8DSAgIHxCb290c3RyYXBwZXJ8 ICAgfFN1YnNjcmliZXJ8LS0tPnwgIGRhdGEgIHw8LS0tfHJlcG9zaXRvcnl8ICAgT3V0DSAg ICstLS0tLS0tLS0tLS0rICAgfHBhcmFtZXRlciB8ICAgIHxhbmFseXNpc3wgICAgKy0tLS0t LS0tLS0rICAgb2YNICAgICAgICAgICAgICAgICAgICB8ZGF0YWJhc2UgIHwgICAgfCB0b29s cyAgfCAgICAgICAgICAgICAgICAgICBTY29wZQ0gICAgICAgICAgICAgICAgICAgICstLS0t LS0tLS0tKyAgICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgIHwNICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdg0NICAgRmlndXJlIDE6IFNjaGVtYXRpYyBvZiBtYWluIGVsZW1lbnRz IG9mIGFuIExNQVAtYmFzZWQNICAgbWVhc3VyZW1lbnQgc3lzdGVtDSAgIChzaG93aW5nIHRo ZSBlbGVtZW50cyBpbiBhbmQgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGUgTE1BUCBXRykNDTMu ICBUZXJtaW5vbG9neQ0NICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGVybWlub2xvZ3kgZm9y IExNQVAuICBQbGVhc2Ugbm90ZSB0aGF0IGRlZmluZWQNICAgdGVybXMgYXJlIGNhcGl0YWxp emVkLg0NICAgQWN0aXZlIE1lYXN1cmVtZW50IE1ldGhvZCAoVGFzayk6IAVBIHR5cGUgb2Yg TWVhc3VyZW1lbnQgTWV0aG9kIChUYXNrKQ0gICB0aGF0IGludm9sdmVzIGEgTWVhc3VyZW1l bnQgQWdlbnQgYW5kIGEgTWVhc3VyZW1lbnQgUGVlciAob3IgcG9zc2libHkNICAgUGVlcnMp LCB3aGVyZSBlaXRoZXIgdGhlIE1lYXN1cmVtZW50IEFnZW50IG9yIHRoZSBNZWFzdXJlbWVu dCBQZWVyDSAgIGluamVjdHMgQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMgaW50byB0aGUg bmV0d29yayBkZXN0aW5lZCBmb3IgdGhlDSAgIG90aGVyLCBhbmQgd2hpY2ggaW52b2x2ZXMg b25lIG9mIHRoZW0gbWVhc3VyaW5nIHNvbWUgcGVyZm9ybWFuY2Ugb3INICAgcmVsaWFiaWxp dHkgcGFyYW1ldGVyIGFzc29jaWF0ZWQgd2l0aCB0aGUgdHJhbnNmZXIgb2YgdGhlIHRyYWZm aWMuDQ0gICBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYzogdGhlIHBhY2tldChzKSBnZW5l cmF0ZWQgYnkgdGhlDSAgIE1lYXN1cmVtZW50IEFnZW50IGFuZC9vciB0aGUgTWVhc3VyZW1l bnQgUGVlciwgYXMgcGFydCBvZiBhbiBBY3RpdmUNICAgTWVhc3VyZW1lbnQgVGFzay4NDQ0N DQ1FYXJkbGV5LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSnVseSAyNSwgMjAxNCAgICAg ICAgICAgICAgICAgW1BhZ2UgOF0NDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTE1B UCBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNA0NDSAgIEJvb3RzdHJh cDogQSBwcm9jZXNzIHRoYXQgaW5pdGlhbGlzZXMgYSBNZWFzdXJlbWVudCBBZ2VudCB3aXRo IHRoZQ0gICBpbmZvcm1hdGlvbiBuZWNlc3NhcnkgdG8gYmUgaW50ZWdyYXRlZCBpbnRvIGEg bWVhc3VyZW1lbnQgc3lzdGVtLg0NICAgQ2FwYWJpbGl0aWVzOiBJbmZvcm1hdGlvbiBhYm91 dCB0aGUgTWVhc3VyZW1lbnQgTWV0aG9kcyB0aGF0IHRoZSBNQQ0gICBjYW4gcGVyZm9ybSBh bmQgdGhlIGRldmljZSBob3N0aW5nIHRoZSBNQSwgZm9yIGV4YW1wbGUgaXRzIGludGVyZmFj ZQ0gICB0eXBlIGFuZCBzcGVlZCBhbmQgaXRzIElQIGFkZHJlc3MuDQ0gICBDaGFubmVsOiBh biBJbnN0cnVjdGlvbiBDaGFubmVsLCBSZXBvcnQgQ2hhbm5lbCBvciBNQS10by1Db250cm9s bGVyDSAgIENoYW5uZWwNBQ0gICBDb2xsZWN0b3I6IEEgZnVuY3Rpb24gdGhhdCByZWNlaXZl cyBhIFJlcG9ydCBmcm9tIGEgTWVhc3VyZW1lbnQNICAgQWdlbnQuDQ0gICBDb21wb3NpdGUg TWV0cmljOiBBIE1ldHJpYyB0aGF0IGlzIGEgY29tYmluYXRpb24gb2Ygb3RoZXIgTWV0cmlj cywNICAgYW5kL29yIGEgY29tYmluYXRpb24gb2YgdGhlIHNhbWUgTWV0cmljIG1lYXN1cmVk IG92ZXIgZGlmZmVyZW50IHBhcnRzDSAgIG9mIHRoZSBuZXR3b3JrIG9yIGF0IGRpZmZlcmVu dCB0aW1lcy4NDSAgIENvbnRyb2xsZXI6IEEgZnVuY3Rpb24gdGhhdCBwcm92aWRlcyBhIE1l YXN1cmVtZW50IEFnZW50IHdpdGgNICAgSW5zdHJ1Y3Rpb24ocykuDQ0gICBDb250cm9sIENo YW5uZWw6IGEgY29tbXVuaWNhdGlvbnMgY2hhbm5lbCBiZXR3ZWVuIGEgQ29udHJvbGxlciBh bmQgYQ0gICBNQSwgd2hpY2ggaXMgZGVmaW5lZCBieSBhIHNwZWNpZmljIENvbnRyb2xsZXIs IE1BIGFuZCBhc3NvY2lhdGVkDSAgIHNlY3VyaXR5LCBhbmQgb3ZlciB3aGljaCBJbnN0cnVj dGlvbnMgYXJlIHNlbnQuDQ0gICBDb250cm9sIFByb3RvY29sOiBUaGUgcHJvdG9jb2wgZGVs aXZlcmluZyBJbnN0cnVjdGlvbihzKSBmcm9tIGENICAgQ29udHJvbGxlciB0byBhIE1lYXN1 cmVtZW50IEFnZW50LiAgSXQgYWxzbyBkZWxpdmVycyBGYWlsdXJlDSAgIEluZm9ybWF0aW9u IGFuZCBDYXBhYmlsaXRpZXMgSW5mb3JtYXRpb24gZnJvbSB0aGUgTWVhc3VyZW1lbnQgQWdl bnQNICAgdG8gdGhlIENvbnRyb2xsZXIuDQ0gICBDeWNsZS1JRDogKG9wdGlvbmFsKSBBIHRh ZyB0aGF0IGlzIHNlbnQgYnkgdGhlIENvbnRyb2xsZXIgaW4gYW4NICAgSW5zdHJ1Y3Rpb24g YW5kIGVjaG9lZCBieSB0aGUgTUEgaW4gaXRzIFJlcG9ydC4gIFRoZSBzYW1lIEN5Y2xlLUlE IGlzDSAgIHVzZWQgYnkgc2V2ZXJhbCBNQXMgdGhhdCB1c2UgdGhlIHNhbWUgTWVhc3VyZW1l bnQgTWV0aG9kIHdpdGggdGhlDSAgIHNhbWUgSW5wdXQgUGFyYW1ldGVycy4gIEhlbmNlIHRo ZSBDeWNsZS1JRCBhbGxvd3MgdGhlIENvbGxlY3RvciB0bw0gICBlYXNpbHkgaWRlbnRpZnkg TWVhc3VyZW1lbnQgUmVzdWx0cyB0aGF0IHNob3VsZCBiZSBjb21wYXJhYmxlLg0NICAgRGF0 YSBNb2RlbDogVGhlIGltcGxlbWVudGF0aW9uIG9mIGFuIEluZm9ybWF0aW9uIE1vZGVsIGlu IGENICAgcGFydGljdWxhciBkYXRhIG1vZGVsbGluZyBsYW5ndWFnZS4NDSAgIEVudmlyb25t ZW50YWwgQ29uc3RyYWludDogQSBwYXJhbWV0ZXIgdGhhdCBpcyBtZWFzdXJlZCBhcyBwYXJ0 IG9mIHRoZQ0gICBNZWFzdXJlbWVudCBUYXNrLCBpdHMgdmFsdWUgZGV0ZXJtaW5pbmcgd2hl dGhlciB0aGUgcmVzdCBvZiB0aGUNICAgTWVhc3VyZW1lbnQgVGFzayBwcm9jZWVkcy4NDSAg IEZhaWx1cmUgSW5mb3JtYXRpb246IEluZm9ybWF0aW9uIGFib3V0IHRoZSBNQSdzIGZhaWx1 cmUgdG8gYWN0aW9uIG9yDSAgIGV4ZWN1dGUgYW4gSW5zdHJ1Y3Rpb24sIHdoZXRoZXIgY29u Y2VybmluZyBNZWFzdXJlbWVudCBUYXNrcyBvcg0gICBSZXBvcnRpbmcuDQ0gICBHcm91cC1J RDogKG9wdGlvbmFsKSBBbiBpZGVudGlmaWVyIG9mIGEgZ3JvdXAgb2YgTUFzLg0NDQ0NRWFy ZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQgICAgICAgICAg ICAgICAgIFtQYWdlIDldDQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExNQVAgRnJh bWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQNDQ0gICBJbmZvcm1hdGlvbiBN b2RlbDogVGhlIHByb3RvY29sLW5ldXRyYWwgZGVmaW5pdGlvbiBvZiB0aGUgc2VtYW50aWNz DSAgIG9mIHRoZSBJbnN0cnVjdGlvbnMsIHRoZSBSZXBvcnQsIHRoZSBzdGF0dXMgb2YgdGhl IGRpZmZlcmVudCBlbGVtZW50cw0gICBvZiB0aGUgbWVhc3VyZW1lbnQgc3lzdGVtIGFzIHdl bGwgb2YgdGhlIGV2ZW50cyBpbiB0aGUgc3lzdGVtLg0NICAgSW5wdXQgUGFyYW1ldGVyOiBB IHBhcmFtZXRlciB3aG9zZSB2YWx1ZSBpcyBsZWZ0IG9wZW4gYnkgdGhlDSAgIE1lYXN1cmVt ZW50IE1ldGhvZCBhbmQgaXMgc2V0IHRvIGEgc3BlY2lmaWMgdmFsdWUgaW4gYSBNZWFzdXJl bWVudA0gICBUYXNrLiAgQWx0ZXJpbmcgdGhlIHZhbHVlIG9mIGFuIElucHV0IFBhcmFtZXRl ciBkb2VzIG5vdCBjaGFuZ2UgdGhlDSAgIGZ1bmRhbWVudGFsIG5hdHVyZSBvZiB0aGUgTWVh c3VyZW1lbnQgTWV0aG9kLg0NICAgSW5zdHJ1Y3Rpb246IFRoZSBkZXNjcmlwdGlvbiBvZiBN ZWFzdXJlbWVudCBUYXNrcyB0byBwZXJmb3JtIGFuZCB0aGUNICAgZGV0YWlscyBvZiB0aGUg UmVwb3J0IHRvIHNlbmQuICBUaGUgSW5zdHJ1Y3Rpb24gaXMgc2VudCBieSBhDSAgIENvbnRy b2xsZXIgdG8gYSBNZWFzdXJlbWVudCBBZ2VudC4NDSAgIE1BLXRvLUNvbnRyb2xsZXIgQ2hh bm5lbDogYSBjb21tdW5pY2F0aW9ucyBjaGFubmVsIGJldHdlZW4gYSBNQSBhbmQgYQ0gICBD b250cm9sbGVyLCB3aGljaCBpcyBkZWZpbmVkIGJ5IGEgc3BlY2lmaWMgQ29udHJvbGxlciwg TUEgYW5kDSAgIGFzc29jaWF0ZWQgc2VjdXJpdHksIGFuZCBvdmVyIHdoaWNoIENhcGFiaWxp dGllcyBhbmQgRmFpbHVyZQ0gICBJbmZvcm1hdGlvbiBpcyBzZW50Lg0NICAgTWVhc3VyZW1l bnQgQWdlbnQgKE1BKTogVGhlIGZ1bmN0aW9uIHRoYXQgcmVjZWl2ZXMgSW5zdHJ1Y3Rpb25z IGZyb20NICAgYSBDb250cm9sbGVyLCBwZXJmb3JtcyBNZWFzdXJlbWVudCBUYXNrcyAocGVy aGFwcyBpbiBjb25jZXJ0IHdpdGggYQ0gICBNZWFzdXJlbWVudCBQZWVyKSBhbmQgcmVwb3J0 cyBNZWFzdXJlbWVudCBSZXN1bHRzIHRvIGEgQ29sbGVjdG9yLg0NICAgTWVhc3VyZW1lbnQg QWdlbnQgSWRlbnRpZmllciAoTUEtSUQpOiBhIFVVSUQgW1JGQzQxMjJdLCB3aGljaCBpcw0g ICBjb25maWd1cmVkIGFzIHBhcnQgb2YgdGhlIEJvb3RzdHJhcHBpbmcgYW5kIGluY2x1ZGVk IGluIGENICAgQ2FwYWJpbGl0aWVzIG1lc3NhZ2UsIEZhaWx1cmUgSW5mb3JtYXRpb24gbWVz c2FnZSBhbmQgb3B0aW9uYWxseSBpbiBhDSAgIFJlcG9ydC4NDSAgIE1lYXN1cmVtZW50IE1l dGhvZDogVGhlIHByb2Nlc3MgZm9yIGFzc2Vzc2luZyB0aGUgdmFsdWUgb2YgYSBNZXRyaWM7 DSAgIHRoZSBwcm9jZXNzIG9mIG1lYXN1cmluZyBzb21lIHBlcmZvcm1hbmNlIG9yIHJlbGlh YmlsaXR5IHBhcmFtZXRlcjsNICAgdGhlIGdlbmVyYWxpc2F0aW9uIG9mIGEgTWVhc3VyZW1l bnQgVGFzay4NDSAgIE1lYXN1cmVtZW50IFBlZXI6IFRoZSBmdW5jdGlvbiB0aGF0IHJlY2Vp dmVzIGNvbnRyb2wgbWVzc2FnZXMgYW5kDSAgIEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmlj IGZyb20gYSBNZWFzdXJlbWVudCBBZ2VudCBhbmQgbWF5IHJlcGx5IHRvDSAgIHRoZSBNZWFz dXJlbWVudCBBZ2VudCBhcyBkZWZpbmVkIGJ5IHRoZSBBY3RpdmUgTWVhc3VyZW1lbnQgTWV0 aG9kLg0NICAgTWVhc3VyZW1lbnQgUmVzdWx0OiBUaGUgb3V0cHV0IG9mIGEgc2luZ2xlIE1l YXN1cmVtZW50IFRhc2sgKHRoZQ0gICB2YWx1ZSBvYnRhaW5lZCBmb3IgdGhlIHBhcmFtZXRl ciBvZiBpbnRlcmVzdCBvciBNZXRyaWMpLg0NICAgTWVhc3VyZW1lbnQgU2NoZWR1bGU6IHRo ZSBzY2hlZHVsZSBmb3IgcGVyZm9ybWluZyBNZWFzdXJlbWVudCBUYXNrcy4NDSAgIE1lYXN1 cmVtZW50IFN1cHByZXNzaW9uOiBhIHR5cGUgb2YgSW5zdHJ1Y3Rpb24gdGhhdCB0ZW1wb3Jh cmlseSBzdG9wcw0gICAoc3VwcHJlc3NlcykgQWN0aXZlIE1lYXN1cmVtZW50IFRhc2tzLg0N ICAgTWVhc3VyZW1lbnQgVGFzazogVGhlIGFjdCB0aGF0IHlpZWxkcyBhIHNpbmdsZSBNZWFz dXJlbWVudCBSZXN1bHQ7DSAgIHRoZSBhY3QgY29uc2lzdGluZyBvZiB0aGUgKHNpbmdsZSkg b3BlcmF0aW9uIG9mIHRoZSBNZWFzdXJlbWVudA0gICBNZXRob2QgYXQgYSBwYXJ0aWN1bGFy IHRpbWUgYW5kIHdpdGggYWxsIGl0cyBwYXJhbWV0ZXJzIHNldCB0bw0gICBzcGVjaWZpYyB2 YWx1ZXMuDQ0NDQ1FYXJkbGV5LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSnVseSAyNSwg MjAxNCAgICAgICAgICAgICAgICBbUGFnZSAxMF0NDUludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgTE1BUCBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNA0NDSAg IE1ldHJpYzogVGhlIHF1YW50aXR5IHJlbGF0ZWQgdG8gdGhlIHBlcmZvcm1hbmNlIGFuZCBy ZWxpYWJpbGl0eSBvZg0gICB0aGUgbmV0d29yayB0aGF0IHdlJ2QgbGlrZSB0byBrbm93IHRo ZSB2YWx1ZSBvZiwgYW5kIHRoYXQgaXMNICAgY2FyZWZ1bGx5IHNwZWNpZmllZC4NDSAgIFBh c3NpdmUgTWVhc3VyZW1lbnQgTWV0aG9kIChUYXNrKTogBUEgTWVhc3VyZW1lbnQgTWV0aG9k IChUYXNrKSBpbg0gICB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IG9ic2VydmVzIGV4aXN0 aW5nIHRyYWZmaWMgYnV0IGRvZXMgbm90DSAgIGluamVjdCBBY3RpdmUgTWVhc3VyZW1lbnQg VHJhZmZpYy4NDSAgIFJlcG9ydDogVGhlIE1lYXN1cmVtZW50IFJlc3VsdHMgYW5kIG90aGVy IGFzc29jaWF0ZWQgaW5mb3JtYXRpb24gKGFzDSAgIGRlZmluZWQgYnkgdGhlIEluc3RydWN0 aW9uKS4gIFRoZSBSZXBvcnQgaXMgc2VudCBieSBhIE1lYXN1cmVtZW50DSAgIEFnZW50IHRv IGEgQ29sbGVjdG9yLg0NICAgUmVwb3J0IENoYW5uZWw6IGEgY29tbXVuaWNhdGlvbnMgY2hh bm5lbCBiZXR3ZWVuIGEgTUEgYW5kIGENICAgQ29sbGVjdG9yLCB3aGljaCBpcyBkZWZpbmVk IGJ5IGEgc3BlY2lmaWMgTUEsIENvbGxlY3RvciwgUmVwb3J0DSAgIFNjaGVkdWxlIGFuZCBh c3NvY2lhdGVkIHNlY3VyaXR5LCBhbmQgb3ZlciB3aGljaCBSZXBvcnRzIGFyZSBzZW50Lg0N ICAgUmVwb3J0IFByb3RvY29sOiBUaGUgcHJvdG9jb2wgZGVsaXZlcmluZyBSZXBvcnQocykg ZnJvbSBhIE1lYXN1cmVtZW50DSAgIEFnZW50IHRvIGEgQ29sbGVjdG9yLg0NICAgUmVwb3J0 IFNjaGVkdWxlOiB0aGUgc2NoZWR1bGUgZm9yIHNlbmRpbmcgb25lIG9yIG1vcmUgUmVwb3J0 cyB0byBhDSAgIENvbGxlY3Rvci4NDSAgIFN1YnNjcmliZXI6IEFuIGVudGl0eSAoYXNzb2Np YXRlZCB3aXRoIG9uZSBvciBtb3JlIHVzZXJzKSB0aGF0IGlzDSAgIGVuZ2FnZWQgaW4gYSBz dWJzY3JpcHRpb24gd2l0aCBhIHNlcnZpY2UgcHJvdmlkZXIuICBUaGUgU3Vic2NyaWJlciBp cw0gICBhbGxvd2VkIHRvIHN1YnNjcmliZSBhbmQgdW4tc3Vic2NyaWJlIHNlcnZpY2VzLCBh bmQgdG8gcmVnaXN0ZXIgYQ0gICB1c2VyIG9yIGEgbGlzdCBvZiB1c2VycyBhdXRob3JpemVk IHRvIGVuam95IHRoZXNlIHNlcnZpY2VzLiAgW1ExNzQxXQ0gICBCb3RoIHRoZSBTdWJzY3Jp YmVyIGFuZCBzZXJ2aWNlIHByb3ZpZGVyIGFyZSBhbGxvd2VkIHRvIHNldCB0aGUNICAgbGlt aXRzIHJlbGF0aXZlIHRvIHRoZSB1c2UgdGhhdCBhc3NvY2lhdGVkIHVzZXJzIG1ha2Ugb2Yg c3Vic2NyaWJlZA0gICBzZXJ2aWNlcy4NDTQuICBDb25zdHJhaW50cw0NICAgVGhlIExNQVAg ZnJhbWV3b3JrIG1ha2VzIHNvbWUgaW1wb3J0YW50IGFzc3VtcHRpb25zLCB3aGljaCBjb25z dHJhaW4NICAgdGhlIHNjb3BlIG9mIHRoZSB3b3JrIHRvIGJlIGRvbmUuDQ00LjEuICBNZWFz dXJlbWVudCBzeXN0ZW0gaXMgdW5kZXIgdGhlIGRpcmVjdGlvbiBvZiBhIHNpbmdsZSBvcmdh bmlzYXRpb24NDSAgIEluIHRoZSBMTUFQIGZyYW1ld29yaywgdGhlIG1lYXN1cmVtZW50IHN5 c3RlbSBpcyB1bmRlciB0aGUgZGlyZWN0aW9uDSAgIG9mIGEgc2luZ2xlIG9yZ2FuaXNhdGlv biB0aGF0IGlzIHJlc3BvbnNpYmxlIGJvdGggZm9yIHRoZSBkYXRhIGFuZA0gICB0aGUgcXVh bGl0eSBvZiBleHBlcmllbmNlIGRlbGl2ZXJlZCB0byBpdHMgdXNlcnMuICBDbGVhcg0gICBy ZXNwb25zaWJpbGl0eSBpcyBjcml0aWNhbCBnaXZlbiB0aGF0IGEgbWlzYmVoYXZpbmcgbGFy Z2Utc2NhbGUNICAgbWVhc3VyZW1lbnQgc3lzdGVtIGNvdWxkIHBvdGVudGlhbGx5IGhhcm0g dXNlciBleHBlcmllbmNlLCB1c2VyDSAgIHByaXZhY3kgYW5kIG5ldHdvcmsgc2VjdXJpdHku DQ0gICBIb3dldmVyLCB0aGUgY29tcG9uZW50cyBvZiBhbiBMTUFQIG1lYXN1cmVtZW50IHN5 c3RlbSBjYW4gYmUgZGVwbG95ZWQNICAgaW4gYWRtaW5pc3RyYXRpdmUgZG9tYWlucyB0aGF0 IGFyZSBub3Qgb3duZWQgYnkgdGhlIG1lYXN1cmluZw0gICBvcmdhbmlzYXRpb24uICBUaHVz LCB0aGUgc3lzdGVtIG9mIGZ1bmN0aW9ucyBkZXBsb3llZCBieSBhIHNpbmdsZQ0NDQ0NRWFy ZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQgICAgICAgICAg ICAgICAgW1BhZ2UgMTFdDQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExNQVAgRnJh bWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQNDQ0gICBvcmdhbmlzYXRpb24g Y29uc3RpdHV0ZXMgYSBzaW5nbGUgTE1BUCBkb21haW4gd2hpY2ggbWF5IHNwYW4NICAgb3du ZXJzaGlwIG9yIG90aGVyIGFkbWluaXN0cmF0aXZlIGJvdW5kYXJpZXMuDQ00LjIuICBFYWNo IE1BIG1heSBvbmx5IGhhdmUgYSBzaW5nbGUgQ29udHJvbGxlciBhdCBhbnkgcG9pbnQgaW4g dGltZQ0NICAgQSBNQSBpcyBpbnN0cnVjdGVkIGJ5IG9uZSBDb250cm9sbGVyIGFuZCBpcyBp biBvbmUgbWVhc3VyZW1lbnQNICAgc3lzdGVtLiAgVGhlIGNvbnN0cmFpbnQgYXZvaWRzIGRp ZmZlcmVudCBDb250cm9sbGVycyBnaXZpbmcgYSBNQQ0gICBjb25mbGljdGluZyBpbnN0cnVj dGlvbnMgYW5kIHNvIG1lYW5zIHRoYXQgdGhlIE1BIGRvZXMgbm90IGhhdmUgdG8NICAgbWFu YWdlIGNvbnRlbnRpb24gYmV0d2VlbiBtdWx0aXBsZSBNZWFzdXJlbWVudCAob3IgUmVwb3J0 KSBTY2hlZHVsZXMuDSAgIFRoaXMgc2ltcGxpZmllcyB0aGUgZGVzaWduIG9mIE1BcyAoY3Jp dGljYWwgZm9yIGEgbGFyZ2Utc2NhbGUNICAgaW5mcmFzdHJ1Y3R1cmUpIGFuZCBhbGxvd3Mg YSBNZWFzdXJlbWVudCBTY2hlZHVsZSB0byBiZSB0ZXN0ZWQgb24NICAgc3BlY2lmaWMgdHlw ZXMgb2YgTUEgYmVmb3JlIGRlcGxveW1lbnQgdG8gZW5zdXJlIHRoYXQgdGhlIGVuZCB1c2Vy DSAgIGV4cGVyaWVuY2UgaXMgbm90IGltcGFjdGVkIChkdWUgdG8gQ1BVLCBtZW1vcnkgb3Ig YnJvYWRiYW5kLXByb2R1Y3QNICAgY29uc3RyYWludHMpLg0NICAgQW4gb3BlcmF0b3IgbWF5 IGhhdmUgc2V2ZXJhbCBDb250cm9sbGVycywgcGVyaGFwcyB3aXRoIGEgQ29udHJvbGxlcg0g ICBmb3IgZGlmZmVyZW50IHR5cGVzIG9mIE1BIChob21lIGdhdGV3YXlzLCB0YWJsZXRzKSBv ciBsb2NhdGlvbg0gICAoSXBzd2ljaCwgRWRpbmJ1cmdoKS4NDTUuICBMTUFQIFByb3RvY29s IE1vZGVsDQ0gICBBIHByb3RvY29sIG1vZGVsIFtSRkM0MTAxXSBwcmVzZW50cyBhbiBhcmNo aXRlY3R1cmFsIG1vZGVsIGZvciBob3cNICAgdGhlIHByb3RvY29sIG9wZXJhdGVzIGFuZCBu ZWVkcyB0byBhbnN3ZXIgdGhyZWUgYmFzaWMgcXVlc3Rpb25zOg0NICAgMS4gIFdoYXQgcHJv YmxlbSBpcyB0aGUgcHJvdG9jb2wgdHJ5aW5nIHRvIGFjaGlldmU/DQ0gICAyLiAgV2hhdCBt ZXNzYWdlcyBhcmUgYmVpbmcgdHJhbnNtaXR0ZWQsIGFuZCB3aGF0IGRvIHRoZXkgbWVhbj8N DSAgIDMuICBXaGF0IGFyZSB0aGUgaW1wb3J0YW50LCBidXQgdW5vYnZpb3VzLCBmZWF0dXJl cyBvZiB0aGUgcHJvdG9jb2w/DQ0gICBBbiBMTUFQIHN5c3RlbSBnb2VzIHRocm91Z2ggdGhl IGZvbGxvd2luZyBwaGFzZXM6DQ0gICBvICBhIGJvb3RzdHJhcHBpbmcgcHJvY2VzcyBiZWZv cmUgdGhlIE1BIGNhbiB0YWtlIHBhcnQgaW4gdGhlIG90aGVyDSAgICAgIHRocmVlIHBoYXNl cw0NICAgbyAgYSBDb250cm9sIFByb3RvY29sLCB3aGljaCBkZWxpdmVycyBhbiBJbnN0cnVj dGlvbiBmcm9tIGENICAgICAgQ29udHJvbGxlciB0byBhIE1BLCBkZXRhaWxpbmcgd2hhdCBN ZWFzdXJlbWVudCBUYXNrcyB0aGUgTUEgc2hvdWxkDSAgICAgIHBlcmZvcm0gYW5kIHdoZW4s IGFuZCBob3cgaXQgc2hvdWxkIHJlcG9ydCB0aGUgTWVhc3VyZW1lbnQgUmVzdWx0cw0NICAg byAgdGhlIGFjdHVhbCBNZWFzdXJlbWVudCBUYXNrcyBhcmUgcGVyZm9ybWVkLiAgQW4gQWN0 aXZlIE1lYXN1cmVtZW50DSAgICAgIFRhc2sgaW52b2x2ZXMgc2VuZGluZyBBY3RpdmUgTWVh c3VyZW1lbnQgVHJhZmZpYyBiZXR3ZWVuIHRoZQ0gICAgICBNZWFzdXJlbWVudCBBZ2VudCBh bmQgYSBNZWFzdXJlbWVudCBQZWVyLCB3aGlsc3QgYSBQYXNzaXZlDSAgICAgIE1lYXN1cmVt ZW50IFRhc2sgaW52b2x2ZXMgKG9ubHkpIHRoZSBNZWFzdXJlbWVudCBBZ2VudCBvYnNlcnZp bmcNICAgICAgZXhpc3RpbmcgdXNlciB0cmFmZmljLiAgVGhlIExNQVAgV0cgZG9lcyBub3Qg ZGVmaW5lIE1lYXN1cmVtZW50DSAgICAgIE1ldGhvZHMsIGhvd2V2ZXIgdGhlIElQUE0gV0cg ZG9lcy4NDSAgIG8gIGEgUmVwb3J0IFByb3RvY29sLCB3aGljaCBkZWxpdmVycyBhIFJlcG9y dCBmcm9tIHRoZSBNQSB0byBhDSAgICAgIENvbGxlY3Rvci4gIFRoZSBSZXBvcnQgY29udGFp bnMgdGhlIE1lYXN1cmVtZW50IFJlc3VsdHMuDQ0NDUVhcmRsZXksIGV0IGFsLiAgICAgICAg ICAgRXhwaXJlcyBKdWx5IDI1LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0NSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBMTUFQIEZyYW1ld29yayAgICAgICAgICAgICAg ICAgSmFudWFyeSAyMDE0DQ0NICAgSW4gdGhlIGRpYWdyYW1zIHRoZSBmb2xsb3dpbmcgY29u dmVudGlvbiBpcyB1c2VkOg0NICAgbyAgKG9wdGlvbmFsKTogaW5kaWNhdGVkIGJ5IHJvdW5k IGJyYWNrZXRzDQ0gICBvICBbcG90ZW50aWFsbHkgcmVwZWF0ZWRdOiBpbmRpY2F0ZWQgYnkg c3F1YXJlIGJyYWNrZXRzDQ0gICBUaGUgcHJvdG9jb2wgbW9kZWwgaXMgY2xvc2VseSByZWxh dGVkIHRvIHRoZSBJbmZvcm1hdGlvbiBNb2RlbA0gICBbSS1ELmJ1cmJyaWRnZS1sbWFwLWlu Zm9ybWF0aW9uLW1vZGVsXSwgd2hpY2ggaXMgdGhlIGFic3RyYWN0DSAgIGRlZmluaXRpb24g b2YgdGhlIGluZm9ybWF0aW9uIGNhcnJpZWQgYnkgdGhlIHByb3RvY29sIG1vZGVsLiAgVGhl DSAgIHB1cnBvc2Ugb2YgYm90aCBpcyB0byBwcm92aWRlIGEgcHJvdG9jb2wgYW5kIGRldmlj ZSBpbmRlcGVuZGVudCB2aWV3LA0gICB3aGljaCBjYW4gYmUgaW1wbGVtZW50ZWQgdmlhIHNw ZWNpZmljIHByb3RvY29scy4gIFRoZSBMTUFQIFdHIHdpbGwNICAgZGVmaW5lIGEgc3BlY2lm aWMgQ29udHJvbCBQcm90b2NvbCBhbmQgUmVwb3J0IFByb3RvY29sLCBidXQgb3RoZXJzDSAg IGNvdWxkIGJlIGRlZmluZWQgYnkgb3RoZXIgc3RhbmRhcmRzIGJvZGllcyBvciBiZSBwcm9w cmlldGFyeS4NICAgSG93ZXZlciBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGV5IGFsbCBpbXBs ZW1lbnQgdGhlIHNhbWUgSW5mb3JtYXRpb24NICAgTW9kZWwgYW5kIHByb3RvY29sIG1vZGVs LCBpbiBvcmRlciB0byBlYXNlIHRoZSBkZWZpbml0aW9uLCBvcGVyYXRpb24NICAgYW5kIGlu dGVyb3BlcmFiaWxpdHkgb2YgbGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnQgc3lzdGVtcy4NDSAg IFRoZSBkaWFncmFtcyBzaG93IHRoZSB2YXJpb3VzIExNQVAgbWVzc2FnZXMgYW5kIFNlY3Rp b24gNS41IGNvbnNpZGVycw0gICBob3cgdGhleSBjb3VsZCBiZSBtYXBwZWQgb250byBhbiB1 bmRlcmx5aW5nIHRyYW5zcG9ydCBwcm90b2NvbC4NDTUuMS4gIEJvb3RzdHJhcHBpbmcgcHJv Y2Vzcw0NICAgVGhlIHByaW1hcnkgcHVycG9zZSBvZiBib290c3RyYXBwaW5nIGlzIHRvIGVu YWJsZSB0aGUgTUEgYW5kDSAgIENvbnRyb2xsZXIgdG8gYmUgaW50ZWdyYXRlZCBpbnRvIGEg bWVhc3VyZW1lbnQgc3lzdGVtLiAgSW4gb3JkZXIgdG8NICAgZG8gdGhhdCwgdGhlIE1BIG5l ZWRzIHRvIHJldHJpZXZlIGluZm9ybWF0aW9uIGFib3V0IGl0c2VsZiAobGlrZSBpdHMNICAg aWRlbnRpdHkgaW4gdGhlIG1lYXN1cmVtZW50IHN5c3RlbSksIGFib3V0IHRoZSBDb250cm9s bGVyLCBhcyB3ZWxsIGFzDSAgIHNlY3VyaXR5IGluZm9ybWF0aW9uIChzdWNoIGFzIGNlcnRp ZmljYXRlcyBhbmQgY3JlZGVudGlhbHMpLg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1FYXJk bGV5LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSnVseSAyNSwgMjAxNCAgICAgICAgICAg ICAgICBbUGFnZSAxM10NDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTE1BUCBGcmFt ZXdvcmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNA0NDQ0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LSsNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8IE1lYXN1cmVtZW50ICB8DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgQWdlbnQgICAgICAgfA0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLSsNICAgKGluaXRpYWwgQ29udHJvbGxlciBkZXRhaWxzOg0gICAgYWRkcmVzcyBvciBG UUROLCAgICAgICAgICAgICAgICAgICAgICAtPg0gICAgc2VjdXJpdHkgY3JlZGVudGlhbHMp DQ0gICArLS0tLS0tLS0tLS0tLS0tLS0rDSAgIHwgICAgaW5pdGlhbCAgICAgIHwNICAgfCAg IENvbnRyb2xsZXIgICAgfA0gICArLS0tLS0tLS0tLS0tLS0tLS0rDSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtICAgICAgICAgICAgICAocmVnaXN0ZXIp DQ0gICBDb250cm9sbGVyIGRldGFpbHM6DSAgICBhZGRyZXNzIG9yIEZRRE4sICAgICAgICAg ICAgICAgICAgICAgIC0+DSAgICBzZWN1cml0eSBjcmVkZW50aWFscw0NICAgKy0tLS0tLS0t LS0tLS0tLS0tKw0gICB8ICAgICAgICAgICAgICAgICB8DSAgIHwgICBDb250cm9sbGVyICAg IHwNICAgKy0tLS0tLS0tLS0tLS0tLS0tKw0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8LSAgICAgICAgICAgICAgcmVnaXN0ZXINICAgTUEtSUQsIChHcm91 cC1JRCksICAgICAgICAgICAgICAgICAgICAgLT4NICAgQ29udHJvbCBDaGFubmVsLA0gICAo U3VwcHJlc3Npb24gQ2hhbm5lbCksDSAgIE1BLXRvLUNvbnRyb2xsZXIgQ2hhbm5lbA0NICAg VGhlIE1BIGtub3dzIGhvdyB0byBjb250YWN0IGEgQ29udHJvbGxlciB0aHJvdWdoIHNvbWUg ZGV2aWNlIC9hY2Nlc3MNICAgc3BlY2lmaWMgbWVjaGFuaXNtLiAgRm9yIGV4YW1wbGUsIHRo aXMgY291bGQgYmUgaW4gdGhlIGZpcm13YXJlLA0gICBkb3dubG9hZGVkLCBtYW51YWxseSBj b25maWd1cmVkIG9yIHZpYSBhIHByb3RvY29sIGxpa2UgVFItMDY5LiAgVGhlDSAgIENvbnRy b2xsZXIgY291bGQgZWl0aGVyIGJlIHRoZSBvbmUgdGhhdCB3aWxsIHNlbmQgaXQgSW5zdHJ1 Y3Rpb25zIG9yDSAgIGVsc2UgYW4gaW5pdGlhbCBDb250cm9sbGVyICh3aG9zZSBkZXRhaWxz IG1heSBiZSBzdGF0aWNhbGx5DSAgIGNvbmZpZ3VyZWQpLiAgVGhlIHJvbGUgb2YgYW4gaW5p dGlhbCBDb250cm9sbGVyIGlzIHNpbXBseSB0byBpbmZvcm0NICAgdGhlIE1BIGhvdyB0byBj b250YWN0IGl0cyBhY3R1YWwgQ29udHJvbGxlciwgZm9yIGV4YW1wbGUgaXRzIEZRRE4NICAg KEZ1bGx5IFF1YWxpZmllZCBEb21haW4gTmFtZSkgW1JGQzEwMzVdLg0NICAgVGhlIE1BIGxl YXJucyBpdHMgaWRlbnRpZmllciAoTUEtSUQpLiAgSXQgbWF5IGFsc28gYmUgdG9sZCBhIEdy b3VwLUlEDSAgIGFuZCB3aGV0aGVyIHRvIGluY2x1ZGUgdGhlIE1BLUlEIGFzIHdlbGwgYXMg dGhlIEdyb3VwLUlEIGluIGl0cw0gICBSZXBvcnRzLiAgQSBHcm91cC1JRCB3b3VsZCBiZSBz aGFyZWQgYnkgc2V2ZXJhbCBNQXMgYW5kIGNvdWxkIGJlDSAgIHVzZWZ1bCBmb3IgcHJpdmFj eSByZWFzb25zLCBmb3IgaW5zdGFuY2UgdG8gaGluZGVyIHRyYWNraW5nIG9mIGENICAgbW9i aWxlIGRldmljZS4NDSAgIFRoZSBNQSBpcyBhbHNvIHRvbGQgYWJvdXQgdGhlIENvbnRyb2wg Q2hhbm5lbCBvdmVyIHdoaWNoIGl0IHdpbGwNICAgcmVjZWl2ZSBJbnN0cnVjdGlvbnMgZnJv bSB0aGUgQ29udHJvbGxlciwgaW4gcGFydGljdWxhciB0aGUNICAgYXNzb2NpYXRlZCBzZWN1 cml0eSBpbmZvcm1hdGlvbiwgZm9yIGV4YW1wbGUgdG8gZW5hYmxlIHRoZSBNQSB0bw0gICBk ZWNyeXB0IHRoZSBJbnN0cnVjdGlvbi4gIE9wdGlvbmFsbHkgYW55IFN1cHByZXNzaW9uIG1l c3NhZ2VzIGNhbiBiZQ0gICBzZW50IG92ZXIgYSBkaWZmZXJlbnQgQ2hhbm5lbC4gIFRoZSBN QSBpcyBhbHNvIGluZm9ybWVkIGFib3V0IHRoZSBNQS0NDQ0NRWFyZGxleSwgZXQgYWwuICAg ICAgICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMTRd DQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAg ICAgICAgICBKYW51YXJ5IDIwMTQNDQ0gICB0by1Db250cm9sbGVyIENoYW5uZWwsIG92ZXIg d2hpY2ggdGhlIE1BIGNhbiB0ZWxsIHRoZSBDb250cm9sbGVyDSAgIGFib3V0IGl0cyBDYXBh YmlsaXRpZXMgYW5kIGFueSBGYWlsdXJlIEluZm9ybWF0aW9uLiAgVGhpcyBjb25zaXN0cyBv Zg0gICB0aGUgYWRkcmVzcyBvZiB0aGUgQ29udHJvbGxlciwgZm9yIGluc3RhbmNlIGl0cyBV UkwsIGFuZCBzZWN1cml0eQ0gICBkZXRhaWxzIGZvciBNQS10by1Db250cm9sbGVyIG1lc3Nh Z2VzLg0NICAgVGhlIE1BIG1heSB0ZWxsIHRoZSBDb250cm9sbGVyIGl0cyBDYXBhYmlsaXRp ZXMsIGluIHBhcnRpY3VsYXIgdGhlDSAgIE1lYXN1cmVtZW50IE1ldGhvZHMgaXQgY2FuIHBl cmZvcm0uDQ0gICBJZiB0aGUgZGV2aWNlIHdpdGggdGhlIE1BIHJlLWJvb3RzLCB0aGVuIHRo ZSBNQSBuZWVkcyB0byByZS1yZWdpc3RlciwNICAgc28gdGhhdCBpdCBjYW4gcmVjZWl2ZSBh IG5ldyBJbnN0cnVjdGlvbi4gIFRvIGF2b2lkIGEgIm1hc3MgY2FsbGluZw0gICBldmVudCIg YWZ0ZXIgYSB3aWRlc3ByZWFkIHBvd2VyIHJlc3RvcmF0aW9uIGFmZmVjdGluZyBtYW55IE1B cywgaXQgaXMNICAgc2Vuc2libGUgZm9yIGFuIE1BIHRvIHBhdXNlIGZvciBhIHJhbmRvbSBk ZWxheSAocGVyaGFwcyBpbiB0aGUgcmFuZ2UNICAgb2Ygb25lIG1pbnV0ZSBvciBzbykgYmVm b3JlIHJlLXJlZ2lzdGVyaW5nLg0NICAgV2hpbHN0IHRoZSBMTUFQIFdHIGNvbnNpZGVycyB0 aGUgYm9vdHN0cmFwcGluZyBwcm9jZXNzLCBpdCBpcyBvdXQgb2YNICAgc2NvcGUgdG8gZGVm aW5lIGEgYm9vdHN0cmFwIG1lY2hhbmlzbSwgYXMgaXQgZGVwZW5kcyBvbiB0aGUgdHlwZSBv Zg0gICBkZXZpY2UgYW5kIGFjY2Vzcy4NDTUuMi4gIENvbnRyb2wgUHJvdG9jb2wNDSAgIFRo ZSBwcmltYXJ5IHB1cnBvc2Ugb2YgdGhlIENvbnRyb2wgUHJvdG9jb2wgaXMgdG8gYWxsb3cg dGhlDSAgIENvbnRyb2xsZXIgdG8gY29uZmlndXJlIGEgTWVhc3VyZW1lbnQgQWdlbnQgd2l0 aCBhbiBJbnN0cnVjdGlvbiBhYm91dA0gICB3aGF0IE1lYXN1cmVtZW50IFRhc2tzIHRvIGRv LCB3aGVuIHRvIGRvIHRoZW0sIGFuZCBob3cgdG8gcmVwb3J0IHRoZQ0gICBNZWFzdXJlbWVu dCBSZXN1bHRzLiAgVGhlIE1lYXN1cmVtZW50IEFnZW50IHRoZW4gYWN0cyBvbiB0aGUNICAg SW5zdHJ1Y3Rpb24gYXV0b25vbW91c2x5Lg0NKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDXwgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgTWVhc3VyZW1l bnQgfA18ICBDb250cm9sbGVyICAgICB8PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT18ICBBZ2VudCAgICAgIHwNKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQ0oQ2FwYWJpbGl0aWVzIHJl cXVlc3QpICAgICAgICAgICAgICAgICAgIC0+DSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPC0gICAgICAgICAgICBDYXBhYmlsaXRpZXMNQUNLICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtPg0NDUluc3RydWN0aW9uOg1bKE1lYXN1 cmVtZW50IFRhc2sgKElucHV0IFBhcmFtZXRlcnMpKSwgIC0+DSAoTWVhc3VyZW1lbnQgU2No ZWR1bGUpLA0gKFJlcG9ydCBDaGFubmVsKHMpKV0NICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8LSAgICAgICAgICAgICAgQUNLDQ0NICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8LSAgICAgICAgIEZhaWx1cmUgSW5mb3JtYXRp b246DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbcmVhc29uXQ1BQ0sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0+ DQ0NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQg ICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg IExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQNDQ0gICBUaGUg Q29udHJvbGxlciBuZWVkcyB0byBrbm93IHRoZSBDYXBhYmlsaXRpZXMgb2YgdGhlIE1BLCBh bmQgaW4NICAgcGFydGljdWxhciB3aGF0IE1lYXN1cmVtZW50IE1ldGhvZHMgaXQgc3VwcG9y dHMsIHNvIHRoYXQgaXQgY2FuDSAgIGNvcnJlY3RseSBpbnN0cnVjdCB0aGUgTUEuICBJdCBp cyBwb3NzaWJsZSB0aGF0IHRoZSBDb250cm9sbGVyIGtub3dzDSAgIHRoZSBNQSdzIENhcGFi aWxpdGllcyB2aWEgc29tZSBtZWNoYW5pc20gYmV5b25kIHRoZSBzY29wZSBvZiBMTUFQLA0g ICBzdWNoIGFzIGEgZGV2aWNlLXNwZWNpZmljIHByb3RvY29sLiAgSW4gTE1BUCwgdGhlIE1B IGNhbiBpbmZvcm0gdGhlDSAgIENvbnRyb2xsZXIgYWJvdXQgaXRzIENhcGFiaWxpdGllcy4g IFRoaXMgbWVzc2FnZSBjb3VsZCBiZSBzZW50IGluDSAgIHNldmVyYWwgY2lyY3Vtc3RhbmNl czogd2hlbiB0aGUgTUEgZmlyc3QgY29tbXVuaWNhdGVzIHdpdGggYQ0gICBDb250cm9sbGVy OyB3aGVuIHRoZSBNQSBiZWNvbWVzIGNhcGFibGUgb2YgYSBuZXcgTWVhc3VyZW1lbnQgTWV0 aG9kOw0gICB3aGVuIHJlcXVlc3RlZCBieSB0aGUgQ29udHJvbGxlciAoZm9yIGV4YW1wbGUs IGlmIHRoZSBDb250cm9sbGVyDSAgIGZvcmdldHMgd2hhdCB0aGUgTUEgY2FuIGRvIG9yIG90 aGVyd2lzZSB3YW50cyB0byByZXN5bmNocm9uaXplIHdoYXQNICAgaXQga25vd3MgYWJvdXQg dGhlIE1BKS4gIAVOb3RlIHRoYXQgQ2FwYWJpbGl0aWVzIGRvIG5vdCBpbmNsdWRlDSAgIGR5 bmFtaWMgaW5mb3JtYXRpb24gbGlrZSB0aGUgTUEncyBjdXJyZW50bHkgdW51c2VkIENQVSwg bWVtb3J5IG9yDSAgIGJhdHRlcnkgbGlmZS4NDSAgIEEgc2luZ2xlIEluc3RydWN0aW9uIG1l c3NhZ2UgY29udGFpbnMgb25lLCB0d28sIHRocmVlIG9yIGFsbCBmb3VyBSBvZg0gICB0aGUg Zm9sbG93aW5nIGVsZW1lbnRzOg0NICAgbyAgY29uZmlndXJhdGlvbiBvZiBhbGwgdGhlIE1l YXN1cmVtZW50IFRhc2tzLCBlYWNoIG9mIHdoaWNoIG5lZWRzOg0NICAgICAgKiAgdGhlIE1l YXN1cmVtZW50IE1ldGhvZCwgc3BlY2lmaWVkIGFzIGEgVVJOIHRvIGEgcmVnaXN0cnkgZW50 cnkuDSAgICAgICAgIFRoZSByZWdpc3RyeSBjb3VsZCBiZSBkZWZpbmVkIGJ5IHRoZSBJRVRG DSAgICAgICAgIFtJLUQuYmFnbnVsby1pcHBtLW5ldy1yZWdpc3RyeS1pbmRlcGVuZGVudF0s IGxvY2FsbHkgYnkgdGhlDSAgICAgICAgIG9wZXJhdG9yIG9mIHRoZSBtZWFzdXJlbWVudCBz eXN0ZW0gb3IgcGVyaGFwcyBieSBhbm90aGVyDSAgICAgICAgIHN0YW5kYXJkcyBvcmdhbmlz YXRpb24uDQ0gICAgICAqICBhbnkgSW5wdXQgUGFyYW1ldGVycyB0aGF0IG5lZWQgdG8gYmUg c2V0IGZvciB0aGUgTWVhc3VyZW1lbnQNICAgICAgICAgTWV0aG9kLCBzdWNoIGFzIHRoZSBh ZGRyZXNzIG9mIHRoZSBNZWFzdXJlbWVudCBQZWVyDQ0gICAgICAqICBpZiB0aGUgZGV2aWNl IHdpdGggdGhlIE1BIGhhcyBtdWx0aXBsZSBpbnRlcmZhY2VzLCB0aGVuIHRoZQ0gICAgICAg ICBpbnRlcmZhY2UgdG8gdXNlDQ0gICAgICAqICBvcHRpb25hbGx5LCBhIEN5Y2xlLUlEDQ0g ICAgICAqICBhIG5hbWUgZm9yIHRoaXMgZWFjaCBNZWFzdXJlbWVudCBUYXNrIGNvbmZpZ3Vy YXRpb24FDQ0gICBvICBjb25maWd1cmF0aW9uIG9mIGFsbCB0aGUgUmVwb3J0IENoYW5uZWxz LCBlYWNoIG9mIHdoaWNoIG5lZWRzOg0NICAgICAgKiAgdGhlIGFkZHJlc3Mgb2YgdGhlIENv bGxlY3RvciwgZm9yIGluc3RhbmNlIGl0cyBVUkwNDSAgICAgICogIHRoZSB0aW1pbmcgb2Yg d2hlbiB0byByZXBvcnQgTWVhc3VyZW1lbnQgUmVzdWx0cywgZm9yIGV4YW1wbGUNICAgICAg ICAgZXZlcnkgaG91ciBvciBpbW1lZGlhdGVseQ0NICAgICAgKiAgc2VjdXJpdHkgZm9yIHNl bmRpbmcgdGhlIFJlcG9ydCwgZm9yIGV4YW1wbGUgdGhlIFguNTA5DSAgICAgICAgIGNlcnRp ZmljYXRlDQ0gICAgICAqICBhIG5hbWUgZm9yIHRoaXMgZWFjaCBSZXBvcnQgQ2hhbm5lbAUg ZW50cnkNDSAgIG8gIHRoZSBzZXQgb2YgcGVyaW9kaWMgTWVhc3VyZW1lbnQgU2NoZWR1bGVz LCBlYWNoIG9mIHdoaWNoIG5lZWRzOg0NDQ1FYXJkbGV5LCBldCBhbC4gICAgICAgICAgIEV4 cGlyZXMgSnVseSAyNSwgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSAxNl0NDUludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgTE1BUCBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEph bnVhcnkgMjAxNA0NDSAgICAgICogIHRoZSBuYW1lIG9mIG9uZSBvciBzZXZlcmFsIE1lYXN1 cmVtZW50IFRhc2sgY29uZmlndXJhdGlvbnMNDSAgICAgICogIHRoZSB0aW1pbmcgb2Ygd2hl biB0aGUgTWVhc3VyZW1lbnQgVGFza3MgYXJlIHRvIGJlIHBlcmZvcm1lZC4NICAgICAgICAg UG9zc2libGUgdHlwZXMgb2YgdGltaW5nIGFyZSBwZXJpb2RpYyBhbmQgY2FsZW5kYXItYmFz ZWQNICAgICAgICAgcGVyaW9kaWMNDSAgICAgICogIHRoZSBuYW1lIG9mIGEgUmVwb3J0IENo YW5uZWwgb3IgQ2hhbm5lbHMgb24gd2hpY2ggdG8gcmVwb3J0IHRoZQ0gICAgICAgICBNZWFz dXJlbWVudCBSZXN1bHRzDQ0gICAgICAqICBhIG5hbWUgZm9yIHRoaXMgZWFjaCBNZWFzdXJl bWVudCBTY2hlZHVsZQUgZW50cnkNDSAgIG8gIHRoZSBzZXQgb2Ygb25lLW9mZiBNZWFzdXJl bWVudCBTY2hlZHVsZXMsIGVhY2ggb2Ygd2hpY2ggbmVlZHMgdGhlDSAgICAgIHNhbWUgaXRl bXMgYXMgZm9yIGEgcGVyaW9kaWMgTWVhc3VyZW1lbnQgU2NoZWR1bGUsIGV4Y2VwdCB0aGF0 IHRoZQ0gICAgICBwb3NzaWJsZSB0eXBlcyBvZiB0aW1pbmcgYXJlIG9uZS1vZmYgaW1tZWRp YXRlIGFuZCBvbmUtb2ZmIGF0IGENICAgICAgZnV0dXJlIHRpbWUuDQ0gICBBIHNpbmdsZSBJ bnN0cnVjdGlvbiBtZXNzYWdlIGNvbnRhaW5zIG9uZSwgdHdvLCB0aHJlZSBvciBhbGwgZm91 ciAFb2YNICAgdGhlIGFib3ZlIGVsZW1lbnRzLiAgVGhpcyBhbGxvd3MgdGhlIGRpZmZlcmVu dCBlbGVtZW50cyB0byBiZSB1cGRhdGVkDSAgIGluZGVwZW5kZW50bHkgYXQgZGlmZmVyZW50 IHRpbWVzIGFuZCBpbnRlcnZhbHMsIGZvciBleGFtcGxlIGl0IGlzDSAgIGxpa2VseSB0aGF0 IHRoZSBwZXJpb2RpYyBNZWFzdXJlbWVudCBTY2hlZHVsZSB3aWxsIGJlIHVwZGF0ZWQgbW9y ZQ0gICBvZnRlbiB0aGFuIHRoZSBvdGhlciBlbGVtZW50cy4NDSAgIE5vdGUgdGhhdCBhbiBJ bnN0cnVjdGlvbiBtZXNzYWdlIHJlcGxhY2VzIChyYXRoZXIgdGhhbiBhZGRzIHRvKSB0aG9z ZQ0gICBlbGVtZW50cyB0aGF0IGl0IGluY2x1ZGVzLiAgRm9yIGV4YW1wbGUsIGlmIHRoZSBt ZXNzYWdlIGluY2x1ZGVzDSAgIChvbmx5KSBhIHBlcmlvZGljIE1lYXN1cmVtZW50IFNjaGVk dWxlLCB0aGVuIHRoYXQgcmVwbGFjZXMgdGhlIG9sZA0gICBwZXJpb2RpYyBNZWFzdXJlbWVu dCBTY2hlZHVsZSBidXQgZG9lcyBub3QgYWx0ZXIgdGhlIGNvbmZpZ3VyYXRpb24gb2YNICAg dGhlIE1lYXN1cmVtZW50IFRhc2tzIGFuZCBSZXBvcnQgQ2hhbm5lbHMuDQ0gICBQZXJpb2Rp YyBNZWFzdXJlbWVudCBTY2hlZHVsZXMgY29udGFpbiB0aGUgbmFtZSBvZiBvbmUgb3Igc2V2 ZXJhbA0gICBNZWFzdXJlbWVudCBUYXNrIGNvbmZpZ3VyYXRpb25zIHRoYXQgYXJlIHRvIGJl IGNhcnJpZWQgb3V0IG9uIGENICAgcmVjdXJyaW5nIGJhc2lzLCB3aGlsc3Qgb25lLW9mZiBN ZWFzdXJlbWVudCBTY2hlZHVsZXMgY29udGFpbiBub24tDSAgIHJlY3VycmluZyBNZWFzdXJl bWVudCBUYXNrcy4gIE9uZS1vZmYgYW5kIHBlcmlvZGljIE1lYXN1cmVtZW50DSAgIFNjaGVk dWxlcyBhcmUga2VwdCBzZXBhcmF0ZSBzbyB0aGF0IHRoZSBDb250cm9sbGVyIGNhbiBpbnN0 cnVjdCB0aGUNICAgTUEgdG8gcGVyZm9ybSBhbiBhZCBob2MgTWVhc3VyZW1lbnQgVGFzayAo Zm9yIGluc3RhbmNlIHRvIGhlbHANICAgaXNvbGF0ZSBhIGZhdWx0KSB3aXRob3V0IGhhdmlu ZyB0byByZS1ub3RpZnkgdGhlIE1BIGFib3V0IHRoZQ0gICBwZXJpb2RpYyBNZWFzdXJlbWVu dCBTY2hlZHVsZS4NDSAgIE5vdGUgdGhhdCB0aGUgSW5zdHJ1Y3Rpb24gaW5mb3JtcyB0aGUg TUE7IHRoZSBDb250cm9sIFByb3RvY29sIGRvZXMNICAgbm90IGFsbG93IHRoZSBNQSB0byBu ZWdvdGlhdGUsIGFzIHRoaXMgd291bGQgYWRkIGNvbXBsZXhpdHkgdG8gdGhlDSAgIE1BLCBD b250cm9sbGVyIGFuZCBDb250cm9sIFByb3RvY29sIGZvciBsaXR0bGUgYmVuZWZpdC4NDSAg IFRoZSBNQSBjYW4gaW5mb3JtIHRoZSBDb250cm9sbGVyIGFib3V0IGEgRmFpbHVyZS4gIFRo ZXJlIGFyZSB0d28NICAgYnJvYWQgY2F0ZWdvcmllcyBvZiBmYWlsdXJlOiAoMSkgdGhlIE1B IGNhbm5vdCBhY3Rpb24gdGhlIEluc3RydWN0aW9uDSAgIChmb3IgZXhhbXBsZSwgaXQgZG9l c24ndCBpbmNsdWRlIGEgcGFyYW1ldGVyIHRoYXQgaXMgbWFuZGF0b3J5IGZvcg0gICB0aGUg cmVxdWVzdGVkIE1lYXN1cmVtZW50IE1ldGhvZDsgb3IgaXQgaXMgbWlzc2luZyBkZXRhaWxz IG9mIHRoZQ0gICB0YXJnZXQgQ29sbGVjdG9yKS4gKDIpIHRoZSBNQSBjYW5ub3QgZXhlY3V0 ZSB0aGUgTWVhc3VyZW1lbnQgVGFzayBvcg0gICBkZWxpdmVyIHRoZSBSZXBvcnQgKGZvciBl eGFtcGxlLCB0aGUgTUEgdW5leHBlY3RlZGx5IGhhcyBubyBzcGFyZSBDUFUNICAgY3ljbGVz OyBvciB0aGUgQ29sbGVjdG9yIGlzIG5vdCByZXNwb25kaW5nKS4gIE5vdGUgdGhhdCBpdCBp cyBub3QNDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjUsIDIw MTQgICAgICAgICAgICAgICAgW1BhZ2UgMTddDQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQNDQ0gICBj b25zaWRlcmVkIGEgZmFpbHVyZSBpZiBhIE1lYXN1cmVtZW50IFRhc2sgKGNvcnJlY3RseSkg ZG9lc24ndCBzdGFydDsNICAgZm9yIGV4YW1wbGUgaWYgdGhlIE1BIGRldGVjdHMgY3Jvc3Mt dHJhZmZpYywgdGhpcyBpcyByZXBvcnRlZCB0byB0aGUNICAgQ29sbGVjdG9yIGluIHRoZSBu b3JtYWwgbWFubmVyLiAgTm90ZSBhbHNvIHRoYXQgdGhlIE1BIGRvZXMgbm90DSAgIGluZm9y bSB0aGUgQ29udHJvbGxlciBhYm91dCBub3JtYWwgb3BlcmF0aW9uIG9mIGl0cyBNZWFzdXJl bWVudCBUYXNrcw0gICBhbmQgUmVwb3J0cy4NDSAgIEluIHRoZSBGaWd1cmUsIEFDSyBtZWFu cyB0aGF0IHRoZSBtZXNzYWdlIGhhcyBiZWVuIGRlbGl2ZXJlZA0gICBzdWNjZXNzZnVsbHku DQ0gICBGaW5hbGx5LCBub3RlIHRoYXQgdGhlIE1BIGRvZXNuJ3QgZG8gYSAnc2FmZXR5IGNo ZWNrJyB3aXRoIHRoZQ0gICBDb250cm9sbGVyICh0aGF0IGl0IHNob3VsZCBzdGlsbCBjb250 aW51ZSB3aXRoIHRoZSByZXF1ZXN0ZWQNICAgTWVhc3VyZW1lbnQgVGFza3MpIC0gbm9yIGRv ZXMgaXQgaW5mb3JtIHRoZSBDb250cm9sbGVyIGFib3V0DSAgIE1lYXN1cmVtZW50IFRhc2tz IHN0YXJ0aW5nIGFuZCBzdG9wcGluZy4gIEl0IHNpbXBseSBjYXJyaWVzIG91dCB0aGUNICAg TWVhc3VyZW1lbnQgVGFza3MgYXMgaW5zdHJ1Y3RlZCwgdW5sZXNzIGl0IGdldHMgYW4gdXBk YXRlZA0gICBJbnN0cnVjdGlvbi4NDSAgIFRoZSBMTUFQIFdHIHdpbGwgZGVmaW5lIGEgQ29u dHJvbCBQcm90b2NvbCBhbmQgaXRzIGFzc29jaWF0ZWQgRGF0YQ0gICBNb2RlbCB0aGF0IGlt cGxlbWVudHMgdGhlIFByb3RvY29sICYgSW5mb3JtYXRpb24gTW9kZWwuICBUaGlzIG1heSBi ZQ0gICBhIHNpbXBsZSBpbnN0cnVjdGlvbi1yZXNwb25zZSBwcm90b2NvbC4NDTUuMi4xIENv bnRyb2wgUHJvdG9jb2wgYW5kIE1lYXN1cmVtZW50IFBlZXJzBQ0NNS4yLjEuICBNZWFzdXJl bWVudCBTdXBwcmVzc2lvbg0NICAgTWVhc3VyZW1lbnQgU3VwcHJlc3Npb24gaXMgdXNlZCBp ZiB0aGUgbWVhc3VyZW1lbnQgc3lzdGVtIHdhbnRzIHRvDSAgIGVsaW1pbmF0ZSBpbmVzc2Vu dGlhbCB0cmFmZmljLCBiZWNhdXNlIHRoZXJlIGlzIHNvbWUgdW5leHBlY3RlZA0gICBuZXR3 b3JrIGlzc3VlIGZvciBleGFtcGxlLiAgVGhlIENvbnRyb2xsZXIgaW5zdHJ1Y3RzIHRoZSBN QSB0bw0gICB0ZW1wb3JhcmlseSBub3QgYmVnaW4gbmV3IEFjdGl2ZSBNZWFzdXJlbWVudCBU YXNrcy4gIEJ5IGRlZmF1bHQsDSAgIHN1cHByZXNzaW9uIGFwcGxpZXMgdG8gYWxsIEFjdGl2 ZSBNZWFzdXJlbWVudCBUYXNrcywgc3RhcnRzDSAgIGltbWVkaWF0ZWx5IGFuZCBjb250aW51 ZXMgdW50aWwgYW4gdW4tc3VwcHJlc3MgbWVzc2FnZSBpcyByZWNlaXZlZC4NICAgT3B0aW9u YWxseSB0aGUgc3VwcHJlc3MgbWVzc2FnZSBtYXkgaW5jbHVkZToNDSAgIG8gIGEgc2V0IG9m IEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrcyB0byBzdXBwcmVzczsgdGhlIG90aGVycyBhcmUg bm90DSAgICAgIHN1cHByZXNzZWQuICBGb3IgZXhhbXBsZSwgYSBwYXJ0aWN1bGFyIE1lYXN1 cmVtZW50IFRhc2sgbWF5IGJlDSAgICAgIG92ZXJsb2FkaW5nIGEgTWVhc3VyZW1lbnQgUGVl ci4NDSAgIG8gIGEgc2V0IG9mIE1lYXN1cmVtZW50IFNjaGVkdWxlcyB0byBzdXBwcmVzczsg dGhlIG90aGVycyBhcmUgbm90DSAgICAgIHN1cHByZXNzZWQuICBGb3IgZXhhbXBsZSwgc3Vw cG9zZSB0aGUgbWVhc3VyZW1lbnQgc3lzdGVtIGhhcw0gICAgICBkZWZpbmVkIHR3byBTY2hl ZHVsZXMsIG9uZSB3aXRoIHRoZSBtb3N0IGNyaXRpY2FsIEFjdGl2ZQ0gICAgICBNZWFzdXJl bWVudCBUYXNrcyBhbmQgdGhlIG90aGVyIHdpdGggbGVzcyBjcml0aWNhbCBvbmVzIHRoYXQN ICAgICAgY3JlYXRlIGEgbG90IG9mIHRyYWZmaWMsIHRoZW4gaXQgbWF5IG9ubHkgd2FudCB0 byBzdXBwcmVzcyB0aGUNICAgICAgc2Vjb25kLg0NICAgbyAgYSBzdGFydCB0aW1lLCBhdCB3 aGljaCBzdXBwcmVzc2lvbiBiZWdpbnMNDSAgIG8gIGFuIGVuZCB0aW1lLCBhdCB3aGljaCBz dXBwcmVzc2lvbiBlbmRzLg0NICAgSXQgaXMgbm90IHN0YW5kYXJkaXNlZCB3aGF0IHRoZSBp bXBhY3Qgb2YgU3VwcHJlc3Npb24gaXMgb246DQ0NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAg ICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMThdDQ1J bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAg ICAgICBKYW51YXJ5IDIwMTQNDQ0gICBvICBQYXNzaXZlIE1lYXN1cmVtZW50IFRhc2tzOyBz aW5jZSB0aGV5IGRvIG5vdCBjcmVhdGUgYW55IEFjdGl2ZQ0gICAgICBNZWFzdXJlbWVudCBU cmFmZmljIHRoZXJlIGlzIG5vIG5lZWQgdG8gc3VwcHJlc3MgdGhlbSwgaG93ZXZlciBpdA0g ICAgICBtYXkgYmUgc2ltcGxlciBmb3IgYW4gaW1wbGVtZW50YXRpb24gdG8gZG8gc28NDSAg IG8gIG9uLWdvaW5nIEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrczsgc2VlIFNlY3Rpb24gNS4z DQ0gICBOb3RlIHRoYXQgU3VwcHJlc3Npb24gaXMgbm90IGludGVuZGVkIHRvIHBlcm1hbmVu dGx5IHN0b3AgYQ0gICBNZWFzdXJlbWVudCBUYXNrIChpbnN0ZWFkLCB0aGUgQ29udHJvbGxl ciBzaG91bGQgc2VuZCBhIG5ldw0gICBNZWFzdXJlbWVudCBTY2hlZHVsZSksIG5vciB0byBw ZXJtYW5lbnRseSBkaXNhYmxlIGEgTUEgKGluc3RlYWQsIHNvbWUNICAga2luZCBvZiBtYW5h Z2VtZW50IGFjdGlvbiBpcyBzdWdnZXN0ZWQpLg0NICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDSAgIHwg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg TWVhc3VyZW1lbnQgfA0gICB8ICBDb250cm9sbGVyICAgICB8PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT18ICBBZ2VudCAgICAgIHwNICAgKy0tLS0tLS0tLS0tLS0tLS0t KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQ0g ICBTdXBwcmVzczoNICAgWyhNZWFzdXJlbWVudCBUYXNrKSwgICAgICAgICAgICAgICAgICAg ICAtPg0gICAgKE1lYXN1cmVtZW50IFNjaGVkdWxlKSwNICAgIHN0YXJ0IHRpbWUsIGVuZCB0 aW1lXQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtICAg ICAgICAgICAgICBBQ0sNDSAgIFVuLXN1cHByZXNzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLT4NICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 LSAgICAgICAgICAgICAgQUNLDQ0NNS4zLiAgU3RhcnRpbmcgYW5kIHN0b3BwaW5nIE1lYXN1 cmVtZW50IFRhc2tzDQ0gICBUaGUgTE1BUCBXRyBpcyBuZXV0cmFsIHRvIHdoYXQgdGhlIGFj dHVhbCBNZWFzdXJlbWVudCBUYXNrIGlzLiAgVGhlDSAgIFdHIGRvZXMgbm90IGRlZmluZSBh IGdlbmVyaWMgc3RhcnQgYW5kIHN0b3AgcHJvY2Vzcywgc2luY2UgdGhlDSAgIGNvcnJlY3Qg YXBwcm9hY2ggZGVwZW5kcyBvbiB0aGUgcGFydGljdWxhciBNZWFzdXJlbWVudCBUYXNrOyB0 aGUNICAgZGV0YWlscyBhcmUgZGVmaW5lZCBhcyBwYXJ0IG9mIGVhY2ggTWVhc3VyZW1lbnQg TWV0aG9kLCBhbmQgaGVuY2UNICAgcG90ZW50aWFsbHkgYnkgdGhlIElQUE0gV0cuICBUaGlz IHNlY3Rpb24gcHJvdmlkZXMgc29tZSBnZW5lcmFsDSAgIGhpbnRzLg0NICAgT25jZSB0aGUg TUEgZ2V0cyBpdHMgTWVhc3VyZW1lbnQgYW5kIFJlcG9ydCBTY2hlZHVsZXMgZnJvbSBpdHMN ICAgQ29udHJvbGxlciwgdGhlbiBpdCB0aGVuIGFjdHMgYXV0b25vbW91c2x5LCBpbiB0ZXJt cyBvZiBvcGVyYXRpb24gb2YgdGhlDSAgIE1lYXN1cmVtZW50IFRhc2tzIGFuZCByZXBvcnRp bmcgb2YgdGhlIHJlc3VsdHMuICBPbmUgaW1wbGljYXRpb24gaXMNICAgdGhhdCB0aGUgTUEg aW5pdGlhdGVzIE1lYXN1cmVtZW50IFRhc2tzLiAgQXMgYW4gZXhhbXBsZSwgZm9yIHRoZQ0g ICBjb21tb24gY2FzZSB3aGVyZSB0aGUgTUEgaXMgb24gYSBob21lIGdhdGV3YXksIHRoZSBN QSBpbml0aWF0ZXMgYQ0gICAnZG93bmxvYWQgc3BlZWQgdGVzdCcgYnkgYXNraW5nIGEgTWVh c3VyZW1lbnQgUGVlciB0byBzZW5kIHRoZSBmaWxlLg0NICAgTWFueSBBY3RpdmUgTWVhc3Vy ZW1lbnQgVGFza3MgYmVnaW4gd2l0aCBhIHByZS1jaGVjayBiZWZvcmUgdGhlIHRlc3QNICAg dHJhZmZpYyBpcyBzZW50LiAgQWN0aW9uIGNvdWxkIGluY2x1ZGU6DQ0gICBvICB0aGUgTUEg Y2hlY2tpbmcgdGhhdCB0aGVyZSBpcyBubyBjcm9zcy10cmFmZmljOyBpbiBvdGhlciB3b3Jk cywgYQ0gICAgICBjaGVjayB0aGF0IHRoZSB1c2VyIGlzbid0IGFscmVhZHkgc2VuZGluZyB0 cmFmZmljOw0NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjUs IDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMTldDQ1JbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQNDQ0g ICBvICB0aGUgTUEgY2hlY2tpbmcgd2l0aCB0aGUgTWVhc3VyZW1lbnQgUGVlciB0aGF0IGl0 IGNhbiBoYW5kbGUgYSBuZXcNICAgICAgTWVhc3VyZW1lbnQgVGFzayAoaW4gY2FzZSB0aGUg TWVhc3VyZW1lbnQgUGVlciBpcyBhbHJlYWR5IGhhbmRsaW5nDSAgICAgIG1hbnkgTWVhc3Vy ZW1lbnQgVGFza3Mgd2l0aCBvdGhlciBNQXMpOw0NICAgbyAgdGhlIGZpcnN0IHBhcnQgb2Yg dGhlIE1lYXN1cmVtZW50IFRhc2sgY29uc2lzdGluZyBvZiB0cmFmZmljIHRoYXQNICAgICAg cHJvYmVzIHRoZSBwYXRoIHRvIG1ha2Ugc3VyZSBpdCBpc24ndCBvdmVybG9hZGVkLg0NICAg TyAgdGhlIE1BIGNoZWNraW5nIGl0cyBvd24gcmVzb3VyY2UgY2FwYWJpbGl0aWVzIHRvIGVu c3VyZSBzdWZmaWNpZW50IHJlc291cmNlcyBhcmUgYXZhaWxhYmxlIHRvIGV4ZWN1dGUgdGhl IE1lYXN1cmVtZW50IFRhc2sgcmVsaWFibHkuBQ0NICAgSXQgaXMgcG9zc2libGUgdGhhdCBz aW1pbGFyIGNoZWNrcyBjb250aW51ZSBkdXJpbmcgdGhlIE1lYXN1cmVtZW50DSAgIFRhc2ss IGVzcGVjaWFsbHkgb25lIHRoYXQgaXMgbG9uZy1ydW5uaW5nIGFuZC9vciBjcmVhdGVzIGEg bG90IG9mDSAgIEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljLCB3aGljaCBtYXkgYmUgYWJh bmRvbmVkIHdoaWxzdCBpbi0NICAgcHJvZ3Jlc3MuICBBIE1lYXN1cmVtZW50IFRhc2sgY291 bGQgYWxzbyBiZSBhYmFuZG9uZWQgaW4gcmVzcG9uc2UgdG8NICAgYSAic3VwcHJlc3MiIG1l c3NhZ2UgKHNlZSBTZWN0aW9uIDUuMi4xKS4gIEFjdGlvbiBjb3VsZCBpbmNsdWRlOg0NICAg byAgRm9yICd1cGxvYWQnIHRlc3RzLCB0aGUgTUEgbm90IHNlbmRpbmcgdHJhZmZpYw0NICAg byAgRm9yICdkb3dubG9hZCcgdGVzdHMsIHRoZSBNQSBjbG9zaW5nIHRoZSBUQ1AgY29ubmVj dGlvbiBvciBzZW5kaW5nDSAgICAgIGEgVFdBTVAgU3RvcCBjb250cm9sIG1lc3NhZ2UgW1JG QzUzNTddLg0NICAgVGhlIENvbnRyb2xsZXIgbWF5IHdhbnQgYSBNQSB0byBydW4gdGhlIHNh bWUgTWVhc3VyZW1lbnQgVGFzaw0gICBpbmRlZmluaXRlbHkgKGZvciBleGFtcGxlLCAicnVu IHRoZSAndXBsb2FkIHNwZWVkJyBNZWFzdXJlbWVudCBUYXNrDSAgIG9uY2UgYW4gaG91ciB1 bnRpbCBmdXJ0aGVyIG5vdGljZSIpLiAgVG8gYXZvaWQgdGhlIE1BIGdlbmVyYXRpbmcNICAg dHJhZmZpYyBmb3JldmVyIGFmdGVyIGEgQ29udHJvbGxlciBoYXMgcGVybWFuZW50bHkgZmFp bGVkLCBpdCBpcw0gICBzdWdnZXN0ZWQgdGhhdCB0aGUgTWVhc3VyZW1lbnQgU2NoZWR1bGUg aW5jbHVkZXMgYSB0aW1lIGxpbWl0ICgicnVuDSAgIHRoZSAndXBsb2FkIHNwZWVkJyBNZWFz dXJlbWVudCBUYXNrIG9uY2UgYW4gaG91ciBmb3IgdGhlIG5leHQgMzANICAgZGF5cyIpIGFu ZCB0aGF0IHRoZSBNZWFzdXJlbWVudCBTY2hlZHVsZSBpcyB1cGRhdGVkIHJlZ3VsYXJseSAo c2F5LA0gICBldmVyeSAxMCBkYXlzKS4NDSAgIHtDb21tZW50OiBJdCBpcyBwb3NzaWJsZSB0 aGF0IHRoZSBzZXQgb2YgbWVhc3VyZW1lbnQgc2NoZWR1bGVzDSAgIGltcGxpZXMgb3Zlcmxh cHBpbmcgTWVhc3VyZW1lbnQgVGFza3MuICBJdCBpcyBub3QgY2xlYXIgdGhlIGJlc3QNICAg dGhpbmcgdG8gZG8uICBPdXIgY3VycmVudCBzdWdnZXN0aW9uIGlzIHRvIGxlYXZlIHRoaXMg dG8gdGhlIHByb3RvY29sDSAgIGRvY3VtZW50Ln0NBQ01LjQuICBSZXBvcnQgUHJvdG9jb2wN DSAgIFRoZSBwcmltYXJ5IHB1cnBvc2Ugb2YgdGhlIFJlcG9ydCBQcm90b2NvbCBpcyB0byBh bGxvdyBhIE1lYXN1cmVtZW50DSAgIEFnZW50IHRvIHJlcG9ydCBpdHMgTWVhc3VyZW1lbnQg UmVzdWx0cyB0byBhIENvbGxlY3RvciwgYW5kIHRoZQ0gICBjb250ZXh0IGluIHdoaWNoIHRo ZXkgd2VyZSBvYnRhaW5lZC4NDQ0NDQ0NDQ0NDQ0NDQ1FYXJkbGV5LCBldCBhbC4gICAgICAg ICAgIEV4cGlyZXMgSnVseSAyNSwgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSAyMF0NDUlu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTE1BUCBGcmFtZXdvcmsgICAgICAgICAgICAg ICAgIEphbnVhcnkgMjAxNA0NDSAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDSAgfCAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBNZWFzdXJlbWVudCB8 DSAgfCAgIENvbGxlY3RvciAgICAgfD09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09fCAgQWdlbnQgICAgICB8DSAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQ0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC0gICAgICAgICAgUmVwb3J0Og0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbTUEtSUQgJi9vciBHcm91 cC1JRCwNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE1lYXN1cmVtZW50IFJlc3VsdHMsDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZGV0YWlscyBvZiBNZWFzdXJlbWVudCBUYXNrXQ0gIEFDSyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLT4NDQ0gICBUaGUgUmVwb3J0IGNvbnRhaW5z Og0NICAgbyAgdGhlIE1BLUlEIG9yIGEgR3JvdXAtSUQgKHRvIGFub255bWlzZSByZXN1bHRz KQ0NICAgbyAgdGhlIGFjdHVhbCBNZWFzdXJlbWVudCBSZXN1bHRzLCBpbmNsdWRpbmcgdGhl IHRpbWUgBXRoZXkgd2VyZQ0gICAgICBtZWFzdXJlZA0NICAgbyAgdGhlIGRldGFpbHMgb2Yg dGhlIE1lYXN1cmVtZW50IFRhc2sgKHRvIGF2b2lkIHRoZSBDb2xsZWN0b3IgaGF2aW5nDSAg ICAgIHRvIGFzayB0aGUgQ29udHJvbGxlciBmb3IgdGhpcyBpbmZvcm1hdGlvbiBsYXRlcikN DSAgIFRoZSBNQSBzZW5kcyBSZXBvcnRzIGFzIGRlZmluZWQgYnkgdGhlIFJlcG9ydCBDaGFu bmVsIGluIHRoZQ0gICBDb250cm9sbGVyJ3MgSW5zdHJ1Y3Rpb24uICBJdCBpcyBwb3NzaWJs ZSB0aGF0IHRoZSBJbnN0cnVjdGlvbiB0ZWxscw0gICB0aGUgTUEgdG8gcmVwb3J0IHRoZSBz YW1lIFJlc3VsdHMgdG8gbW9yZSB0aGFuIG9uZSBDb2xsZWN0b3IsIG9yIHRvDSAgIHJlcG9y dCBhIGRpZmZlcmVudCBzdWJzZXQgb2YgUmVzdWx0cyB0byBkaWZmZXJlbnQgQ29sbGVjdG9y cy4gIEl0IGlzDSAgIGFsc28gcG9zc2libGUgdGhhdCBhIE1lYXN1cmVtZW50IFRhc2sgbWF5 IGNyZWF0ZSB0d28gKG9yIG1vcmUpDSAgIE1lYXN1cmVtZW50IFJlc3VsdHMsIHdoaWNoIGNv dWxkIGJlIHJlcG9ydGVkIGRpZmZlcmVudGx5IChmb3INICAgZXhhbXBsZSwgb25lIFJlc3Vs dCBjb3VsZCBiZSByZXBvcnRlZCBwZXJpb2RpY2FsbHksIHdoaWxzdCB0aGUgc2Vjb25kDSAg IFJlc3VsdCBjb3VsZCBiZSBhbiBhbGFybSB0aGF0IGlzIGNyZWF0ZWQgYXMgc29vbiBhcyB0 aGUgbWVhc3VyZWQNICAgdmFsdWUgb2YgdGhlIE1ldHJpYyBjcm9zc2VzIGEgdGhyZXNob2xk IGFuZCB0aGF0IGlzIHJlcG9ydGVkDSAgIGltbWVkaWF0ZWx5KS4NDSAgIE9wdGlvbmFsbHks IGEgUmVwb3J0IGlzIG5vdCBzZW50IHdoZW4gdGhlcmUgYXJlIG5vIE1lYXN1cmVtZW50DSAg IFJlc3VsdHMuDQ0gICBJbiB0aGUgaW5pdGlhbCBMTUFQIEluZm9ybWF0aW9uIE1vZGVsIGFu ZCBSZXBvcnQgUHJvdG9jb2wsIGZvcg0gICBzaW1wbGljaXR5IHdlIGFzc3VtZSB0aGF0IGFs bCBNZWFzdXJlbWVudCBSZXN1bHRzIGFyZSByZXBvcnRlZCBhcy1pcywNICAgYnV0IGFsbG93 IGV4dGVuc2liaWxpdHkgc28gdGhhdCBhIG1lYXN1cmVtZW50IHN5c3RlbSAob3IgcGVyaGFw cyBhDSAgIHNlY29uZCBwaGFzZSBvZiBMTUFQKSBjb3VsZCBhbGxvdyBhIE1BIHRvIHByZS1w cm9jZXNzIE1lYXN1cmVtZW50DSAgIFJlc3VsdHMgYmVmb3JlIGl0IHJlcG9ydHMgdGhlbS4g IFBvdGVudGlhbCBleGFtcGxlcyBvZiBwcmUtcHJvY2Vzc2luZw0gICBieSB0aGUgTUEgYXJl Og0FDSAgIG8gIGxhYmVsbGluZwUsIG9yIHBlcmhhcHMgbm90IGluY2x1ZGluZywgTWVhc3Vy ZW1lbnQgUmVzdWx0cyBpbXBhY3RlZA0gICAgICBieSwgZm9yIGluc3RhbmNlLCBjcm9zcy10 cmFmZmljIG9yIHRoZSBNZWFzdXJlbWVudCBQZWVyIGJlaW5nIGJ1c3kNDSAgIG8gIG5vdCBy ZXBvcnRpbmcgdGhlIE1lYXN1cmVtZW50IFJlc3VsdHMgaWYgdGhlIE1BIGJlbGlldmVzIHRo YXQgdGhleQ0gICAgICBhcmUgaW52YWxpZA0NDQ1FYXJkbGV5LCBldCBhbC4gICAgICAgICAg IEV4cGlyZXMgSnVseSAyNSwgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSAyMV0NDUludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgTE1BUCBGcmFtZXdvcmsgICAgICAgICAgICAgICAg IEphbnVhcnkgMjAxNA0NDSAgIG8gIGRldGFpbGluZyB3aGVuIHN1cHByZXNzaW9uIHN0YXJ0 ZWQgYW5kIGVuZGVkDQ0gICBvICBmaWx0ZXJpbmcgb3V0bGllciBSZXN1bHRzBQ0NICAgbyAg Y2FsY3VsYXRpbmcgc29tZSBzdGF0aXN0aWMgbGlrZSBhdmVyYWdlIChiZXlvbmQgdGhhdCBk ZWZpbmVkIGJ5DSAgICAgIHRoZSBNZWFzdXJlbWVudCBUYXNrIGl0c2VsZikNBQ0gICBUaGUg bWVhc3VyZW1lbnQgc3lzdGVtIG1heSBkZWZpbmUgd2hhdCBoYXBwZW5zIGlmIGEgQ29sbGVj dG9yDSAgIHVuZXhwZWN0ZWRseSBkb2VzIG5vdCBoZWFyIGZyb20gYSBNQSwgZm9yIGV4YW1w bGUgdGhlIENvbnRyb2xsZXINICAgY291bGQgc2VuZCBhIGZyZXNoIFJlcG9ydCBTY2hlZHVs ZSB0byB0aGUgTUEuDQ0gICBUaGUgTE1BUCBXRyB3aWxsIGRlZmluZSBhIFJlcG9ydCBQcm90 b2NvbCBhbmQgaXRzIGFzc29jaWF0ZWQgRGF0YQ0gICBNb2RlbCB0aGF0IGltcGxlbWVudHMg dGhlIEluZm9ybWF0aW9uIE1vZGVsIGFuZCBwcm90b2NvbCBtb2RlbC4gIFRoaXMNICAgbWF5 IGJlIGEgc2ltcGxlIGluc3RydWN0aW9uLXJlc3BvbnNlIHByb3RvY29sLg0NNS41LiAgT3Bl cmF0aW9uIG9mIExNQVAgb3ZlciB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQgcHJvdG9jb2wN DSAgIFRoZSBhYm92ZSBzZWN0aW9ucyBoYXZlIGRlc2NyaWJlZCBMTUFQJ3MgcHJvdG9jb2wg bW9kZWwuICBUaGUgTE1BUA0gICB3b3JraW5nIGdyb3VwIHdpbGwgYWxzbyBzcGVjaWZ5IGhv dyBpdCBvcGVyYXRlcyBvdmVyIGFuIGV4aXN0aW5nDSAgIHByb3RvY29sLCB0byBiZSBzZWxl Y3RlZCwgZm9yIGV4YW1wbGUgUkVTVC1zdHlsZSBIVFRQKFMpLiAgSXQgaXMgYWxzbw0gICBw b3NzaWJsZSB0aGF0IGEgZGlmZmVyZW50IGNob2ljZSBpcyBtYWRlIGZvciB0aGUgQ29udHJv bCBhbmQgUmVwb3J0DSAgIFByb3RvY29scywgZm9yIGV4YW1wbGUgTkVUQ09ORi1ZQU5HIGFu ZCBJUEZJWCByZXNwZWN0aXZlbHkuICBJdCBpcw0gICBldmVuIHBvc3NpYmxlIHRoYXQgYSBk aWZmZXJlbnQgY2hvaWNlIGNvdWxkIGJlIG1hZGUgZm9yIFN1cHByZXNzaW9uDSAgIGFuZCBm b3Igb3RoZXIgSW5zdHJ1Y3Rpb24gbWVzc2FnZXMuDQ0gICBGb3IgdGhlIENvbnRyb2wgUHJv dG9jb2wsIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBwcm90b2NvbCBjb3VsZCBiZToFDQ0g ICBvICBhICdwdXNoJyBwcm90b2NvbCAodGhhdCBpcywgZnJvbSB0aGUgQ29udHJvbGxlciB0 byB0aGUgTUEpDQ0gICBvICBhIG11bHRpY2FzdCBwcm90b2NvbCAoZnJvbSB0aGUgQ29udHJv bGxlciB0byBhIGdyb3VwIG9mIE1BcykNDSAgIG8gIGEgJ3B1bGwnIHByb3RvY29sLiAgVGhl IE1BIHBlcmlvZGljYWxseSBjaGVja3Mgd2l0aCBDb250cm9sbGVyIGlmDSAgICAgIHRoZSBJ bnN0cnVjdGlvbiBoYXMgY2hhbmdlZCBhbmQgcHVsbHMgYSBuZXcgSW5zdHJ1Y3Rpb24gaWYN ICAgICAgbmVjZXNzYXJ5LiAgQSBwdWxsIHByb3RvY29sIHNlZW1zIGF0dHJhY3RpdmUgZm9y IGEgTUEgYmVoaW5kIGEgTkFUDSAgICAgIChhcyBpcyB0eXBpY2FsIGZvciBhIE1BIG9uIGFu IGVuZC11c2VyJ3MgZGV2aWNlKSwgc28gdGhhdCBpdCBjYW4NICAgICAgaW5pdGlhdGUgdGhl IGNvbW11bmljYXRpb25zLiAgQSBwdWxsIG1lY2hhbmlzbSBpcyBsaWtlbHkgdG8NICAgICAg cmVxdWlyZSB0aGUgTUEgdG8gYmUgY29uZmlndXJlZCB3aXRoIGhvdyBmcmVxdWVudGx5IGl0 IHNob3VsZA0gICAgICBjaGVjayBpbiB3aXRoIHRoZSBDb250cm9sbGVyLCBhbmQgcGVyaGFw cyB3aGF0IGl0IHNob3VsZCBkbyBpZiB0aGUNICAgICAgQ29udHJvbGxlciBpcyB1bnJlYWNo YWJsZSBhZnRlciBhIGNlcnRhaW4gbnVtYmVyIG9mIGF0dGVtcHRzLg0NICAgbyAgYSBoeWJy aWQgcHJvdG9jb2wuICBJbiBhZGRpdGlvbiB0byBhIHB1bGwgcHJvdG9jb2wsIHRoZSBDb250 cm9sbGVyDSAgICAgIGNhbiBhbHNvIHB1c2ggYW4gYWxlcnQgdG8gdGhlIE1BIHRoYXQgaXQg c2hvdWxkIGltbWVkaWF0ZWx5IHB1bGwgYQ0gICAgICBuZXcgSW5zdHJ1Y3Rpb24uDQ0gICBG b3IgdGhlIFJlcG9ydCBQcm90b2NvbCwgdGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0IHByb3Rv Y29sIGNvdWxkIGJlOg0NICAgbyAgYSAncHVzaCcgcHJvdG9jb2wgKHRoYXQgaXMsIGZyb20g dGhlIE1BIHRvIHRoZSBDb2xsZWN0b3IpDQ0NDQ1FYXJkbGV5LCBldCBhbC4gICAgICAgICAg IEV4cGlyZXMgSnVseSAyNSwgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSAyMl0NDUludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgTE1BUCBGcmFtZXdvcmsgICAgICAgICAgICAgICAg IEphbnVhcnkgMjAxNA0NDSAgIG8gIHBlcmhhcHMgc3VwcGxlbWVudGVkIGJ5IHRoZSBhYmls aXR5IGZvciB0aGUgQ29sbGVjdG9yIHRvICdwdWxsJw0gICAgICBNZWFzdXJlbWVudCBSZXN1 bHRzIGZyb20gYSBNQS4NDTUuNi4gIEl0ZW1zIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhlIExN QVAgUHJvdG9jb2wgTW9kZWwNDSAgIFRoZXJlIGFyZSBzZXZlcmFsIHBvdGVudGlhbCBpbnRl cmFjdGlvbnMgYmV0d2VlbiBMTUFQIGVsZW1lbnRzIHRoYXQNICAgYXJlIG91dCBvZiBzY29w ZSBvZiBkZWZpbml0aW9uIGJ5IHRoZSBMTUFQIFdHOg0NICAgMS4gIEl0IGRvZXMgbm90IGRl ZmluZSBhIGNvb3JkaW5hdGlvbiBwcm9jZXNzIGJldHdlZW4gTUFzLiAgV2hpbHN0IGENICAg ICAgIG1lYXN1cmVtZW50IHN5c3RlbSBtYXkgZGVmaW5lIGNvb3JkaW5hdGVkIE1lYXN1cmVt ZW50IFNjaGVkdWxlcw0gICAgICAgYWNyb3NzIGl0cyB2YXJpb3VzIE1BcywgdGhlcmUgaXMg bm8gZGlyZWN0IGNvb3JkaW5hdGlvbiBiZXR3ZWVuDSAgICAgICBNQXMuDQ0gICAyLiAgSXQg ZG9lcyBub3QgZGVmaW5lIGludGVyYWN0aW9ucyBiZXR3ZWVuIHRoZSBDb2xsZWN0b3IgYW5k DSAgICAgICBDb250cm9sbGVyLiAgSXQgaXMgcXVpdGUgbGlrZWx5IHRoYXQgdGhlcmUgd2ls bCBiZSBzdWNoDSAgICAgICBpbnRlcmFjdGlvbnMsIG9wdGlvbmFsbHkgaW50ZXJtZWRpYXRl ZCBieSB0aGUgZGF0YSBhbmFseXNpcw0gICAgICAgdG9vbHMuICBGb3IgZXhhbXBsZSBpZiB0 aGVyZSBpcyBhbiAiaW50ZXJlc3RpbmciIE1lYXN1cmVtZW50DSAgICAgICBSZXN1bHQgdGhl biB0aGUgbWVhc3VyZW1lbnQgc3lzdGVtIG1heSB3YW50IHRvIHRyaWdnZXIgZXh0cmENICAg ICAgIE1lYXN1cmVtZW50IFRhc2tzIHRoYXQgZXhwbG9yZSB0aGUgcG90ZW50aWFsIGNhdXNl IGluIG1vcmUNICAgICAgIGRldGFpbC4NDSAgIDMuICBJdCBkb2VzIG5vdCBkZWZpbmUgY29v cmRpbmF0aW9uIGJldHdlZW4gZGlmZmVyZW50IG1lYXN1cmVtZW50DSAgICAgICBzeXN0ZW1z LiAgRm9yIGV4YW1wbGUsIGl0IGRvZXMgbm90IGRlZmluZSB0aGUgaW50ZXJhY3Rpb24gb2Yg YSBNQQ0gICAgICAgaW4gb25lIG1lYXN1cmVtZW50IHN5c3RlbSB3aXRoIGEgQ29udHJvbGxl ciBvciBDb2xsZWN0b3IgaW4gYQ0gICAgICAgZGlmZmVyZW50IG1lYXN1cmVtZW50IHN5c3Rl bS4gIFdoaWxzdCBpdCBpcyBsaWtlbHkgdGhhdCB0aGUNICAgICAgIENvbnRyb2wgYW5kIFJl cG9ydCBQcm90b2NvbHMgY291bGQgYmUgcmUtdXNlZCBvciBhZGFwdGVkIGZvciB0aGlzDSAg ICAgICBzY2VuYXJpbywgYW55IGZvcm0gb2YgY29vcmRpbmF0aW9uIGJldHdlZW4gZGlmZmVy ZW50DSAgICAgICBvcmdhbmlzYXRpb25zIGludm9sdmVzIGRpZmZpY3VsdCBjb21tZXJjaWFs IGFuZCB0ZWNobmljYWwgaXNzdWVzDSAgICAgICBhbmQgc28sIGdpdmVuIHRoZSBub3ZlbHR5 IG9mIGxhcmdlLXNjYWxlIG1lYXN1cmVtZW50IGVmZm9ydHMsIGFueQ0gICAgICAgZm9ybSBv ZiBpbnRlci1vcmdhbmlzYXRpb24gY29vcmRpbmF0aW9uIGlzIG91dHNpZGUgdGhlIHNjb3Bl IG9mDSAgICAgICB0aGUgTE1BUCBXRy4gIE5vdGUgdGhhdCBhIHNpbmdsZSBNQSBpcyBpbnN0 cnVjdGVkIGJ5IGEgc2luZ2xlDSAgICAgICBDb250cm9sbGVyIGFuZCBpcyBvbmx5IGluIG9u ZSBtZWFzdXJlbWVudCBzeXN0ZW0uDQ0gICAgICAgKiAgQW4gaW50ZXJlc3Rpbmcgc2NlbmFy aW8gaXMgd2hlcmUgYSBob21lIGNvbnRhaW5zIHR3bw0gICAgICAgICAgaW5kZXBlbmRlbnQg TUFzLCBmb3IgZXhhbXBsZSBvbmUgY29udHJvbGxlZCBieSBhIHJlZ3VsYXRvciBhbmQNICAg ICAgICAgIG9uZSBjb250cm9sbGVkIGJ5IGFuIElTUC4gIFRoZW4gdGhlIEFjdGl2ZSBNZWFz dXJlbWVudCBUcmFmZmljDSAgICAgICAgICBvZiBvbmUgTUEgaXMgdHJlYXRlZCBieSB0aGUg b3RoZXIgTUEganVzdCBsaWtlIGFueSBvdGhlciB1c2VyDSAgICAgICAgICB0cmFmZmljLg0N ICAgNC4gIEl0IGRvZXMgbm90IGNvbnNpZGVyIGhvdyB0byBwcmV2ZW50IGEgbWFsaWNpb3Vz IHBhcnR5ICJnYW1pbmcgdGhlDSAgICAgICBzeXN0ZW0iLiAgRm9yIGV4YW1wbGUsIHdoZXJl IGEgcmVndWxhdG9yIGlzIHJ1bm5pbmcgYSBtZWFzdXJlbWVudA0gICAgICAgc3lzdGVtIGlu IG9yZGVyIHRvIGJlbmNobWFyayBvcGVyYXRvcnMsIGEgbWFsaWNpb3VzIG9wZXJhdG9yDSAg ICAgICBjb3VsZCB0cnkgdG8gaWRlbnRpZnkgdGhlIGJyb2FkYmFuZCBsaW5lcyB0aGF0IHRo ZSByZWd1bGF0b3Igd2FzDSAgICAgICBtZWFzdXJpbmcgYW5kIHByaW9yaXRpc2UgdGhhdCB0 cmFmZmljLiAgSXQgaXMgYXNzdW1lZCB0aGlzIGlzIGENICAgICAgIHBvbGljeSBpc3N1ZSBh bmQgd291bGQgYmUgZGVhbHQgd2l0aCB0aHJvdWdoIGEgY29kZSBvZiBjb25kdWN0DSAgICAg ICBmb3IgaW5zdGFuY2UuDQ0NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVz IEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMjNdDQ1JbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5 IDIwMTQNDQ0gICA1LiAgSXQgZG9lcyBub3QgZGVmaW5lIGhvdyB0byBhbmFseXNlIE1lYXN1 cmVtZW50IFJlc3VsdHMsIGluY2x1ZGluZw0gICAgICAgaG93IHRvIGludGVycHJldCBtaXNz aW5nIFJlc3VsdHMuDQ0gICA2LiAgSXQgZG9lcyBub3Qgc3BlY2lmaWNhbGx5IGRlZmluZSBh IGVuZHVzZXItY29udHJvbGxlZCBtZWFzdXJlbWVudA0gICAgICAgc3lzdGVtLCBzZWUgc3Vi LXNlY3Rpb24gNS42LjEuDQ01LjYuMS4gIEVuZHVzZXItY29udHJvbGxlZCBtZWFzdXJlbWVu dCBzeXN0ZW0NDSAgIFRoZSBXRyBjb25jZW50cmF0ZXMgb24gdGhlIGNhc2VzIHdoZXJlIGFu IElTUCBvciBhIHJlZ3VsYXRvciBydW5zIHRoZQ0gICBtZWFzdXJlbWVudCBzeXN0ZW0uICBI b3dldmVyLCB3ZSBleHBlY3QgdGhhdCBMTUFQIGZ1bmN0aW9uYWxpdHkgd2lsbA0gICBhbHNv IGJlIHVzZWQgaW4gdGhlIGNvbnRleHQgb2YgYW4gZW5kdXNlci1jb250cm9sbGVkIG1lYXN1 cmVtZW50DSAgIHN5c3RlbS4gIFRoZXJlIGFyZSBhdCBsZWFzdCB0d28gd2F5cyB0aGlzIGNv dWxkIGhhcHBlbiAodGhleSBoYXZlDSAgIHZhcmlvdXMgcHJvcyBhbmQgY29ucyk6DQ0gICAx LiAgYW4gZW5kdXNlciBjb3VsZCBzb21laG93IHJlcXVlc3QgdGhlIElTUC0gKG9yIHJlZ3Vs YXRvci0pIHJ1bg0gICAgICAgbWVhc3VyZW1lbnQgc3lzdGVtIHRvIHRlc3QgaGlzL2hlciBs aW5lLiAgVGhlIElTUCAob3IgcmVndWxhdG9yKQ0gICAgICAgQ29udHJvbGxlciB3b3VsZCB0 aGVuIHNlbmQgYW4gSW5zdHJ1Y3Rpb24gdG8gdGhlIE1BIGluIHRoZSB1c3VhbA0gICAgICAg TE1BUCB3YXkuICBOb3RlIHRoYXQgYSB1c2VyIGNhbid0IGRpcmVjdGx5IGluaXRpYXRlIGEg TWVhc3VyZW1lbnQNICAgICAgIFRhc2sgb24gYW4gSVNQLSAob3IgcmVndWxhdG9yLSkgY29u dHJvbGxlZCBNQS4NDSAgIDIuICBhbiBlbmR1c2VyIGNvdWxkIGRlcGxveSB0aGVpciBvd24g bWVhc3VyZW1lbnQgc3lzdGVtLCB3aXRoIHRoZWlyDSAgICAgICBvd24gTUEsIENvbnRyb2xs ZXIgYW5kIENvbGxlY3Rvci4gIEZvciBleGFtcGxlLCB0aGUgdXNlciBjb3VsZA0gICAgICAg aW1wbGVtZW50IGFsbCB0aHJlZSBmdW5jdGlvbnMgb250byB0aGUgc2FtZSBlbmR1c2VyLW93 bmVkIGVuZA0gICAgICAgZGV2aWNlLCBwZXJoYXBzIGJ5IGRvd25sb2FkaW5nIHRoZSBmdW5j dGlvbnMgZnJvbSB0aGUgSVNQIG9yDSAgICAgICByZWd1bGF0b3IuICBUaGVuIHRoZSBMTUFQ IENvbnRyb2wgYW5kIFJlcG9ydCBQcm90b2NvbHMgZG8gbm90DSAgICAgICBuZWVkIHRvIGJl IHVzZWQsIGJ1dCB1c2luZyBMTUFQJ3MgSW5mb3JtYXRpb24gTW9kZWwgd291bGQgc3RpbGwN ICAgICAgIGJlIGJlbmVmaWNpYWwuICBUaGUgTWVhc3VyZW1lbnQgUGVlciBjb3VsZCBiZSBp biB0aGUgaG9tZSBnYXRld2F5DSAgICAgICBvciBvdXRzaWRlIHRoZSBob21lIG5ldHdvcms7 IGluIHRoZSBsYXR0ZXIgY2FzZSB0aGUgTWVhc3VyZW1lbnQNICAgICAgIFBlZXIgaXMgaGln aGx5IGxpa2VseSB0byBiZSBydW4gYnkgYSBkaWZmZXJlbnQgb3JnYW5pc2F0aW9uLA0gICAg ICAgd2hpY2ggcmFpc2VzIGV4dHJhIHByaXZhY3kgY29uc2lkZXJhdGlvbnMuDQ0gICBJbiBi b3RoIGNhc2VzIHRoZXJlIHdpbGwgYmUgc29tZSB3YXkgZm9yIHRoZSB1c2VyIHRvIGluaXRp YXRlIHRoZQ0gICBNZWFzdXJlbWVudCBUYXNrKHMpLiAgVGhlIG1lY2hhbmlzbSBpcyBvdXQt b2Ytc2NvcGUgb2YgdGhlIExNQVAgV0csDSAgIGJ1dCBjb3VsZCBpbmNsdWRlIHRoZSB1c2Vy IGNsaWNraW5nIGEgYnV0dG9uIG9uIGEgR1VJIG9yIHNlbmRpbmcgYQ0gICB0ZXh0IG1lc3Nh Z2UuICBQcmVzdW1hYmx5IHRoZSB1c2VyIHdpbGwgYWxzbyBiZSBhYmxlIHRvIHNlZSB0aGUN ICAgTWVhc3VyZW1lbnQgUmVzdWx0cywgcGVyaGFwcyBzdW1tYXJpc2VkIG9uIGEgd2VicGFn ZS4gIEl0IGlzDSAgIHN1Z2dlc3RlZCB0aGF0IHRoZXNlIGludGVyZmFjZXMgY29uZm9ybSB0 byB0aGUgTE1BUCBndWlkYW5jZSBvbiB0aGUNICAgcHJpdmFjeSBpbiBTZWN0aW9uIDguDQ02 LiAgRGVwbG95bWVudCBjb25zaWRlcmF0aW9ucw0NNi4xLiAgQ29udHJvbGxlcg0NICAgVGhl IENvbnRyb2xsZXIgc2hvdWxkIHVuZGVyc3RhbmQgYm90aCB0aGUgTUEncyBMTUFQIENhcGFi aWxpdGllcyAoZm9yDSAgIGluc3RhbmNlIHdoYXQgTWVhc3VyZW1lbnQgTWV0aG9kcyBpdCBj YW4gcGVyZm9ybSkgYW5kIGFib3V0IHRoZSBNQSdzDSAgIG90aGVyIGNhcGFiaWxpdGllcyBs aWtlIHByb2Nlc3NpbmcgcG93ZXIgYW5kIG1lbW9yeS4gIFRoaXMgYWxsb3dzIHRoZQ0gICBD b250cm9sbGVyIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBNZWFzdXJlbWVudCBTY2hlZHVsZSBv ZiBNZWFzdXJlbWVudA0NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1 bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMjRdDQ1JbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIw MTQNDQ0gICBUYXNrcyBhbmQgdGhlIFJlcG9ydGluZyBTY2hlZHVsZSBhcmUgc2Vuc2libGUg Zm9yIGVhY2ggTUEgdGhhdCBpdA0gICBJbnN0cnVjdHMuDQ0gICBBbiBJbnN0cnVjdGlvbiBp cyBsaWtlbHkgdG8gaW5jbHVkZSBzZXZlcmFsIE1lYXN1cmVtZW50IFRhc2tzLg0gICBUeXBp Y2FsbHkgdGhlc2UgcnVuIGF0IGRpZmZlcmVudCB0aW1lcywgYnV0IGl0IGlzIGFsc28gcG9z c2libGUgZm9yDSAgIHRoZW0gdG8gcnVuIGF0IHRoZSBzYW1lIHRpbWUsIGlmIHRoZSBDb250 cm9sbGVyIGlzIHN1cmUgdGhhdCBvbmUgVGFzaw0gICB3aWxsIG5vdCBhZmZlY3QgdGhlIFJl c3VsdHMgb2YgYW5vdGhlciBUYXNrLg0NICAgVGhlIENvbnRyb2xsZXIgc2hvdWxkIGVuc3Vy ZSB0aGF0IHRoZSBBY3RpdmUgTWVhc3VyZW1lbnQgVGFza3MgZG8gbm90DSAgIGhhdmUgYW4g YWR2ZXJzZSBlZmZlY3Qgb24gdGhlIGVuZCB1c2VyLiAgVHlwaWNhbGx5IFRhc2tzLCBlc3Bl Y2lhbGx5DSAgIHRob3NlIHRoYXQgZ2VuZXJhdGUgYSBzdWJzdGFudGlhbCBhbW91bnQgb2Yg dHJhZmZpYywgd2lsbCBpbmNsdWRlIGENICAgcHJlLWNoZWNrIHRoYXQgdGhlIHVzZXIgaXNu J3QgYWxyZWFkeSBzZW5kaW5nIHRyYWZmaWMgKFNlY3Rpb24gNS4zKS4NICAgQW5vdGhlciBj b25zaWRlcmF0aW9uIGlzIHdoZXRoZXIgQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMgd2ls bA0gICBpbXBhY3QgYSBTdWJzY3JpYmVyJ3MgYmlsbCBvciB0cmFmZmljIGNhcC4NBQ0gICBU aGUgZGlmZmVyZW50IGVsZW1lbnRzIG9mIHRoZSBJbnN0cnVjdGlvbiBjYW4gYmUgdXBkYXRl ZA0gICBpbmRlcGVuZGVudGx5LiAgRm9yIGV4YW1wbGUsIHRoZSBNZWFzdXJlbWVudCBUYXNr cyBjb3VsZCBiZQ0gICBjb25maWd1cmVkIHdpdGggZGlmZmVyZW50IElucHV0IFBhcmFtZXRl cnMgd2hpbHN0IGtlZXBpbmcgdGhlIHNhbWUNICAgTWVhc3VyZW1lbnQgU2NoZWR1bGUuICBJ biBnZW5lcmFsIHRoaXMgc2hvdWxkIG5vdCBjcmVhdGUgYW55IGlzc3VlcywNICAgc2luY2Ug TWVhc3VyZW1lbnQgTWV0aG9kcyBzaG91bGQgYmUgZGVmaW5lZCBzbyB0aGVpciBmdW5kYW1l bnRhbA0gICBuYXR1cmUgZG9lcyBub3QgY2hhbmdlIGZvciBhIG5ldyB2YWx1ZSBvZiBJbnB1 dCBQYXJhbWV0ZXIuICBUaGVyZQ0gICBjb3VsZCBiZSBhIHByb2JsZW0gaWYsIGZvciBleGFt cGxlLCBhIE1lYXN1cmVtZW50IFRhc2sgaW52b2x2aW5nIGENICAgMWtCIGZpbGUgdXBsb2Fk IGNvdWxkIGJlIGNoYW5nZWQgaW50byBhIDFHQiBmaWxlIHVwbG9hZC4NDSAgIEEgbWVhc3Vy ZW1lbnQgc3lzdGVtIG1heSBoYXZlIG11bHRpcGxlIENvbnRyb2xsZXJzIChidXQgbm90ZSB0 aGUNICAgb3ZlcnJpZGluZyBwcmluY2lwbGUgdGhhdCBhIHNpbmdsZSBNQSBpcyBpbnN0cnVj dGVkIGJ5IGEgc2luZ2xlDSAgIENvbnRyb2xsZXIgYXQgYW55IHBvaW50IGluIHRpbWUgKFNl Y3Rpb24gNC4yKSkuICBGb3IgZXhhbXBsZSwgdGhlcmUNICAgY291bGQgYmUgZGlmZmVyZW50 IENvbnRyb2xsZXJzIGZvciBkaWZmZXJlbnQgdHlwZXMgb2YgTUEgKGhvbWUNICAgZ2F0ZXdh eXMsIHRhYmxldHMpIG9yIGxvY2F0aW9ucyAoSXBzd2ljaCwgRWRpbmJ1cmdoKSwgZm9yIGxv YWQNICAgYmFsYW5jaW5nIG9yIHRvIGNvcGUgd2l0aCBmYWlsdXJlIG9mIG9uZSBDb250cm9s bGVyLiAgT25lIHBvc3NpYmlsaXR5DSAgIGlzIHRoYXQgQm9vdHN0cmFwcGluZyBpbnZvbHZl cyBhbiBpbml0aWFsIENvbnRyb2xsZXIsIHdob3NlIHJvbGUgaXMNICAgc2ltcGx5IHRvIGlu Zm9ybSB0aGUgTUEgaG93IHRvIGNvbnRhY3QgaXRzIGFjdHVhbCBDb250cm9sbGVyLg0NNi4y LiAgTWVhc3VyZW1lbnQgQWdlbnQNDSAgIFRoZSBNZWFzdXJlbWVudCBBZ2VudCBjb3VsZCB0 YWtlIGEgbnVtYmVyIG9mIGZvcm1zOiBhIGRlZGljYXRlZA0gICBwcm9iZSwgc29mdHdhcmUg b24gYSBQQywgZW1iZWRkZWQgaW50byBhbiBhcHBsaWFuY2UsIG9yIGV2ZW4gZW1iZWRkZWQN ICAgaW50byBhIGdhdGV3YXkuICBBIHNpbmdsZSBzaXRlIChob21lLCBicmFuY2ggb2ZmaWNl IGV0Yy4pIHRoYXQgaXMNICAgcGFydGljaXBhdGluZyBpbiBhIG1lYXN1cmVtZW50IGNvdWxk IG1ha2UgdXNlIG9mIG9uZSBvciBtdWx0aXBsZQ0gICBNZWFzdXJlbWVudCBBZ2VudHMgaW4g YSBzaW5nbGUgbWVhc3VyZW1lbnQuICBJZiB0aGUgc2l0ZSBpcyBtdWx0aQ0gICBob21lZCB0 aGVyZSBtaWdodCBiZSBhIE1lYXN1cmVtZW50IEFnZW50IHBlciBpbnRlcmZhY2UuDQ0gICBU aGUgTWVhc3VyZW1lbnQgQWdlbnQgY291bGQgYmUgZGVwbG95ZWQgaW4gYSB2YXJpZXR5IG9m IGxvY2F0aW9ucy4NICAgTm90IGFsbCBkZXBsb3ltZW50IGxvY2F0aW9ucyBhcmUgYXZhaWxh YmxlIHRvIGV2ZXJ5IGtpbmQgb2YNICAgTWVhc3VyZW1lbnQgQWdlbnQuICBUaGVyZSBhcmUg YWxzbyBhIHZhcmlldHkgb2YgbGltaXRhdGlvbnMgYW5kDSAgIHRyYWRlLW9mZnMgZGVwZW5k aW5nIG9uIHRoZSBmaW5hbCBwbGFjZW1lbnQuICBUaGUgbmV4dCBzZWN0aW9ucw0gICBvdXRs aW5lIHNvbWUgb2YgdGhlIGxvY2F0aW9ucyBhIE1lYXN1cmVtZW50IEFnZW50IG1heSBiZSBk ZXBsb3llZC4NICAgVGhpcyBpcyBub3QgYW4gZXhoYXVzdGl2ZSBsaXN0IGFuZCBjb21iaW5h dGlvbnMgbWF5IGFsc28gYXBwbHkuDQ0NDUVhcmRsZXksIGV0IGFsLiAgICAgICAgICAgRXhw aXJlcyBKdWx5IDI1LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDI1XQ0NSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICBMTUFQIEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFu dWFyeSAyMDE0DQ0NICAgSWYgdGhlIEluc3RydWN0aW9uIGluY2x1ZGVzIHNldmVyYWwgTWVh c3VyZW1lbnQgVGFza3MsIHRoZXNlIGNvdWxkIGJlDSAgIHNjaGVkdWxlZCB0byBydW4gYXQg ZGlmZmVyZW50IHRpbWVzIG9yIHBvc3NpYmx5IGF0IHRoZSBzYW1lIHRpbWUgLQ0gICBzb21l IFRhc2tzIG1heSBiZSBjb21wYXRpYmxlLCBpbiB0aGF0IHRoZXkgZG8gbm90IGFmZmVjdCBl YWNoIG90aGVyJ3MNICAgUmVzdWx0cywgd2hpbHN0IHdpdGggb3RoZXJzIGdyZWF0IGNhcmUg d291bGQgbmVlZCB0byBiZSB0YWtlbi4NDSAgIFRoZSBtZWFzdXJlbWVudCBzeXN0ZW0gYWxz byBuZWVkcyB0byBjb25zaWRlciBjYXJlZnVsbHkgaG93IHRvDSAgIGludGVycHJldCBtaXNz aW5nIFJlc3VsdHM7IGZvciBleGFtcGxlLCBpZiB0aGUgbWlzc2luZyBSZXN1bHRzIGFyZQ0g ICBpZ25vcmVkIGFuZCB0aGUgbGFjayBvZiBhIFJlcG9ydCBpcyBjYXVzZWQgYnkgaXRzIGJy b2FkYmFuZCBiZWluZw0gICBicm9rZW4sIHRoZW4gdGhlIGVzdGltYXRlIG9mIG92ZXJhbGwg cGVyZm9ybWFuY2UsIGF2ZXJhZ2VkIGFjcm9zcyBhbGwNICAgTUFzLCB3b3VsZCBiZSB0b28g b3B0aW1pc3RpYy4NDTYuMi4xLiAgTWVhc3VyZW1lbnQgQWdlbnQgZW1iZWRkZWQgaW4gc2l0 ZSBnYXRld2F5DQ0gICBBIE1lYXN1cmVtZW50IEFnZW50IGVtYmVkZGVkIHdpdGggdGhlIHNp dGUgZ2F0ZXdheSwgZm9yIGV4YW1wbGUgYQ0gICBob21lIHJvdXRlciBvciB0aGUgZWRnZSBy b3V0ZXIgb2YgYSBicmFuY2ggb2ZmaWNlIGluIGEgbWFuYWdlZA0gICBzZXJ2aWNlIGVudmly b25tZW50LCBpcyBvbmUgb2YgYmV0dGVyIHBsYWNlcyB0aGUgTWVhc3VyZW1lbnQgQWdlbnQN ICAgY291bGQgYmUgZGVwbG95ZWQuICBBbGwgc2l0ZS10by1JU1AgdHJhZmZpYyB3b3VsZCB0 cmF2ZXJzZSB0aHJvdWdoDSAgIHRoZSBnYXRld2F5IGFuZCBwYXNzaXZlIG1lYXN1cmVtZW50 cyBjb3VsZCBlYXNpbHkgYmUgcGVyZm9ybWVkLg0gICBTaW1pbGFybHksIGR1ZSB0byB0aGlz IHVzZXIgdHJhZmZpYyB2aXNpYmlsaXR5LCBhbiBBY3RpdmUNICAgTWVhc3VyZW1lbnRzIFRh c2sgY291bGQgYmUgcmVzY2hlZHVsZWQgc28gYXMgbm90IHRvIGNvbXBldGUgd2l0aCB1c2Vy DSAgIHRyYWZmaWMuICBHZW5lcmFsbHkgTkFUIGFuZCBmaXJld2FsbCBzZXJ2aWNlcyBhcmUg YnVpbHQgaW50byB0aGUNICAgZ2F0ZXdheSwgYWxsb3dpbmcgdGhlIE1lYXN1cmVtZW50IEFn ZW50IHRoZSBvcHRpb24gdG8gb2ZmZXIgaXRzDSAgIENvbnRyb2xsZXIgZmFjaW5nIG1hbmFn ZW1lbnQgaW50ZXJmYWNlIG91dHNpZGUgb2YgdGhlIE5BVC9maXJld2FsbC4NICAgVGhpcyBw bGFjZW1lbnQgb2YgdGhlIG1hbmFnZW1lbnQgaW50ZXJmYWNlIGFsbG93cyB0aGUgQ29udHJv bGxlciB0bw0gICB1bmlsYXRlcmFsbHkgY29udGFjdCB0aGUgTWVhc3VyZW1lbnQgQWdlbnQg Zm9yIGluc3RydWN0aW9ucy4NICAgSG93ZXZlciwgaWYgdGhlIHNpdGUgZ2F0ZXdheSBpcyBv d25lZCBhbmQgb3BlcmF0ZWQgYnkgdGhlIHNlcnZpY2UNICAgcHJvdmlkZXIsIHRoZSBNZWFz dXJlbWVudCBBZ2VudCB3aWxsIGdlbmVyYWxseSBub3QgYmUgZGlyZWN0bHkNICAgYXZhaWxh YmxlIGZvciBvdmVyIHRoZSB0b3AgcHJvdmlkZXJzLCB0aGUgcmVndWxhdG9yLCBlbmQgdXNl cnMgb3INICAgZW50ZXJwcmlzZXMuDQ02LjIuMi4gIE1lYXN1cmVtZW50IEFnZW50IGVtYmVk ZGVkIGJlaGluZCBzaXRlIE5BVCAvRmlyZXdhbGwNDSAgIFRoZSBNZWFzdXJlbWVudCBBZ2Vu dCBjb3VsZCBhbHNvIGJlIGVtYmVkZGVkIGJlaGluZCBhIE5BVCwgYQ0gICBmaXJld2FsbCwg b3IgYm90aC4gIEluIHRoaXMgY2FzZSB0aGUgQ29udHJvbGxlciBtYXkgbm90IGJlIGFibGUg dG8NICAgdW5pbGF0ZXJhbGx5IGNvbnRhY3QgdGhlIE1lYXN1cmVtZW50IEFnZW50IHVubGVz cyBlaXRoZXIgc3RhdGljIHBvcnQNICAgZm9yd2FyZGluZyBjb25maWd1cmF0aW9uIG9yIGZp cmV3YWxsIHBpbiBob2xpbmcgaXMgY29uZmlndXJlZCwgYW5kDSAgIG1pZ2h0IG5vdCBhbHdh eXMgYmUgcG9zc2libGUuICBJdCB3b3VsZCByZXF1aXJlIHVzZXIgaW50ZXJ2ZW50aW9uIG9y DSAgIHByZS1wcm92aXNpb25pbmcgYnkgdGhlIG9wZXJhdG9yIHZpYSBhIG1lY2hhbmlzbXMg c3VjaCBhcyBUUi0wNjkuDSAgIFRoZSBNZWFzdXJlbWVudCBBZ2VudCBtYXkgb3JpZ2luYXRl IGEgc2Vzc2lvbiB0b3dhcmRzIHRoZSBDb250cm9sbGVyDSAgIGFuZCBtYWludGFpbiB0aGUg c2Vzc2lvbiBmb3IgYmlkaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9ucy4gIFRoaXMNICAgd291 bGQgYWxsZXZpYXRlIHRoZSBuZWVkIHRvIGhhdmUgdXNlciBpbnRlcnZlbnRpb24gb24gdGhl IGdhdGV3YXksDSAgIGJ1dCB3b3VsZCByZWR1Y2UgdGhlIG92ZXJhbGwgc2FsZWFiaWxpdHkg b2YgdGhlIENvbnRyb2xsZXIgYXMgaXQNICAgd291bGQgaGF2ZSB0byBtYWludGFpbiBhIGhp Z2hlciBudW1iZXIgb2YgYWN0aXZlIHNlc3Npb25zLiAgVGhhdA0gICBzYWlkLCBzZW5kaW5n IGtlZXBhbGl2ZXMgdG8gcHJvcCBvcGVuIHRoZSBmaXJld2FsbCBjb3VsZCBzZXJ2ZSBhIGR1 YWwNICAgcHVycG9zZSBpbiB0ZXN0aW5nIG5ldHdvcmsgcmVhY2hhYmlsaXR5IGZvciB0aGUg TWVhc3VyZW1lbnQgQWdlbnQuDSAgIEFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIHVzZSBh IHByb3RvY29sIHN1Y2ggYXMgVVBuUCBvciBQQ1ANICAgW1JGQzY4ODddIHRvIGNvbnRyb2wg dGhlIE5BVC9maXJld2FsbCBpZiB0aGUgZ2F0ZXdheSBzdXBwb3J0cyB0aGlzDSAgIGtpbmQg b2YgY29udHJvbC4NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkg MjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMjZdDQ1JbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQN DQ02LjIuMy4gIE1lYXN1cmVtZW50IEFnZW50IGluIGEgbXVsdGktaG9tZWQgc2l0ZQ0NICAg QSBicm9hZGJhbmQgc2l0ZSBtYXkgYmUgbXVsdGktaG9tZWQuICBGb3IgZXhhbXBsZSwgdGhl IHNpdGUgbWF5IGJlDSAgIGNvbm5lY3RlZCB0byBtdWx0aXBsZSBicm9hZGJhbmQgSVNQcywg cGVyaGFwcyBmb3IgcmVkdW5kYW5jeSBvciBsb2FkLQ0gICBzaGFyaW5nLCBvciBoYXZlIGJv dGggd2lyZWQgYW5kIHdpcmVsZXNzIGJyb2FkYmFuZCBjb25uZWN0aXZpdHkuICBJdA0gICBt YXkgYWxzbyBiZSBoZWxwZnVsIHRvIHRoaW5rIG9mIGR1YWwgc3RhY2sgSVB2NCBhbmQgSVB2 NiBicm9hZGJhbmQNICAgZGV2aWNlcyBhcyBtdWx0aS1ob21lZC4gIEluIHRoZXNlIGNhc2Vz LCB0aGVyZSBuZWVkcyB0byBiZSBjbGFyaXR5IG9uDSAgIHdoaWNoIG5ldHdvcmsgY29ubmVj dGl2aXR5IG9wdGlvbiBpcyBiZWluZyBtZWFzdXJlZC4gIFNvbWV0aW1lcyB0aGlzDSAgIGlz IGVhc2lseSByZXNvbHZlZCBieSB0aGUgbG9jYXRpb24gb2YgdGhlIE1BIGl0c2VsZi4gIEZv ciBleGFtcGxlLCBpZg0gICB0aGUgTUEgaXMgYnVpbHQgaW50byB0aGUgZ2F0ZXdheSAoYW5k IHRoZSBnYXRld2F5IG9ubHkgaGFzIGEgc2luZ2xlDSAgIFdBTiBzaWRlIGludGVyZmFjZSks IHRoZXJlIGlzIGxpdHRsZSBjb25mdXNpb24gb3IgY2hvaWNlLiAgSG93ZXZlciwNICAgZm9y IG11bHRpLWhvbWVkIGdhdGV3YXlzIG9yIGRldmljZXMgYmVoaW5kIHRoZSBnYXRld2F5KHMp IG9mIG11bHRpLQ0gICBob21lZCBzaXRlcyBpdCB3b3VsZCBiZSBwcmVmZXJhYmxlIHRvIGV4 cGxpY2l0bHkgc2VsZWN0IHRoZSBuZXR3b3JrDSAgIHRvIG1lYXN1cmUgKFtSRkM1NTMzXSkg YnV0IHRoZSBuZXR3b3JrIG1lYXN1cmVkIHNob3VsZCBiZSBpbmNsdWRlZCBpbg0gICB0aGUg TWVhc3VyZW1lbnQgUmVzdWx0LiAgU2VjdGlvbiAzLjIgb2YgW0ktRC5pZXRmLWhvbWVuZXQt YXJjaF0NICAgZGVzY3JpYmVzIGR1YWwtc3RhY2sgYW5kIG11bHRpLWhvbWluZyB0b3BvbG9n aWVzIHRoYXQgbWlnaHQgYmUNICAgZW5jb3VudGVyZWQgaW4gYSBob21lIG5ldHdvcmsgKHdo aWNoIGlzIGdlbmVyYWxseSBhIGJyb2FkYmFuZA0gICBjb25uZWN0ZWQgc2l0ZSkuICBUaGUg TXVsdGlwbGUgSW50ZXJmYWNlcyAobWlmKSB3b3JraW5nIGdyb3VwIGNvdmVycw0gICBjYXNl cyB3aGVyZSBob3N0cyBhcmUgZWl0aGVyIGRpcmVjdGx5IGF0dGFjaGVkIHRvIG11bHRpcGxl IG5ldHdvcmtzDSAgIChwaHlzaWNhbCBvciB2aXJ0dWFsKSBvciBpbmRpcmVjdGx5IChtdWx0 aXBsZSBkZWZhdWx0IHJvdXRlcnMsIGV0Yy4pLg0gICBbUkZDNjQxOV0gcHJvdmlkZXMgdGhl IGN1cnJlbnQgcHJhY3RpY2VzIG9mIG11bHRpLWludGVyZmFjZXMgaG9zdHMNICAgdG9kYXku ICBBcyBvbmUgYWltIGlzIGZvciBhIE1BIGlzIHRvIG1lYXN1cmUgdGhlIGVuZCB1c2VyJ3Mg cXVhbGl0eQ0gICBvZiBleHBlcmllbmNlLCBpdCBpcyBpbXBvcnRhbnQgdG8gdW5kZXJzdGFu ZCB0aGUgY3VycmVudCBwcmFjdGljZXMuDQ02LjMuICBNZWFzdXJlbWVudCBQZWVyDQ0gICBB IE1lYXN1cmVtZW50IFBlZXIgcGFydGljaXBhdGVzIGluIEFjdGl2ZSBNZWFzdXJlbWVudCBU YXNrcy4gIEl0IG1heQ0gICBoYXZlIHNwZWNpZmljIGZ1bmN0aW9uYWxpdHkgdG8gZW5hYmxl IGl0IHRvIHBhcnRpY2lwYXRlIGluIGENICAgcGFydGljdWxhciBNZWFzdXJlbWVudCBNZXRo b2QuICBPbiB0aGUgb3RoZXIgaGFuZCwgb3RoZXIgTWVhc3VyZW1lbnQNICAgTWV0aG9kcyBt YXkgcmVxdWlyZSBubyBzcGVjaWFsIGZ1bmN0aW9uYWxpdHksIGZvciBleGFtcGxlIGlmIHRo ZQ0gICBNZWFzdXJlbWVudCBBZ2VudCBzZW5kcyBhIHBpbmcgdG8gZXhhbXBsZS5jb20gdGhl biB0aGUgc2VydmVyIGF0DSAgIGV4YW1wbGUuY29tIHBsYXlzIHRoZSByb2xlIG9mIGEgTWVh c3VyZW1lbnQgUGVlci4NDSAgIEEgZGV2aWNlIG1heSBwYXJ0aWNpcGF0ZSBpbiBzb21lIE1l YXN1cmVtZW50IFRhc2tzIGFzIGEgTWVhc3VyZW1lbnQNICAgQWdlbnQgYW5kIGluIG90aGVy cyBhcyBhIE1lYXN1cmVtZW50IFBlZXIuDQ03LiAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMN DSAgIFRoZSBzZWN1cml0eSBvZiB0aGUgTE1BUCBmcmFtZXdvcmsgc2hvdWxkIHByb3RlY3Qg dGhlIGludGVyZXN0cyBvZg0gICB0aGUgbWVhc3VyZW1lbnQgb3BlcmF0b3IocyksIHRoZSBu ZXR3b3JrIHVzZXIocykgYW5kIG90aGVyIGFjdG9ycyB3aG8NICAgY291bGQgYmUgaW1wYWN0 ZWQgYnkgYSBjb21wcm9taXNlZCBtZWFzdXJlbWVudCBkZXBsb3ltZW50LiAgVGhlDSAgIG1l YXN1cmVtZW50IHN5c3RlbSBtdXN0IHNlY3VyZSB0aGUgdmFyaW91cyBjb21wb25lbnRzIG9m IHRoZSBzeXN0ZW0NICAgZnJvbSB1bmF1dGhvcmlzZWQgYWNjZXNzIG9yIGNvcnJ1cHRpb24u DQ0gICBXZSBhc3N1bWUgdGhhdCBlYWNoIE1lYXN1cmVtZW50IEFnZW50IChNQSkgd2lsbCBy ZWNlaXZlIGl0cw0gICBJbnN0cnVjdGlvbnMgZnJvbSBhIHNpbmdsZSBvcmdhbmlzYXRpb24s IHdoaWNoIG9wZXJhdGVzIHRoZQ0gICBDb250cm9sbGVyLiAgVGhlc2UgSW5zdHJ1Y3Rpb25z IG11c3QgYmUgYXV0aGVudGljYXRlZCAodG8gZW5zdXJlIHRoYXQNICAgdGhleSBjb21lIGZy b20gdGhlIHRydXN0ZWQgQ29udHJvbGxlciksIGNoZWNrZWQgZm9yIGludGVncml0eSAodG8N DQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQgICAg ICAgICAgICAgICAgW1BhZ2UgMjddDQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExN QVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQNDQ0gICBlbnN1cmUg bm8tb25lIGhhcyB0YW1wZXJlZCB3aXRoIHRoZW0pIGFuZCBub3QgdnVsbmVyYWJsZSB0byBy ZXBsYXkNICAgYXR0YWNrcy4gIElmIGEgbWFsaWNpb3VzIHBhcnR5IGNhbiBnYWluIGNvbnRy b2wgb2YgdGhlIE1BIHRoZXkgY2FuDSAgIHVzZSBpdCB0byBsYXVuY2ggRG9TIGF0dGFja3Mg YXQgdGFyZ2V0cywgcmVkdWNlIHRoZSBlbmQgdXNlcidzDSAgIHF1YWxpdHkgb2YgZXhwZXJp ZW5jZSBhbmQgY29ycnVwdCB0aGUgTWVhc3VyZW1lbnQgUmVzdWx0cyB0aGF0IGFyZQ0gICBy ZXBvcnRlZCB0byB0aGUgQ29sbGVjdG9yLiAgQnkgYWx0ZXJpbmcgdGhlIE1lYXN1cmVtZW50 IFRhc2tzIGFuZC9vcg0gICB0aGUgYWRkcmVzcyB0aGF0IFJlc3VsdHMgYXJlIHJlcG9ydGVk IHRvLCB0aGV5IGNhbiBhbHNvIGNvbXByb21pc2UNICAgdGhlIGNvbmZpZGVudGlhbGl0eSBv ZiB0aGUgbmV0d29yayB1c2VyIGFuZCB0aGUgTUEgZW52aXJvbm1lbnQgKHN1Y2gNICAgYXMg aW5mb3JtYXRpb24gYWJvdXQgdGhlIGxvY2F0aW9uIG9mIGRldmljZXMgb3IgdGhlaXIgdHJh ZmZpYykuDQ0gICBSZXBvcnRpbmcgYnkgdGhlIE1BIG11c3QgYWxzbyBiZSBzZWN1cmVkIHRv IG1haW50YWluIGNvbmZpZGVudGlhbGl0eS4NICAgVGhlIHJlc3VsdHMgbXVzdCBiZSBlbmNy eXB0ZWQgc3VjaCB0aGF0IG9ubHkgdGhlIGF1dGhvcmlzZWQgQ29sbGVjdG9yDSAgIGNhbiBk ZWNyeXB0IHRoZSByZXN1bHRzIHRvIHByZXZlbnQgdGhlIGxlYWthZ2Ugb2YgY29uZmlkZW50 aWFsIG9yDSAgIHByaXZhdGUgaW5mb3JtYXRpb24uICBJbiBhZGRpdGlvbiBpdCBtdXN0IGJl IGF1dGhlbnRpY2F0ZWQgdGhhdCB0aGUNICAgcmVzdWx0cyBoYXZlIGNvbWUgZnJvbSB0aGUg ZXhwZWN0ZWQgTUEgYW5kIHRoYXQgdGhleSBoYXZlIG5vdCBiZWVuDSAgIHRhbXBlcmVkIHdp dGguICBJdCBtdXN0IG5vdCBiZSBwb3NzaWJsZSB0byBmb29sIGEgTUEgaW50byBpbmplY3Rp bmcNICAgZmFsc2lmaWVkIGRhdGEgaW50byB0aGUgbWVhc3VyZW1lbnQgcGxhdGZvcm0gb3Ig dG8gY29ycnVwdCB0aGUNICAgcmVzdWx0cyBvZiBhIHJlYWwgTUEuICBUaGUgcmVzdWx0cyBt dXN0IGFsc28gYmUgaGVsZCBhbmQgcHJvY2Vzc2VkDSAgIHNlY3VyZWx5IGFmdGVyIGNvbGxl Y3Rpb24gYW5kIGFuYWx5c2lzLg0NICAgQXZhaWxhYmlsaXR5IHNob3VsZCBhbHNvIGJlIGNv bnNpZGVyZWQuICBXaGlsZSB0aGUgbG9zcyBvZiBzb21lIE1Bcw0gICBtYXkgbm90IGJlIGNv bnNpZGVyZWQgY3JpdGljYWwsIHRoZSB1bmF2YWlsYWJpbGl0eSBvZiB0aGUgQ29sbGVjdG9y DSAgIGNvdWxkIG1lYW4gdGhhdCB2YWx1YWJsZSBidXNpbmVzcyBkYXRhIG9yIGRhdGEgY3Jp dGljYWwgdG8gYQ0gICByZWd1bGF0b3J5IHByb2Nlc3MgaXMgbG9zdC4gIFNpbWlsYXJseSwg dGhlIHVuYXZhaWxhYmlsaXR5IG9mIGENICAgQ29udHJvbGxlciBjb3VsZCBtZWFuIHRoYXQg dGhlIE1BcyBkbyBub3Qgb3BlcmF0ZSBhIGNvcnJlY3QNICAgTWVhc3VyZW1lbnQgU2NoZWR1 bGUuDQ0gICBBIG1hbGljaW91cyBwYXJ0eSBjb3VsZCAiZ2FtZSB0aGUgc3lzdGVtIi4gIEZv ciBleGFtcGxlLCB3aGVyZSBhDSAgIHJlZ3VsYXRvciBpcyBydW5uaW5nIGEgbWVhc3VyZW1l bnQgc3lzdGVtIGluIG9yZGVyIHRvIGJlbmNobWFyaw0gICBvcGVyYXRvcnMsIGFuIG9wZXJh dG9yIGNvdWxkIHRyeSB0byBpZGVudGlmeSB0aGUgYnJvYWRiYW5kIGxpbmVzIHRoYXQNICAg dGhlIHJlZ3VsYXRvciB3YXMgbWVhc3VyaW5nIGFuZCBwcmlvcml0aXNlIHRoYXQgdHJhZmZp Yy4gIFRoaXMNICAgcG90ZW50aWFsIGlzc3VlIGlzIGN1cnJlbnRseSBoYW5kbGVkIGJ5IGEg Y29kZSBvZiBjb25kdWN0LiAgSXQgaXMNICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIExN QVAgV0cgdG8gY29uc2lkZXIgdGhlIGlzc3VlLg0NOC4gIFByaXZhY3kgQ29uc2lkZXJhdGlv bnMgZm9yIExNQVANDSAgIFRoZSBMTUFQIFdvcmtpbmcgR3JvdXAgd2lsbCBjb25zaWRlciBw cml2YWN5IGFzIGEgY29yZSByZXF1aXJlbWVudA0gICBhbmQgd2lsbCBlbnN1cmUgdGhhdCBi eSBkZWZhdWx0IHRoZSBDb250cm9sIGFuZCBSZXBvcnQgUHJvdG9jb2xzDSAgIG9wZXJhdGUg aW4gYSBwcml2YWN5LXNlbnNpdGl2ZSBtYW5uZXIgYW5kIHRoYXQgcHJpdmFjeSBmZWF0dXJl cyBhcmUNICAgd2VsbC1kZWZpbmVkLg0NICAgVGhpcyBzZWN0aW9uIHByb3ZpZGVzIGEgc2V0 IG9mIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgZm9yIExNQVAuICBUaGlzDSAgIHNlY3Rpb24g YmVuZWZpdHMgZ3JlYXRseSBmcm9tIHRoZSB0aW1lbHkgcHVibGljYXRpb24gb2YgW1JGQzY5 NzNdLg0gICBQcml2YWN5IGFuZCBzZWN1cml0eSAoU2VjdGlvbiA3KSBhcmUgcmVsYXRlZC4g IEluIHNvbWUganVyaXNkaWN0aW9ucw0gICBwcml2YWN5IGlzIGNhbGxlZCBkYXRhIHByb3Rl Y3Rpb24uDQ0gICBXZSBiZWdpbiB3aXRoIGEgc2V0IG9mIGFzc3VtcHRpb25zIHJlbGF0ZWQg dG8gcHJvdGVjdGluZyB0aGUNICAgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIG9mIGluZGl2aWR1 YWxzIGFuZCBvcmdhbmlzYXRpb25zIHBhcnRpY2lwYXRpbmcNICAgaW4gTE1BUC1vcmNoZXN0 cmF0ZWQgbWVhc3VyZW1lbnQgYW5kIGRhdGEgY29sbGVjdGlvbi4NDQ0NRWFyZGxleSwgZXQg YWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1Bh Z2UgMjhdDQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAg ICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQNDQ04LjEuICBDYXRlZ29yaWVzIG9mIEVudGl0 aWVzIHdpdGggSW5mb3JtYXRpb24gb2YgSW50ZXJlc3QNDSAgIExNQVAgcHJvdG9jb2xzIG5l ZWQgdG8gcHJvdGVjdCB0aGUgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIG9mIHRoZQ0gICBmb2xs b3dpbmcgZW50aXRpZXMsIGluY2x1ZGluZyBpbmRpdmlkdWFscyBhbmQgb3JnYW5pc2F0aW9u cyB3aG8NICAgcGFydGljaXBhdGUgaW4gbWVhc3VyZW1lbnQgYW5kIGNvbGxlY3Rpb24gb2Yg cmVzdWx0cy4NDSAgIG8gIEluZGl2aWR1YWwgSW50ZXJuZXQgdXNlcnM6IFBlcnNvbnMgd2hv IHV0aWxpc2UgSW50ZXJuZXQgYWNjZXNzDSAgICAgIHNlcnZpY2VzIGZvciBjb21tdW5pY2F0 aW9ucyB0YXNrcywgYWNjb3JkaW5nIHRvIHRoZSB0ZXJtcyBvZg0gICAgICBzZXJ2aWNlIG9m IGEgc2VydmljZSBhZ3JlZW1lbnQuICBTdWNoIHBlcnNvbnMgbWF5IGJlIGEgc2VydmljZQ0g ICAgICBTdWJzY3JpYmVyLCBvciBoYXZlIGJlZW4gZ2l2ZW4gcGVybWlzc2lvbiBieSB0aGUg U3Vic2NyaWJlciB0byB1c2UNICAgICAgdGhlIHNlcnZpY2UuDQ0gICBvICBJbnRlcm5ldCBz ZXJ2aWNlIHByb3ZpZGVyczogT3JnYW5pc2F0aW9ucyB3aG8gb2ZmZXIgSW50ZXJuZXQNICAg ICAgYWNjZXNzIHNlcnZpY2Ugc3Vic2NyaXB0aW9ucywgYW5kIHRodXMgaGF2ZSBhY2Nlc3Mg dG8gc2Vuc2l0aXZlDSAgICAgIGluZm9ybWF0aW9uIG9mIGluZGl2aWR1YWxzIHdobyBjaG9v c2UgdG8gdXNlIHRoZSBzZXJ2aWNlLiAgVGhlc2UNICAgICAgb3JnYW5pc2F0aW9ucyBkZXNp cmUgdG8gcHJvdGVjdCB0aGVpciBTdWJzY3JpYmVycyBhbmQgdGhlaXIgb3duDSAgICAgIHNl bnNpdGl2ZSBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgc3RvcmVkIGluIHRoZSBwcm9jZXNz IG9mDSAgICAgIHBlcmZvcm1pbmcgTWVhc3VyZW1lbnQgVGFza3MgYW5kIGNvbGxlY3Rpbmcg YW5kIFJlc3VsdHMuDQ0gICBvICBSZWd1bGF0b3JzOiBQdWJsaWMgYXV0aG9yaXRpZXMgcmVz cG9uc2libGUgZm9yIGV4ZXJjaXNpbmcNICAgICAgc3VwZXJ2aXNpb24gb2YgdGhlIGVsZWN0 cm9uaWMgY29tbXVuaWNhdGlvbnMgc2VjdG9yLCBhbmQgd2hpY2ggbWF5DSAgICAgIGhhdmUg YWNjZXNzIHRvIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBvZiBpbmRpdmlkdWFscyB3aG8NICAg ICAgcGFydGljaXBhdGUgaW4gYSBtZWFzdXJlbWVudCBjYW1wYWlnbi4gIFNpbWlsYXJseSwg cmVndWxhdG9ycw0gICAgICBkZXNpcmUgdG8gcHJvdGVjdCB0aGUgcGFydGljaXBhbnRzIGFu ZCB0aGVpciBvd24gc2Vuc2l0aXZlDSAgICAgIGluZm9ybWF0aW9uLg0NICAgbyAgT3RoZXIg TE1BUCBzeXN0ZW0gb3BlcmF0b3JzOiBPcmdhbmlzYXRpb25zIHdobyBvcGVyYXRlIG1lYXN1 cmVtZW50DSAgICAgIHN5c3RlbXMgb3IgcGFydGljaXBhdGUgaW4gbWVhc3VyZW1lbnRzIGlu IHNvbWUgd2F5Lg0NICAgQWx0aG91Z2ggcHJpdmFjeSBpcyBhIHByb3RlY3Rpb24gZXh0ZW5k ZWQgdG8gaW5kaXZpZHVhbHMsIHdlIGluY2x1ZGUNICAgZGlzY3Vzc2lvbiBvZiBJU1BzIGFu ZCBvdGhlciBMTUFQIHN5c3RlbSBvcGVyYXRvcnMgaW4gdGhpcyBzZWN0aW9uLg0gICBUaGVz ZSBvcmdhbmlzYXRpb25zIGhhdmUgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGludm9sdmVkIGlu IHRoZSBMTUFQDSAgIHN5c3RlbSwgYW5kIG1hbnkgb2YgdGhlIHNhbWUgZGFuZ2VycyBhbmQg bWl0aWdhdGlvbnMgYXJlIGFwcGxpY2FibGUuDSAgIEZ1cnRoZXIsIHRoZSBJU1BzIHN0b3Jl IGluZm9ybWF0aW9uIG9uIHRoZWlyIFN1YnNjcmliZXJzIGJleW9uZCB0aGF0DSAgIHVzZWQg aW4gdGhlIExNQVAgc3lzdGVtIChmb3IgaW5zdGFuY2UgYmlsbGluZyBpbmZvcm1hdGlvbiks IGFuZCB0aGVyZQ0gICBzaG91bGQgYmUgYSBiZW5lZml0IGluIGNvbnNpZGVyaW5nIGFsbCB0 aGUgbmVlZHMgYW5kIHBvdGVudGlhbA0gICBzb2x1dGlvbnMgY29oZXJlbnRseS4NDTguMi4g IEV4YW1wbGVzIG9mIFNlbnNpdGl2ZSBJbmZvcm1hdGlvbg0NICAgVGhpcyBzZWN0aW9uIGdp dmVzIGV4YW1wbGVzIG9mIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUNICAg bWVhc3VyZWQgb3Igc3RvcmVkIGluIGEgbWVhc3VyZW1lbnQgc3lzdGVtLCBhbmQgd2hpY2gg aXMgdG8gYmUga2VwdA0gICBwcml2YXRlIGJ5IGRlZmF1bHQgaW4gdGhlIExNQVAgY29yZSBw cm90b2NvbHMuDQ0gICBFeGFtcGxlcyBvZiBTdWJzY3JpYmVyIG9yIGF1dGhvcmlzZWQgSW50 ZXJuZXQgdXNlciBzZW5zaXRpdmUNICAgaW5mb3JtYXRpb246DQ0NDQ0NRWFyZGxleSwgZXQg YWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1Bh Z2UgMjldDQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAg ICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQNDQ0gICBvICBTdWItSVAgbGF5ZXIgYWRkcmVz c2VzIGFuZCBuYW1lcyAoTUFDIGFkZHJlc3MsIGJhc2Ugc3RhdGlvbiBJRCwNICAgICAgU1NJ RCkNDSAgIG8gIElQIGFkZHJlc3MgaW4gdXNlDQ0gICBvICBQZXJzb25hbCBJZGVudGlmaWNh dGlvbiAocmVhbCBuYW1lKQ0NICAgbyAgTG9jYXRpb24gKHN0cmVldCBhZGRyZXNzLCBjaXR5 KQ0NICAgbyAgU3Vic2NyaWJlZCBzZXJ2aWNlIHBhcmFtZXRlcnMNDSAgIG8gIENvbnRlbnRz IG9mIHRyYWZmaWMgKGFjdGl2aXR5LCBETlMgcXVlcmllcywgZGVzdGluYXRpb25zLA0gICAg ICBlcXVpcG1lbnQgdHlwZXMsIGFjY291bnQgaW5mbyBmb3Igb3RoZXIgc2VydmljZXMsIGV0 Yy4pDQ0gICBvICBTdGF0dXMgYXMgYSBzdHVkeSB2b2x1bnRlZXIgYW5kIFNjaGVkdWxlIG9m IChBY3RpdmUpIE1lYXN1cmVtZW50DSAgICAgIFRhc2tzDQ0gICBFeGFtcGxlcyBvZiBJbnRl cm5ldCBTZXJ2aWNlIFByb3ZpZGVyIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbjoNDSAgIG8gIE1l YXN1cmVtZW50IGRldmljZSBpZGVudGlmaWNhdGlvbiAoZXF1aXBtZW50IElEIGFuZCBJUCBh ZGRyZXNzKQ0NICAgbyAgTWVhc3VyZW1lbnQgSW5zdHJ1Y3Rpb25zIChjaG9pY2Ugb2YgbWVh c3VyZW1lbnRzKQ0NICAgbyAgTWVhc3VyZW1lbnQgUmVzdWx0cyAoc29tZSBtYXkgYmUgc2hh cmVkLCBvdGhlcnMgbWF5IGJlIHByaXZhdGUpDQ0gICBvICBNZWFzdXJlbWVudCBTY2hlZHVs ZSAoZXhhY3QgdGltZXMpDQ0gICBvICBOZXR3b3JrIHRvcG9sb2d5IChsb2NhdGlvbnMsIGNv bm5lY3Rpdml0eSwgcmVkdW5kYW5jeSkNDSAgIG8gIFN1YnNjcmliZXIgYmlsbGluZyBpbmZv cm1hdGlvbiwgYW5kIGFueSBvZiB0aGUgYWJvdmUgU3Vic2NyaWJlcg0gICAgICBpbmZvcm1h dGlvbiBrbm93biB0byB0aGUgcHJvdmlkZXIuDQ0gICBvICBBdXRoZW50aWNhdGlvbiBjcmVk ZW50aWFscyAoc3VjaCBhcyBjZXJ0aWZpY2F0ZXMpDQ0gICBPdGhlciBvcmdhbmlzYXRpb25z IHdpbGwgaGF2ZSBzb21lIGNvbWJpbmF0aW9uIG9mIHRoZSBsaXN0cyBhYm92ZS4NICAgVGhl IExNQVAgc3lzdGVtIHdvdWxkIG5vdCB0eXBpY2FsbHkgZXhwb3NlIGFsbCBvZiB0aGUgaW5m b3JtYXRpb24NICAgYWJvdmUsIGJ1dCBjb3VsZCBleHBvc2UgYSBjb21iaW5hdGlvbiBvZiBp dGVtcyB3aGljaCBjb3VsZCBiZQ0gICBjb3JyZWxhdGVkIHdpdGggb3RoZXIgcGllY2VzIGNv bGxlY3RlZCBieSBhbiBhdHRhY2tlciAoYXMgZGlzY3Vzc2VkDSAgIGluIHRoZSBzZWN0aW9u IG9uIFRocmVhdHMgYmVsb3cpLg0NOC4zLiAgS2V5IERpc3RpbmN0aW9uIEJldHdlZW4gQWN0 aXZlIGFuZCBQYXNzaXZlIE1lYXN1cmVtZW50IFRhc2tzDQ0gICBQYXNzaXZlIGFuZCBBY3Rp dmUgTWVhc3VyZW1lbnQgVGFza3MgcmFpc2UgZGlmZmVyZW50IHByaXZhY3kgaXNzdWVzLg0N ICAgUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrcyBhcmUgY29uZHVjdGVkIG9uIGEgdXNlcidz IHRyYWZmaWMsIHN1Y2gNICAgdGhhdCBzZW5zaXRpdmUgaW5mb3JtYXRpb24gaXMgcHJlc2Vu dCBhbmQgc3RvcmVkIGluIHRoZSBtZWFzdXJlbWVudA0gICBzeXN0ZW0gKGhvd2V2ZXIgYnJp ZWZseSB0aGlzIHN0b3JhZ2UgbWF5IGJlKS4gIFdlIG5vdGUgdGhhdCBzb21lDSAgIGF1dGhv cml0aWVzIG1ha2UgYSBkaXN0aW5jdGlvbiBvbiB0aW1lIG9mIHN0b3JhZ2UsIGFuZCBpbmZv cm1hdGlvbg0NDQ1FYXJkbGV5LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSnVseSAyNSwg MjAxNCAgICAgICAgICAgICAgICBbUGFnZSAzMF0NDUludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgTE1BUCBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNA0NDSAg IHRoYXQgaXMga2VwdCBvbmx5IHRlbXBvcmFyaWx5IHRvIHBlcmZvcm0gYSBjb21tdW5pY2F0 aW9ucyBmdW5jdGlvbiBpcw0gICBub3Qgc3ViamVjdCB0byByZWd1bGF0aW9uIChmb3IgZXhh bXBsZSwgYWN0aXZlIHF1ZXVlIG1hbmFnZW1lbnQsIGRlZXANICAgcGFja2V0IGluc3BlY3Rp b24pLiAgUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrcyBjb3VsZCByZXZlYWwgYWxsIHRoZQ0g ICB3ZWJzaXRlcyBhIFN1YnNjcmliZXIgdmlzaXRzIGFuZCB0aGUgYXBwbGljYXRpb25zIGFu ZC9vciBzZXJ2aWNlcw0gICB0aGV5IHVzZS4NDSAgIEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNr cyBhcmUgY29uZHVjdGVkIG9uIHRyYWZmaWMgd2hpY2ggaXMgY3JlYXRlZA0gICBzcGVjaWZp Y2FsbHkgZm9yIHRoZSBwdXJwb3NlLiAgRXZlbiBpZiBhIHVzZXIgaG9zdCBnZW5lcmF0ZXMg QWN0aXZlDSAgIE1lYXN1cmVtZW50IFRyYWZmaWMsIHRoZXJlIGlzIHNpZ25pZmljYW50bHkg bGltaXRlZCBzZW5zaXRpdmUNICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFN1YnNjcmliZXIg cHJlc2VudCBhbmQgc3RvcmVkIGluIHRoZQ0gICBtZWFzdXJlbWVudCBzeXN0ZW0gY29tcGFy ZWQgdG8gdGhlIHBhc3NpdmUgY2FzZSwgYXMgZm9sbG93czoNDSAgIG8gIElQIGFkZHJlc3Mg aW4gdXNlIChhbmQgcG9zc2libHkgc3ViLUlQIGFkZHJlc3NlcyBhbmQgbmFtZXMpDQ0gICBv ICBTdGF0dXMgYXMgYSBzdHVkeSB2b2x1bnRlZXIgYW5kIFNjaGVkdWxlIG9mIEFjdGl2ZSBN ZWFzdXJlbWVudA0gICAgICBUYXNrcw0NICAgT24gdGhlIG90aGVyIGhhbmQsIGZvciBhIHNl cnZpY2UgcHJvdmlkZXIgdGhlIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbg0gICBsaWtlIE1lYXN1 cmVtZW50IFJlc3VsdHMgaXMgdGhlIHNhbWUgZm9yIFBhc3NpdmUgYW5kIEFjdGl2ZQ0gICBN ZWFzdXJlbWVudCBUYXNrcy4NDSAgIEZyb20gdGhlIFN1YnNjcmliZXIgcGVyc3BlY3RpdmUs IGJvdGggQWN0aXZlIGFuZCBQYXNzaXZlIE1lYXN1cmVtZW50DSAgIFRhc2tzIHBvdGVudGlh bGx5IGV4cG9zZSB0aGUgZGVzY3JpcHRpb24gb2YgSW50ZXJuZXQgYWNjZXNzIHNlcnZpY2UN ICAgYW5kIHNwZWNpZmljIHNlcnZpY2UgcGFyYW1ldGVycywgc3VjaCBhcyBzdWJzY3JpYmVk IHJhdGUgYW5kIHR5cGUgb2YNICAgYWNjZXNzLg0NOC40LiAgUHJpdmFjeSBhbmFseXNpcyBv ZiB0aGUgQ29tbXVuaWNhdGlvbnMgTW9kZWxzDQ0gICBUaGlzIHNlY3Rpb24gZXhhbWluZXMg ZWFjaCBvZiB0aGUgcHJvdG9jb2wgZXhjaGFuZ2VzIGRlc2NyaWJlZCBhdCBhDSAgIGhpZ2gg bGV2ZWwgaW4gU2VjdGlvbiA1IGFuZCBzb21lIGV4YW1wbGUgTWVhc3VyZW1lbnQgVGFza3Ms IGFuZA0gICBpZGVudGlmaWVzIHNwZWNpZmljIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiB3aGlj aCBtdXN0IGJlIHNlY3VyZWQNICAgZHVyaW5nIGNvbW11bmljYXRpb24gZm9yIGVhY2ggY2Fz ZS4gIFdpdGggdGhlIHByb3RvY29sLXJlbGF0ZWQNICAgc2Vuc2l0aXZlIGluZm9ybWF0aW9u IGlkZW50aWZpZWQsIHdlIGhhdmUgY2FuIGJldHRlciBjb25zaWRlciB0aGUNICAgdGhyZWF0 cyBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9uLg0NICAgRnJvbSB0aGUgcHJp dmFjeSBwZXJzcGVjdGl2ZSwgYWxsIGVudGl0aWVzIHBhcnRpY2lwYXRpbmcgaW4gTE1BUA0g ICBwcm90b2NvbHMgY2FuIGJlIGNvbnNpZGVyZWQgIm9ic2VydmVycyIgYWNjb3JkaW5nIHRv IHRoZSBkZWZpbml0aW9uDSAgIGluIFtSRkM2OTczXS4gIFRoZWlyIHN0b3JlZCBpbmZvcm1h dGlvbiBwb3RlbnRpYWxseSBwb3NlcyBhIHRocmVhdCB0bw0gICBwcml2YWN5LCBlc3BlY2lh bGx5IGlmIG9uZSBvciBtb3JlIG9mIHRoZXNlIGZ1bmN0aW9uYWwgZW50aXRpZXMgaGFzDSAg IGJlZW4gY29tcHJvbWlzZWQuICBMaWtld2lzZSwgYWxsIGRldmljZXMgb24gdGhlIHBhdGhz IHVzZWQgZm9yDSAgIGNvbnRyb2wsIHJlcG9ydGluZywgYW5kIG1lYXN1cmVtZW50IGFyZSBh bHNvIG9ic2VydmVycy4NDTguNC4xLiAgTUEgQm9vdHN0cmFwcGluZw0NICAgU2VjdGlvbiA1 LjEgcHJvdmlkZXMgdGhlIGNvbW11bmljYXRpb24gbW9kZWwgZm9yIHRoZSBCb290c3RyYXBw aW5nDSAgIHByb2Nlc3MuDQ0NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVz IEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMzFdDQ1JbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5 IDIwMTQNDQ0gICBBbHRob3VnaCB0aGUgc3BlY2lmaWNhdGlvbiBvZiBtZWNoYW5pc21zIGZv ciBCb290c3RyYXBwaW5nIHRoZSBNQSBhcmUNICAgYmV5b25kIHRoZSBMTUFQIHNjb3BlLCBk ZXNpZ25lcnMgc2hvdWxkIHJlY29nbml6ZSB0aGF0IHRoZQ0gICBCb290c3RyYXBwaW5nIHBy b2Nlc3MgaXMgZXh0cmVtZWx5IHBvd2VyZnVsIGFuZCBjb3VsZCBjYXVzZSBhbiBNQSB0bw0g ICBqb2luIGEgbmV3IG9yIGRpZmZlcmVudCBMTUFQIHN5c3RlbSB3aXRoIGEgZGlmZmVyZW50 IENvbnRyb2xsZXIgYW5kDSAgIENvbGxlY3Rvciwgb3Igc2ltcGx5IGluc3RhbGwgbmV3IE1l YXN1cmVtZW50IE1ldGhvZHMgKGZvciBleGFtcGxlIHRvDSAgIHBhc3NpdmVseSByZWNvcmQg RE5TIHF1ZXJpZXMpLiAgQSBCb290c3RyYXAgYXR0YWNrIGNvdWxkIHJlc3VsdCBpbiBhDSAg IGJyZWFjaCBvZiB0aGUgTE1BUCBzeXN0ZW0gd2l0aCBzaWduaWZpY2FudCBzZW5zaXRpdmUg aW5mb3JtYXRpb24NICAgZXhwb3N1cmUgZGVwZW5kaW5nIG9uIHRoZSBjYXBhYmlsaXRpZXMg b2YgdGhlIE1BLCBzbyBzdWZmaWNpZW50DSAgIHNlY3VyaXR5IHByb3RlY3Rpb25zIGFyZSB3 YXJyYW50ZWQuDQ0gICBUaGUgQm9vdHN0cmFwcGluZyBwcm9jZXNzIHByb3ZpZGVzIHNlbnNp dGl2ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUNICAgTE1BUCBzeXN0ZW0gYW5kIHRoZSBvcmdh bmlzYXRpb24gdGhhdCBvcGVyYXRlcyBpdCwgc3VjaCBhcw0NICAgbyAgSW5pdGlhbCBDb250 cm9sbGVyIElQIGFkZHJlc3Mgb3IgRlFETg0NICAgbyAgQXNzaWduZWQgQ29udHJvbGxlciBJ UCBhZGRyZXNzIG9yIEZRRE4NDSAgIG8gIFNlY3VyaXR5IGNlcnRpZmljYXRlcyBhbmQgY3Jl ZGVudGlhbHMNDSAgIER1cmluZyB0aGUgQm9vdHN0cmFwIHByb2Nlc3MsIHRoZSBNQSByZWNl aXZlcyBpdHMgTUEtSUQgd2hpY2ggaXMgYQ0gICBwZXJzaXN0ZW50IHBzZXVkb255bSBmb3Ig dGhlIFN1YnNjcmliZXIgaW4gdGhlIGNhc2UgdGhhdCB0aGUgTUEgaXMNICAgbG9jYXRlZCBh dCBhIHNlcnZpY2UgZGVtYXJjYXRpb24gcG9pbnQuICBUaHVzLCB0aGUgTUEtSUQgaXMNICAg Y29uc2lkZXJlZCBzZW5zaXRpdmUgaW5mb3JtYXRpb24sIGJlY2F1c2UgaXQgY291bGQgcHJv dmlkZSB0aGUgbGluaw0gICBiZXR3ZWVuIFN1YnNjcmliZXIgaWRlbnRpZmljYXRpb24gYW5k IE1lYXN1cmVtZW50cyBSZXN1bHRzLg0NICAgQWxzbywgdGhlIEJvb3RzdHJhcCBwcm9jZXNz IGNvdWxkIGFzc2lnbiBhIEdyb3VwLUlEIHRvIHRoZSBNQS4gIFRoZQ0gICBzcGVjaWZpYyBk ZWZpbml0aW9uIG9mIGluZm9ybWF0aW9uIHJlcHJlc2VudGVkIGluIGEgR3JvdXAtSUQgaXMg dG8gYmUNICAgZGV0ZXJtaW5lZCwgYnV0IHNldmVyYWwgZXhhbXBsZXMgYXJlIGVudmlzYWdl ZCBpbmNsdWRpbmcgdXNlIGFzIGENICAgcHNldWRvbnltIGZvciBhIHNldCBvZiBTdWJzY3Jp YmVycywgYSBjbGFzcyBvZiBzZXJ2aWNlLCBhbiBhY2Nlc3MNICAgdGVjaG5vbG9neSwgb3Ig b3RoZXIgaW1wb3J0YW50IGNhdGVnb3JpZXMuICBBc3NpZ25tZW50IG9mIGEgR3JvdXAtSUQN ICAgZW5hYmxlcyBhbm9ueW1pc2F0aW9uIHNldHMgdG8gYmUgZm9ybWVkIG9uIHRoZSBiYXNp cyBvZiBzZXJ2aWNlIHR5cGUvDSAgIGdyYWRlL3JhdGVzLiAgVGh1cywgdGhlIG1hcHBpbmcg YmV0d2VlbiBHcm91cC1JRCBhbmQgTUEtSUQgaXMNICAgY29uc2lkZXJlZCBzZW5zaXRpdmUg aW5mb3JtYXRpb24uDQ04LjQuMi4gIENvbnRyb2xsZXIgPC0+IE1lYXN1cmVtZW50IEFnZW50 DQ0gICBUaGUgaGlnaC1sZXZlbCBjb21tdW5pY2F0aW9uIG1vZGVsIGZvciBpbnRlcmFjdGlv bnMgYmV0d2VlbiB0aGUgTE1BUA0gICBDb250cm9sbGVyIGFuZCBNZWFzdXJlbWVudCBBZ2Vu dCBpcyBpbGx1c3RyYXRlZCBpbiBTZWN0aW9uIDUuMi4gIFRoZQ0gICBwcmltYXJ5IHB1cnBv c2Ugb2YgdGhpcyBleGNoYW5nZSBpcyB0byBhdXRoZW50aWNhdGUgYW5kIHRhc2sgYQ0gICBN ZWFzdXJlbWVudCBBZ2VudCB3aXRoIE1lYXN1cmVtZW50IEluc3RydWN0aW9ucywgd2hpY2gg dGhlDSAgIE1lYXN1cmVtZW50IEFnZW50IHRoZW4gYWN0cyBvbiBhdXRvbm9tb3VzbHkuDQ0g ICBQcmltYXJpbHkgSVAgYWRkcmVzc2VzIGFuZCBwc2V1ZG9ueW1zIChNQS1JRCwgR3JvdXAt SUQpIGFyZSBleGNoYW5nZWQNICAgd2l0aCBhIGNhcGFiaWxpdHkgcmVxdWVzdCwgdGhlbiBt ZWFzdXJlbWVudC1yZWxhdGVkIGluZm9ybWF0aW9uIG9mDSAgIGludGVyZXN0IHN1Y2ggYXMg dGhlIHBhcmFtZXRlcnMsIHNjaGVkdWxlLCBtZXRyaWNzLCBhbmQgSVAgYWRkcmVzc2VzDSAg IG9mIG1lYXN1cmVtZW50IGRldmljZXMuICBUaHVzLCB0aGUgbWVhc3VyZW1lbnQgSW5zdHJ1 Y3Rpb24gY29udGFpbnMNICAgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIHdoaWNoIG11c3QgYmUg c2VjdXJlZC4gIEZvciBleGFtcGxlLCB0aGUgZmFjdA0gICB0aGF0IGFuIElTUCBpcyBydW5u aW5nIGFkZGl0aW9uYWwgbWVhc3VyZW1lbnRzIGJleW9uZCB0aGUgc2V0DQ0NDUVhcmRsZXks IGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI1LCAyMDE0ICAgICAgICAgICAgICAg IFtQYWdlIDMyXQ0NSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBMTUFQIEZyYW1ld29y ayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE0DQ0NICAgcmVwb3J0ZWQgZXh0ZXJuYWxs eSBpcyBzZW5zaXRpdmUgaW5mb3JtYXRpb24sIGFzIGFyZSB0aGUgYWRkaXRpb25hbA0gICBN ZWFzdXJlbWVudHMgVGFza3MgdGhlbXNlbHZlcy4gIFRoZSBNZWFzdXJlbWVudCBTY2hlZHVs ZSBpcyBhbHNvDSAgIHNlbnNpdGl2ZSwgYmVjYXVzZSBhbiBhdHRhY2tlciBpbnRlbmRpbmcg dG8gYmlhcyB0aGUgcmVzdWx0cyB3aXRob3V0DSAgIGJlaW5nIGRldGVjdGVkIGNhbiB1c2Ug dGhpcyBpbmZvcm1hdGlvbiB0byBncmVhdCBhZHZhbnRhZ2UuDQ0gICBBbiBvcmdhbmlzYXRp b24gb3BlcmF0aW5nIHRoZSBDb250cm9sbGVyIGhhdmluZyBubyBzZXJ2aWNlDSAgIHJlbGF0 aW9uc2hpcCB3aXRoIGEgdXNlciB3aG8gaG9zdHMgdGhlIE1lYXN1cmVtZW50IEFnZW50ICpj b3VsZCogZ2Fpbg0gICByZWFsLW5hbWUgbWFwcGluZyB0byBhIHB1YmxpYyBJUCBhZGRyZXNz IHRocm91Z2ggdXNlciBwYXJ0aWNpcGF0aW9uDSAgIGluIGFuIExNQVAgc3lzdGVtICh0aGlz IGFwcGxpZXMgdG8gdGhlIE1lYXN1cmVtZW50IENvbGxlY3Rpb24NICAgcHJvdG9jb2wsIGFz IHdlbGwpLg0NOC40LjMuICBDb2xsZWN0b3IgPC0+IE1lYXN1cmVtZW50IEFnZW50DQ0gICBU aGUgaGlnaC1sZXZlbCBjb21tdW5pY2F0aW9uIG1vZGVsIGZvciBpbnRlcmFjdGlvbnMgYmV0 d2VlbiB0aGUNICAgTWVhc3VyZW1lbnQgQWdlbnQgYW5kIENvbGxlY3RvciBpcyBpbGx1c3Ry YXRlZCBpbiBTZWN0aW9uIDUuNC4gIFRoZQ0gICBwcmltYXJ5IHB1cnBvc2Ugb2YgdGhpcyBl eGNoYW5nZSBpcyB0byBhdXRoZW50aWNhdGUgYW5kIGNvbGxlY3QNICAgTWVhc3VyZW1lbnQg UmVzdWx0cyBmcm9tIGEgTUEsIHdoaWNoIHRoZSBNQSBoYXMgbWVhc3VyZWQgYXV0b25vbW91 c2x5DSAgIGFuZCBzdG9yZWQuDQ0gICBUaGUgTWVhc3VyZW1lbnQgUmVzdWx0cyBhcmUgdGhl IGFkZGl0aW9uYWwgc2Vuc2l0aXZlIGluZm9ybWF0aW9uDSAgIGluY2x1ZGVkIGluIHRoZSBD b2xsZWN0b3ItTUEgZXhjaGFuZ2UuICBPcmdhbmlzYXRpb25zIGNvbGxlY3RpbmcgTE1BUA0g ICBtZWFzdXJlbWVudHMgaGF2ZSB0aGUgcmVzcG9uc2liaWxpdHkgZm9yIGRhdGEgY29udHJv bC4gIFRodXMsIHRoZQ0gICBSZXN1bHRzIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBjb21tdW5p Y2F0ZWQgaW4gdGhlIENvbGxlY3RvciBwcm90b2NvbA0gICBtdXN0IGJlIHNlY3VyZWQuDQ04 LjQuNC4gIE1lYXN1cmVtZW50IFBlZXIgPC0+IE1lYXN1cmVtZW50IEFnZW50DQ0gICBBbHRo b3VnaCB0aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgbWVjaGFuaXNtcyBmb3IgYW4gQWN0aXZl DSAgIE1lYXN1cmVtZW50IFRhc2sgaXMgYmV5b25kIHRoZSBzY29wZSBvZiBMTUFQLCBpdCBy YWlzZXMgcG90ZW50aWFsDSAgIHByaXZhY3kgaXNzdWVzLiAgVGhlIGhpZ2gtbGV2ZWwgY29t bXVuaWNhdGlvbnMgbW9kZWwgYmVsb3cNICAgaWxsdXN0cmF0ZXMgdGhlIHZhcmlvdXMgZXhj aGFuZ2VzIHRvIGV4ZWN1dGUgQWN0aXZlIE1lYXN1cmVtZW50IFRhc2tzDSAgIGFuZCBzdG9y ZSB0aGUgUmVzdWx0cy4NDSAgIFdlIG5vdGUgdGhlIHBvdGVudGlhbCBmb3IgYWRkaXRpb25h bCBvYnNlcnZlcnMgaW4gdGhlIGZpZ3VyZXMgYmVsb3cNICAgYnkgaW5kaWNhdGluZyB0aGUg cG9zc2libGUgcHJlc2VuY2Ugb2YgYSBOQVQsIHdoaWNoIGhhcyBhZGRpdGlvbmFsDSAgIHNp Z25pZmljYW5jZSB0byB0aGUgcHJvdG9jb2xzIGFuZCBkaXJlY3Rpb24gb2YgaW5pdGlhdGlv bi4NDSAgIFRoZSB2YXJpb3VzIG1lc3NhZ2VzIGFyZSBvcHRpb25hbCwgZGVwZW5kaW5nIG9u IHRoZSBuYXR1cmUgb2YgdGhlDSAgIEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrLiAgSXQgbWF5 IGludm9sdmUgc2VuZGluZyBBY3RpdmUgTWVhc3VyZW1lbnQNICAgVHJhZmZpYyBmcm9tIHRo ZSBNZWFzdXJlbWVudCBQZWVyIHRvIE1BLCBNQSB0byBNZWFzdXJlbWVudCBQZWVyLCBvcg0g ICBib3RoLg0NDQ0NDQ0NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1 bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMzNdDQ1JbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIw MTQNDQ0gICAgX19fX19fX19fX19fX19fX18gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBfX19fX19fX19fX19fX19fXw0gICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwNICAgfE1lYXN1cmVtZW50IFBl ZXIgfD09PT09PT09PT09IE5BVCA/ID09PT09PT09PT18TWVhc3VyZW1lbnQgQWdlbnR8DSAg IHxfX19fX19fX19fX19fX19fX3wgICAgICAgICAgICAgICAgICAgICAgICAgICAgfF9fX19f X19fX19fX19fX19ffA0NICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtICAg ICAgICAgICAgICAoS2V5IE5lZ290aWF0aW9uICYNICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBFbmNyeXB0aW9uIFNldHVwKQ0gICAoRW5jcnlw dGVkIENoYW5uZWwgICAgICAgICAgICAgLT4NICAgRXN0YWJsaXNoZWQpDSAgIChBbm5vdW5j ZSBjYXBhYmlsaXRpZXMgICAgICAgICAtPg0gICAmIHN0YXR1cykNICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDwtICAgICAgICAgICAgICAoU2VsZWN0IGNhcGFiaWxpdGll cykNICAgQUNLICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0+DSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8LSAgICAgICAgICAgICAgKE1lYXN1cmVtZW50IFJlcXVl c3QNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChN QStNUCBJUEFkZHJzLHNldCBvZg0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNZXRyaWNzLCBTY2hlZHVsZSkpDSAgIEFDSyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtPg0NICAgQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMgICAg IDw+ICAgICAgICBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYw0gICAobWF5L21heSBub3Qg YmUgZW5jcnlwdGVkKSAgICAgICAgICAgICAgIChtYXkvbWF5IG5vdCBiZSBlbmNyeXB0ZWQp DQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0gICAgICAgICAgICAoU3Rv cCBNZWFzdXJlbWVudCBUYXNrKQ0NICAgTWVhc3VyZW1lbnQgUmVzdWx0cyAgICAgICAgICAg IC0+DSAgIChpZiBhcHBsaWNhYmxlKQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPC0gICAgICAgICAgICAgICBBQ0ssIENsb3NlDQ0gICBUaGlzIGV4Y2hhbmdlIHByaW1h cmlseSBleHBvc2VzIHRoZSBJUCBhZGRyZXNzZXMgb2YgbWVhc3VyZW1lbnQNICAgZGV2aWNl cyBhbmQgdGhlIGluZmVyZW5jZSBvZiBtZWFzdXJlbWVudCBwYXJ0aWNpcGF0aW9uIGZyb20g c3VjaA0gICB0cmFmZmljLiAgVGhlcmUgbWF5IGJlIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBv biBrZXkgcG9pbnRzIGluIGENICAgc2VydmljZSBwcm92aWRlcidzIG5ldHdvcmsgaW5jbHVk ZWQuICBUaGVyZSBtYXkgYWxzbyBiZSBhY2Nlc3MgdG8NICAgbWVhc3VyZW1lbnQtcmVsYXRl ZCBpbmZvcm1hdGlvbiBvZiBpbnRlcmVzdCBzdWNoIGFzIHRoZSBNZXRyaWNzLA0gICBTY2hl ZHVsZSwgYW5kIGludGVybWVkaWF0ZSByZXN1bHRzIGNhcnJpZWQgaW4gdGhlIEFjdGl2ZSBN ZWFzdXJlbWVudA0gICBUcmFmZmljICh1c3VhbGx5IGEgc2V0IG9mIHRpbWVzdGFtcHMpLg0N ICAgSWYgdGhlIEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIGlzIHVuZW5jcnlwdGVkLCBh cyBmb3VuZCBpbiBtYW55DSAgIHN5c3RlbXMgdG9kYXksIHRoZW4gYm90aCB0aW1pbmcgYW5k IGxpbWl0ZWQgcmVzdWx0cyBhcmUgb3BlbiB0byBvbi0NICAgcGF0aCBvYnNlcnZlcnMuDQ04 LjQuNS4gIFBhc3NpdmUgTWVhc3VyZW1lbnQgQWdlbnQNDSAgIEFsdGhvdWdoIHRoZSBzcGVj aWZpY2F0aW9uIG9mIHRoZSBtZWNoYW5pc21zIGZvciBhIFBhc3NpdmUNICAgTWVhc3VyZW1l bnQgVGFzayBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIExNQVAsIGl0IHJhaXNlcyBwb3RlbnRp YWwNICAgcHJpdmFjeSBpc3N1ZXMuDQ0gICBUaGUgaGlnaC1sZXZlbCBjb21tdW5pY2F0aW9u cyBtb2RlbCBiZWxvdyBpbGx1c3RyYXRlcyB0aGUgY29sbGVjdGlvbg0gICBvZiB1c2VyIGlu Zm9ybWF0aW9uIG9mIGludGVyZXN0IHdpdGggdGhlIE1lYXN1cmVtZW50IEFnZW50IHBlcmZv cm1pbmcNICAgdGhlIG1vbml0b3JpbmcgYW5kIHN0b3JhZ2Ugb2YgdGhlIFJlc3VsdHMuICBU aGlzIHBhcnRpY3VsYXIgZXhjaGFuZ2UNDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBF eHBpcmVzIEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMzRdDQ1JbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBK YW51YXJ5IDIwMTQNDQ0gICBpcyBmb3IgcGFzc2l2ZSBtZWFzdXJlbWVudCBvZiBETlMgUmVz cG9uc2UgVGltZSwgd2hpY2ggbW9zdA0gICBmcmVxdWVudGx5IHVzZXMgVURQIHRyYW5zcG9y dC4NDSAgICBfX19fX19fX19fX19fX19fXyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgX19fX19fX19fX19fDSAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA0gICB8ICBETlMgU2Vy dmVyICAgICB8PT09PT09PT09PT0gTkFUID8gPT09PT09PT09PSo9PT09PT09fCBVc2VyIGNs aWVudHwNICAgfF9fX19fX19fX19fX19fX19ffCAgICAgICAgICAgICAgICAgICAgICAgICAg ICBeICAgICAgIHxfX19fX19fX19fX198DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgX19fX19ffF9fX19fX18NICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwNICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIE1lYXN1cmVtZW50IHwNICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgQWdlbnQgICAgIHwNICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxfX19fX19fX19fX19fX3wN DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LSAgICAgICAgICAgICAgTmFt ZSBSZXNvbHV0aW9uIFJlcQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKE1BK01QIElQQWRkcnMsDSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRGVzaXJlZCBEb21haW4gTmFtZSkNICAgUmV0dXJu IFJlY29yZCAgICAgICAgICAgICAgICAgIC0+DQ0NICAgVGhpcyBleGNoYW5nZSBwcmltYXJp bHkgZXhwb3NlcyB0aGUgSVAgYWRkcmVzc2VzIG9mIG1lYXN1cmVtZW50DSAgIGRldmljZXMg YW5kIHRoZSBpbnRlbnQgdG8gY29tbXVuaWNhdGUgd2l0aCBvciBhY2Nlc3MgdGhlIHNlcnZp Y2VzIG9mDSAgICJEb21haW4gTmFtZSIuICBUaGVyZSBtYXkgYmUgaW5mb3JtYXRpb24gb24g a2V5IHBvaW50cyBpbiBhIHNlcnZpY2UNICAgcHJvdmlkZXIncyBuZXR3b3JrLCBzdWNoIGFz IHRoZSBhZGRyZXNzIG9mIG9uZSBvZiBpdHMgRE5TIHNlcnZlcnMuDSAgIFRoZSBNZWFzdXJl bWVudCBBZ2VudCBtYXkgYmUgZW1iZWRkZWQgaW4gdGhlIHVzZXIgaG9zdCwgb3IgaXQgbWF5 IGJlDSAgIGxvY2F0ZWQgaW4gYW5vdGhlciBkZXZpY2UgY2FwYWJsZSBvZiBvYnNlcnZpbmcg dXNlciB0cmFmZmljLg0NICAgSW4gcHJpbmNpcGxlLCBhbnkgb2YgdGhlIHVzZXIgc2Vuc2l0 aXZlIGluZm9ybWF0aW9uIG9mIGludGVyZXN0DSAgIChsaXN0ZWQgYWJvdmUpIGNhbiBiZSBj b2xsZWN0ZWQgYW5kIHN0b3JlZCBpbiB0aGUgcGFzc2l2ZSBtb25pdG9yaW5nDSAgIHNjZW5h cmlvIGFuZCBzbyBtdXN0IGJlIHNlY3VyZWQuDQ0gICBJdCB3b3VsZCBhbHNvIGJlIHBvc3Np YmxlIGZvciBhIE1lYXN1cmVtZW50IEFnZW50IHRvIHNvdXJjZSB0aGUgRE5TDSAgIHF1ZXJ5 IGl0c2VsZi4gIEJ1dCB0aGVuLCBhcyB3aXRoIGFueSBhY3RpdmUgbWVhc3VyZW1lbnQgdGFz aywgdGhlcmUNICAgYXJlIGZldyBwcml2YWN5IGNvbmNlcm5zLg0NOC40LjYuICBTdG9yYWdl IGFuZCBSZXBvcnRpbmcgb2YgTWVhc3VyZW1lbnQgUmVzdWx0cw0NICAgQWx0aG91Z2ggdGhl IG1lY2hhbmlzbXMgZm9yIGNvbW11bmljYXRpbmcgcmVzdWx0cyAoYmV5b25kIHRoZSBpbml0 aWFsDSAgIENvbGxlY3RvcikgYXJlIGJleW9uZCB0aGUgTE1BUCBzY29wZSwgdGhlcmUgYXJl IHBvdGVudGlhbCBwcml2YWN5DSAgIGlzc3VlcyByZWxhdGVkIHRvIGEgc2luZ2xlIG9yZ2Fu aXNhdGlvbidzIHN0b3JhZ2UgYW5kIHJlcG9ydGluZyBvZg0gICBNZWFzdXJlbWVudCBSZXN1 bHRzLiAgQm90aCBzdG9yYWdlIGFuZCByZXBvcnRpbmcgZnVuY3Rpb25zIGNhbiBoZWxwDSAg IHRvIHByZXNlcnZlIHByaXZhY3kgYnkgaW1wbGVtZW50aW5nIHRoZSBtaXRpZ2F0aW9ucyBk ZXNjcmliZWQgYmVsb3cuDQ04LjUuICBUaHJlYXRzDQ0gICBUaGlzIHNlY3Rpb24gaW5kaWNh dGVzIGhvdyBlYWNoIG9mIHRoZSB0aHJlYXRzIGRlc2NyaWJlZCBpbiBbUkZDNjk3M10NICAg YXBwbHkgdG8gdGhlIExNQVAgZW50aXRpZXMgYW5kIHRoZWlyIGNvbW11bmljYXRpb24gYW5k IHN0b3JhZ2Ugb2YNICAgImluZm9ybWF0aW9uIG9mIGludGVyZXN0Ii4NDQ0NDUVhcmRsZXks IGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI1LCAyMDE0ICAgICAgICAgICAgICAg IFtQYWdlIDM1XQ0NSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBMTUFQIEZyYW1ld29y ayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE0DQ0NOC41LjEuICBTdXJ2ZWlsbGFuY2UN DSAgIFNlY3Rpb24gNS4xLjEgb2YgW1JGQzY5NzNdIGRlc2NyaWJlcyBTdXJ2ZWlsbGFuY2Ug YXMgdGhlICJvYnNlcnZhdGlvbg0gICBvciBtb25pdG9yaW5nIG9mIGFuZCBpbmRpdmlkdWFs J3MgY29tbXVuaWNhdGlvbnMgb3IgYWN0aXZpdGllcy4iDSAgIEhlbmNlIGFsbCBQYXNzaXZl IE1lYXN1cmVtZW50IFRhc2tzIGFyZSBhIGZvcm0gb2Ygc3VydmVpbGxhbmNlLCB3aXRoDSAg IGluaGVyZW50IHJpc2tzLg0NICAgQWN0aXZlIE1lYXN1cmVtZW50IE1ldGhvZHMgd2hpY2gg YXZvaWQgcGVyaW9kcyBvZiB1c2VyIHRyYW5zbWlzc2lvbg0gICBpbmRpcmVjdGx5IHByb2R1 Y2UgYSByZWNvcmQgb2YgdGltZXMgd2hlbiBhIHN1YnNjcmliZXIgb3IgYXV0aG9yaXNlZA0g ICB1c2VyIGhhcyB1c2VkIHRoZWlyIG5ldHdvcmsgYWNjZXNzIHNlcnZpY2UuDQ0gICBBY3Rp dmUgTWVhc3VyZW1lbnQgTWV0aG9kcyBtYXkgYWxzbyB1dGlsaXNlIGFuZCBzdG9yZSBhIFN1 YnNjcmliZXIncw0gICBjdXJyZW50bHkgYXNzaWduZWQgSVAgYWRkcmVzcyB3aGVuIGNvbmR1 Y3RpbmcgbWVhc3VyZW1lbnRzIHRoYXQgYXJlDSAgIHJlbGV2YW50IHRvIGEgc3BlY2lmaWMg U3Vic2NyaWJlci4gIFNpbmNlIHRoZSBNZWFzdXJlbWVudCBSZXN1bHRzIGFyZQ0gICB0aW1l LXN0YW1wZWQsIHRoZXkgY291bGQgcHJvdmlkZSBhIHJlY29yZCBvZiBJUCBhZGRyZXNzIGFz c2lnbm1lbnRzDSAgIG92ZXIgdGltZS4NDSAgIEVpdGhlciBvZiB0aGUgYWJvdmUgcGllY2Vz IG9mIGluZm9ybWF0aW9uIGNvdWxkIGJlIHVzZWZ1bCBpbg0gICBjb3JyZWxhdGlvbiBhbmQg aWRlbnRpZmljYXRpb24sIGRlc2NyaWJlZCBiZWxvdy4NDTguNS4yLiAgU3RvcmVkIERhdGEg Q29tcHJvbWlzZQ0NICAgU2VjdGlvbiA1LjEuMiBvZiBbUkZDNjk3M10gZGVzY3JpYmVzIFN0 b3JlZCBEYXRhIENvbXByb21pc2UgYXMNICAgcmVzdWx0aW5nIGZyb20gaW5hZGVxdWF0ZSBt ZWFzdXJlcyB0byBzZWN1cmUgc3RvcmVkIGRhdGEgZnJvbQ0gICB1bmF1dGhvcmlzZWQgb3Ig aW5hcHByb3ByaWF0ZSBhY2Nlc3MuICBGb3IgTE1BUCBzeXN0ZW1zIHRoaXMgaW5jbHVkZXMN ICAgZGVsZXRpbmcgb3IgbW9kaWZ5aW5nIGNvbGxlY3RlZCBtZWFzdXJlbWVudCByZWNvcmRz LCBhcyB3ZWxsIGFzIGRhdGENICAgdGhlZnQuDQ0gICBUaGUgcHJpbWFyeSBMTUFQIGVudGl0 eSBzdWJqZWN0IHRvIGNvbXByb21pc2UgaXMgdGhlIHJlcG9zaXRvcnksDSAgIHdoaWNoIHN0 b3JlcyB0aGUgTWVhc3VyZW1lbnQgUmVzdWx0czsgZXh0ZW5zaXZlIHNlY3VyaXR5IGFuZCBw cml2YWN5DSAgIHRocmVhdCBtaXRpZ2F0aW9ucyBhcmUgd2FycmFudGVkLiAgVGhlIENvbGxl Y3RvciBhbmQgTUEgYWxzbyBzdG9yZQ0gICBzZW5zaXRpdmUgaW5mb3JtYXRpb24gdGVtcG9y YXJpbHksIGFuZCBuZWVkIHByb3RlY3Rpb24uICBUaGUNICAgY29tbXVuaWNhdGlvbnMgYmV0 d2VlbiB0aGUgbG9jYWwgc3RvcmFnZSBvZiB0aGUgQ29sbGVjdG9yIGFuZCB0aGUNICAgcmVw b3NpdG9yeSBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBMTUFQIHdvcmsgYXQgdGhpcyB0 aW1lLCB0aG91Z2gNICAgdGhpcyBjb21tdW5pY2F0aW9ucyBjaGFubmVsIHdpbGwgY2VydGFp bmx5IG5lZWQgcHJvdGVjdGlvbiBhcyB3ZWxsIGFzDSAgIHRoZSBtYXNzIHN0b3JhZ2UgaXRz ZWxmLg0NICAgVGhlIExNQVAgQ29udHJvbGxlciBtYXkgaGF2ZSBkaXJlY3QgYWNjZXNzIHRv IHN0b3JhZ2Ugb2YgU3Vic2NyaWJlcg0gICBpbmZvcm1hdGlvbiAobG9jYXRpb24sIGJpbGxp bmcsIHNlcnZpY2UgcGFyYW1ldGVycywgZXRjLikgYW5kIG90aGVyDSAgIGluZm9ybWF0aW9u IHdoaWNoIHRoZSBjb250cm9sbGluZyBvcmdhbmlzYXRpb24gY29uc2lkZXJzIHByaXZhdGUs IGFuZA0gICBhZ2FpbiBuZWVkcyBwcm90ZWN0aW9uLg0NOC41LjMuICBDb3JyZWxhdGlvbiBh bmQgSWRlbnRpZmljYXRpb24NDSAgIFNlY3Rpb25zIDUuMi4xIGFuZCA1LjIuMiBvZiBbUkZD Njk3M10gZGVzY3JpYmVzIENvcnJlbGF0aW9uIGFzDSAgIGNvbWJpbmluZyB2YXJpb3VzIHBp ZWNlcyBvZiBpbmZvcm1hdGlvbiB0byBvYnRhaW4gZGVzaXJlZA0gICBjaGFyYWN0ZXJpc3Rp Y3Mgb2YgYW4gaW5kaXZpZHVhbCwgYW5kIElkZW50aWZpY2F0aW9uIGFzIHVzaW5nIHRoaXMN ICAgcHJvY2VzcyB0byBpbmZlciBpZGVudGl0eS4NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAg ICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMzZdDQ1J bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAg ICAgICBKYW51YXJ5IDIwMTQNDQ0gICBUaGUgbWFpbiByaXNrIGlzIHRoYXQgdGhlIExNQVAg c3lzdGVtIGNvdWxkIHVud2l0dGluZ2x5IHByb3ZpZGUgYSBrZXkNICAgcGllY2Ugb2YgdGhl IGNvcnJlbGF0aW9uIGNoYWluLCBzdGFydGluZyB3aXRoIGFuIHVua25vd24gU3Vic2NyaWJl cidzDSAgIElQIGFkZHJlc3MgYW5kIGFub3RoZXIgcGllY2Ugb2YgaW5mb3JtYXRpb24uICBG b3IgZXhhbXBsZSwgYQ0gICBTdWJzY3JpYmVyIHV0aWxpc2VkIEludGVybmV0IGFjY2VzcyBm cm9tIDIwMDAgdG8gMjMxMCBVVEMsIGJlY2F1c2UNICAgdGhlIEFjdGl2ZSBNZWFzdXJlbWVu dCBUYXNrcyB3ZXJlIGRlZmVycmVkLCBvciBzZW50IGEgbmFtZSByZXNvbHV0aW9uDSAgIGZv ciB3d3cuZXhhbXBsZS5jb20gYXQgMjMwMCBVVEMuDQ04LjUuNC4gIFNlY29uZGFyeSBVc2Ug YW5kIERpc2Nsb3N1cmUNDSAgIFNlY3Rpb25zIDUuMi4zIGFuZCA1LjIuNCBvZiBbUkZDNjk3 M10gZGVzY3JpYmVzIFNlY29uZGFyeSBVc2UgYXMNICAgdW5hdXRob3Jpc2VkIHV0aWxpc2F0 aW9uIG9mIGFuIGluZGl2aWR1YWwncyBpbmZvcm1hdGlvbiBmb3IgYSBwdXJwb3NlDSAgIHRo ZSBpbmRpdmlkdWFsIGRpZCBub3QgaW50ZW5kLCBhbmQgRGlzY2xvc3VyZSBpcyB3aGVuIHN1 Y2gNICAgaW5mb3JtYXRpb24gaXMgcmV2ZWFsZWQgY2F1c2luZyBvdGhlcidzIG5vdGlvbnMg b2YgdGhlIGluZGl2aWR1YWwgdG8NICAgY2hhbmdlLCBvciBjb25maWRlbnRpYWxpdHkgdG8g YmUgdmlvbGF0ZWQuDQ0gICBQYXNzaXZlIE1lYXN1cmVtZW50IFRhc2tzIGFyZSBhIGZvcm0g b2YgU2Vjb25kYXJ5IFVzZSwgYW5kIHRoZQ0gICBTdWJzY3JpYmVycycgcGVybWlzc2lvbiBh bmQgdGhlIG1lYXN1cmVkIElTUCdzIHBlcm1pc3Npb24gc2hvdWxkIGJlDSAgIG9idGFpbmVk IGJlZm9yZWhhbmQuICBBbHRob3VnaCB1c2VyIHRyYWZmaWMgaXMgb25seSBpbmRpcmVjdGx5 DSAgIGludm9sdmVkLCB0aGUgTWVhc3VyZW1lbnQgUmVzdWx0cyBmcm9tIEFjdGl2ZSBNZWFz dXJlbWVudCBUYXNrcw0gICBwcm92aWRlIHNvbWUgbGltaXRlZCBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgU3Vic2NyaWJlci9JU1AgYW5kIGNvdWxkDSAgIGJlIHVzZWQgZm9yIFNlY29uZGFy eSBVc2VzLiAgRm9yIGV4YW1wbGUsIHRoZSB1c2Ugb2YgdGhlIFJlc3VsdHMgaW4NICAgdW5h dXRob3Jpc2VkIG1hcmtldGluZyBjYW1wYWlnbnMgd291bGQgcXVhbGlmeSBhcyBTZWNvbmRh cnkgVXNlLg0NOC42LiAgTWl0aWdhdGlvbnMNDSAgIFRoaXMgc2VjdGlvbiBleGFtaW5lcyB0 aGUgbWl0aWdhdGlvbnMgbGlzdGVkIGluIHNlY3Rpb24gNiBvZg0gICBbUkZDNjk3M10gYW5k IHRoZWlyIGFwcGxpY2FiaWxpdHkgdG8gTE1BUCBzeXN0ZW1zLiAgTm90ZSB0aGF0IGVhY2gN ICAgc2VjdGlvbiBpbiBbUkZDNjk3M10gaWRlbnRpZmllcyB0aGUgdGhyZWF0IGNhdGVnb3Jp ZXMgdGhhdCBlYWNoDSAgIHRlY2huaXF1ZSBtaXRpZ2F0ZXMuDQ04LjYuMS4gIERhdGEgTWlu aW1pc2F0aW9uDQ0gICBTZWN0aW9uIDYuMSBvZiBbUkZDNjk3M10gZW5jb3VyYWdlcyBjb2xs ZWN0aW5nIGFuZCBzdG9yaW5nIHRoZQ0gICBtaW5pbWFsIGluZm9ybWF0aW9uIG5lZWRlZCB0 byBwZXJmb3JtIGEgdGFzay4NDSAgIFRoZXJlIGFyZSB0d28gbGV2ZWxzIG9mIGluZm9ybWF0 aW9uIG5lZWRlZCBmb3IgTE1BUCByZXN1bHRzIHRvIGJlDSAgIHVzZWZ1bCBmb3IgYSBzcGVj aWZpYyB0YXNrOiB0cm91Ymxlc2hvb3RpbmcgYW5kIGdlbmVyYWwgcmVzdWx0cw0gICByZXBv cnRpbmcuDQ0gICBGb3IgZ2VuZXJhbCByZXN1bHRzLCB0aGUgcmVzdWx0cyBjYW4gYmUgYWdn cmVnYXRlZCBpbnRvIGxhcmdlDSAgIGNhdGVnb3JpZXMgKHRoZSBtb250aCBvZiBNYXJjaCwg YWxsIHN1YnNjcmliZXJzIFdlc3Qgb2YgdGhlDSAgIE1pc3Npc3NpcHBpIFJpdmVyKS4gIElu IHRoaXMgY2FzZSwgYWxsIGluZGl2aWR1YWwgaWRlbnRpZmljYXRpb25zDSAgIChpbmNsdWRp bmcgSVAgYWRkcmVzcyBvZiB0aGUgTUEpIGNhbiBiZSBleGNsdWRlZCwgYW5kIG9ubHkgcmVs ZXZhbnQNICAgcmVzdWx0cyBhcmUgcHJvdmlkZWQuICBIb3dldmVyLCB0aGlzIGltcGxpZXMg YSBmaWx0ZXJpbmcgcHJvY2VzcyB0bw0gICByZWR1Y2UgdGhlIGluZm9ybWF0aW9uIGZpZWxk cywgYmVjYXVzZSBncmVhdGVyIGRldGFpbCB3YXMgbmVlZGVkIHRvDSAgIGNvbmR1Y3QgdGhl IE1lYXN1cmVtZW50IFRhc2tzIGluIHRoZSBmaXJzdCBwbGFjZS4NDQ0NDQ1FYXJkbGV5LCBl dCBhbC4gICAgICAgICAgIEV4cGlyZXMgSnVseSAyNSwgMjAxNCAgICAgICAgICAgICAgICBb UGFnZSAzN10NDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTE1BUCBGcmFtZXdvcmsg ICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNA0NDSAgIEZvciB0cm91Ymxlc2hvb3Rpbmcs IHNvIHRoYXQgYSBuZXR3b3JrIG9wZXJhdG9yIG9yIGVuZCB1c2VyIGNhbg0gICBpZGVudGlm eSBhIHBlcmZvcm1hbmNlIGlzc3VlIG9yIGZhaWx1cmUsIHBvdGVudGlhbGx5IGFsbCB0aGUg bmV0d29yaw0gICBpbmZvcm1hdGlvbiAoSVAgYWRkcmVzc2VzLCBlcXVpcG1lbnQgSURzLCBs b2NhdGlvbiksIE1lYXN1cmVtZW50DSAgIFNjaGVkdWxlLCBzZXJ2aWNlIGNvbmZpZ3VyYXRp b24sIE1lYXN1cmVtZW50IFJlc3VsdHMsIGFuZCBvdGhlcg0gICBpbmZvcm1hdGlvbiBtYXkg YXNzaXN0IGluIHRoZSBwcm9jZXNzLiAgVGhpcyBpbmNsdWRlcyB0aGUgaW5mb3JtYXRpb24N ICAgbmVlZGVkIHRvIGNvbmR1Y3QgdGhlIE1lYXN1cmVtZW50cyBUYXNrcywgYW5kIHJlcHJl c2VudHMgYSBuZWVkIHdoZXJlDSAgIHRoZSBtYXhpbXVtIHJlbGV2YW50IGluZm9ybWF0aW9u IGlzIGRlc2lyYWJsZSwgdGhlcmVmb3JlIHRoZSBncmVhdGVzdA0gICBwcm90ZWN0aW9ucyBz aG91bGQgYmUgYXBwbGllZC4NDSAgIFdlIG5vdGUgdGhhdCBhIHVzZXIgbWF5IGdpdmUgdGVt cG9yYXJ5IHBlcm1pc3Npb24gZm9yIFBhc3NpdmUNICAgTWVhc3VyZW1lbnQgVGFza3MgdG8g ZW5hYmxlIGRldGFpbGVkIHRyb3VibGVzaG9vdGluZywgYnV0IHdpdGhob2xkDSAgIHBlcm1p c3Npb24gZm9yIHRoZW0gaW4gZ2VuZXJhbC4gIEhlcmUgdGhlIGdyZWF0ZXN0IGJyZWFkdGgg b2YNICAgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGlzIHBvdGVudGlhbGx5IGV4cG9zZWQsIGFu ZCB0aGUgbWF4aW11bSBwcml2YWN5DSAgIHByb3RlY3Rpb24gbXVzdCBiZSBwcm92aWRlZC4N DSAgIEZvciBNQXMgd2l0aCBhY2Nlc3MgdG8gdGhlIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBv ZiB1c2VycyAoZS5nLiwNICAgd2l0aGluIGEgaG9tZSBvciBhIHBlcnNvbmFsIGhvc3QvaGFu ZHNldCksIGl0IGlzIGRlc2lyYWJsZSBmb3IgdGhlDSAgIHJlc3VsdHMgY29sbGVjdGlvbiB0 byBtaW5pbWlzZSB0aGUgZGF0YSByZXBvcnRlZCwgYnV0IGFsc28gdG8gYmFsYW5jZQ0gICB0 aGlzIGRlc2lyZSB3aXRoIHRoZSBuZWVkcyBvZiB0cm91Ymxlc2hvb3Rpbmcgd2hlbiBhIHNl cnZpY2UNICAgc3Vic2NyaXB0aW9uIGV4aXN0cyBiZXR3ZWVuIHRoZSB1c2VyIGFuZCBvcmdh bmlzYXRpb24gb3BlcmF0aW5nIHRoZQ0gICBtZWFzdXJlbWVudHMuDQ0gICBGb3IgcGFzc2l2 ZSBtZWFzdXJlbWVudHMgd2hlcmUgdGhlIE1BIHJlcG9ydHMgZmxvdyBpbmZvcm1hdGlvbiB0 byB0aGUNICAgQ29sbGVjdG9yLCB0aGUgQ29sbGVjdG9yIG1heSBwZXJmb3JtIHByZS1zdG9y YWdlIG1pbmltaXNhdGlvbiBhbmQNICAgb3RoZXIgbWl0aWdhdGlvbnMgKGJlbG93KSB0byBo ZWxwIHByZXNlcnZlIHByaXZhY3kuDQ04LjYuMi4gIEFub255bWl0eQ0NICAgU2VjdGlvbiA2 LjEuMSBvZiBbUkZDNjk3M10gZGVzY3JpYmVzIGEgd2F5IGluIHdoaWNoIGFub255bWl0eSBp cw0gICBhY2hpZXZlZDogInRoZXJlIG11c3QgZXhpc3QgYSBzZXQgb2YgaW5kaXZpZHVhbHMg dGhhdCBhcHBlYXIgdG8gaGF2ZQ0gICB0aGUgc2FtZSBhdHRyaWJ1dGVzIGFzIHRoZSBpbmRp dmlkdWFsIiwgZGVmaW5lZCBhcyBhbiAiYW5vbnltaXR5DSAgIHNldCIuDQ0gICBFeHBlcmlt ZW50YWwgbWV0aG9kcyBmb3IgYW5vbnltaXNhdGlvbiBvZiB1c2VyIGlkZW50aWZpYWJsZSBk YXRhDSAgIGFwcGxpY2FibGUgdG8gUGFzc2l2ZSBNZWFzdXJlbWVudCBNZXRob2RzIGhhdmUg YmVlbiBpZGVudGlmaWVkIGluDSAgIFtSRkM2MjM1XS4gIEhvd2V2ZXIsIHRoZSBmaW5kaW5n cyBvZiBzZXZlcmFsIG9mIHRoZSBzYW1lIGF1dGhvcnMgaXMNICAgdGhhdCAidGhlcmUgaXMg aW5jcmVhc2luZyBldmlkZW5jZSB0aGF0IGFub255bWlzYXRpb24gYXBwbGllZCB0bw0gICBu ZXR3b3JrIHRyYWNlIG9yIGZsb3cgZGF0YSBvbiBpdHMgb3duIGlzIGluc3VmZmljaWVudCBm b3IgbWFueSBkYXRhDSAgIHByb3RlY3Rpb24gYXBwbGljYXRpb25zIGFzIGluIFtCdXIxMF0u Ig0NICAgRXNzZW50aWFsbHksIHRoZSBkZXRhaWxzIG9mIHBhc3NpdmUgbWVhc3VyZW1lbnQg dGFza3MgY2FuIG9ubHkgYmUNICAgYWNjZXNzZWQgYnkgY2xvc2VkIG9yZ2FuaXNhdGlvbnMs IGFuZCB1bmtub3duIGluamVjdGlvbiBhdHRhY2tzIGFyZQ0gICBhbHdheXMgbGVzcyBleHBl bnNpdmUgdGhhbiB0aGUgcHJvdGVjdGlvbnMgZnJvbSB0aGVtLiAgSG93ZXZlciwgc29tZQ0g ICBmb3JtcyBvZiBzdW1tYXJ5IG1heSBwcm90ZWN0IHRoZSB1c2VyJ3Mgc2Vuc2l0aXZlIGlu Zm9ybWF0aW9uDSAgIHN1ZmZpY2llbnRseSB3ZWxsLCBhbmQgc28gZWFjaCBNZXRyaWMgbXVz dCBiZSBldmFsdWF0ZWQgaW4gdGhlIGxpZ2h0DSAgIG9mIHByaXZhY3kuDQ0NDQ0NRWFyZGxl eSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAg ICAgW1BhZ2UgMzhdDQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExNQVAgRnJhbWV3 b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQNDQ0gICBUaGUgbWV0aG9kcyBpbiBb UkZDNjIzNV0gY291bGQgYmUgYXBwbGllZCBtb3JlIHN1Y2Nlc3NmdWxseSBpbiBBY3RpdmUN ICAgTWVhc3VyZW1lbnQgTWV0aG9kcywgd2hlcmUgdGhlcmUgYXJlIHByb3RlY3Rpb25zIGZy b20gaW5qZWN0aW9uDSAgIGF0dGFjay4gIFRoZSBzdWNjZXNzZnVsIGF0dGFjayB3b3VsZCBy ZXF1aXJlIGJyZWFraW5nIHRoZSBpbnRlZ3JpdHkNICAgcHJvdGVjdGlvbiBvZiB0aGUgTE1B UCBSZXBvcnRpbmcgUHJvdG9jb2wgYW5kIGluamVjdGluZyBNZWFzdXJlbWVudA0gICBSZXN1 bHRzIChrbm93biBmaW5nZXJwcmludCwgc2VlIHNlY3Rpb24gMy4yIG9mIFtSRkM2OTczXSkg Zm9yDSAgIGluY2x1c2lvbiB3aXRoIHRoZSBzaGFyZWQgYW5kIGFub255bWlzZWQgcmVzdWx0 cywgdGhlbiBmaW5nZXJwcmludGluZw0gICB0aG9zZSByZWNvcmRzIHRvIGFzY2VydGFpbiB0 aGUgYW5vbnltaXNhdGlvbiBwcm9jZXNzLg0NICAgQmVzaWRlIGFub255bWlzYXRpb24gb2Yg bWVhc3VyZWQgUmVzdWx0cyBmb3IgYSBzcGVjaWZpYyB1c2VyIG9yDSAgIHByb3ZpZGVyLCB0 aGUgdmFsdWUgb2Ygc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGNhbiBiZSBmdXJ0aGVyIGRpbHV0 ZWQNICAgYnkgc3VtbWFyaXNpbmcgdGhlIHJlc3VsdHMgb3ZlciBtYW55IGluZGl2aWR1YWxz IG9yIGFyZWFzIHNlcnZlZCBieQ0gICB0aGUgcHJvdmlkZXIuICBUaGVyZSBpcyBhbiBvcHBv cnR1bml0eSBlbmFibGVkIGJ5IGZvcm1pbmcgYW5vbnltaXR5DSAgIHNldHMgW1JGQzY5NzNd IGJhc2VkIG9uIHRoZSByZWZlcmVuY2UgcGF0aCBtZWFzdXJlbWVudCBwb2ludHMgaW4NICAg W0ktRC5pZXRmLWlwcG0tbG1hcC1wYXRoXS4gIEZvciBleGFtcGxlLCBhbGwgbWVhc3VyZW1l bnRzIGZyb20gdGhlDSAgIFN1YnNjcmliZXIgZGV2aWNlIGNhbiBiZSBpZGVudGlmaWVkIGFz ICJtcDAwMCIsIGluc3RlYWQgb2YgdXNpbmcgdGhlDSAgIElQIGFkZHJlc3Mgb3Igb3RoZXIg ZGV2aWNlIGluZm9ybWF0aW9uLiAgVGhlIHNhbWUgYW5vbnltaXNhdGlvbg0gICBhcHBsaWVz IHRvIHRoZSBJbnRlcm5ldCBTZXJ2aWNlIFByb3ZpZGVyLCB3aGVyZSB0aGVpciBJbnRlcm5l dA0gICBnYXRld2F5IHdvdWxkIGJlIHJlZmVycmVkIHRvIGFzICJtcDE5MCIuDQ04LjYuMy4g IFBzZXVkb255bWl0eQ0NICAgU2VjdGlvbiA2LjEuMiBvZiBbUkZDNjk3M10gaW5kaWNhdGVz IHRoYXQgcHNldWRvbnltcywgb3Igbmlja25hbWVzLA0gICBhcmUgYSBwb3NzaWJsZSBtaXRp Z2F0aW9uIHRvIHJldmVhbGluZyBvbmUncyB0cnVlIGlkZW50aXR5LCBzaW5jZQ0gICB0aGVy ZSBpcyBubyByZXF1aXJlbWVudCB0byB1c2UgcmVhbCBuYW1lcyBpbiBhbG1vc3QgYWxsIHBy b3RvY29scy4NDSAgIEEgcHNldWRvbnltIGZvciBhIG1lYXN1cmVtZW50IGRldmljZSdzIElQ IGFkZHJlc3MgY291bGQgYmUgYW4gTE1BUC0NICAgdW5pcXVlIGVxdWlwbWVudCBJRC4gIEhv d2V2ZXIsIHRoaXMgd291bGQgbGlrZWx5IGJlIGEgcGVybWFuZW50DSAgIGhhbmRsZSBmb3Ig dGhlIGRldmljZSwgYW5kIGxvbmctdGVybSB1c2Ugd2Vha2VucyBhIHBzZXVkb255bSdzIHBv d2VyDSAgIHRvIG9ic2N1cmUgaWRlbnRpdHkuDQ04LjYuNC4gIE90aGVyIE1pdGlnYXRpb25z DQ0gICBEYXRhIGNhbiBiZSBkZS1wZXJzb25hbGlzZWQgYnkgYmx1cnJpbmcgaXQsIGZvciBl eGFtcGxlIGJ5IGFkZGluZw0gICBzeW50aGV0aWMgZGF0YSwgZGF0YS1zd2FwcGluZywgb3Ig cGVydHVyYmluZyB0aGUgdmFsdWVzIGluIHdheXMgdGhhdA0gICBjYW4gYmUgcmV2ZXJzZWQg b3IgY29ycmVjdGVkLg0NICAgU2VjdGlvbnMgNi4yIGFuZCA2LjMgb2YgW1JGQzY5NzNdIGRl c2NyaWJlIFVzZXIgUGFydGljaXBhdGlvbiBhbmQNICAgU2VjdXJpdHksIHJlc3BlY3RpdmVs eS4NDSAgIFdoZXJlIExNQVAgbWVhc3VyZW1lbnRzIGludm9sdmUgZGV2aWNlcyBvbiB0aGUg U3Vic2NyaWJlcidzIHByZW1pc2VzDSAgIG9yIFN1YnNjcmliZXItb3duZWQgZXF1aXBtZW50 LCBpdCBpcyBlc3NlbnRpYWwgdG8gc2VjdXJlIHRoZQ0gICBTdWJzY3JpYmVyJ3MgcGVybWlz c2lvbiB3aXRoIHJlZ2FyZCB0byB0aGUgc3BlY2lmaWMgaW5mb3JtYXRpb24gdGhhdA0gICB3 aWxsIGJlIGNvbGxlY3RlZC4gIFRoZSBpbmZvcm1lZCBjb25zZW50IG9mIHRoZSBTdWJzY3Jp YmVyIChhbmQsIGlmDSAgIGRpZmZlcmVudCwgdGhlIGVuZCB1c2VyKSBpcyBuZWVkZWQsIGlu Y2x1ZGluZyB0aGUgc3BlY2lmaWMgcHVycG9zZSBvZg0gICB0aGUgbWVhc3VyZW1lbnRzLiAg VGhlIGFwcHJvdmFsIHByb2Nlc3MgY291bGQgaW52b2x2ZSBzaG93aW5nIHRoZQ0gICBTdWJz Y3JpYmVyIHRoZWlyIG1lYXN1cmVkIGluZm9ybWF0aW9uIGFuZCByZXN1bHRzIGJlZm9yZSBp bnN0aXR1dGluZw0gICBwZXJpb2RpYyBjb2xsZWN0aW9uLCBvciBiZWZvcmUgYWxsIGluc3Rh bmNlcyBvZiBjb2xsZWN0aW9uLCB3aXRoIHRoZQ0gICBvcHRpb24gdG8gY2FuY2VsIGNvbGxl Y3Rpb24gdGVtcG9yYXJpbHkgb3IgcGVybWFuZW50bHkuDQ0NDUVhcmRsZXksIGV0IGFsLiAg ICAgICAgICAgRXhwaXJlcyBKdWx5IDI1LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDM5 XQ0NSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBMTUFQIEZyYW1ld29yayAgICAgICAg ICAgICAgICAgSmFudWFyeSAyMDE0DQ0NICAgSXQgc2hvdWxkIGFsc28gYmUgY2xlYXIgd2hv IGlzIGxlZ2FsbHkgcmVzcG9uc2libGUgZm9yIGRhdGENICAgcHJvdGVjdGlvbiAocHJpdmFj eSk7IGluIHNvbWUganVyaXNkaWN0aW9ucyB0aGlzIHJvbGUgaXMgY2FsbGVkIHRoZQ0gICAn ZGF0YSBjb250cm9sbGVyJy4gIEl0IGlzIGdvb2QgcHJhY3RpY2UgdG8gdGltZSBsaW1pdCB0 aGUgc3RvcmFnZSBvZg0gICBwZXJzb25hbCBpbmZvcm1hdGlvbi4NDSAgIEFsdGhvdWdoIHRo ZSBkZXRhaWxzIG9mIHZlcmlmaWNhdGlvbiB3b3VsZCBiZSBpbXBlbmV0cmFibGUgdG8gbW9z dA0gICBzdWJzY3JpYmVycywgdGhlIE1BIGNvdWxkIGJlIGFyY2hpdGVjdGVkIGFzIGFuICJh cHAiIHdpdGggb3Blbg0gICBzb3VyY2UtY29kZSwgcHJlLWRvd25sb2FkIGFuZCBlbWJlZGRl ZCB0ZXJtcyBvZiB1c2UgYW5kIGFncmVlbWVudCBvbg0gICBtZWFzdXJlbWVudHMsIGFuZCBw cm90ZWN0aW9uIGZyb20gY29kZSBtb2RpZmljYXRpb25zIHVzdWFsbHkgcHJvdmlkZWQNICAg YnkgdGhlIGFwcC1zdG9yZXMuICBGdXJ0aGVyLCB0aGUgYXBwIGl0c2VsZiBjb3VsZCBwcm92 aWRlIGRhdGENICAgcmVkdWN0aW9uIGFuZCB0ZW1wb3Jhcnkgc3RvcmFnZSBtaXRpZ2F0aW9u cyBhcyBhcHByb3ByaWF0ZSBhbmQNICAgY2VydGlmaWVkIHRocm91Z2ggY29kZSByZXZpZXcu DQ0gICBMTUFQIHByb3RvY29scywgZGV2aWNlcywgYW5kIHRoZSBpbmZvcm1hdGlvbiB0aGV5 IHN0b3JlIGNsZWFybHkgbmVlZA0gICB0byBiZSBzZWN1cmUgZnJvbSB1bmF1dGhvcmlzZWQg YWNjZXNzLiAgVGhpcyBpcyB0aGUgaGFuZC1vZmYgYmV0d2Vlbg0gICBwcml2YWN5IGFuZCBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyAoU2VjdGlvbiA3KS4gIFRoZSBEYXRhIENvbnRyb2xs ZXINICAgaGFzIHRoZSAobGVnYWwpIHJlc3BvbnNpYmlsaXR5IHRvIG1haW50YWluIGRhdGEg cHJvdGVjdGlvbnMgZGVzY3JpYmVkDSAgIGluIHRoZSBTdWJzY3JpYmVyJ3MgYWdyZWVtZW50 IGFuZCBhZ3JlZW1lbnRzIHdpdGggb3RoZXINICAgb3JnYW5pc2F0aW9ucy4NDTkuICBJQU5B IENvbnNpZGVyYXRpb25zDQ0gICBUaGVyZSBhcmUgbm8gSUFOQSBjb25zaWRlcmF0aW9ucyBp biB0aGlzIG1lbW8uDQ0xMC4gIEFja25vd2xlZGdtZW50cw0NICAgVGhpcyBkb2N1bWVudCBp cyBhIG1lcmdlciBvZiB0aHJlZSBpbmRpdmlkdWFsIGRyYWZ0czogZHJhZnQtZWFyZGxleS0N ICAgbG1hcC10ZXJtaW5vbG9neS0wMiwgZHJhZnQtYWtodGVyLWxtYXAtZnJhbWV3b3JrLTAw LCBhbmQgZHJhZnQtDSAgIGVhcmRsZXktbG1hcC1mcmFtZXdvcmstMDIuDQ0gICBUaGFua3Mg dG8gSnVlcmdlbiBTY2hvZW53YWVsZGVyIGZvciBoaXMgZGV0YWlsZWQgcmV2aWV3IG9mIHRo ZQ0gICB0ZXJtaW5vbG9neS4gIFRoYW5rcyB0byBDaGFybGVzIENvb2sgZm9yIGEgdmVyeSBk ZXRhaWxlZCByZXZpZXcgb2YNICAgLTAyLg0NICAgVGhhbmtzIHRvIG51bWVyb3VzIHBlb3Bs ZSBmb3IgbXVjaCBkaXNjdXNzaW9uLCBkaXJlY3RseSBhbmQgb24gdGhlDSAgIExNQVAgbGlz dCAoYXBvbG9naWVzIHRvIHRob3NlIHVuaW50ZW50aW9uYWxseSBvbWl0dGVkKTogQWxhbiBD bGFyaywNICAgQWxpc3NhIENvb3BlciwgQW5kcmVhIFNvcHBlcmEsIEJhcmJhcmEgU3Rhcmss IEJlbm9pdCBDbGFpc2UsIEJyaWFuDSAgIFRyYW1tZWxsLCBDaGFybGVzIENvb2ssIERhdmUg VGhvcm5lLCBGcm9kZSBTb2VyZW5zZW4sIEdyZWcgTWlyc2t5LA0gICBHdWFuZ3FpbmcgRGVu ZywgSmFzb24gV2VpbCwgSmVhbi1GcmFuY29pcyBUcmVtYmxheSwgSmVyb21lIEJlbm9pdCwN ICAgSm9hY2hpbSBGYWJpbmksIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciwgSnVra2EgTWFubmVy LCBLZW4gS28sIE1pY2hhZWwNICAgQnVnZW5oYWdlbiwgUm9sZiBXaW50ZXIsIFNhbSBDcmF3 Zm9yZCwgU2hhcmFtIEhha2ltaSwgU3RldmUgTWlsbGVyLA0gICBUZWQgTGVtb24sIFRpbW90 aHkgQ2FyZXksIFZhaWJoYXYgQmFqcGFpLCBXaWxsaWFtIEx1cHRvbi4NDSAgIFBoaWxpcCBF YXJkbGV5LCBUcmV2b3IgQnVyYnJpZGdlIGFuZCBNYXJjZWxvIEJhZ251bG8gd29yayBpbiBw YXJ0IG9uDSAgIHRoZSBMZW9uZSByZXNlYXJjaCBwcm9qZWN0LCB3aGljaCByZWNlaXZlcyBm dW5kaW5nIGZyb20gdGhlIEV1cm9wZWFuDSAgIFVuaW9uIFNldmVudGggRnJhbWV3b3JrIFBy b2dyYW1tZSBbRlA3LzIwMDctMjAxM10gdW5kZXIgZ3JhbnQNICAgYWdyZWVtZW50IG51bWJl ciAzMTc2NDcuDQ0NDQ1FYXJkbGV5LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSnVseSAy NSwgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSA0MF0NDUludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgTE1BUCBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNA0N DTExLiAgSGlzdG9yeQ0NICAgRmlyc3QgV0cgdmVyc2lvbiwgY29weSBvZiBkcmFmdC1mb2xr cy1sbWFwLWZyYW1ld29yay0wMC4NDTExLjEuICBGcm9tIC0wMCB0byAtMDENDSAgIG8gIG5l dyBzdWItc2VjdGlvbiBvZiBwb3NzaWJsZSB1c2Ugb2YgR3JvdXAtSURzIGZvciBwcml2YWN5 DQ0gICBvICB0d2VhayB0byBkZWZpbml0aW9uIG9mIENvbnRyb2wgcHJvdG9jb2wNDSAgIG8g IGZpeCB0eXBvIGluIGZpZ3VyZSBpbiBTNS40DQ0xMS4yLiAgRnJvbSAtMDEgdG8gLTAyDQ0g ICBvICBjaGFuZ2UgdG8gSU5GT1JNQVRJT05BTCB0cmFjayAocHJldmlvdXMgdmVyc2lvbiBo YWQgdHlwbydkDSAgICAgIFN0YW5kYXJkcyB0cmFjaykNDSAgIG8gIG5ldyBkZWZpbml0aW9u cyBmb3IgQ2FwYWJpbGl0aWVzIEluZm9ybWF0aW9uIGFuZCBGYWlsdXJlDSAgICAgIEluZm9y bWF0aW9uDQ0gICBvICBjbGFyaWZ5IHRoYXQgZGlhZ3JhbXMgc2hvdyBMTUFQLWxldmVsIGlu Zm9ybWF0aW9uIGZsb3dzLg0gICAgICBVbmRlcmx5aW5nIHByb3RvY29sIGNvdWxkIGRvIG90 aGVyIGludGVyYWN0aW9ucywgZWcgdG8gZ2V0IHRocm91Z2gNICAgICAgTkFUIG9yIGZvciBD b2xsZWN0b3IgdG8gcHVsbCBhIFJlcG9ydA0NICAgbyAgYWRkIGhpbnQgdGhhdCBhZnRlciBh IHJlLWJvb3Qgc2hvdWxkIHBhdXNlIHJhbmRvbSB0aW1lIGJlZm9yZSByZS0NICAgICAgcmVn aXN0ZXIgKHRvIGF2b2lkIG1hc3MgY2FsbGluZyBldmVudCkNDSAgIG8gIGRlbGV0ZSB0aGUg b3BlbiBpc3N1ZSAid2hhdCBoYXBwZW5zIGlmIGEgQ29udHJvbGxlciBmYWlscyIgKG5vcm1h bA0gICAgICBtZXRob2RzIGNhbiBoYW5kbGUpDQ0gICBvICBhZGQgc29tZSBleHRyYSB3b3Jk cyBhYm91dCBtdWx0aXBsZSBUYXNrcyBpbiBvbmUgU2NoZWR1bGUNDSAgIG8gIGNsYXJpZnkg dGhhdCBuZXcgU2NoZWR1bGUgcmVwbGFjZXMgKHJhdGhlciB0aGFuIGFkZHMgdG8pIGFuZCBv bGQNICAgICAgb25lLiAgU2ltaWxhcmx5IGZvciBuZXcgY29uZmlndXJhdGlvbiBvZiBNZWFz dXJlbWVudCBUYXNrcyBvcg0gICAgICBSZXBvcnQgQ2hhbm5lbHMuDQ0gICBvICBjbGFyaWZ5 IHN1cHByZXNzaW9uIGlzIHRlbXBvcmFyeSBzdG9wOyBzZW5kIGEgbmV3IFNjaGVkdWxlIHRv DSAgICAgIHBlcm1hbmVudGx5IHN0b3AgVGFza3MNDSAgIG8gIGFsdGVyIHN1cHByZXNzaW9u IHNvIGl0IGlzIEFDS2VkDQ0gICBvICBhZGQgdW4tc3VwcHJlc3MgbWVzc2FnZQ0NICAgbyAg ZXhwYW5kIHRoZSB0ZXh0IG9uIGVycm9yIHJlcG9ydGluZywgdG8gbWVudGlvbiBSZXBvcnRp bmcgZmFpbHVyZXMNICAgICAgKGFzIHdlbGwgYXMgZmFpbHVyZXMgdG8gYWN0aW9uIG9yIGV4 ZWN1dGUgTWVhc3VyZW1lbnQgVGFzayAmDSAgICAgIFNjaGVkdWxlKQ0NICAgbyAgYWRkIHNv bWUgdGV4dCBhYm91dCBob3cgdG8gaGF2ZSBUYXNrcyBydW5uaW5nIGluZGVmaW5pdGVseQ0N DQ1FYXJkbGV5LCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSnVseSAyNSwgMjAxNCAgICAg ICAgICAgICAgICBbUGFnZSA0MV0NDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTE1B UCBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNA0NDSAgIG8gIGFkZCB0 aGF0IG9wdGlvbmFsbHkgYSBSZXBvcnQgaXMgbm90IHNlbnQgd2hlbiB0aGVyZSBhcmUgbm8N ICAgICAgTWVhc3VyZW1lbnQgUmVzdWx0cw0NICAgbyAgYWRkIHRoYXQgYSBNZWFzdXJlbWVu dCBUYXNrIG1heSBjcmVhdGUgbW9yZSB0aGFuIG9uZSBNZWFzdXJlbWVudA0gICAgICBSZXN1 bHQNDSAgIG8gIGNsYXJpZnkgL2FtZW5kIC9leHBhbmQgdGhhdCBSZXBvcnRzIGluY2x1ZGUg dGhlICJyYXciIE1lYXN1cmVtZW50DSAgICAgIFJlc3VsdHMgLSBhbnkgcHJlLXByb2Nlc3Np bmcgaXMgbGVmdCBmb3IgbG1hcDIuMA0NICAgbyAgYWRkIHNvbWUgY2F1dGlvbmFyeSB3b3Jk cyBhYm91dCB3aGF0IGlmIHRoZSBDb2xsZWN0b3IgdW5leHBlY3RlZGx5DSAgICAgIGRvZXNu J3QgaGVhciBmcm9tIGEgTUENDSAgIG8gIGFkZCBzb21lIGV4dHJhIHdvcmRzIGFib3V0IHRo ZSBwb3RlbnRpYWwgaW1wYWN0IG9mIE1lYXN1cmVtZW50DSAgICAgIFRhc2tzDQ0gICBvICBj bGFyaWZpZWQgdmFyaW91cyBhc3BlY3RzIG9mIHRoZSBwcml2YWN5IHNlY3Rpb24NDSAgIG8g IHVwZGF0ZWQgcmVmZXJlbmNlcw0NICAgbyAgbWlub3IgdHdlYWtzDQ0xMS4zLiAgRnJvbSAt MDIgdG8gLTAzDQ0gICBvICBhbGlnbm1lbnQgd2l0aCB0aGUgSW5mb3JtYXRpb24gTW9kZWwN ICAgICAgW0ktRC5idXJicmlkZ2UtbG1hcC1pbmZvcm1hdGlvbi1tb2RlbF0gYXMgdGhpcyBp cyBhZ3JlZWQgYXMgYSBXRw0gICAgICBkb2N1bWVudA0NICAgbyAgT25lLW9mZiBhbmQgcGVy aW9kaWMgTWVhc3VyZW1lbnQgU2NoZWR1bGVzIGFyZSBrZXB0IHNlcGFyYXRlLCBzbw0gICAg ICB0aGF0IHRoZXkgY2FuIGJlIHVwZGF0ZWQgaW5kZXBlbmRlbnRseQ0NICAgbyAgTWVhc3Vy ZW1lbnQgU3VwcHJlc3Npb24gaW4gYSBzZXBhcmF0ZSBzdWItc2VjdGlvbi4gIENhbiBub3cN ICAgICAgb3B0aW9uYWxseSBpbmNsdWRlIHBhcnRpY3VsYXIgTWVhc3VyZW1lbnQgVGFza3Mg Ji9vciBTY2hlZHVsZXMgdG8NICAgICAgc3VwcHJlc3MsIGFuZCBzdGFydC9zdG9wIHRpbWUN DSAgIG8gIGZvciBjbGFyaXR5LCBjb25jZXB0IG9mIENoYW5uZWwgc3BsaXQgaW50byBDb250 cm9sLCBSZXBvcnQgYW5kIE1BLQ0gICAgICB0by1Db250cm9sbGVyIENoYW5uZWxzDQ0gICBv ICBudW1lcm91cyBlZGl0b3JpYWwgY2hhbmdlcywgbWFpbmx5IGFyaXNpbmcgZnJvbSBhIHZl cnkgZGV0YWlsZWQNICAgICAgcmV2aWV3IGJ5IENoYXJsZXMgQ29vaw0NICAgbw0NMTIuICBJ bmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQ0gICBbQnVyMTBdICAgIEJ1cmtoYXJ0LCBNLiwgU2No YXR6bWFubiwgRC4sIFRyYW1tZWxsLCBCLiwgYW5kIEUuIEJvc2NoaSwNICAgICAgICAgICAg ICAiVGhlIFJvbGUgb2YgTmV0d29yayBUcmFjZSBhbm9ueW1pc2F0aW9uIFVuZGVyIEF0dGFj ayIsDSAgICAgICAgICAgICAgSmFudWFyeSAyMDEwLg0NDQ0NRWFyZGxleSwgZXQgYWwuICAg ICAgICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgNDJd DQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAg ICAgICAgICBKYW51YXJ5IDIwMTQNDQ0gICBbUTE3NDFdICAgIFEuMTc0MS43LCAsICJJTVQt MjAwMCByZWZlcmVuY2VzIHRvIFJlbGVhc2UgOSBvZiBHU00tDSAgICAgICAgICAgICAgZXZv bHZlZCBVTVRTIGNvcmUgbmV0d29yayIsDSAgICAgICAgICAgICAgaHR0cDovL3d3dy5pdHUu aW50L3JlYy9ULVJFQy1RLjE3NDEuNy9lbiwgTm92ZW1iZXIgMjAxMS4NDSAgIFtSRkMxMDM1 XSAgTW9ja2FwZXRyaXMsIFAuLCAiRG9tYWluIG5hbWVzIC0gaW1wbGVtZW50YXRpb24gYW5k DSAgICAgICAgICAgICAgc3BlY2lmaWNhdGlvbiIsIFNURCAxMywgUkZDIDEwMzUsIE5vdmVt YmVyIDE5ODcuDQ0gICBbUkZDNDEwMV0gIFJlc2NvcmxhLCBFLiBhbmQgSUFCLCAiV3JpdGlu ZyBQcm90b2NvbCBNb2RlbHMiLCBSRkMgNDEwMSwNICAgICAgICAgICAgICBKdW5lIDIwMDUu DQ0gICBbUkZDNDEyMl0gIExlYWNoLCBQLiwgTWVhbGxpbmcsIE0uLCBhbmQgUi4gU2Fseiwg IkEgVW5pdmVyc2FsbHkNICAgICAgICAgICAgICBVbmlxdWUgSURlbnRpZmllciAoVVVJRCkg VVJOIE5hbWVzcGFjZSIsIFJGQyA0MTIyLCBKdWx5DSAgICAgICAgICAgICAgMjAwNS4NDSAg IFtSRkM1MzU3XSAgSGVkYXlhdCwgSy4sIEtyemFub3dza2ksIFIuLCBNb3J0b24sIEEuLCBZ dW0sIEsuLCBhbmQgSi4NICAgICAgICAgICAgICBCYWJpYXJ6LCAiQSBUd28tV2F5IEFjdGl2 ZSBNZWFzdXJlbWVudCBQcm90b2NvbCAoVFdBTVApIiwNICAgICAgICAgICAgICBSRkMgNTM1 NywgT2N0b2JlciAyMDA4Lg0NICAgW0ktRC5pZXRmLWxtYXAtdXNlLWNhc2VzXQ0gICAgICAg ICAgICAgIExpbnNuZXIsIE0uLCBFYXJkbGV5LCBQLiwgQnVyYnJpZGdlLCBULiwgYW5kIEYu IFNvcmVuc2VuLA0gICAgICAgICAgICAgICJMYXJnZS1TY2FsZSBCcm9hZGJhbmQgTWVhc3Vy ZW1lbnQgVXNlIENhc2VzIiwgZHJhZnQtaWV0Zi0NICAgICAgICAgICAgICBsbWFwLXVzZS1j YXNlcy0wMSAod29yayBpbiBwcm9ncmVzcyksIERlY2VtYmVyIDIwMTMuDQ0gICBbSS1ELmJh Z251bG8taXBwbS1uZXctcmVnaXN0cnktaW5kZXBlbmRlbnRdDSAgICAgICAgICAgICAgQmFn bnVsbywgTS4sIEJ1cmJyaWRnZSwgVC4sIENyYXdmb3JkLCBTLiwgRWFyZGxleSwgUC4sIGFu ZA0gICAgICAgICAgICAgIEEuIE1vcnRvbiwgIkEgcmVnaXN0cnkgZm9yIGNvbW1vbmx5IHVz ZWQgbWV0cmljcy4NICAgICAgICAgICAgICBJbmRlcGVuZGVudCByZWdpc3RyaWVzIiwgZHJh ZnQtYmFnbnVsby1pcHBtLW5ldy1yZWdpc3RyeS0NICAgICAgICAgICAgICBpbmRlcGVuZGVu dC0wMSAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAxMy4NDSAgIFtJLUQuaWV0Zi1ob21l bmV0LWFyY2hdDSAgICAgICAgICAgICAgQ2hvd24sIFQuLCBBcmtrbywgSi4sIEJyYW5kdCwg QS4sIFRyb2FuLCBPLiwgYW5kIEouIFdlaWwsDSAgICAgICAgICAgICAgIklQdjYgSG9tZSBO ZXR3b3JraW5nIEFyY2hpdGVjdHVyZSBQcmluY2lwbGVzIiwgZHJhZnQtDSAgICAgICAgICAg ICAgaWV0Zi1ob21lbmV0LWFyY2gtMTEgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBPY3RvYmVyIDIw MTMuDQ0gICBbUkZDNjQxOV0gIFdhc3Nlcm1hbiwgTS4gYW5kIFAuIFNlaXRlLCAiQ3VycmVu dCBQcmFjdGljZXMgZm9yDSAgICAgICAgICAgICAgTXVsdGlwbGUtSW50ZXJmYWNlIEhvc3Rz IiwgUkZDIDY0MTksIE5vdmVtYmVyIDIwMTEuDQ0gICBbUkZDNjg4N10gIFdpbmcsIEQuLCBD aGVzaGlyZSwgUy4sIEJvdWNhZGFpciwgTS4sIFBlbm5vLCBSLiwgYW5kIFAuDSAgICAgICAg ICAgICAgU2Vsa2lyaywgIlBvcnQgQ29udHJvbCBQcm90b2NvbCAoUENQKSIsIFJGQyA2ODg3 LCBBcHJpbA0gICAgICAgICAgICAgIDIwMTMuDQ0gICBbUkZDNTUzM10gIE5vcmRtYXJrLCBF LiBhbmQgTS4gQmFnbnVsbywgIlNoaW02OiBMZXZlbCAzIE11bHRpaG9taW5nDSAgICAgICAg ICAgICAgU2hpbSBQcm90b2NvbCBmb3IgSVB2NiIsIFJGQyA1NTMzLCBKdW5lIDIwMDkuDQ0N DQ0NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQg ICAgICAgICAgICAgICAgW1BhZ2UgNDNdDQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg IExNQVAgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQNDQ0gICBbSS1E LmJ1cmJyaWRnZS1sbWFwLWluZm9ybWF0aW9uLW1vZGVsXQ0gICAgICAgICAgICAgIEJ1cmJy aWRnZSwgVC4sIEVhcmRsZXksIFAuLCBCYWdudWxvLCBNLiwgYW5kIEouDSAgICAgICAgICAg ICAgU2Nob2Vud2FlbGRlciwgIkluZm9ybWF0aW9uIE1vZGVsIGZvciBMYXJnZS1TY2FsZQ0g ICAgICAgICAgICAgIE1lYXN1cmVtZW50IFBsYXRmb3JtcyAoTE1BUCkiLCBkcmFmdC1idXJi cmlkZ2UtbG1hcC0NICAgICAgICAgICAgICBpbmZvcm1hdGlvbi1tb2RlbC0wMSAod29yayBp biBwcm9ncmVzcyksIE9jdG9iZXIgMjAxMy4NDSAgIFtSRkM2MjM1XSAgQm9zY2hpLCBFLiBh bmQgQi4gVHJhbW1lbGwsICJJUCBGbG93IEFub255bWl6YXRpb24NICAgICAgICAgICAgICBT dXBwb3J0IiwgUkZDIDYyMzUsIE1heSAyMDExLg0NICAgW1JGQzY5NzNdICBDb29wZXIsIEEu LCBUc2Nob2ZlbmlnLCBILiwgQWJvYmEsIEIuLCBQZXRlcnNvbiwgSi4sDSAgICAgICAgICAg ICAgTW9ycmlzLCBKLiwgSGFuc2VuLCBNLiwgYW5kIFIuIFNtaXRoLCAiUHJpdmFjeQ0gICAg ICAgICAgICAgIENvbnNpZGVyYXRpb25zIGZvciBJbnRlcm5ldCBQcm90b2NvbHMiLCBSRkMg Njk3MywgSnVseQ0gICAgICAgICAgICAgIDIwMTMuDQ0gICBbSS1ELmlldGYtaXBwbS1sbWFw LXBhdGhdDSAgICAgICAgICAgICAgQmFnbnVsbywgTS4sIEJ1cmJyaWRnZSwgVC4sIENyYXdm b3JkLCBTLiwgRWFyZGxleSwgUC4sIGFuZA0gICAgICAgICAgICAgIEEuIE1vcnRvbiwgIkEg UmVmZXJlbmNlIFBhdGggYW5kIE1lYXN1cmVtZW50IFBvaW50cyBmb3INICAgICAgICAgICAg ICBMTUFQIiwgZHJhZnQtaWV0Zi1pcHBtLWxtYXAtcGF0aC0wMSAod29yayBpbiBwcm9ncmVz cyksDSAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMTMuDQ1BdXRob3JzJyBBZGRyZXNzZXMN DSAgIFBoaWxpcCBFYXJkbGV5DSAgIEJyaXRpc2ggVGVsZWNvbQ0gICBBZGFzdHJhbCBQYXJr LCBNYXJ0bGVzaGFtIEhlYXRoDSAgIElwc3dpY2gNICAgRU5HTEFORA0NICAgRW1haWw6IHBo aWxpcC5lYXJkbGV5QGJ0LmNvbQ0NDSAgIEFsIE1vcnRvbg0gICBBVCZUIExhYnMNICAgMjAw IExhdXJlbCBBdmVudWUgU291dGgNICAgTWlkZGxldG93biwgTkoNICAgVVNBDQ0gICBFbWFp bDogYWNtb3J0b25AYXR0LmNvbQ0NDQ0NDQ0NDQ0NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAg ICAgICBFeHBpcmVzIEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgNDRdDQ1J bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExNQVAgRnJhbWV3b3JrICAgICAgICAgICAg ICAgICBKYW51YXJ5IDIwMTQNDQ0gICBNYXJjZWxvIEJhZ251bG8NICAgVW5pdmVyc2lkYWQg Q2FybG9zIElJSSBkZSBNYWRyaWQNICAgQXYuIFVuaXZlcnNpZGFkIDMwDSAgIExlZ2FuZXMs IE1hZHJpZCAgMjg5MTENICAgU1BBSU4NDSAgIFBob25lOiAzNCA5MSA2MjQ5NTAwDSAgIEVt YWlsOiBtYXJjZWxvQGl0LnVjM20uZXMNICAgVVJJOiAgIGh0dHA6Ly93d3cuaXQudWMzbS5l cw0NDSAgIFRyZXZvciBCdXJicmlkZ2UNICAgQnJpdGlzaCBUZWxlY29tDSAgIEFkYXN0cmFs IFBhcmssIE1hcnRsZXNoYW0gSGVhdGgNICAgSXBzd2ljaA0gICBFTkdMQU5EDQ0gICBFbWFp bDogdHJldm9yLmJ1cmJyaWRnZUBidC5jb20NDQ0gICBQYXVsIEFpdGtlbg0gICBDaXNjbyBT eXN0ZW1zLCBJbmMuDSAgIDk2IENvbW1lcmNpYWwgU3RyZWV0DSAgIEVkaW5idXJnaCwgU2Nv dGxhbmQgIEVINiA2TFgNICAgVUsNDSAgIEVtYWlsOiBwYWl0a2VuQGNpc2NvLmNvbQ0NDSAg IEFhbWVyIEFraHRlcg0gICBDaXNjbyBTeXN0ZW1zLCBJbmMuDSAgIDcwMjUgS2l0IENyZWVr IFJvYWQNICAgUlRQLCBOQyAgMjc3MDkNICAgVVNBDQ0gICBFbWFpbDogYWFraHRlckBjaXNj by5jb20NDQ0NDQ0NDQ0NDQ0NDQ0NRWFyZGxleSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVz IEp1bHkgMjUsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgNDVdDQ0FSSB0aGluayB0aGF0 IHRoZSBmYWN0IHRoYXQgTUFzIG1heSBoYXZlIGRpZmZlcmVudCBNZWFzdXJlbWVudCBUYXNr IGNhcGFiaWxpdGllcyBpcyBzaWduaWZpY2FudCB0byBjYWxsIG91dCBoZXJlLg0FV2h5IG5v dCBoYXZlIGFuIGVudHJ5IGZvciBhbGwgTWV0cmljcz8gIEluIG90aGVyIHdvcmRzLCB0aGUg UmVnaXN0cnkgY2FuIGNvbnRhaW4gYWxsIHRoZSBTdGFuZGFyZGlzZWQgbWV0cmljcy4gIElm IHRoZSBNZXRyaWMgaXMgbm90IGZvdW5kIGluIHRoZSBSZWdpc3RyeSwgdGhlbiBpdCBoYXMg bm90IGJlZW4gc3RhbmRhcmRpemVkLg0FSZJtIG5vdCBmYW1pbGlhciB3aXRoIHRoaXMgdGVy bWlub2xvZ3kuDQVJIHRoaW5rIHRoYXQgcHV0dGluZyBpbiCTKFRhc2splCBjcmVhdGVzIG1v cmUgY29uZnVzaW9uIGJlY2F1c2UgaXQgaW1wbGllcyB0aGF0IGFuIEFjdGl2ZSBNZWFzdXJl bWVudCBUYXNrIGlzIHRoZSBzYW1lIGFzIGFuIEFjdGl2ZSBNZWFzdXJlbWVudCBNZXRob2Qg d2hpY2ggaXMgbm90IHN0cmljdGx5IHRoZSBjYXNlLiAgSSB3b3VsZCByYXRoZXIgc2VlIGEg c2VwYXJhdGUgZGVmaW5pdGlvbiBmb3IgQWN0aXZlIE1lYXN1cmVtZW50IFRhc2sgd2hpY2gg d291bGQgYmUgYWxvbmcgdGhlIGxpbmVzIG9mIGFuIEFjdGl2ZSBNZWFzdXJlbWVudCBNZXRo b2Qgd2l0aCB0aGUgcGFyYW1ldGVycyBwb3B1bGF0ZWQuDQVUaGlzIGlzbpJ0IHJlYWxseSBh IGRlZmluaXRpb24uICAulCAgVGhpcyBpcyB3aGF0IGlzIGNhbGxlZCBhIJNjaXJjdWxhcpQg ZGVmaW5pdGlvbi4gIEmSbSBub3Qgc3VyZSB3aGF0IHRvIHB1dCBoZXJlLiAgk0EgQ2hhbm5l bCBpcyBhbiBpbmZvcm1hdGlvbiBmbG93IGJldHdlZW4gZWxlbWVudHMgb2YgdGhlIExNQVAg YXJjaGl0ZWN0dXJlIG9mIGEgc3BlY2lmaWMgdHlwZSBvZiBpbmZvcm1hdGlvbg0FSSB0aGlu ayB0aGF0IHB1dHRpbmcgaW4gkyhUYXNrKZQgY3JlYXRlcyBtb3JlIGNvbmZ1c2lvbiBiZWNh dXNlIGl0IGltcGxpZXMgdGhhdCBhIFBhc3NpdmUgTWVhc3VyZW1lbnQgVGFzayBpcyB0aGUg c2FtZSBhcyBhIFBhc3NpdmUgTWVhc3VyZW1lbnQgTWV0aG9kIHdoaWNoIGlzIG5vdCBzdHJp Y3RseSB0aGUgY2FzZS4gIEkgd291bGQgcmF0aGVyIHNlZSBhIHNlcGFyYXRlIGRlZmluaXRp b24gZm9yIFBhc3NpdmUgTWVhc3VyZW1lbnQgVGFzayB3aGljaCB3b3VsZCBiZSBhbG9uZyB0 aGUgbGluZXMgb2YgYSBQYXNzaXZlIE1lYXN1cmVtZW50IE1ldGhvZCB3aXRoIHRoZSBwYXJh bWV0ZXJzIHBvcHVsYXRlZC4NBUluIGFkZGl0aW9uLCB0aGUgQ29udHJvbGxlciBtYXkgbmVl ZCB0byBhc2sgdGhlIE1BIHdoZXRoZXIgaXQgaXMgaW4gU3VwcHJlc3Npb24sIHNvIHRoZSBD b250cm9sbGVyIG1heSBuZWVkIHRvIGFzayB0aGUgTUEgdG8gcmVwb3J0IGJhY2sgdGhlIGNv bnRlbnQgb2YgdGhlIEluc3RydWN0aW9uIHRoYXQgaXMgY3VycmVudGx5IHN0b3JlZCBvbiB0 aGUgTUEuDQVBcmUgeW91IGdvaW5nIHRvIGluY3JlYXNlIHRvIGZpdmUgKHNlcGFyYXRlIGFj dGl2ZSBmcm9tIHBhc3NpdmUpPw0FU2luY2UgYW4gSW5zdHJ1Y3Rpb24gY291bGQgaGF2ZSBt dWx0aXBsZSBNZWFzdXJlbWVudCBUYXNrcywgeW91IHdvdWxkIGhhdmUgYSBuYW1lIGZvciBl YWNoIHRhc2ssIG5vdCBhIHNpbmdsZSBuYW1lIGZvciBhIHNldCBvZiBNZWFzdXJlbWVudCBU YXNrcy4NBVRoZXJlIGNhbiBiZSBtdWx0aXBsZSByZXBvcnQgY2hhbm5lbCBlbnRyaWVzLg0F VGhlcmUgY2FuIGJlIG11bHRpcGxlIE1lYXN1cmVtZW50IFNjaGVkdWxlIGVudHJpZXMuDQVB cmUgeW91IGdvaW5nIHRvIGluY3JlYXNlIHRvIGZpdmUgKHNlcGFyYXRlIGFjdGl2ZSBmcm9t IHBhc3NpdmUpPw0FTWVhc3VyZW1lbnQgUGVlcnMgYWxzbyBuZWVkIHRvIHJlZ2lzdGVyIHdp dGggdGhlIENvbnRyb2xsZXIgd2l0aCB0aGVpciBjYXBhYmlsaXRpZXMgc28gdGhhdCB0aGUg Q29udHJvbGxlciBrbm93cyB0aGV5IGV4aXN0IGFuZCBjYW4gaW5jbHVkZSB0aGVtIGFzIHRh cmdldHMgZm9yIE1BcyB0byBwZXJmb3JtIG1lYXN1cmVtZW50cyB3aXRoLiAgSG93ZXZlciwg YSBNUCBkb2VzIG5vdCByZWNlaXZlIGEgY29tcGxldGUgSW5zdHJ1Y3Rpb24uICBIb3dldmVy LCBpdCBzaG91bGQgYmUgYWJsZSB0byByZWNlaXZlIGEgcGFydGlhbCBJbnN0cnVjdGlvbiB0 aGF0IGNvbnRhaW5zIFN1cHByZXNzIC8gVW5zdXBwcmVzcy4gIFN1cHByZXNzaW9uIGJlaGF2 aW9yIG9mIE1QcyBjYW4gYmUgZGVzY3JpYmVkIGluIHRoZSBNZWFzdXJlbWVudCBTdXBwcmVz c2lvbiBzZWN0aW9uLg0FQW5vdGhlciBwcmUtY2hlY2suDQVTdWdnZXN0aW9uOiAgSW4gdGhl IGV2ZW50IG9mIGEgY29uZmxpY3QsIHRoZSBNQSBydW5zIHRoZSBmaXJzdCBUYXNrIGluIHRo ZSBzZXQgb2YgTWVhc3VyZW1lbnQgdGFza3MuICBXaGVuIGl0IGlzIGZpbmlzaGVkLCB0aGUg dGFzayB0aGF0IHdhcyBpbiBzY2hlZHVsZSBjb25mbGljdCBpcyBydW4uICBUaGUgTUEgaW4g dGhlIHJlc3VsdCBpbmNsdWRlcyB0aGUgc3RhcnQgYW5kIGVuZCB0aW1lIG9mIGVhY2ggVGFz ayBleGVjdXRlZCBzbyB0aGF0IGluIHBvc3QgcHJvY2Vzc2luZyB0aGUgcmVzdWx0cyBjYW4g YmUgdmFsaWRhdGVkIG9yIGluLXZhbGlkYXRlZCBhcyBhcHByb3ByaWF0ZS4NBVN0YXJ0IGFu ZCBzdG9wIHRpbWUuDQVJIGFtIG5vdCBjb21mb3J0YWJsZSB3aXRoIHRoZSBNQSBkb2luZyBh bnkgcHJlLXByb2Nlc3NpbmcuICBUaGF0IGNvdWxkIGxlYWQgdG8gaW5jb25zaXN0ZW50IHJl c3VsdHMuDQVTb21lIG9mIHRoZXNlIGl0ZW1zIEkgd291bGQgY2xhc3NpZnkgYXMgZGVzY3Jp cHRpdmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGVudmlyb25tZW50IHRoYXQgdGhlIG1lYXN1 cmVtZW50IHdhcyBwZXJmb3JtZWQgdW5kZXIgcmF0aGVyIHRoYW4gcHJlLXByb2Nlc3Npbmcu DQVTaG91bGQgbm90IGJlIGZpbHRlcmVkIG91dCBhcyBpdCB3b3VsZCBpbXBhY3QgYXZlcmFn aW5nIHJlc3VsdHMgdGhhdCBtYXkgYmUgZG9uZSBpbiBwb3N0LXByb2Nlc3NpbmcuDQVUaGlz IGNvdWxkIG1ha2UgY29tcGFyaW5nIHJlc3VsdHMgZGlmZmljdWx0LiAgDQVBcmUgd2Ugc2F5 aW5nIHRoYXQgdGhlIHByZWZlcnJlZCB0cmFuc3BvcnQgcHJvdG9jb2wgd2lsbCBiZSBkZWNp ZGVkIGxhdGVyPw0FTWVhc3VyZW1lbnRzIG9uIGEgc3lzdGVtIHdpdGggdHJhZmZpYyBjYXBz IHdpbGwgbGlrZWx5IHJlcXVpcmUgYW4gYWdyZWVtZW50IHdpdGggdGhlIFNlcnZpY2UgUHJv dmlkZXIgdG8gcmFpc2UgdGhlIGNhcCB0byBhY2NvbW1vZGF0ZSB0aGUgbWVhc3VyZW1lbnQg b3IgdG8gY29tcGVuc2F0ZSBmb3IgdGhlIGJpbGxpbmcgaW1wYWN0IG9mIHRoZSBtZWFzdXJl bWVudC4gIEluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUgZXhpc3RlbmNlIG9mIHRyYWZmaWMg Y2FwcyB3aWxsIG5lZWQgdG8gYmUgY29tbXVuaWNhdGVkIHRvIHRoZSBDb250cm9sbGVyLg0N DQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI AAABCAAAwDYAAO82AADwNgAASDgAAEk4AAD/PAAAAD0AAL0+AADAPgAAwz4AAMQ+AADDQAAA OkEAALtEAADp1sCv1pnWj9ZtVz7WKNYAKwEIgQRIAQAFaLraIScWaB4a6QBDShQAT0oDAFBK AABRSgMAXkoDAGFKFAAxAQiBBEgBAAVoudohJxVovj/PABZoi2mTAENKFABPSgMAUEoAAFFK AwBeSgMAYUoUACsBCIEESAEABWi52iEnFmiLaZMAQ0oUAE9KAwBQSgAAUUoDAF5KAwBhShQA QwAIgRVovj/PABZovj/PABdoi2mTAENKFABPSgMAUEoAAFFKAwBeSgMAYUoUAGNIAQBkaAAA AABkaAAAAABkaLnaIScTA2oAAAAAFmiLaZMAMEoXAFUIASsBCIEESAEABWiq2iEnFmgTPncA Q0oUAE9KAwBQSgAAUUoDAF5KAwBhShQAIAEIgQNqAAAAAARIAQAFaKjaIScWaEwtNwAwShcA VQgBACsBCIEESAEABWin2iEnFmhMLTcAQ0oUAE9KAwBQSgAAUUoDAF5KAwBhShQAJBVovj/P ABZovj/PAENKFABPSgMAUEoAAFFKAwBeSgMAYUoUAAArAQiBBEgBAAVo4dohJxZoCVk2AENK FABPSgMAUEoAAFFKAwBeSgMAYUoUAAAPAAgAAEoIAACTCAAA3AgAACUJAABuCQAAtwkAAAAK AABJCgAAkgoAANsKAAAkCwAAbQsAAG4LAABvCwAAsAsAAOMLAADkCwAA7QsAAO4LAAA1DAAA fQwAAMMMAAALDQAAUA0AAFENAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgV DBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABlRDQAA ZQ0AAGYNAACnDQAAyw0AAMwNAAARDgAAUw4AAJsOAADYDgAA2Q4AACIPAABqDwAArA8AAOoP AADrDwAAIBAAACEQAAAyEAAAMxAAAHYQAAChEAAAohAAAKMQAACkEAAApRAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAA AAAAAAAAAAASZPAAAQBnZL4/zwAAGaUQAACmEAAA7xAAAPAQAAA5EQAAOhEAADsRAAB8EQAA pREAAOgRAAAoEgAAcRIAALkSAAD/EgAAQhMAAG4TAABvEwAAgRMAAIITAADLEwAAFBQAAF0U AACmFAAA5xQAADAVAAB1FQAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZ oBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZdRUAAL4V AAAHFgAAUBYAAJkWAADiFgAAKxcAAHQXAAC9FwAABhgAAE8YAACYGAAA4RgAACoZAABzGQAA vBkAAAUaAABOGgAAlxoAAOAaAAApGwAAchsAALQbAAD9GwAARhwAAI8cAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAA AAAAAAAAEmTwAAEAZ2S+P88AABmPHAAA2BwAACEdAABqHQAAsx0AALQdAAC1HQAAth0AAP8d AAAAHgAASR4AAEoeAABLHgAAlB4AAN0eAAAmHwAAbx8AALgfAAABIAAASiAAAJMgAADcIAAA JSEAAG4hAAC3IQAAACIAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAc NCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGQAiAABJIgAA kiIAANsiAAAkIwAAbSMAALYjAAC3IwAAyCMAAMkjAAASJAAAWyQAAKMkAADnJAAAMCUAAHcl AAC6JQAAASYAAEgmAABpJgAAaiYAAKomAACrJgAA8CYAABAnAAARJwAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAA AAAAABJk8AABAGdkvj/PAAAZEScAAEUnAACMJwAAyicAABIoAAArKAAALCgAAG8oAAChKAAA oigAAKMoAACkKAAApSgAAKYoAADvKAAA8CgAADkpAAA6KQAAOykAAH0pAADGKQAADyoAAE8q AACXKgAA3yoAACgrAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQg yCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABkoKwAAcCsAALkr AAD7KwAAQSwAAIcsAADOLAAAEy0AAFwtAACkLQAAtC0AALUtAAD3LQAAPC4AAIQuAADKLgAA Di8AAFMvAACYLwAArC8AAK0vAADxLwAANTAAAHswAACcMAAAnTAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA IgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAA AAASZPAAAQBnZL4/zwAAGZ0wAADlMAAAJzEAAGYxAABnMQAArjEAAMQxAADFMQAABjIAAEcy AACNMgAAzTIAAA8zAABVMwAAmzMAANIzAADTMwAA1DMAANUzAADWMwAAHzQAACA0AABpNAAA ajQAAGs0AACvNAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgj XCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZrzQAAPg0AAA+NQAA hjUAAMw1AAD2NQAA9zUAAD82AACGNgAA+zYAACY3AAAnNwAAVzcAAFg3AACfNwAA6DcAAC04 AAB1OAAAuTgAAP84AABGOQAAbTkAAG45AAC3OQAA/jkAAEI6AADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIA AA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAA EmTwAAEAZ2S+P88AABlCOgAAiDoAAMk6AAAQOwAAVzsAAJk7AADOOwAAzzsAABY8AABaPAAA mzwAAOI8AAAsPQAAbT0AALI9AAD0PQAA9T0AAD4+AACEPgAAzz4AABQ/AAAlPwAAJj8AACc/ AAAoPwAAKT8AAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn 8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGSk/AAByPwAAcz8AALw/ AAC9PwAAvj8AAAZAAABNQAAAk0AAAFNBAACaQQAAw0EAAMRBAAAHQgAAUEIAAJlCAADdQgAA JkMAACdDAABwQwAAtkMAAPtDAABERAAAjUQAANNEAAAXRQAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAAN xjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk 8AABAGdkvj/PAAAZu0QAALxEAAB4WQAAf1kAAIFZAACCWQAAn1kAAKVZAADTXQAA1F0AALxu AADDbgAAxW4AAMZuAADbbgAA4m4AAGl7AABqewAAtpkAALeZAAB4mgAAeZoAAB+dAAD14sDi tuLA4qziiuK24mjiUuJI4j7iAAAAAAAAAAAAABMDagAAAAAWaMlVuAAwShcAVQgBEwNqAAAA ABZo/w/zADBKFwBVCAErAQiBBEgBAAVoatshJxZohBapAENKFABPSgMAUEoAAFFKAwBeSgMA YUoUAEMACIEVaL4/zwAWaL4/zwAXaH04UABDShQAT0oDAFBKAABRSgMAXkoDAGFKFABjSAEA ZGgAAAAAZGgAAAAAZGgjIyJHQwAIgRVovj/PABZovj/PABdofThQAENKFABPSgMAUEoAAFFK AwBeSgMAYUoUAGNIAQBkaAAAAABkaAAAAABkaCEjIkcTA2oAAAAAFmgJWTYAMEoXAFUIARMD agAAAAAWaH04UAAwShcAVQgBQwAIgRVovj/PABZovj/PABdofThQAENKFABPSgMAUEoAAFFK AwBeSgMAYUoUAGNIAQBkaAAAAABkaAAAAABkaB0jIkckFWi+P88AFmi+P88AQ0oUAE9KAwBQ SgAAUUoDAF5KAwBhShQAABMDagAAAAAWaNM0bwAwShcAVQgBABYXRQAAXEUAAKJFAADoRQAA MUYAAHFGAAClRgAApkYAAOxGAAAuRwAAc0cAAJVHAACWRwAA3kcAABxIAABeSAAApkgAALVI AAC2SAAA+EgAADpJAAB/SQAAyEkAAAhKAABRSgAAmkoAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYy ABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAA AQBnZL4/zwAAGZpKAADaSgAA80oAAPRKAAD1SgAA9koAAPdKAABASwAAQUsAAIpLAACLSwAA jEsAANRLAAAcTAAAYUwAAKhMAADxTAAAMk0AAHZNAAC7TQAAxE0AAMVNAAAOTgAAT04AAJVO AADdTgAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQu GDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZ3U4AAPhOAAD5TgAAQk8AAIhP AADLTwAAE1AAAFpQAABbUAAApFAAAMNQAADEUAAAxVAAAMZQAADHUAAAyFAAAMlQAADKUAAA y1AAAMxQAADNUAAAzlAAAM9QAADQUAAA0VAAANJQAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQ lAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEA Z2S+P88AABnSUAAA01AAANRQAADVUAAA1lAAANdQAADYUAAA2VAAANpQAADbUAAA3FAAAN1Q AADeUAAAJ1EAAChRAABxUQAAclEAAHNRAAC2UQAA+VEAAD9SAACGUgAAyVIAAAxTAABPUwAA klMAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgy rDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGZJTAADVUwAAGFQAAFtUAAChVAAA 6FQAACtVAABuVQAAsVUAAPRVAAA3VgAAelYAAL1WAAACVwAARlcAAI1XAADQVwAAE1gAAFZY AABXWAAAkFgAAKZYAADnWAAA6FgAAPhYAAD5WAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQD KAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdk vj/PAAAZ+VgAAEFZAABbWQAAXFkAAKZZAADvWQAANVoAAH1aAADEWgAAClsAAAtbAABJWwAA kFsAAKVbAACmWwAAp1sAAKhbAACpWwAAqlsAAPNbAAD0WwAAPVwAAD5cAAA/XAAAhVwAAMpc AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1 QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABnKXAAAy1wAABJdAABaXQAAgF0AAIFd AADIXQAA010AANVdAAAYXgAAIl4AACNeAABpXgAAsl4AANteAADcXgAAHV8AADBfAAAxXwAA eV8AAL1fAADwXwAA8V8AADRgAAB0YAAAu2AAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygH vApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/ zwAAGbtgAADRYAAA0mAAABVhAABeYQAAo2EAAOlhAAArYgAALGIAAGtiAACSYgAAk2IAANxi AAAfYwAAPWMAAD5jAACGYwAAyWMAANdjAADYYwAAEWQAABJkAAATZAAAFGQAABVkAABeZAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5 AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZXmQAAF9kAACoZAAAqWQAAKpkAADxZAAA OmUAAHxlAAB9ZQAAvWUAAANmAABKZgAAe2YAAHxmAADEZgAABGcAACpnAAArZwAAdGcAALVn AAD1ZwAADWgAAA5oAABWaAAAnWgAAOJoAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wK UA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88A ABniaAAA42gAACdpAABkaQAArWkAALhpAAC5aQAAAWoAAEhqAAB1agAAdmoAALtqAAADawAA SWsAAEprAACOawAAymsAAMtrAAATbAAAFGwAAF1sAACHbAAAiGwAAM5sAAARbQAAU20AAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAA AAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGVNtAABnbQAAaG0AAGltAABqbQAAa20AALRt AAC1bQAA/m0AAP9tAAAAbgAARm4AAIZuAACebgAAn24AAOVuAAApbwAAT28AAFBvAACYbwAA 3W8AAPZvAAD3bwAANnAAAHlwAAC/cAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO 5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZ v3AAAMBwAAAJcQAAInEAACNxAABpcQAAd3EAAHhxAAC9cQAABnIAAEtyAACTcgAA1nIAAB1z AAAqcwAAK3MAADtzAAA8cwAAhHMAAKlzAACqcwAA83MAAPRzAAA8dAAAgnQAAL50AADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAA AAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABm+dAAAAXUAAER1AABldQAAZnUAAK91AADwdQAA NXYAADZ2AAA3dgAAOHYAADl2AACCdgAAg3YAAMx2AADNdgAAznYAAA53AAA/dwAAQHcAAIV3 AACGdwAAyHcAAAx4AABSeAAAm3gAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQR eBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGZt4 AADceAAAIXkAAGd5AACueQAAv3kAAMB5AAAHegAASXoAAGJ6AABjegAAe3oAAHx6AADCegAA BnsAAAd7AAA+ewAAP3sAAIJ7AACDewAAy3sAAMx7AAABfAAAAnwAAEl8AABcfAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAA AAAAAAAAAAAAABJk8AABAGdkvj/PAAAZXHwAAF18AACcfAAA5XwAAC59AAAvfQAAeH0AALt9 AAD8fQAAQ34AAIl+AACyfgAAs34AAPV+AAA0fwAANX8AADZ/AAA3fwAAgH8AAIF/AADKfwAA y38AAMx/AAABgAAAAoAAADCAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgV DBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABkwgAAA MYAAAGyAAABtgAAAr4AAAPCAAAA1gQAAfoEAAMSBAAAKggAAS4IAAJOCAADbggAAF4MAABiD AABhgwAApIMAAKWDAADBgwAAwoMAAAKEAABJhAAAkYQAANqEAAAahQAAG4UAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAA AAAAAAAAAAASZPAAAQBnZL4/zwAAGRuFAAAchQAAHYUAAB6FAAAfhQAAIIUAACGFAAAihQAA I4UAACSFAAAlhQAAJoUAACeFAAAohQAAKYUAACqFAAArhQAALIUAAC2FAAAuhQAAL4UAADCF AAAxhQAAMoUAAHuFAAB8hQAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZ oBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZfIUAAMWF AADGhQAAx4UAAMiFAAARhgAAWoYAAKOGAADshgAADIcAADmHAABThwAAVIcAAGuHAACChwAA mYcAALCHAAD1hwAA9ocAAA2IAAA6iAAAU4gAAFSIAABriAAAgogAAJmIAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAA AAAAAAAAEmTwAAEAZ2S+P88AABmZiAAAsIgAAPOIAAAgiQAANIkAAE6JAABqiQAAa4kAALOJ AAD3iQAAPooAAIaKAADFigAADIsAAFGLAAB9iwAAfosAAMeLAAAKjAAATowAAJKMAACkjAAA pYwAAOmMAAAojQAAbI0AAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAc NCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGWyNAAC0jQAA /Y0AAP6NAAD/jQAAAI4AAEmOAABKjgAAk44AAJSOAACVjgAA2Y4AACKPAABnjwAAkY8AAJKP AADYjwAA/48AAACQAABJkAAAkJAAANmQAAAhkQAAUJEAAFGRAACZkQAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAA AAAAABJk8AABAGdkvj/PAAAZmZEAAOCRAAD2kQAA95EAAA6SAAAPkgAATpIAAJeSAADfkgAA H5MAADyTAAA9kwAAg5MAAMmTAAAPlAAAVZQAAFaUAACClAAAxpQAAPKUAADzlAAA9JQAAAGV AAAtlQAARpUAAFyVAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQg yCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABlclQAAmZUAAJqV AACblQAA5JUAACGWAABNlgAATpYAAE+WAABQlgAAUZYAAFKWAACblgAAnJYAAOWWAADmlgAA 55YAACqXAABtlwAAtZcAAPuXAABCmAAAh5gAAMeYAAAPmQAAU5kAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA IgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAA AAASZPAAAQBnZL4/zwAAGVOZAACamQAA3ZkAACKaAAAzmgAANJoAAH2aAACYmgAAmZoAAOCa AADhmgAAKpsAAF2bAACimwAA5JsAAAWcAAAGnAAATJwAAImcAACKnAAAz5wAAOmcAADqnAAA Cp0AAAudAABJnQAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgj XCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZH50AACSdAAAonQAA KZ0AAEedAABInQAAop4AAKeeAACrngAArJ4AALqeAAC7ngAAwZ4AAP2gAADdx66bkZtvWUCb kSqbAAAAAAAAAAAAAAAAAAAAKwEIgQRIAQAFaDUjIkcWaMlVuABDShQAT0oDAFBKAABRSgMA XkoDAGFKFAAxAQiBBEgBAAVoMiMiRxVovj/PABZoyVW4AENKFABPSgMAUEoAAFFKAwBeSgMA YUoUACsBCIEESAEABWgyIyJHFmjJVbgAQ0oUAE9KAwBQSgAAUUoDAF5KAwBhShQAQwAIgRVo vj/PABZovj/PABdoyVW4AENKFABPSgMAUEoAAFFKAwBeSgMAYUoUAGNIAQBkaAAAAABkaAAA AABkaDIjIkcTA2oAAAAAFmjJVbgAMEoXAFUIASQVaL4/zwAWaL4/zwBDShQAT0oDAFBKAABR SgMAXkoDAGFKFAAAMQEIgQRIAQAFaDAjIkcVaL4/zwAWaMlVuABDShQAT0oDAFBKAABRSgMA XkoDAGFKFAArAQiBBEgBAAVoMCMiRxZoyVW4AENKFABPSgMAUEoAAFFKAwBeSgMAYUoUAEMA CIEVaL4/zwAWaL4/zwAXaMlVuABDShQAT0oDAFBKAABRSgMAXkoDAGFKFABjSAEAZGgAAAAA ZGgAAAAAZGgwIyJHAA1JnQAASp0AAI+dAACQnQAAzJ0AAM2dAAAUngAAN54AADieAAB4ngAA jZ4AAI6eAADCngAAw54AAAmfAAAKnwAAC58AAAyfAABVnwAAVp8AAJ+fAACgnwAAoZ8AAOWf AADmnwAALaAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn 8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGS2gAABvoAAAgaAAAIKg AADLoAAA6KAAAOmgAAAjoQAAJKEAAGyhAAC1oQAA+6EAAA6iAAAPogAAWKIAAKGiAADmogAA LKMAAE6jAABPowAAmKMAANyjAAAipAAAa6QAAJmkAACapAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAAN xjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk 8AABAGdkvj/PAAAZ/aAAAAKhAAAGoQAAB6EAABuhAAAcoQAAIqEAAFSiAABVogAAd60AAHit AACkrQAApa0AAKatAADdx66bkXubkZtlTz4oAAAAAAAAAAAAAAArAQiBBEgBAAVodSoiZxZo NBZRAENKFABPSgMAUEoAAFFKAwBeSgMAYUoUACABCIEDagAAAAAESAEABWh3KiJnFmg0FlEA MEoXAFUIAQArAQiBBEgBAAVodioiZxZoNBZRAENKFABPSgMAUEoAAFFKAwBeSgMAYUoUACsB CIEESAEABWh1KiJnFmi+P88AQ0oUAE9KAwBQSgAAUUoDAF5KAwBhShQAKwEIgQRIAQAFaDUj IkcWaMlVuABDShQAT0oDAFBKAABRSgMAXkoDAGFKFAATA2oAAAAAFmjJVbgAMEoXAFUIASQV aL4/zwAWaL4/zwBDShQAT0oDAFBKAABRSgMAXkoDAGFKFAAAMQEIgQRIAQAFaDMjIkcVaL4/ zwAWaMlVuABDShQAT0oDAFBKAABRSgMAXkoDAGFKFAArAQiBBEgBAAVoMyMiRxZoyVW4AENK FABPSgMAUEoAAFFKAwBeSgMAYUoUAEMACIEVaL4/zwAWaL4/zwAXaMlVuABDShQAT0oDAFBK AABRSgMAXkoDAGFKFABjSAEAZGgAAAAAZGgAAAAAZGgzIyJHAA2apAAA36QAACKlAABopQAA qqUAAPGlAAAzpgAAdKYAAJamAACXpgAA3qYAACSnAABfpwAAYKcAAKSnAADtpwAAM6gAAHio AADAqAAACakAAE6pAABPqQAAUKkAAFGpAACaqQAAm6kAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYy ABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAA AQBnZL4/zwAAGZupAADkqQAA5akAAOapAAAvqgAAd6oAALqqAAADqwAAE6sAABSrAABUqwAA ZasAAGarAACoqwAA6KsAACisAABvrAAArawAAL2sAAC+rAAABK0AAEytAAB3rQAAeK0AAKat AACnrQAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQu GDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZpq0AAKetAADltwAA5rcAAPG4 AADyuAAA87gAAPi4AAD7uAAAALkAABG5AAASuQAAYLkAAGG5AAAXvQAAGL0AAJu9AACjvQAA pL0AAO3axNqu2ozartqM2q7admBKOQAAAAAAAAAAAAAAAAAAAAAAAAAAIAEIgQNqAAAAAARI AQAFaE8jIkcWaP984wAwShcAVQgBACsBCIEESAEABWhPIyJHFmj/fOMAQ0oUAE9KAwBQSgAA UUoDAF5KAwBhShQAKwEIgQRIAQAFaE4jIkcWaP984wBDShQAT0oDAFBKAABRSgMAXkoDAGFK FAArAQiBBEgBAAVoTiMiRxZovj/PAENKFABPSgMAUEoAAFFKAwBeSgMAYUoUAEMACIEVaL4/ zwAWaL4/zwAXaL18mwBDShQAT0oDAFBKAABRSgMAXkoDAGFKFABjSAEAZGgAAAAAZGgAAAAA ZGhMIyJHKwEIgQRIAQAFaEwjIkcWaL18mwBDShQAT0oDAFBKAABRSgMAXkoDAGFKFAArAQiB BEgBAAVoSyMiRxZovXybAENKFABPSgMAUEoAAFFKAwBeSgMAYUoUACQVaL4/zwAWaL4/zwBD ShQAT0oDAFBKAABRSgMAXkoDAGFKFAAAJBVovj/PABZoNBZRAENKFABPSgMAUEoAAFFKAwBe SgMAYUoUABKnrQAAx60AAMitAAAOrgAAUa4AAJOuAADXrgAAFq8AAF2vAACNrwAAjq8AANav AAAbsAAAQbAAAEKwAACHsAAAyrAAAAmxAABMsQAAkbEAAJ+xAACgsQAA0LEAANGxAAD/sQAA ALIAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgy rDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGQCyAABAsgAAQbIAAEKyAABDsgAA RLIAAEWyAACOsgAAj7IAANiyAADZsgAA2rIAAB+zAABnswAAm7MAAJyzAADVswAA1rMAABW0 AABUtAAAnbQAAMm0AADKtAAAE7UAAFy1AACltQAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQD KAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdk vj/PAAAZpbUAAO61AADvtQAA/LUAACu2AABHtgAAYbYAAKG2AACitgAA0bYAABG3AAAStwAA E7cAAEG3AABCtwAAibcAAMu3AAAPuAAAVLgAAJe4AAChuAAAorgAAOS4AAAwuQAAd7kAALu5 AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1 QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABm7uQAAALoAAEi6AABJugAAkboAALy6 AAC9ugAABbsAAD67AAA/uwAAQLsAAEG7AABCuwAAi7sAAIy7AADVuwAA1rsAANe7AAAgvAAA abwAAJe8AACYvAAA4LwAABi9AAAZvQAApb0AAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygH vApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/ zwAAGaS9AAClvQAAgMIAAIHCAADWxgAA18YAAKzLAACtywAAvcsAAL7LAACHzQAAiM0AAPPN AAD0zQAAxNEAAMXRAAAu7QAAL+0AADCjAQAxowEAMqMBAE2jAQCiowEAo6MBAKSjAQBjpAEA ZKQBAIykAQCNpAEA56UBAOilAQDppQEACqYBAO3a0NrG2rzavNq82rzastqo2qGXk4+ThYF3 c2llYVdTAAAGFmgJWTYAABMDagAAAAAWaAlZNgAwShcAVQgBBhZofThQAAAGFmg7RtEAABMD agAAAAAWaH04UAAwShcAVQgBBhZo0zRvAAATA2oAAAAAFmjTNG8AMEoXAFUIAQYWaItpkwAA EwNqAAAAABZoi2mTADBKFwBVCAEGFmgPYVsAAAYWaEwtNwAAEwNqAAAAABZoTC03ADBKFwBV CAEMFWiQHC4AFmhMLTcAABMDagAAAAAWaAMsTwAwShcAVQgBEwNqAAAAABZo01g+ADBKFwBV CAETA2oAAAAAFmhFNHkAMEoXAFUIARMDagAAAAAWaBkzdQAwShcAVQgBEwNqAAAAABZoEwEc ADBKFwBVCAEkFWi+P88AFmi+P88AQ0oUAE9KAwBQSgAAUUoDAF5KAwBhShQAACQVaL4/zwAW aP984wBDShQAT0oDAFBKAABRSgMAXkoDAGFKFAAgpb0AAKa9AADsvQAAMb4AAHK+AAC6vgAA /r4AAP++AAA0vwAANb8AAH6/AACsvwAArb8AAO6/AAA1wAAAecAAAL3AAAAEwQAASMEAAI/B AACiwQAAo8EAAOXBAAApwgAAcsIAAIDCAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wK UA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88A ABmAwgAAgsIAAJjCAACZwgAA4cIAACTDAABMwwAATcMAAE7DAABPwwAAUMMAAFHDAABSwwAA U8MAAFTDAABVwwAAVsMAAFfDAABYwwAAWcMAAFrDAACjwwAApMMAAO3DAADuwwAA78MAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAA AAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGe/DAAA3xAAAf8QAAMfEAAAPxQAAEMUAAEnF AACSxQAA28UAACTGAABMxgAATcYAAE7GAABmxgAAZ8YAAJzGAACdxgAA4cYAAPDGAADxxgAA OscAAHLHAABzxwAAs8cAAPvHAABCyAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO 5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZ QsgAAIrIAADMyAAADckAAFbJAACayQAA2skAAOvJAADsyQAALsoAADrKAAA7ygAAfcoAAMbK AAAMywAAUcsAAJrLAACsywAArssAAPfLAABAzAAAQcwAAIrMAACczAAAncwAAJ7MAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAA AAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABmezAAAn8wAAOjMAADpzAAAMs0AADPNAAA0zQAA Z80AAGjNAACJzQAAis0AANDNAADzzQAA9c0AADbOAAB6zgAAq84AAKzOAADxzgAAOs8AAGzP AABtzwAArM8AAK3PAADzzwAAN9AAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQR eBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGTfQ AACA0AAAx9AAAA3RAABU0QAAe9EAAHzRAADG0QAAx9EAAAjSAAAJ0gAATNIAAE3SAACV0gAA 1tIAAB/TAABm0wAAqNMAAOzTAAA11AAAedQAAHrUAADD1AAADNUAACPVAAAk1QAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAA AAAAAAAAAAAAABJk8AABAGdkvj/PAAAZJNUAAGzVAABt1QAArdUAAK7VAACv1QAAsNUAALHV AAD61QAA+9UAAETWAABF1gAARtYAAIzWAACx1gAAstYAAOrWAADr1gAAMtcAAGTXAABl1wAA rdcAAPTXAAA72AAAR9gAAEjYAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgV DBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABlI2AAA idgAAMjYAAAL2QAAT9kAAJPZAADV2QAA5NkAAOXZAAAq2gAAc9oAALjaAAD72gAARNsAAIDb AADI2wAAEdwAAFjcAACd3AAA1twAANfcAAAW3QAAX90AAKjdAADw3QAAA94AAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAA AAAAAAAAAAASZPAAAQBnZL4/zwAAGQPeAAAE3gAATd4AAJbeAADa3gAAIt8AAGnfAACv3wAA xN8AAMXfAADG3wAAx98AAMjfAADJ3wAAEuAAABPgAABc4AAAXeAAAF7gAACm4AAAz+AAANDg AAAY4QAAPuEAAD/hAABt4QAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZ oBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZbeEAAG7h AAC34QAA/+EAAEPiAACI4gAAo+IAAKTiAADp4gAAMeMAAHnjAADC4wAA+OMAAPnjAABB5AAA h+QAAMzkAAAQ5QAAVeUAAJzlAADl5QAALOYAAHDmAACi5gAAo+YAAOjmAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAA AAAAAAAAEmTwAAEAZ2S+P88AABno5gAAL+cAAHXnAAC45wAA+OcAAD/oAABY6AAAWegAAHfo AAB46AAAiegAAIroAADT6AAAG+kAAGTpAACs6QAArekAAK7pAACv6QAAsOkAAPnpAAD66QAA Q+oAAETqAABF6gAAiuoAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAc NCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGYrqAACY6gAA meoAANvqAAAi6wAAa+sAAJvrAACc6wAA5esAAC3sAAB07AAAvOwAAADtAAAu7QAAMO0AAGzt AACr7QAA8e0AADnuAAB97gAAwu4AAAjvAABE7wAARe8AAInvAADM7wAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAA AAAAABJk8AABAGdkvj/PAAAZzO8AABPwAABV8AAAl/AAAODwAAAn8QAAaPEAAGnxAACB8QAA gvEAAMXxAAAO8gAAU/IAAJfyAADc8gAAF/MAABjzAABe8wAAnfMAAODzAAAj9AAAafQAAKz0 AACt9AAArvQAAK/0AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQg yCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABmv9AAA+PQAAPn0 AABC9QAAQ/UAAET1AACN9QAA0/UAABz2AABe9gAAX/YAAKH2AADn9gAALPcAAHX3AACW9wAA l/cAAMr3AADL9wAAEPgAAFL4AACY+AAA3vgAACH5AABe+QAAp/kAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA IgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAA AAASZPAAAQBnZL4/zwAAGaf5AADr+QAALvoAAHX6AAC8+gAA/PoAAEH7AACD+wAAyPsAANj7 AADZ+wAAFvwAABf8AABX/AAAnfwAAOX8AAAr/QAAc/0AALj9AAAA/gAARP4AAIr+AADO/gAA Ev8AAFv/AACh/wAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgj XCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZof8AAOL/AAAoAAEA PAABAD0AAQA+AAEAPwABAIgAAQCJAAEA0gABANMAAQDUAAEABAEBAAUBAQBLAQEAlAEBANwB AQAiAgEAawIBALMCAQD8AgEAQwMBAIoDAQDRAwEAGAQBAGEEAQDdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIA AA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAA EmTwAAEAZ2S+P88AABlhBAEApAQBAOYEAQAnBQEAbwUBALYFAQD/BQEARQYBAIwGAQDTBgEA 1AYBAOsGAQDsBgEANAcBAHQHAQC8BwEAAAgBAEQIAQB5CAEAeggBAMEIAQDvCAEA8AgBAAwJ AQANCQEAUwkBAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn 8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGVMJAQCcCQEA3wkBACYK AQBRCgEAUgoBAJEKAQDQCgEAGQsBAF4LAQBfCwEAYAsBAGELAQCqCwEAqwsBAPQLAQD1CwEA 9gsBADwMAQCCDAEAxAwBAAoNAQBSDQEAmA0BAOANAQAjDgEA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAAN xjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk 8AABAGdkvj/PAAAZIw4BACQOAQBtDgEAtg4BAPsOAQBCDwEAiA8BAM8PAQAREAEAVxABAIIQ AQCDEAEAyhABABERAQBREQEAlBEBANMRAQDsEQEA7REBADESAQB0EgEAvRIBAP8SAQBEEwEA fxMBAIATAQDdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/Aq hC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABmAEwEApBMBAKUTAQDrEwEA LxQBAHYUAQCHFAEAiBQBANEUAQAXFQEAXxUBAIUVAQCGFQEAxhUBAA4WAQBHFgEASBYBAEkW AQBKFgEAkxYBAJQWAQDdFgEA3hYBAN8WAQAZFwEAGhcBAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYy ABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAA AQBnZL4/zwAAGRoXAQBdFwEAoBcBANkXAQDaFwEAHxgBAGIYAQCnGAEA8BgBAAMZAQAEGQEA RxkBAI0ZAQDUGQEAGhoBAFwaAQCbGgEAnBoBANwaAQAlGwEAYxsBAKcbAQDoGwEA+xsBAPwb AQBFHAEA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQu GDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZRRwBAH8cAQCAHAEAyBwBAA8d AQBWHQEAnh0BAOYdAQAvHgEAcR4BAIoeAQCLHgEAsx4BALQeAQD5HgEAQB8BAHIfAQBzHwEA sx8BAMMfAQDEHwEAxR8BAMYfAQDHHwEAyB8BABEgAQDdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQ lAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEA Z2S+P88AABkRIAEAEiABAFsgAQBcIAEAXSABAKMgAQCvIAEAsCABAMggAQDJIAEA8yABAPQg AQAaIQEAGyEBAD8hAQBAIQEAgCEBAL4hAQC/IQEABiIBABIiAQATIgEAUyIBAFQiAQCaIgEA myIBAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgy rDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGZsiAQDTIgEA1CIBABojAQAbIwEA RCMBAEUjAQCCIwEAgyMBAMkjAQDyIwEA8yMBACskAQAsJAEAciQBALckAQD4JAEAPyUBAGQl AQBlJQEAqCUBAKklAQDxJQEA8iUBADcmAQB+JgEA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQD KAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdk vj/PAAAZfiYBAMImAQAIJwEACScBAAonAQALJwEAVCcBAFUnAQCeJwEAnycBAKAnAQDpJwEA MigBAHkoAQC+KAEAyygBAMwoAQASKQEAWSkBAJopAQDYKQEAGCoBABkqAQBbKgEAXCoBAKEq AQDdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1 QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABmhKgEArSoBAK4qAQD1KgEANCsBAEor AQBLKwEAkysBANorAQAiLAEALSwBAC4sAQBiLAEAYywBAKosAQDtLAEAMC0BAHItAQC3LQEA 5i0BAOctAQArLgEAci4BALsuAQACLwEARC8BAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygH vApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/ zwAAGUQvAQB/LwEAgC8BAJkvAQCaLwEA4C8BAOwvAQDtLwEA7i8BAO8vAQDwLwEA8S8BADow AQA7MAEAhDABAIUwAQCGMAEAzzABAA0xAQBVMQEAnDEBAOQxAQAsMgEAcDIBALMyAQDaMgEA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5 AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZ2jIBANsyAQAhMwEAXzMBAGAzAQCMMwEA jTMBALozAQC7MwEA5zMBAOgzAQAuNAEAdDQBALM0AQD6NAEAOTUBADo1AQCBNQEAyjUBAA82 AQBUNgEAnDYBAOU2AQAmNwEASzcBAEw3AQDdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wK UA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88A ABlMNwEAdTcBAHY3AQC+NwEABjgBAEg4AQCGOAEAtjgBALc4AQAAOQEARjkBAI45AQDVOQEA HDoBAF06AQBeOgEAXzoBAGA6AQCpOgEAqjoBAPM6AQD0OgEA9ToBADw7AQCAOwEAyDsBAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAA AAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGcg7AQAHPAEACDwBAEY8AQCPPAEA1jwBABc9 AQAuPQEALz0BAFc9AQBYPQEAmz0BAOI9AQAlPgEAbj4BAH0+AQB+PgEAwj4BAAs/AQBQPwEA mD8BAKw/AQCtPwEA3D8BAN0/AQAbQAEA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO 5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZ G0ABAGBAAQCeQAEA50ABAAFBAQACQQEASUEBAI9BAQDNQQEAzkEBABNCAQBaQgEAoUIBAKpC AQCrQgEArEIBAK1CAQCuQgEAr0IBALBCAQCxQgEAskIBALNCAQC0QgEA/UIBAP5CAQDdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAA AAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABn+QgEAR0MBAEhDAQBJQwEAjkMBANRDAQAaRAEA YEQBAGFEAQCmRAEA6kQBAA9FAQAfRQEAREUBAFFFAQCZRQEAvkUBAAVGAQBMRgEAk0YBALhG AQC5RgEAAEcBAEdHAQBIRwEAkEcBAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQR eBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGZBH AQCRRwEAtkcBAMlHAQAHSAEACEgBAEtIAQCPSAEA0kgBABdJAQBbSQEAo0kBAM1JAQDOSQEA FEoBAFtKAQBuSgEAb0oBAJFKAQCSSgEA0EoBABVLAQAoSwEAKUsBAHFLAQC6SwEA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAA AAAAAAAAAAAAABJk8AABAGdkvj/PAAAZuksBAAJMAQADTAEABEwBAAVMAQBOTAEAT0wBAJhM AQCZTAEAmkwBANlMAQD7TAEA/EwBAERNAQCNTQEA1k0BAB9OAQBaTgEAlk4BANJOAQAOTwEA Sk8BAEtPAQCRTwEA0k8BABlQAQDdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgV DBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABkZUAEA PlABAD9QAQBAUAEAg1ABAMtQAQASUQEAWFEBAKBRAQDgUQEA4VEBACRSAQBsUgEAkFIBAJFS AQDYUgEAH1MBADxTAQA9UwEAclMBAHNTAQC8UwEAAVQBAEdUAQCOVAEA1lQBAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAA AAAAAAAAAAASZPAAAQBnZL4/zwAAGdZUAQDXVAEA5VQBAOZUAQAvVQEAdFUBAJJVAQCTVQEA lFUBAJVVAQCWVQEA31UBAOBVAQApVgEAKlYBACtWAQBAVgEAQVYBAIpWAQDOVgEAFlcBAClX AQAqVwEAcVcBALlXAQDoVwEA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZ oBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZ6FcBAOlX AQAxWAEAeFgBAMFYAQAIWQEAFlkBABdZAQBXWQEAi1kBAIxZAQCrWQEArFkBAO5ZAQAvWgEA eFoBAMBaAQDKWgEAy1oBAA9bAQBXWwEAnVsBAN1bAQAiXAEAalwBALNcAQDdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAA AAAAAAAAEmTwAAEAZ2S+P88AABmzXAEAz1wBANBcAQAXXQEAXl0BAKddAQDCXQEAw10BAOpd AQDrXQEALV4BAGpeAQCwXgEAzl4BAM9eAQDQXgEA0V4BABpfAQAbXwEAZF8BAGVfAQBmXwEA r18BAPhfAQA4YAEAfmABAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAc NCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGX5gAQDHYAEA 62ABAOxgAQARYQEAEmEBAFZhAQCfYQEA3WEBACViAQBTYgEAVGIBAJZiAQDdYgEAH2MBAGJj AQCpYwEA8GMBADRkAQA1ZAEAR2QBAEhkAQCIZAEAzmQBABFlAQApZQEA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAA AAAAABJk8AABAGdkvj/PAAAZKWUBACplAQBEZQEARWUBAIdlAQC4ZQEAuWUBAP5lAQBBZgEA T2YBAFBmAQCRZgEA0GYBABVnAQBcZwEAo2cBAOpnAQAfaAEAIGgBACFoAQAiaAEAI2gBACRo AQBtaAEAbmgBALdoAQDdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQg yCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABm3aAEAuGgBALlo AQD8aAEARGkBAIhpAQDLaQEAFGoBAF1qAQCmagEAyGoBAMlqAQAKawEAUGsBAJFrAQDaawEA +msBAPtrAQA/bAEAhWwBAM5sAQAObQEAVW0BAGZtAQBnbQEAsG0BAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA IgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAA AAASZPAAAQBnZL4/zwAAGbBtAQD1bQEALG4BAC1uAQA/bgEAQG4BAIRuAQDMbgEAEG8BABlv AQAabwEAXm8BAKNvAQDqbwEALnABAHVwAQCgcAEAoXABAOZwAQAtcQEAdXEBALZxAQD+cQEA DXIBAA5yAQAPcgEA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgj XCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZD3IBABByAQARcgEA EnIBAFtyAQBccgEApXIBAKZyAQCncgEA8HIBADNzAQB6cwEAwXMBAAJ0AQBLdAEAhHQBAIV0 AQDIdAEAD3UBAFZ1AQCddQEA4XUBACd2AQBvdgEAsnYBAPR2AQDdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIA AA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAA EmTwAAEAZ2S+P88AABn0dgEAIHcBACF3AQA2dwEAN3cBAH53AQDDdwEACXgBAAp4AQBReAEA lHgBANx4AQD0eAEA9XgBAA95AQAQeQEAVXkBAJ15AQC+eQEAv3kBAAR6AQAfegEAIHoBAGh6 AQCoegEA8HoBAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn 8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGfB6AQA3ewEAgHsBAMV7 AQANfAEAVXwBAJB8AQCRfAEAknwBAJN8AQDcfAEA3XwBACZ9AQAnfQEAKH0BAGd9AQCufQEA 9n0BAA9+AQAQfgEAVn4BAJh+AQDgfgEAKX8BAGt/AQCtfwEA3QAAAAAAAAAAAAAAAN0AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAAN xjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk 8AABAGdkvj/PAAAZrX8BAM9/AQDQfwEAGIABAGCAAQCpgAEA8oABAC2BAQA/gQEAQIEBAFiB AQBZgQEAi4EBAIyBAQChgQEAooEBAOqBAQAtggEAS4IBAEyCAQCOggEA1IIBANyCAQDdggEA I4MBAGqDAQDdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/Aq hC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABlqgwEAsIMBAPaDAQA8hAEA hIQBAMuEAQAIhQEACYUBAFGFAQCZhQEA2oUBAPaFAQD3hQEA+IUBAPmFAQD6hQEAQ4YBAESG AQCNhgEAjoYBAI+GAQCchgEAnYYBANmGAQDahgEA8YYBAN0AAAAAAAAAAAAAAADdAAAAAAAA AAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYy ABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAA AQBnZL4/zwAAGfGGAQDyhgEAMYcBADKHAQBghwEAYYcBAIKHAQCDhwEAmocBAJuHAQDchwEA 84cBAPSHAQAziAEARYgBAEaIAQCFiAEAzogBAPqIAQD7iAEAQ4kBAHCJAQBxiQEAuokBANSJ AQDViQEA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQu GDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZ1YkBABWKAQAWigEAXYoBAKGK AQC4igEAuYoBAP2KAQAaiwEAG4sBAEKLAQBDiwEAYYsBAGKLAQCqiwEA7YsBAP2LAQD+iwEA P4wBAECMAQBBjAEAQowBAIuMAQCMjAEA1YwBANaMAQDdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQ lAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEA Z2S+P88AABnWjAEA14wBABiNAQAyjQEAM40BAHqNAQCHjQEAiI0BANCNAQAHjgEACI4BAFGO AQBujgEAb44BALSOAQDAjgEAwY4BAPiOAQD5jgEAEo8BABOPAQAmjwEAJ48BAD6PAQA/jwEA ao8BAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgy rDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGWqPAQCxjwEAwI8BAMGPAQAIkAEA NZABADaQAQB4kAEAwJABAOSQAQDlkAEALpEBAEuRAQBMkQEAkpEBAK+RAQCwkQEAtZEBALaR AQDSkQEA05EBABySAQBikgEAfpIBAH+SAQCAkgEA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQD KAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdk vj/PAAAZgJIBAIGSAQCCkgEAy5IBAMySAQAVkwEAFpMBABeTAQBbkwEAhZMBAMyTAQDNkwEA D5QBAE6UAQBPlAEAmJQBALGUAQCylAEA9ZQBADuVAQBPlQEAUJUBAJeVAQDflQEABZYBAAaW AQDdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1 QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABkGlgEAI5YBAGuWAQC0lgEA95YBAPiW AQAnlwEAcJcBALCXAQD4lwEANJgBADWYAQBQmAEAmJgBAN2YAQAimQEAI5kBAGSZAQCmmQEA p5kBAO6ZAQA0mgEASJoBAEmaAQCQmgEAzJoBAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAADcYyABCUAygH vApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/ zwAAGcyaAQDNmgEAzpoBAM+aAQDQmgEA0ZoBANKaAQDTmgEA1JoBAB2bAQAemwEAZ5sBAGib AQBpmwEAk5sBANGbAQARnAEAVJwBAJmcAQCanAEA25wBAAedAQAInQEAS50BAIidAQDNnQEA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5 AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZzZ0BAOGdAQDinQEA/50BAEieAQCOngEA 1J4BAPKeAQDzngEABp8BAAefAQAZnwEALJ8BAE+fAQBanwEAZZ8BAGafAQCGnwEAh58BAIif AQCVnwEAop8BAL2fAQDPnwEA1p8BANefAQDdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAA3GMgAQlAMoB7wK UA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88A ABnXnwEA8p8BAPOfAQD0nwEA9Z8BAPafAQD3nwEA+J8BAPmfAQD6nwEA+58BAPyfAQD9nwEA /p8BAP+fAQBIoAEASaABAJKgAQCToAEAlKABAKegAQDLoAEA4aABAPugAQAEoQEABaEBAN0A AAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgyrDVAOQAA AAAAAAAAAAAAAAAAAAASZPAAAQBnZL4/zwAAGQWhAQAdoQEAOqEBAFqhAQBboQEAXKEBAHCh AQCDoQEApqEBALGhAQC8oQEAvaEBAN+hAQDgoQEA4aEBAPChAQAHogEAH6IBAD+iAQBFogEA RqIBAGKiAQBjogEAZKIBAHSiAQCLogEA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAANxjIAEJQDKAe8ClAO 5BF4FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAGdkvj/PAAAZ i6IBAKKiAQC0ogEAu6IBALyiAQDYogEA2aIBANqiAQDbogEA3KIBAN2iAQDeogEA36IBAOCi AQDhogEA4qIBAOOiAQDkogEA5aIBAOaiAQDnogEAMKMBADGjAQCjowEAY6QBAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADd AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAANgAAAAA AAAAAAAAAADWAAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARgA AAQAAGdkkBwuACIAAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAA AAAAAAAAAAAAAAAAEmTwAAEAZ2S+P88AABhjpAEAjKQBAOilAQDNpgEAKqgBAPeoAQA6qQEA zqkBAP2pAQAyqgEAdaoBACisAQA8rAEAi60BAKGtAQAHrgEAo64BAAmvAQA5rwEAha8BAL2w AQC+sAEAv7ABAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA +wAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2SQHC4AAAEAAAABGAAAFgqm AQA/pgEAzaYBAM6mAQAqqAEAK6gBAPeoAQD4qAEAOqkBADupAQDOqQEAz6kBAP2pAQD+qQEA MqoBADOqAQB1qgEAdqoBACisAQAprAEAPKwBAD2sAQCLrQEAjK0BAKGtAQCirQEAB64BAAiu AQCjrgEApK4BAAmvAQAKrwEAOa8BADqvAQCFrwEAhq8BAL2wAQC+sAEAv7ABAPz47urg3NLO 0s7SztLO0s7EwLayqKSaloyIjIiMiIyIfnpwbMBlAAAAAAAAAAAMFWiQHC4AFmhMLTcAAAYW aAMsTwAAEwNqAAAAABZoAyxPADBKFwBVCAEGFmjTWD4AABMDagAAAAAWaNNYPgAwShcAVQgB BhZoRTR5AAATA2oAAAAAFmhFNHkAMEoXAFUIAQYWaBkzdQAAEwNqAAAAABZoGTN1ADBKFwBV CAEGFmgTARwAABMDagAAAAAWaBMBHAAwShcAVQgBBhZo/3zjAAATA2oAAAAAFmj/fOMAMEoX AFUIAQYWaDQWUQAAEwNqAAAAABZoNBZRADBKFwBVCAEGFmjJVbgAABMDagAAAAAWaMlVuAAw ShcAVQgBBhZo/w/zAAATA2oAAAAAFmj/D/MAMEoXAFUIAQYWaH04UAAAEwNqAAAAABZofThQ ADBKFwBVCAEGFmgJWTYAAAYWaLkY5QAmMgAxkGgBOnDfIW8AH7DQLyCw4D0hsKAFIrCgBSOQ oAUkkKAFJbAAABew0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagQeABIAAQALAQ8A BwAEAAQABAAAAAQACAAAAJgAAACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAAngAAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAAHYCAAB2AgAAdgIAAHYCAAB2AgAA dgIAAHYCAAB2AgAAdgIAADYGAAA2BgAANgYAADYGAAA2BgAANgYAAD4CAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAACoAAAANgYAADYG AAAWAAAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAC4AAAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAaAEAAEgBAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAALADAAA2BgAAMgYAABgAAADAAwAA 0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMAD AADQAwAA4AMAAPADAAAABAAAEAQAADIGAAAoAgAA2AEAAOgBAAAgBAAAMAQAAEAEAABQBAAA YAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAE AABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAA UAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAE AABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAA QAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAE AABABAAAUAQAAGAEAABwBAAAgAQAAJAEAAA4AQAAWAEAAPgBAAAIAgAAGAIAAFYCAAB+AgAA IAAAAE9KBABQSgQAUUoEAF9IAQRtSAkEbkgJBHNICQR0SAkEAAAAAEYAAGDx/wIARgAMEAAA 3yFvAAAABgBOAG8AcgBtAGEAbAAAAAgAAAASZBQBAQAYAENKFgBfSAEEYUoWAG1ICQRzSAkE dEgJBGgAAQABABIAaAAMEA8AwXs+AJAACQBIAGUAYQBkAGkAbgBnACAAMQAAABkAAQASZAAA AAATpGQAFKRkAEAmAFskAVwkAQAiADUIgUNKGABLSCQAT0oDAFBKAABRSgMAXAiBXkoDAGFK GABkAAIAAQAiAGQADBAQAMF7PgCQAAkASABlAGEAZABpAG4AZwAgADIAAAAZAAIAEmQAAAAA E6RkABSkZABAJgFbJAFcJAEAHgA1CIFDShgAT0oDAFBKAABRSgMAXAiBXkoDAGFKGABkAAMA AQAyAGQADBARAMF7PgCQAAkASABlAGEAZABpAG4AZwAgADMAAAAZAAMAEmQAAAAAE6RkABSk ZABAJgJbJAFcJAEAHgA1CIFDShgAT0oDAFBKAABRSgMAXAiBXkoDAGFKGABkAAQAAQBCAGQA DBASAMF7PgCQAAkASABlAGEAZABpAG4AZwAgADQAAAAZAAQAEmQAAAAAE6RkABSkZABAJgNb JAFcJAEAHgA1CIFDShgAT0oDAFBKAABRSgMAXAiBXkoDAGFKGABkAAUAAQBSAGQADBATAMF7 PgCQAAkASABlAGEAZABpAG4AZwAgADUAAAAZAAUAEmQAAAAAE6RkABSkZABAJgRbJAFcJAEA HgA1CIFDShgAT0oDAFBKAABRSgMAXAiBXkoDAGFKGABkAAYAAQBiAGQADBAUAMF7PgCQAAkA SABlAGEAZABpAG4AZwAgADYAAAAZAAYAEmQAAAAAE6RkABSkZABAJgVbJAFcJAEAHgA1CIFD ShgAT0oDAFBKAABRSgMAXAiBXkoDAGFKGAAAAAAAAABEAEFg8v+hAEQADAwAAAAAAAAQABYA RABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAUgBpAPP/ swBSAAwdAAAAAAAAMAYMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMAADTWBgAB CgNsADTWBgABBQMAAGH2AwAAAgALAAAAKABrIPT/wQAoAAANAAAAAAAAMAYHAE4AbwAgAEwA aQBzAHQAAAACAAwAAAAAAFYA/g+iAPEAVgAMAAEAwXs+AJAADgBIAGUAYQBkAGkAbgBnACAA MQAgAEMAaABhAHIAAAAiADUIAUNKGABLSCQAT0oDAFBKAABRSgMAXAgBXkoDAGFKGABSAP4P ogABAVIADAACAMF7PgCQAA4ASABlAGEAZABpAG4AZwAgADIAIABDAGgAYQByAAAAHgA1CAFD ShgAT0oDAFBKAABRSgMAXAgBXkoDAGFKGABSAP4PogARAVIADAADAMF7PgCQAA4ASABlAGEA ZABpAG4AZwAgADMAIABDAGgAYQByAAAAHgA1CAFDShgAT0oDAFBKAABRSgMAXAgBXkoDAGFK GABSAP4PogAhAVIADAAEAMF7PgCQAA4ASABlAGEAZABpAG4AZwAgADQAIABDAGgAYQByAAAA HgA1CAFDShgAT0oDAFBKAABRSgMAXAgBXkoDAGFKGABSAP4PogAxAVIADAAFAMF7PgCQAA4A SABlAGEAZABpAG4AZwAgADUAIABDAGgAYQByAAAAHgA1CAFDShgAT0oDAFBKAABRSgMAXAgB XkoDAGFKGABSAP4PogBBAVIADAAGAMF7PgCQAA4ASABlAGEAZABpAG4AZwAgADYAIABDAGgA YQByAAAAHgA1CAFDShgAT0oDAFBKAABRSgMAXAgBXkoDAGFKGABcAP4PogBRAVwADAEWAMF7 PgAwBhYASABUAE0ATAAgAFAAcgBlAGYAbwByAG0AYQB0AHQAZQBkACAAQwBoAGEAcgAAABgA Q0oYAE9KAwBQSgAAUUoDAF5KAwBhShgAkgBlAAEAYgGSAAwJFQDBez4AMAYRAEgAVABNAEwA IABQAHIAZQBmAG8AcgBtAGEAdAB0AGUAZAAAAD0AFgANxjIAEJQDKAe8ClAO5BF4FQwZoBw0 IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAABJk8AABAAAYAENKGABPSgMAUEoAAFFK AwBeSgMAYUoYAEIAJ0CiAHEBQgAMDQAATC03ADAGEQBDAG8AbQBtAGUAbgB0ACAAUgBlAGYA ZQByAGUAbgBjAGUAAAAIAENKEABhShAAPAAeQAEAggE8AAwNGQBMLTcAMAYMAEMAbwBtAG0A ZQBuAHQAIABUAGUAeAB0AAAAAgAYAAgAQ0oUAGFKFABCAP4PogCRAUIADAEYAEwtNwAwBhEA QwBvAG0AbQBlAG4AdAAgAFQAZQB4AHQAIABDAGgAYQByAAAACABDShQAYUoUAEAAagCBAYIB QAAMDRsATC03ADAGDwBDAG8AbQBtAGUAbgB0ACAAUwB1AGIAagBlAGMAdAAAAAIAGgAGADUI gVwIgUYA/g+SAbEBRgAMARoATC03ADAGFABDAG8AbQBtAGUAbgB0ACAAUwB1AGIAagBlAGMA dAAgAEMAaABhAHIAAAAGADUIAVwIAU4AmQABAMIBTgAMDR0ATC03ADAGDABCAGEAbABsAG8A bwBuACAAVABlAHgAdAAAAAgAHAASZPAAAQAUAENKEABPSgUAUUoFAF5KBQBhShAATgD+D6IA 0QFOAAwBHABMLTcAMAYRAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0ACAAQwBoAGEAcgAAABQA Q0oQAE9KBQBRSgUAXkoFAGFKEABQSwMEFAAGAAgAAAAhAIKKvBP6AAAAHAIAABMAAABbQ29u dGVudF9UeXBlc10ueG1srJHLasMwEEX3hf6D0LbYcroopdjOokl3fSzSDxjksS1qj4Q0Ccnf d+y4ULoILXQjEGLOmXtVro/joA4Yk/NU6VVeaIVkfeOoq/T77im71yoxUAODJ6z0CZNe19dX 5e4UMCmZplTpnjk8GJNsjyOk3AckeWl9HIHlGjsTwH5Ah+a2KO6M9cRInPHE0HX5KgtE16B6 g8gvMIrHsKDw+/kMJICYC1irxzNhWqLSEMLgLLBEMAdqfugz37bOYuPtfhRpPoMX2M0EM79c YPU/6i/nBlvYD6y2R+niXH/EIf0t21JrLpNz/tS7kC4YLpe3tGHmv60/AQAA//8DAFBLAwQU AAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMY JXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/ f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5Fx X9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Q tbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUv dGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+Xj gzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQCW ta3ilgYAAFAbAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2 Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdS ksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjx hLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+Ajoxmxp uVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBP wI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2Bq Htfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8b c/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4 GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7kh zQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+e fvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMY FDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmi FZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4U DklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvS eoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1L Tt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANO Frr7DiWOu0+vBrdp6Ig0CxA9MxHal1CqnQoc0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Y k6oyYftE+V2EO1l0u1wE9O2vuVt4kuwRCPP5jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2 LXK8sEMeU8YGasrIDWmaZAn7RNCHQb3OnA5JcWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw654m EsqMdChRyiUc7MxwJW2NhyZd2WNhUx8YbD2QWO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFau ZERB7ddhVtdCnZlb3YhmSp3DrVAZfDivGgwW1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYL F+kiGeGAZD7Ses/7qG6clMeKuQmA2KnwkT7knWK1EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8 pPP2RDqypJycLEFHba/VXG56yMdp2xvDmRYe4xS8LnXPh1kIF0O+EjbsT01mk+Uzb7Zyxdwk qMM1hbX7nMJOHUiFVFtYRjY0zFQWAizRnKz8y00w60UpYCP9NaRYWYNg+NekADu6riXjMfFV 2dmlEW07+5qVUj5RRAyi4AiN2ETsY3C/DlXQJ6ASriZMRdAvcI+mrW2m3OKcJV359srg7Dhm aYSzcqtTNM9kCzd5XMhg3krigW6Vshvlzq+KSfkLUqUcxv8zVfR+AjcFK4H2gA/XuAIjna9t jwsVcahCaUT9voDGwdQOiBa4i4VpCCq4TDb/BTnU/23OWRomreHAp/ZpiASF/UhFgpA9KEsm +k4hVs/2LkuSZYRMRJXElakVe0QOCRvqGriq93YPRRDqpppkZcDgTsaf+55l0CjUTU4535wa Uuy9Ngf+6c7HJjMo5dZh09Dk9i9ErNhV7XqzPN97y4roiVmb1cizApiVtoJWlvavKcI5t1pb seY0Xm7mwoEX5zWGwaIhSuG+B+k/sP9R4TP7ZUJvqEO+D7UVwYcGTQzCBqL6km08kC6QdnAE jZMdtMGkSVnTZq2Ttlq+WV9wp1vwPWFsLdlZ/H1OYxfNmcvOycWLNHZmYcfWdmyhqcGzJ1MU hsb5QcY4xnzSKn914qN74OgtuN+fMCVNMME3JYGh9RyYPIDktxzN0o2/AAAA//8DAFBLAwQU AAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdl ci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUNNj8kUeztDa4sCC6HYb6Z abuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeRSyhNJiRSKC4xmHIO J0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/TgaiWcvHxZd /lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAIKKvBP6AAAA HAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA CAAAACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAUAgAAdGhlbWUvdGhlbWUvdGhlbWVN YW5hZ2VyLnhtbFBLAQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAWAAAAAAAAAAAAAAAAANEC AAB0aGVtZS90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcA AAAAAAAAAAAAAAAAmwkAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVs c1BLBQYAAAAABQAFAF0BAACWCgAAAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJV VEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3Nj aGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQx IiB0eDE9ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2Nl bnQyPSJhY2NlbnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2Nl bnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5r PSJmb2xIbGluayIvPhQAQwBlAG4AdAB1AHIAeQBMAGkAbgBrACAARQBtAHAAbABvAHkAZQBl AO8uAAD/NAAAuzwAAIFRAADTVQAAxWYAALaRAAB4kgAAR5UAALqWAAAbmQAAVJoAAKSlAACj tQAAgLoAANa+AACswwAAvcMAAIfFAADzxQAAxMkAAC7lAAC/qAEAAgBDAEUAAAAAAAAAAAAA AAAAAAAAAAAAAAAhtpAWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAIuZAWAgBDAEUAAAAA AAAAAAAAAAAAAAAAAAAAAABqu5AWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAADDW5sWAgBD AEUAAAAAAAAAAAAAAAAAAAAAAAAAAACww5AWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAACf XJsWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAADgZJsWAgBDAEUAAAAAAAAAAAAAAAAAAAAA AAAAAADhYZsWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAADmX5sWAgBDAEUAAAAAAAAAAAAA AAAAAAAAAAAAAAAeYZsWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAAACYZsWAgBDAEUAAAAA AAAAAAAAAAAAAAAAAAAAAACOYZsWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAAD4iJwWAgBD AEUAAAAAAAAAAAAAAAAAAAAAAAAAAACFZpsWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAf Z5sWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAADxZ5sWAgBDAEUAAAAAAAAAAAAAAAAAAAAA AAAAAAB8aJsWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAuaZsWAgBDAEUAAAAAAAAAAAAA AAAAAAAAAAAAAAD0aJsWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAAClaZsWAgBDAEUAAAAA AAAAAAAAAAAAAAAAAAAAAADVapsWAgBDAEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAEbpsWgCoi ZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoi ZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoi ZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoi ZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoi ZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoi ZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoi ZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoiZwAAAAAAAAAAAAAAAAAAgCoi ZwAAAAAAAAAAAAAAAAAAAAAAAHIAAAAyAQAAWwEAALcCAACcAwAA+QQAAMYFAAAJBgAAnQYA AMwGAAABBwAARAcAAPcIAAALCQAAWgoAAHAKAADWCgAAcgsAANgLAAAIDAAAVAwAAIwNAACP DQAAAAAAAL+oAQAIAACMAgAAAP////8ACAAAu0QAAB+dAAD9oAAApq0AAKS9AAAKpgEAv7AB ANkAAADmAAAA/gAAAAEBAAAEAQAACQEAAEUBAAAACAAAUQ0AAKUQAAB1FQAAjxwAAAAiAAAR JwAAKCsAAJ0wAACvNAAAQjoAACk/AAAXRQAAmkoAAN1OAADSUAAAklMAAPlYAADKXAAAu2AA AF5kAADiaAAAU20AAL9wAAC+dAAAm3gAAFx8AAAwgAAAG4UAAHyFAACZiAAAbI0AAJmRAABc lQAAU5kAAEmdAAAtoAAAmqQAAJupAACnrQAAALIAAKW1AAC7uQAApb0AAIDCAADvwwAAQsgA AJ7MAAA30AAAJNUAAEjYAAAD3gAAbeEAAOjmAACK6gAAzO8AAK/0AACn+QAAof8AAGEEAQBT CQEAIw4BAIATAQAaFwEARRwBABEgAQCbIgEAfiYBAKEqAQBELwEA2jIBAEw3AQDIOwEAG0AB AP5CAQCQRwEAuksBABlQAQDWVAEA6FcBALNcAQB+YAEAKWUBALdoAQCwbQEAD3IBAPR2AQDw egEArX8BAGqDAQDxhgEA1YkBANaMAQBqjwEAgJIBAAaWAQDMmgEAzZ0BANefAQAFoQEAi6IB AGOkAQC/sAEA2gAAANsAAADcAAAA3QAAAN4AAADfAAAA4AAAAOEAAADiAAAA4wAAAOQAAADl AAAA5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAAAPEAAADyAAAA8wAA APQAAAD1AAAA9gAAAPcAAAD4AAAA+QAAAPoAAAD7AAAA/AAAAP0AAAD/AAAAAAEAAAIBAAAD AQAABQEAAAYBAAAHAQAACAEAAAoBAAALAQAADAEAAA0BAAAOAQAADwEAABABAAARAQAAEgEA ABMBAAAUAQAAFQEAABYBAAAXAQAAGAEAABkBAAAaAQAAGwEAABwBAAAdAQAAHgEAAB8BAAAg AQAAIQEAACIBAAAjAQAAJAEAACUBAAAmAQAAJwEAACgBAAApAQAAKgEAACsBAAAsAQAALQEA AC4BAAAvAQAAMAEAADEBAAAyAQAAMwEAADQBAAA1AQAANgEAADcBAAA4AQAAOQEAADoBAAA7 AQAAPAEAAD0BAAA+AQAAPwEAAEABAABBAQAAQgEAAEMBAABEAQAADwAA8DgAAAAAAAbwGAAA AAIIAAACAAAAAQAAAAEAAAABAAAAAgAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAPAALw kgAAABAACPAIAAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAA AAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAA vwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAA//8WAAoAAAAAASG2 kBb/////AAAAAQi5kBb/////AAAAAWq7kBb/////AAAAAcNbmxb/////AAAAAbDDkBb///// AAAAAZ9cmxb/////AAAAAeBkmxb/////AAAAAeFhmxb/////AAAAAeZfmxb/////AAAAAR5h mxb/////AAAAAQJhmxb/////AAAAAY5hmxb/////AAAAAfiInBb/////AAAAAYVmmxb///// AAAAAR9nmxb/////AAAAAfFnmxb/////AAAAAXxomxb/////AAAAAS5pmxb/////AAAAAfRo mxb/////AAAAAaVpmxb/////AAAAAdVqmxb/////AAAAAQRumxb/////wC4AAOk0AAC3PAAA clEAAIFVAACiZgAAM5EAAHSSAAAUlQAAl5YAAPKYAABPmgAAeKUAABm1AACjuQAA0b4AAP7C AACuwwAAaMUAAIrFAAB/yQAAvOQAADObAQAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAA BwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQA AAAVAAAA7y4AAP80AAC7PAAAgVEAANNVAADFZgAAtpEAAHiSAABHlQAAupYAABuZAABUmgAA pKUAAKO1AACAugAA1r4AAKzDAAC9wwAAh8UAAPPFAADEyQAALuUAADObAQAAAAAAZgEAAG0B AACLAgAAkQIAANQCAADaAgAAWAQAAGcEAABGBwAATwcAAPIMAAD+DAAAFRAAABwQAABeGAAA ahgAAOsYAAD3GAAA3xwAAOIcAABLHwAAUR8AAFIfAABWHwAAgiIAAIYiAACaIgAAnyIAAMsp AADXKQAAmyoAAKoqAACCLAAAiCwAAIksAACNLAAA5zMAAPIzAAAlNAAAMzQAAAM1AAAMNQAA DTUAABE1AADlNQAA8jUAAFY5AABmOQAAtzwAALs8AABuPQAAcj0AABxCAAAlQgAAO0QAAEBE AABpRwAAckcAAMFOAADNTgAAXFQAAGdUAAB+WgAAh1oAAE9iAABdYgAA5msAAPJrAABLbAAA V2wAAPNtAAD/bQAA0W4AAN1uAAC1eAAAwHgAAMF4AADFeAAAaZMAAHKTAABzkwAAd5MAAPeT AAADlAAADaoAABmqAACJvgAAkr4AALTDAAC9wwAAh9MAAJTTAAAm1AAAMtQAADfXAABB1wAA f9gAAIbYAAD52AAAANkAAEfZAABO2QAAJNoAACvaAACu2gAAtdoAAAPcAAAK3AAAutwAAMHc AABi3gAAbt4AANjfAADi3wAAqvYAALX2AAAj9wAALfcAAHn3AACF9wAAj/wAAJX8AACW/AAA nfwAAFX9AABY/QAALgIBADoCAQCvAgEAuwIBAJYEAQCZBAEAoQYBAKsGAQDgCgEA6goBAPIN AQD/DQEAjg8BAJsPAQAHEAEADhABACYRAQAzEQEA2hEBAOcRAQAfFAEALBQBABgVAQAlFQEA kBcBAJoXAQA1HAEAQhwBADgrAQBEKwEApy4BALQuAQAONAEAGjQBAO02AQD6NgEAPT4BAEg+ AQCNRwEAkEcBAMlHAQDQRwEAH0wBAC1MAQCeTgEAoU4BAK5PAQC4TwEAEFABABdQAQAyUgEA PlIBAINVAQCPVQEARlgBAE5YAQBZWQEAZVkBAGZZAQBxWQEA81sBAP9bAQA3XQEAQ10BAJ5k AQCmZAEAOmUBAEZlAQDkZQEA8GUBADZnAQBDZwEAFWgBACJoAQD8aAEACWkBACNsAQAtbAEA bWwBAHpsAQCPbAEAnGwBABVtAQAgbQEA520BAO1tAQDubQEA8m0BAPNtAQD3bQEApG4BALFu AQApbwEANW8BACJxAQAucQEALXgBADl4AQAweQEAPXkBAOF5AQDoeQEAWXoBAGB6AQBhegEA bnoBAG17AQBzewEAg3sBAIp7AQCiewEAqHsBANh7AQDdewEA3nsBAOd7AQDuewEA9HsBAPl7 AQACfAEAR3wBAE18AQBPfAEAVnwBAFd8AQBkfAEAZnwBAGt8AQB4fAEAenwBAK58AQC0fAEA tXwBALt8AQDofAEA73wBAPB8AQD2fAEAOX0BAEB9AQC0fQEAvX0BANV/AQDbfwEAvIABAL6A AQA8gwEAQYMBAHOHAQB+hwEAf4cBAIOHAQDviQEA+YkBABSKAQAaigEARYoBAFKKAQDbiwEA 5osBAF2MAQBljAEAy4wBANOMAQDgjAEA5IwBAAqNAQAUjQEAXo0BAGWNAQBrjQEAdY0BAKWN AQCsjQEADI4BABKOAQATjgEAF44BADGOAQA4jgEAro4BALKOAQD+jgEAB48BAAiPAQAMjwEA NY8BADyPAQDdjwEA5I8BAOWPAQDpjwEAO5ABAEGQAQBCkAEASZABAF6QAQBjkAEAaZABAG6Q AQCAkAEAhZABAEaRAQBLkQEAzZEBANaRAQDckQEA4ZEBAFeSAQBfkgEAa5IBAHKSAQCEkgEA j5IBAG+TAQB6kwEAe5MBAH+TAQC9kwEAxJMBAN+TAQDskwEARJQBAE2UAQBOlAEAUpQBAKiU AQCulAEAzZQBANqUAQAilQEALJUBADKVAQA3lQEA6JUBAO6VAQDvlQEA85UBAPSVAQD4lQEA DZYBABSWAQAvlwEAN5cBAD6XAQBIlwEAn5gBAKaYAQCGmQEAjpkBAJWZAQCfmQEA6ZkBAO+Z AQBnmgEAbJoBAG2aAQBzmgEAMZsBAP2bAQAJnAEAxqMBANCjAQAfpAEAJqQBACekAQAnpAEA wKgBAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHAB0ABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcABwAcAAcAHAAHAAQABwAEAAcAAAAAAMYDAADiAwAAOAQAADoE AACABAAAhAQAAMYEAADOBAAADgUAABUFAACqBQAAtAUAAFYGAABdBgAAngYAAKcGAAAlBwAA KAcAAG0HAABxBwAArwcAALcHAAB5CAAAgQgAAKYIAAC1CAAA6wkAAPYJAAArCgAANAoAAHQK AAB2CgAAvAoAAMMKAAACCwAABQsAAEULAABOCwAArgwAALwMAADyDAAA/gwAADgNAAA/DQAA gA0AAIQNAAAPDgAAHw4AAFgOAABiDgAApQ4AALMOAADqDgAA9Q4AADMPAAA8DwAAfA8AAIgP AADFDwAAzQ8AABIQAAAcEAAAoBAAAK0QAADpEAAA9xAAADYRAABEEQAAfxEAAI0RAADIEQAA 1hEAAA0SAAAbEgAA6BIAAPUSAAAxEwAAPBMAAHoTAACAEwAABRQAAA8UAABSFAAAVxQAAJsU AACoFAAA5BQAAPAUAAAtFQAAOxUAAHYVAACAFQAAthUAAMUVAABXFgAAYRYAAJwWAACmFgAA 6RYAAPgWAAAyFwAAOxcAAHsXAACJFwAAxBcAANAXAAAJGAAAFxgAAFYYAABdGAAAnxgAAKsY AADoGAAA9xgAADEZAAA5GQAAUhoAAFkaAACbGgAAohoAAOQaAADrGgAAFRwAACEcAABeHAAA YxwAAKYcAACsHAAA6hwAAPEcAAAzHQAANh0AAHodAAB+HQAAvR0AAMUdAAAEHgAACh4AAEse AABQHgAAbR4AAHkeAACuHgAAux4AAPYeAAD8HgAAYR8AAGcfAACPHwAAlB8AAM0fAADYHwAA FSAAABYgAACmIAAAtSAAAIAhAACLIQAAySEAAMshAAASIgAAGSIAAJoiAACfIgAApyIAAKoi AABzIwAAdSMAAL0jAAC/IwAA/iMAAAYkAABFJAAARyQAANEkAADiJAAAFiUAAB0lAABfJQAA YiUAAKclAACzJQAAPyYAAEcmAABWJwAAWycAAPQnAAD5JwAAfigAAIEoAADoKAAA6ygAACop AAA0KQAAgSkAAKYpAACxKQAAuikAAMgpAADXKQAADCoAABMqAABNKgAAWSoAAJMqAACZKgAA 0yoAAN8qAAAVKwAAGysAAFsrAABeKwAAoSsAAKQrAADWKwAA5SsAAG4sAAB2LAAA/iwAAAEt AABELQAASS0AANItAADVLQAA+i0AAAYuAACMLgAAlS4AAAEvAAAILwAAoi8AAK4vAADrLwAA 7i8AADAwAAA1MAAAeDAAAHswAAC8MAAAwzAAAAIxAAAFMQAASTEAAEwxAAC6MQAAwjEAAEUy AABNMgAAzDIAANUyAABaMwAAYTMAAJwzAAClMwAAXTQAAGc0AACeNAAApzQAAOU0AADoNAAA LzUAADE1AABwNQAAejUAALU1AAC5NQAA0jYAANc2AAAXNwAAGzcAACk3AAA4NwAACTgAAAs4 AABQOAAAVDgAAFY5AABmOQAAnTkAAKY5AAAKOgAAIzoAAFM6AABVOgAA4DoAAOk6AABzOwAA dTsAALk7AAC9OwAARzwAAEk8AACQPAAAmDwAAF89AABkPQAApT0AAKo9AAA0PgAANz4AAHQ+ AAB/PgAA7z4AAAE/AAAxPwAAOD8AAHY/AAB8PwAAH0AAACtAAACpQAAAq0AAAPtAAAAsQQAA PUEAAEZBAACCQQAAiEEAAMtBAADRQQAAC0IAAEZCAABUQgAAXUIAAN1CAADmQgAA90IAAAZD AADXQwAA20MAAB9EAAAiRAAAZEQAAGtEAACrRAAAskQAAPREAAD6RAAANUUAAD5FAAB5RQAA gUUAAL5FAADCRQAAEUYAABVGAABSRgAAWkYAAJhGAACcRgAA4EYAAONGAABFRwAASEcAAItH AACQRwAAzkcAANlHAAAWSAAAH0gAAKdIAACqSAAA3kgAAO1IAABeSgAAbEoAAJhLAACmSwAA E00AAB9NAADhTgAA6E4AAFtPAABmTwAAVFAAAFVQAACTUAAAnlAAAKpQAACxUAAARFEAAElR AACpUQAArVEAADhSAAA/UgAAgFIAAIVSAADHUgAA0lIAAJNTAACkUwAAqlMAALlTAACIVAAA k1QAABVVAAAYVQAAXVUAAGFVAAAbVgAAIVYAAGxWAAByVgAAtVYAALdWAAAgVwAAL1cAAMBX AADIVwAAN1gAAFlYAAC+WAAAwFgAAGFZAABlWQAAplkAAKpZAADsWQAA8lkAAG5aAAB4WgAA iVsAAJBbAADMWwAA1lsAAPBbAADyWwAAFVwAACRcAAD0XAAA9lwAAD1dAAA/XQAABl4AAAte AABNXgAAWF4AAMdeAADOXgAAB18AAClfAAC4XwAAwl8AAFlgAABaYAAAKmEAADRhAACwYQAA t2EAAARiAAAHYgAAS2IAAE5iAAAGYwAACWMAAJFjAACWYwAAYWQAAGtkAABtZAAAhmQAANFk AADUZAAAVmUAAF5lAABrZQAAemUAAElmAABMZgAAiWYAAJJmAADoZgAA7WYAACxnAAAyZwAA m2cAAKJnAADgZwAA9WcAAAxpAAAhaQAAbGkAAHZpAADAaQAAx2kAAAlqAAAQagAATmoAAFJq AADZagAA32oAACBrAAAoawAAh2sAAIprAACtawAAu2sAAD9sAABBbAAAhWwAAIhsAADBbAAA z2wAAARtAAAPbQAAR20AAE5tAACybQAAtG0AAPNtAAD/bQAAOW4AAEhuAADRbgAA3W4AABFv AAAabwAAQ28AAEpvAADLbwAA0W8AAA9wAAAacAAAVXAAAFtwAADfcAAA7XAAACRxAAAscQAA anEAAHRxAACxcQAAvHEAAApyAAANcgAAxXIAAMhyAAAFdAAACXQAAE90AABUdAAAYHQAAGR0 AADrdAAA8nQAADJ1AAA4dQAASXYAAFF2AAC2dgAAunYAAPt2AAAFdwAAN3cAAEZ3AAAFeAAA CXgAADR4AAA4eAAA83gAAP14AAA4eQAAP3kAAIF5AACGeQAAx3kAAM15AAANegAAEnoAAN56 AADhegAAZHsAAGd7AACoewAAuHsAAAV8AAA7fAAATHwAAE58AACUfAAAnHwAAN18AADlfAAA Mn0AAEF9AABLfgAAWX4AAJJ+AACafgAA8H4AAPd+AAAQfwAAF38AAD1/AABFfwAAc38AAHp/ AAARgAAAGIAAAD6AAABGgAAAtoEAAL6BAAD6gQAABIIAAImCAACNggAAyIIAANKCAAAPgwAA EoMAAMqDAADNgwAADYQAABWEAABRhAAAV4QAAJWEAACbhAAA7IQAAPOEAAArhQAANYUAAG+F AAB2hQAAt4UAALuFAAAAhgAAD4YAAJiGAAClhgAA3IYAAOGGAAAlhwAAKIcAAGqHAABxhwAA TIgAAE6IAACTiAAAmIgAANyIAADkiAAAJIkAACaJAACciQAAoYkAAOOJAADpiQAA+okAAASK AACaigAAnooAAOKKAAD2igAAIosAADuLAADJiwAA1osAACeNAAAsjQAAGY4AAB+OAABSjgAA YY4AAC2PAAA3jwAAcI8AAHmPAAC4jwAAu48AAP6PAAACkAAARZAAAGeQAACKkAAAkZAAABKR AAAWkQAAVpEAAF2RAACdkQAAn5EAAOCRAADnkQAAJZIAACySAACAkgAAg5IAAJySAACskgAA 55IAAO2SAACrkwAAs5MAAO2TAAD2kwAADJQAABKUAACQlAAAlZQAANiUAADhlAAA8JQAAP2U AAARlQAAFZUAAE2VAABdlQAAlpUAAJyVAADTlQAA2ZUAAB2WAAAilgAAPpYAAEmWAACBlgAA jJYAAJSWAACYlgAAxpYAAMyWAAAMlwAAG5cAAKeXAACtlwAA7JcAAPKXAAB4mAAAgJgAAIiY AACOmAAA75gAAPOYAAAnmQAALZkAAHKZAAB2mQAAu5kAAMOZAAABmgAAB5oAAFuaAABemgAA pJoAALGaAADpmgAA75oAAC+bAAA0mwAAm5sAAKObAADgmwAA5JsAACWcAAAtnAAAbpwAAHGc AAAlnQAALp0AAGudAAB0nQAANp4AAD2eAAB3ngAAf54AAOGeAADkngAAJ58AAF6fAACnnwAA rJ8AAPGfAAD0nwAANqAAADmgAAB7oAAAgaAAAJKgAACVoAAAw6AAAMqgAAAMoQAAEqEAAFGh AABgoQAA6aEAAPOhAAAyogAANaIAAHqiAACZogAAvaIAAMOiAAAGowAACaMAAFejAABjowAA K6QAAFOkAACwpAAAvKQAAE+lAABQpQAApKUAAKWlAACspQAAuqUAABGmAAAapgAAVKYAAFum AACWpgAAoaYAANqmAADlpgAAGacAACSnAACRpwAAlacAANynAADmpwAAIagAACyoAABFqAAA SagAAI2oAACXqAAA0KgAANeoAABSqQAAWKkAAJepAACdqQAAo6kAAKepAADUqQAA2akAAEWq AABUqgAA3aoAAOeqAABtqwAAcKsAAJ+rAACkqwAAoKwAAKSsAABfrQAAbK0AAEuuAABQrgAA Fq8AACGvAADOrwAA1a8AABKwAAAZsAAAV7AAAGKwAACasAAAn7AAADOxAABisQAAerEAAH6x AAC+sQAAxLEAAASyAAAMsgAAlLIAAJuyAADAsgAAxrIAAAuzAAAQswAAQrMAAFGzAADaswAA 4LMAAG+0AABztAAAm7QAAKG0AADmtAAA7LQAABy1AAAitQAAdbYAAH22AAC9tgAAvrYAAAK3 AAAItwAAOLcAAD63AACEtwAAhbcAAPG3AAD9twAAOLgAADy4AAB8uAAAg7gAAMC4AADJuAAA B7kAAAq5AABLuQAAT7kAAJK5AACXuQAA6LkAAO+5AAAsugAAMboAAHW6AAB9ugAAhboAAI66 AAAnuwAALrsAAFq7AABpuwAAt7wAAL+8AAAHvgAADr4AAGq+AABwvgAAoL4AAKa+AADnvgAA 774AAPS+AAD6vgAAQL8AAEK/AAC2vwAAz78AAP6/AAABwAAARcAAAEvAAACNwAAAkcAAABDB AAAXwQAAncEAAKLBAADdwQAA6MEAABvCAAAewgAAMcIAADnCAACAwgAAisIAAMnCAADMwgAA D8MAABXDAABUwwAAbcMAAJ3DAACfwwAAscMAAL3DAAD9wwAA/8MAAETEAABKxAAAkMQAAJPE AACfxAAArsQAADfFAABDxQAAa8UAAHfFAACNxQAAm8UAANbFAADZxQAAOcYAAEXGAAB9xgAA gsYAAPTGAAAzxwAAPccAAEDHAABwxwAAfMcAAPbHAAD9xwAAOsgAAELIAACDyAAAi8gAAMrI AAAFyQAAEMkAABTJAABXyQAAWskAAMrJAADOyQAADMoAABDKAABQygAAVMoAAJvKAACeygAA 3MoAAOXKAAAmywAAKMsAAGzLAAB0ywAArssAALXLAADyywAA98sAAH3MAACBzAAAycwAAMzM AAASzQAAFc0AAHDNAAB0zQAAsc0AAMDNAABJzgAAU84AALXOAAC9zgAANc8AADjPAAC0zwAA v88AAPvPAAAB0AAAQtAAAEbQAACQ0AAAm9AAAM/QAADb0AAAEtEAABfRAADc0QAA4tEAAB7S AAAp0gAAMdIAADjSAAB60gAAfNIAAL/SAADI0gAAS9MAAFPTAACH0wAAlNMAAM/TAADS0wAA GNQAABzUAABf1AAAYtQAAN7UAADj1AAAINUAACvVAABp1QAAbNUAALLVAAC01QAA+tUAAAHW AABU1gAAWtYAAJ3WAACj1gAA4dYAAObWAAAp1wAAMtcAAHDXAAB21wAAttcAALnXAADJ1wAA 2NcAAK3YAACw2AAA99gAAPjYAAAf2QAAJdkAAETZAABO2QAAutkAAMXZAAAC2gAABtoAAEba AABM2gAAi9oAAJLaAACr2gAArdoAAPDaAAD72gAAgNsAAInbAAAA3AAAAtwAAEjcAABL3AAA jtwAAJfcAADT3AAA2dwAABfdAAAg3QAAXN0AAGDdAACj3QAApd0AAOzdAADu3QAAd94AAHze AADr3gAA/94AADLfAAA13wAAeN8AAHzfAAC73wAA8N8AAPvfAAAE4AAAQuAAAEngAAB74AAA iOAAANbgAADe4AAAHuEAACPhAACw4QAAv+EAAI3iAACX4gAAJeMAACnjAABu4wAAcuMAAOjj AADs4wAAMOQAADXkAAB35AAAgOQAAAPlAAAJ5QAAb+UAAHzlAACu5QAAuOUAAPTlAAAJ5gAA POYAAEHmAACA5gAAhuYAAMXmAADK5gAAjOcAAJbnAADP5wAA/ucAABboAAAb6AAAWOgAAGDo AACa6AAAo+gAAOPoAADl6AAAKukAADDpAABs6QAAeukAAMjpAADN6QAAEeoAABXqAABW6gAA Y+oAAJrqAADF6gAA3+oAAOTqAACg6wAAsusAAOPrAADp6wAAJuwAAC3sAACv7AAAvuwAAJDt AACZ7QAA1u0AANrtAACk7gAAre4AAOruAADx7gAAL+8AADXvAAB47wAAfO8AAJzvAACq7wAA E/AAABfwAABV8AAAXPAAAJvwAACg8AAA4fAAAOTwAACq8QAAsfEAAO7xAAD18QAAv/IAAMvy AABE8wAATPMAAIbzAACP8wAAy/MAANbzAADe8wAA7PMAAFr0AABi9AAAoPQAAKz0AADo9AAA 8vQAAC71AAAz9QAAdvUAAIb1AAAD9gAABvYAAEf2AABM9gAAjfYAAJD2AADR9gAA1vYAABX3 AAAZ9wAAXvcAAGX3AAAr+AAAL/gAAD/4AABO+AAA2fgAAOf4AABO+QAAV/kAAJf5AACe+QAA 3/kAAOL5AAAl+gAALPoAAG76AABz+gAAtvoAALj6AAD/+gAAAvsAAI37AACQ+wAA1PsAANn7 AAAb/AAAHfwAAGT8AABn/AAAp/wAALD8AADp/AAA9PwAACr9AAAz/QAAcv0AAHf9AAC6/QAA wv0AAEj+AABN/gAAj/4AAJH+AADX/gAA5f4AADf/AAA7/wAAd/8AAIH/AABHAAEAUgABAMQA AQDuAAEAVgEBAFkBAQCfAQEApAEBAOIBAQDtAQEAKQIBAC0CAQDTAgEA3gIBABwDAQAgAwEA YQMBAHADAQD5AwEA/wMBAD8EAQBGBAEAhQQBAIgEAQDHBAEAzgQBAA0FAQAVBQEAVQUBAFgF AQCbBQEAngUBAOMFAQDlBQEAuQYBALwGAQD+BgEABQcBAEUHAQBMBwEAiwcBAJMHAQDSBwEA 2wcBABQIAQAbCAEAWggBAGIIAQDNCAEA0AgBABQJAQAZCQEAVAkBAF4JAQDWCQEA6wkBADQK AQA9CgEAdwoBAIAKAQDACgEAwwoBAAILAQALCwEARwsBAE4LAQDuCwEA8QsBADIMAQA5DAEA eQwBAIUMAQDUDAEA2wwBAGINAQBpDQEAyQ0BANINAQARDgEAEw4BAEoOAQBZDgEA4g4BAO8O AQBgDwEAaQ8BAKMPAQCuDwEA3Q8BAOoPAQAlEAEALRABAGgQAQBvEAEA9hABAPkQAQAHEQEA EhEBAE0RAQBTEQEAkxEBAJ4RAQDaEQEA5xEBACASAQApEgEAYhIBAGwSAQCfEgEArBIBAOIS AQDtEgEAKxMBAC8TAQBpEwEAdBMBAK0TAQCzEwEA7hMBAPkTAQD/EwEABxQBAEsUAQBSFAEA yxQBANUUAQBZFQEAXxUBAOkVAQDtFQEAMhYBADgWAQB0FgEAfRYBAI4WAQCZFgEA/BYBAAQX AQBDFwEAShcBALYXAQDBFwEAyBcBANcXAQBgGAEAZhgBALMYAQC4GAEAzBgBANcYAQD3GAEA AhkBAB4ZAQArGQEAQxkBAE4ZAQCGGQEAjxkBAMIZAQDLGQEAVxoBAGUaAQCeGgEArBoBANca AQDlGgEAHhsBACwbAQBIGwEAUhsBAIYbAQCTGwEAzxsBANobAQD2GwEABxwBALocAQC/HAEA +xwBAAUdAQBCHQEARB0BAGgdAQBuHQEAOh4BAD4eAQCBHgEAhx4BAMUeAQDQHgEACx8BABof AQCjHwEApx8BAOwfAQDvHwEANSABADsgAQB8IAEAhCABAMEgAQDFIAEAFSEBACEhAQCdIQEA qCEBANshAQDmIQEAHCIBACEiAQBfIgEAaCIBAPgiAQD8IgEANyMBAEkjAQDdIwEA4CMBACUk AQArJAEAMSQBADskAQCtJAEAsSQBAPAkAQD6JAEAMyUBADklAQB1JQEAfiUBALolAQDBJQEA LiYBADcmAQB1JgEAdyYBAL4mAQDFJgEABScBAAknAQBHJwEATicBAIUnAQCKJwEA4ycBAOon AQDxJwEAACgBANIoAQDYKAEAWCkBAFwpAQDnKQEA8CkBAC8qAQA1KgEAcyoBAHsqAQC2KgEA vioBAGMrAQBtKwEAkCsBAJsrAQC+KwEAySsBADEsAQA7LAEAdywBAH4sAQC2LAEAwCwBAP0s AQAELQEAhC0BAIwtAQDNLQEA1y0BABIuAQAbLgEAVy4BAGEuAQCfLgEApi4BAOguAQDzLgEA KS8BADMvAQBRLwEAXi8BAOIvAQDkLwEACTABABAwAQADMQEABzEBAEkxAQBRMQEAkTEBAJMx AQDYMQEA4TEBAB8yAQAjMgEAYDIBAG8yAQD4MgEAADMBAIMzAQCMMwEAyzMBANAzAQBJNAEA VTQBAJI0AQCbNAEA2TQBANs0AQAaNQEAIjUBADQ1AQBANQEAvjUBAMA1AQDlNQEA7DUBAHE2 AQB0NgEAxTYBAM02AQAONwEAGjcBAJs3AQCfNwEAsjcBAMA3AQBjOAEAajgBAKE4AQCsOAEA 6jgBAO04AQBMOQEATjkBAJI5AQCeOQEAFjoBAC46AQCkOgEAqDoBALQ6AQDDOgEA9jsBAPs7 AQBEPgEASD4BAAQ/AQALPwEALT8BADQ/AQC6PwEAvD8BAE5AAQBVQAEAkkABAJlAAQDVQAEA 3EABABpBAQAtQQEAXkEBAGdBAQAXQgEAHkIBAF5CAQBiQgEAdEIBAH5CAQAYQwEAH0MBAHRD AQB2QwEAvUMBAMBDAQAFRAEAFEQBAJ1EAQCfRAEA3EQBAOZEAQCQRQEAlkUBAMFGAQDPRgEA hkgBAI1IAQDOSAEA3EgBABVJAQAfSQEAo0kBAKpJAQAoSgEALkoBAG9KAQB3SgEA20oBAOBK AQAiSwEAJUsBAEJLAQBMSwEABEwBAApMAQBKTAEAXkwBAJFMAQCTTAEA2kwBAN1MAQDmTAEA Mk0BADdNAQB4TQEAg00BAJZNAQClTQEAME4BAD9OAQCNTgEAj04BABlPAQAhTwEAdE8BAH5P AQC8TwEAwE8BADRQAQA9UAEAe1ABAINQAQDEUAEA0FABAAtRAQAPUQEAWlEBAGVRAQCRUQEA mlEBAPFRAQD6UQEAMlIBAD5SAQB7UgEAg1IBAMNSAQDIUgEAElMBABdTAQBaUwEAYFMBAKBT AQCpUwEA4FMBAO5TAQAlVAEAL1QBAG1UAQBxVAEAtlQBALlUAQAaVQEAJVUBAGFVAQBsVQEA qlUBAK9VAQDIVQEA1lUBADBWAQA5VgEAbVYBAHxWAQCzVgEAulYBANFWAQDgVgEAslcBALdX AQD7VwEAJ1gBAIFYAQCEWAEAylgBAM1YAQDxWAEA/VgBAFlZAQBlWQEAolkBAKVZAQDgWQEA 61kBAChaAQAuWgEA4FoBAOhaAQAiWwEAKlsBAGVbAQBsWwEArFsBAK5bAQDzWwEA/1sBADhc AQBGXAEAi1wBAL1cAQDRXAEA2FwBABRdAQAdXQEAL10BADZdAQCKXQEAkV0BAAFeAQAHXgEA RF4BAE1eAQCUXgEAnl4BANNeAQDmXgEAGV8BACJfAQBfXwEAZl8BAKZfAQCsXwEA7V8BAPRf AQAkYAEAM2ABAP9gAQAHYQEAR2EBAFJhAQDOYQEA2WEBABdiAQAdYgEAYGIBAGNiAQCpYgEA tGIBAFNjAQBdYwEAlGMBAJ1jAQDdYwEA52MBADxkAQA+ZAEAQmQBAEhkAQCIZAEAj2QBANFk AQDVZAEAEWUBAB1lAQBYZQEAZGUBAPhlAQD9ZQEAMmYBAD5mAQCHZgEAj2YBAM9mAQDSZgEA E2cBABZnAQBhZwEAa2cBAO1nAQDxZwEAMWgBADhoAQB4aAEAgmgBAOloAQDxaAEAMGkBADZp AQB4aQEAfWkBALlpAQDFaQEAAWoBAANqAQASagEAIWoBADZrAQA8awEAfWsBAIdrAQAFbAEA DmwBAE5sAQBTbAEAy2wBANNsAQASbQEAFG0BAFltAQBcbQEAoG0BAKRtAQD9bQEAA24BAHJu AQCZbgEAtW4BALxuAQD3bgEA/m4BACZvAQA1bwEAgW8BAIRvAQDGbwEAy28BAFRwAQBacAEA l3ABAJ1wAQDfcAEA4XABAPpwAQACcQEAWHEBAGFxAQCgcQEAo3EBAAdyAQAecgEAa3IBAG1y AQDzcgEA93IBADpzAQBDcwEAg3MBAIZzAQAQdAEAGHQBAFh0AQBedAEAk3QBAKJ0AQBqdQEA dHUBALJ1AQC2dQEA+XUBAAF2AQBZdgEAZHYBAJt2AQCmdgEA43YBAO92AQAsdwEALncBAG53 AQB3dwEAsHcBALl3AQAbeAEAHXgBAGN4AQBqeAEArHgBAK94AQD1eAEA93gBADB5AQA9eQEA 7XkBAAB6AQAwegEASXoBAJF6AQCcegEAeHwBAHp8AQBUfQEAV30BAN19AQDmfQEA+n0BAAl+ AQCgfgEA2H4BAN5+AQDlfgEA9X4BAPt+AQA1fwEAPX8BAGR/AQBqfwEAh38BAI5/AQCefwEA p38BAPd/AQD9fwEASYABAFOAAQD+gAEABIEBAEmBAQBRgQEAdIEBAH2BAQDAgQEAx4EBANiB AQDegQEAGYIBACOCAQBjggEAZoIBALyCAQDGggEAA4MBAA6DAQAegwEAJoMBAEaDAQBMgwEA ZYMBAG6DAQCxgwEAs4MBAAGEAQAHhAEAQoQBAFGEAQDahAEA4IQBADaFAQA8hQEAi4UBAJWF AQALhgEAEYYBAFeGAQBehgEAcoYBAHiGAQDEhgEA0IYBAPyGAQAGhwEAFocBAB6HAQArhwEA MocBAEKHAQBOhwEAt4cBAL+HAQDEhwEAyocBAA6IAQASiAEAOYgBAEeIAQB+iAEAiIgBAMaI AQDOiAEA6IgBAO6IAQA0iQEAQYkBAE+JAQBaiQEAmIkBAJ6JAQCziQEAtIkBAIKKAQCRigEA LYsBADCLAQBpiwEAcIsBAB2MAQAqjAEAXo0BAJaNAQDCjgEA044BAAaQAQAUkAEA65ABAP+Q AQAjkQEAMJsBADGbAQDTowEAKKQBAMCoAQAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAEAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAAwAHAAcABAAHAAAAAAAwmwEA MZsBADKbAQCimwEAo5sBAL2oAQDAqAEABAAHAAMABAAHAAQABwACAJ9q3xcAAAAAAAAAAAAB AgACACxqhFUAAAAAAAAAAA8BEgBkAAAAZAAAAGQAAABkAAAAAgAyAAAABAAAAAgAAADlAAAA AAAAACsAAAATARwAvnEkACI8KAAqISkAkBwuABxoMADiRTYACVk2AEwtNwAhRDwA01g+AMF7 PgAvDkEA0RpPAAMsTwB9OFAANBZRAA9hWwDfIW8A0zRvABkzdQATPncARTR5AA8lhwChQIwA i2mTAMRvlQDrRpsAvXybANMsowCCOqQAjEemAEdgqACEFqkAyVW4AFZJxQD/BMoAvj/PAJFd zwA7RtEAS2DhAP984wC5GOUA6G/mAJYj6AAeGukAIH7sAP8P8wDbA/cAx3X+AAAAAAAxmwEA M5sBAAAAAAABAAAA/0ABAAEAeWIAAEljAAAAmGQFAQABAHliAAAAAAAAeWIAAAAAAAACEAAA AAAAAAC/qAEAQAAAEABAAAD//wIAAAAHAFUAbgBrAG4AbwB3AG4AFABDAGUAbgB0AHUAcgB5 AEwAaQBuAGsAIABFAG0AcABsAG8AeQBlAGUA//8CAAgAAAAAAAAAAAAAAAAAAAAAAAAAAQD/ /wIAAAAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABwAAAEcekAEAAAICBgMFBAUCAwT/ KgDgQXgAwAkAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAA ADUekAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAA ADMukAEAAAILBgQCAgICAgT/KgDgQ3gAwAkAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA/ PZABAAACBwMJAgIFAgQE/yoA4EN4AMAJAAAAAAAAAP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAg AE4AZQB3AAAANy6QAQAAAg8FAgICBAMCBP8CAOH/rABACQAAAAAAAACfAQAAAAAAAEMAYQBs AGkAYgByAGkAAAA1LpABAAACCwYEAwUEBAIE/y4A4VtgAMApAAAAAAAAAP8BAQAAAAAAVABh AGgAbwBtAGEAAABBHpABAAACBAUDBQQGAwIE/wIA4P8kAEIAAAAAAAAAAJ8BAAAAAAAAQwBh AG0AYgByAGkAYQAgAE0AYQB0AGgAAAAiAAQAMYiMGADw0AIAAGgBAAAAAIPaISeAKiJnAAAA ACAArQsAAF89AADSXQEALQDSAAAABAADkOoCAABfPQAA0l0BAC0A0gAAAOoCAAAAAAAA2QMA 8BAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAWgBbQAtACB gRIwAAAAAAAAAAAAAAAAAABfmgEAX5oBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAMoMRAPAQAAgA/P0B AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEhYAAAAAAnw/w8BCCRQAADkBAAAAAAAAP///3// //9/AAAAAP///3////9/////f8F7PgAABAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAACEEAAAA AAAAAAAAAAAAAAAAAAAAEBwAAAYAAAAAAAAAAAB4AAAAeAAAAAAAAAAAAAAAoAUAAP//EgAA AAAAAAAAAAAAAAAAABQAQwBlAG4AdAB1AHIAeQBMAGkAbgBrACAARQBtAHAAbABvAHkAZQBl ABQAQwBlAG4AdAB1AHIAeQBMAGkAbgBrACAARQBtAHAAbABvAHkAZQBlAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABgECAAAA AAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAB4AQAAEAAAAAEAAACIAAAA AgAAAJAAAAADAAAAnAAAAAQAAACoAAAABQAAAMgAAAAHAAAA1AAAAAgAAADoAAAACQAAAAgB AAASAAAAFAEAAAoAAAA0AQAADAAAAEABAAANAAAATAEAAA4AAABYAQAADwAAAGABAAAQAAAA aAEAABMAAABwAQAAAgAAAOQEAAAeAAAABAAAAAAAAAAeAAAABAAAAAAAAAAeAAAAGAAAAENl bnR1cnlMaW5rIEVtcGxveWVlAAAAAB4AAAAEAAAAAAAAAB4AAAAMAAAATm9ybWFsLmRvdG0A HgAAABgAAABDZW50dXJ5TGluayBFbXBsb3llZQAAAAAeAAAABAAAADMyAAAeAAAAGAAAAE1p Y3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAATviOoQEAAEAAAAAA+gSigRvPAUAAAAAA6HK0 kyLPAQMAAAAtAAAAAwAAAF89AAADAAAA0l0BAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAA AAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA8AAAAAwAAAABAAAAaAAAAA8AAABwAAAA BQAAAIQAAAAGAAAAjAAAABEAAACUAAAAFwAAAJwAAAALAAAApAAAABAAAACsAAAAEwAAALQA AAAWAAAAvAAAAA0AAADEAAAADAAAANEAAAACAAAA5AQAAB4AAAAMAAAAQ2VudHVyeUxpbmsA AwAAAOoCAAADAAAA0gAAAAMAAABfmgEAAwAAAAAADAALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAALAAAAAAAAAB4QAAABAAAAAQAAAAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcA AAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAA FQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIA AAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAA MAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0A AAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAA SwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgA AABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAA ZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMA AAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAA gQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4A AACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAA nAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYAAACnAAAAqAAAAKkA AACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAAALUAAAC2AAAA twAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAAwwAAAMQA AADFAAAAxgAAAMcAAADIAAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAAzwAAANAAAADRAAAA 0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAAANwAAADdAAAA3gAAAN8A AADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA 7QAAAO4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQAAAD1AAAA9gAAAPcAAAD4AAAA+QAAAPoA AAD7AAAA/AAAAP0AAAD+AAAA/wAAAAABAAABAQAAAgEAAAMBAAAEAQAABQEAAAYBAAAHAQAA CAEAAAkBAAAKAQAACwEAAAwBAAANAQAADgEAAA8BAAAQAQAAEQEAABIBAAATAQAAFAEAABUB AAAWAQAAFwEAABgBAAAZAQAAGgEAABsBAAAcAQAAHQEAAB4BAAAfAQAAIAEAACEBAAAiAQAA IwEAACQBAAAlAQAAJgEAACcBAAAoAQAAKQEAACoBAAArAQAALAEAAC0BAAAuAQAALwEAADAB AAAxAQAAMgEAADMBAAA0AQAANQEAADYBAAA3AQAAOAEAADkBAAA6AQAAOwEAADwBAAA9AQAA PgEAAD8BAABAAQAAQQEAAEIBAABDAQAARAEAAEUBAABGAQAA/v///0gBAABJAQAASgEAAEsB AABMAQAATQEAAE4BAAD+////UAEAAFEBAABSAQAAUwEAAFQBAABVAQAAVgEAAFcBAABYAQAA WQEAAFoBAABbAQAAXAEAAF0BAABeAQAAXwEAAGABAABhAQAAYgEAAGMBAABkAQAAZQEAAGYB AABnAQAAaAEAAGkBAABqAQAAawEAAGwBAABtAQAAbgEAAG8BAABwAQAAcQEAAHIBAABzAQAA dAEAAHUBAAB2AQAAdwEAAHgBAAB5AQAAegEAAHsBAAB8AQAAfQEAAH4BAAB/AQAAgAEAAIEB AACCAQAA/v///4QBAACFAQAAhgEAAIcBAACIAQAAiQEAAIoBAAD+////jAEAAI0BAACOAQAA jwEAAJABAACRAQAAkgEAAP7////9/////f////3////9////mAEAAP7////+/////v////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIA AAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAgME+vJMizwGaAQAAgAAAAAAAAABEAGEAdABhAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEcB AAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAATwEAAN1nAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANIwCAAAAAAAFAFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIMBAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiwEAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AQD+/wMK AAD/////BgkCAAAAAADAAAAAAAAARicAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgOTctMjAw MyBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA= --------------040908070909070104050301-- From ken.ko@adtran.com Thu Feb 6 13:36:22 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE181A0258 for ; Thu, 6 Feb 2014 13:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7hsIP_VuBLM for ; Thu, 6 Feb 2014 13:36:18 -0800 (PST) Received: from p02c12o148.mxlogic.net (p02c12o148.mxlogic.net [208.65.145.81]) by ietfa.amsl.com (Postfix) with ESMTP id 982BE1A0133 for ; Thu, 6 Feb 2014 13:36:17 -0800 (PST) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o148.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 05004f25.2adf80e5a940.31631.00-588.84684.p02c12o148.mxlogic.net (envelope-from ); Thu, 06 Feb 2014 14:36:16 -0700 (MST) X-MXL-Hash: 52f400506b4cb32b-f2c2e60e33764d76d0891526ab6f2400438abc08 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o148.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id 34004f25.0.31509.00-334.84320.p02c12o148.mxlogic.net (envelope-from ); Thu, 06 Feb 2014 14:36:09 -0700 (MST) X-MXL-Hash: 52f400497dfc4102-ea48b653c97abf3877c80ae566c9eefd58022839 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.01.0438.000; Thu, 6 Feb 2014 15:36:02 -0600 From: KEN KO To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: [lmap] WGLC for http://www.ietf.org/id/draft-ietf-lmap-framework-03.txt Thread-Index: Ac8YP1MxATKR0Iw1RyKcPlwz98oRLALBLI4Q Date: Thu, 6 Feb 2014 21:36:02 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA243D862C@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA243D862C@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.221.46] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB7774FDAE5exmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=Z/db6gtA c=1 sm=1 a=0XgpNN2/4a34ymu16SVwsQ==:17 a] X-AnalysisOut: [=2qL5HIk2eJwA:10 a=qZHQZMT3apYA:10 a=uSp1aO0N3sgA:10 a=njS] X-AnalysisOut: [VscJewVsA:10 a=BLceEmwcHowA:10 a=xqWC_Br6kY4A:10 a=48vgC7m] X-AnalysisOut: [UAAAA:8 a=eJNrpioGAAAA:8 a=OUT5rZy6ux0A:10 a=oGQYjV0D0-c3T] X-AnalysisOut: [nv2mIgA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=O6EI606FzA] X-AnalysisOut: [Un8TR-:21 a=QPzd3A7XzvfD8vIc:21 a=yMhMjlubAAAA:8 a=SSmOFEA] X-AnalysisOut: [CAAAA:8 a=YTAaM3TkEgaiUrOTgJwA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7] X-AnalysisOut: [L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tter_5Zwo] X-AnalysisOut: [jY9ZCLQ:21] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014020620); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Subject: Re: [lmap] WGLC for http://www.ietf.org/id/draft-ietf-lmap-framework-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 21:36:22 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB7774FDAE5exmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Many thanks to the authors for this draft. It expresses many of the concept= s for lmap clearly and concisely. Here are my comments for WGLC. They are l= engthy because I am trying to include my reasoning, not because there are a= lot of issues. P.5, starting with 2nd para. Of Section 2. Suggest that Measurement Method= is described first so that we move from the general to the specific (Measu= rement Task). Suggested text: A Measurement Method defines how to measure a Metric of interest. It is very useful to standardise Measurement Methods, so that it is meaningful to compare measurements of the same Metric made at different times and places. It is also useful to define a registry for commonly-used Metrics [I-D.bagnulo-ippm-new-registry-independent] so that a Measurement Method can be referred to simply by its identifier in the registry. The Measurement Methods and registry will hopefully be referenced by other standards organisations. A Measurement Task is a specific instantiation of a Measurement Method which generates a Measurement Result. An Active Measurement Task involves either a Measurement Agent (MA) injecting Active Measurement Traffic into the network destined for a Measurement Peer, and/or a Measurement Peer sending Active Measurement Traffic to a MA; one of them measures some parameter associated with the transfer of the packet(s). A Passive Measurement Task involves only a MA, which simply observes existing traffic - for example, it could simply count bytes or it might calculate the average loss for a particular flow. P.6, Collector: delete "It may also do some post-processing on the results,= for instance to eliminate outliers, as they can severely impact the aggreg= ated results." And replace with "It then provides the results to a results= repository (see below)." Reasons for deleting this sentence: - Keep functional definitions well delineated. A Collector col= lects and stores data for use by other functions. A post-processing analysi= s function may modify that data. - Avoid implicit approval for any "post-processing" function t= hat modifies the database so that raw results are no longer available for a= nalysis. In particular, elimination of Outliers strikes me as a bad example= - different analyses can create different useful algorithms to identify an= d remove outliers. - The fact that the Collector and the results repository are t= wo logically separate functions reinforces the above point. There should be= no post processing of the measurement results prior to storage in the repo= sitory. P.9: Delete the definition of Composite Metric (isn't used anywhere, imprec= ise definition). P.10, definition of Measurement Task: Delete "The act that yields a single = Measurement Result." Later in the draft reference is made to Measurement Ta= sks that can yield multiple results. P.14, bottom: Delete "Optionally any Suppression message can be sent over a= different channel." There is no mention of this in the Suppression section= , and Suppression is being handled as an element within the Instruction. P.16: Change "Measurement Task" to "Measurement Task Configuration" in the = first bullet. This configures parameters for a Method and potentially appli= es to many iterations of a Measurement Task. P.17, 2nd full para.: change sentence to "For example, if the message inclu= des (only) a set of periodic Measurement Schedules, then that replaces the= old set but does not alter the Measurement Task Configurations and Report = Channels." The element may contain more than one Measurement Schedule. Bottom of P.21/top of P.22: I think we need to encourage restraint in any p= reprocessing of Measurement Results before they get to the repository, sinc= e this precludes any chance of analyzing the raw results. Overall: I think the draft is missing a means for a Controller to provide = explicit suppression to a Measurement Peer. In the current draft there is n= o mention of a controller interacting with a Peer and Figure 1 shows no con= nection between the two. For the most part, that is expected. MA and MP are= two related but distinct logical functions - one initiates upon direction = from a Controller, the other is limited to responding. However, if suppression is required the Controller should be able to notify= both ends, so that a MP can reject suppressed Tasks that are initiated eit= her by MAs that have not yet received the suppression Instruction or by MAs= controlled from another domain entirely. (I know, this is out of scope for= lmap. But this seems to be an important omission, and I think we can justi= fy it if need be out of a concern that even in the same domain, some MAs ma= y not get timely notification). This would not be necessary for an MP sitting in, say, a set-top box, becau= se that MP will not interact with thousands of MAs. It is necessary for the= large dedicated devices at network peering points, etc., and adding a cont= roller interface for those devices doesn't measurably increase the complexi= ty. I expect them to also have resident MA functions anyway to support tro= ubleshooting. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, January 23, 2014 7:31 AM To: lmap@ietf.org Subject: [lmap] WGLC for http://www.ietf.org/id/draft-ietf-lmap-framework-0= 3.txt This is a Working Group Last Call for the Internet-Draft 'A framework for l= arge-scale measurement platforms (LMAP)' which can be found at http://www.ietf.org/id/draft-ietf-lmap-framework-03.txt. Please send your = comments about this I-D to the WG mail list until 2/6/13. If you have no c= omments but you believe that the document is ready to be submitted to the I= ESG for consideration as Informational RFC a short mail stating this is als= o welcome. Thanks and Regards, Dan --_000_D14B7E40AEBFD54EA3AD964902DD7CB7774FDAE5exmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Many thanks to the aut= hors for this draft. It expresses many of the concepts for lmap clearly and= concisely. Here are my comments for WGLC. They are lengthy because I am tr= ying to include my reasoning, not because there are a lot of issues.

 

P.5, starting with 2nd para. Of Section 2.  Suggest that Measurement Method is de= scribed first so that we move from the general to the specific (Measurement= Task). Suggested text:

 

   A Measurement Method defines =
how to measure a Metric of interest. It 
   is very useful to standa=
rdise Measurement Methods, so that it is
   meaningful to compare measure=
ments of the same Metric made at
   different times and places.&n=
bsp; It is also useful to define a registry
   for commonly-used Metrics [I-=
D.bagnulo-ippm-new-registry-independent]
   so that a Measurement Method =
can be referred to simply by its
   identifier in the registry.&n=
bsp; The Measurement Methods and registry
   will hopefully be referenced =
by other standards organisations.
 
   A Measurement Task is a speci=
fic instantiation of a Measurement Method 
   which generates a Measur=
ement Result.  An Active Measurement Task 
   involves either a Measur=
ement Agent (MA) injecting Active Measurement 
   Traffic into the network=
 destined for a Measurement Peer, and/or a 
   Measurement Peer sending=
 Active Measurement Traffic to a MA; one of 
   them measures some param=
eter associated with the transfer of the 
   packet(s).  A Passi=
ve Measurement Task involves only a MA, which 
   simply observes existing=
 traffic - for example, it could simply count
   bytes or it might calculate t=
he average loss for a particular flow.

 

P.6, Collector: delete= “It may also do some post-processing on the results, for instance to= eliminate outliers, as they can severely impact the aggregated results.= 221;  And replace with “It then provides the results to a results repository (see below).”

 

Reasons for deleting this sentence:

-           &nb= sp;  Keep functional definitions well delineated. A Collector collects= and stores data for use by other functions. A post-processing analysis fun= ction may modify that data.

-           &nb= sp;  Avoid implicit approval for any “post-processing” fun= ction that modifies the database so that raw results are no longer availabl= e for analysis. In particular, elimination of Outliers strikes me as a bad example – different analyses can cre= ate different useful algorithms to identify and remove outliers. 

-           &nb= sp;  The fact that the Collector and the results repository are two lo= gically separate functions reinforces the above point. There should be no p= ost processing of the measurement results prior to storage in the repository.

 

P.9: Delete the defini= tion of Composite Metric (isn’t used anywhere, imprecise definition).=

 

P.10, definition of Me= asurement Task: Delete “The act that yields a single Measurement Resu= lt.” Later in the draft reference is made to Measurement Tasks that c= an yield multiple results.

 

P.14, bottom: Delete &= #8220;Optionally any Suppression message can be sent over a different chann= el.” There is no mention of this in the Suppression section, and Supp= ression is being handled as an element within the Instruction.

 

P.16: Change “Me= asurement Task” to “Measurement Task Configuration” in th= e first bullet. This configures parameters for a Method and potentially app= lies to many iterations of a Measurement Task.

 

P.17, 2nd f= ull para.: change sentence to “For example, if the message includes&n= bsp; (only) a set of periodic Measurement Schedules, then that replaces the= old set but does not alter the Measurement Task Configurations and Report Channels.” The element may contain more th= an one Measurement Schedule.

 

Bottom of P.21/top of = P.22: I think we need to encourage restraint in any preprocessing of Measur= ement Results before they get to the repository, since this precludes any c= hance of analyzing the raw results.

 

Overall:  I think= the draft is missing a means for a Controller to provide explicit suppress= ion to a Measurement Peer. In the current draft there is no mention of a co= ntroller interacting with a Peer and Figure 1 shows no connection between the two. For the most part, that is expected= . MA and MP are two related but distinct logical functions – one init= iates upon direction from a Controller, the other is limited to responding.=

 

However, if suppression is required the Controller should be able to n= otify both ends, so that a MP can reject suppressed Tasks that are initiate= d either by MAs that have not yet received the suppression Instruction or by MAs controlled from another domain entir= ely. (I know, this is out of scope for lmap. But this seems to be an import= ant omission, and I think we can justify it if need be out of a concern tha= t even in the same domain, some MAs may not get timely notification).

 

This would not be necessary for an MP sitting in, say, a set-top box, = because that MP will not interact with thousands of MAs. It is necessary fo= r the large dedicated devices at network peering points, etc., and adding a controller interface for those devices = doesn’t measurably increase the complexity.  I expect them to al= so have resident MA functions anyway to support troubleshooting.

 

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, January 23, 2014 7:31 AM
To: lmap@ietf.org
Subject: [lmap] WGLC for http://www.ietf.org/id/draft-ietf-lmap-fram= ework-03.txt

 

This is a Working Group Last Call for the Internet-Draft ‘A fram=
ework for large-scale measurement platforms (LMAP)’ which can be foun=
d at

 http://www.ietf.org/id/draft-ietf-lmap-framework-03.t= xt. Please send your comments about this I-D to the WG mail list until = 2/6/13.  If you have no comments but you believe that the document is ready to be submitted to the IESG for conside= ration as Informational RFC a short mail stating this is also welcome.

 

Thanks and Regards,

 

Dan

--_000_D14B7E40AEBFD54EA3AD964902DD7CB7774FDAE5exmb1corpadtran_-- From j.schoenwaelder@jacobs-university.de Fri Feb 7 08:25:44 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227F91A01AF for ; Fri, 7 Feb 2014 08:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boREPsyp2-2s for ; Fri, 7 Feb 2014 08:25:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 113D31A01E8 for ; Fri, 7 Feb 2014 08:25:42 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6EC7201DC; Fri, 7 Feb 2014 17:25:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tNad_pOzqXh1; Fri, 7 Feb 2014 17:25:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD0EC201B8; Fri, 7 Feb 2014 17:25:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D0BFF2B16199; Fri, 7 Feb 2014 17:25:37 +0100 (CET) Date: Fri, 7 Feb 2014 17:25:37 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20140207162537.GA52614@elstar.local> Mail-Followup-To: lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [lmap] review of draft-ietf-lmap-framework-03 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:25:44 -0000 Hi, I think the document is generally in a good shape. I do only have a few technical comments: a] I do not like the term MA-to-Controller channel. The situation is a bit complicated to explain. So let me go through a couple of definitions in order to explain why I think the terms we have are confusing: A Control Protocol "delivering Instruction(s) from a Controller to a Measurement Agent" and it "delivers Failure Information and Capabilities Information from the Measurement Agent to the Controller." A Control Channel is a channel "over which Instructions are sent." So this is really an instruction channel somewhat mis-labelled as an Control Channel. A MA-to-Controller Channel is a channel over which Capabilities and Failure Information is sent. I think it would be more consistent to call it a Capabilities and Failure Information Channel. So if we keep the separation of the channels as they are defined, I would suggest to rename Control Channel to Instruction Channel and MA-to-Controller Channel to Capabilities and Failure Information Channel. That said, one can ask what the value is of defining two channels for the Control Protocol. Since the Control Protocol carries three different things, why are two of them in one channel and the third in a separate channel? Would it not make sense to either have three separate channels (Instruction Channel, Capabilities Channel, Failure Information Channel) or, alternatively, to have just one Control Channel? What is in the document right now does not seem to be very consistent. If I were to use lets say NETCONF, then Instruction and Capabilities would likely be carried over one "channel" while Failure Information would likely be carried over a separate notification "channel". I am mentioning this just as an example to demonstrate why the current distinction seems somewhat arbitrary. As far as I am concerned, my preference is that the terminology has a since conceptual Control Channel that carries Instructions, Capabilities, and Failure Information. I can also live with having three distinct conceptual channels (Instruction Channel, Capabilities Channel, Failure Information Channel) between the MA and the Controller. b] The figure on page 14 mentions a "Suppression Channel" which I think is a leftover and should be removed. There is also text talking about a different channel for Suppressions on page 14. c] The definition of Capabilities mentions "interface type and speed and its IP address" as examples. The text on page 16 says "Note that Capabilities do not include dynamic information like the MA's currently unused CPU, memory or battery life." For many devices, the set of IP addresses assigned to an interface is pretty much dynamic information, consider for example temporary IPv6 addresses with Randomized Interface Identifiers. My proposal is to (a) add text to the definition of Capabilities clarifying that Capabilities do not include dynamic information and (b) to remove IP address from the examples mentioned in the Capabilities definition. d] I do not understand the {Comment} on page 20. Overlapping measurement tasks may be fine, it really depends on what the tasks actually do. I do not think a protocol document can resolve this. I sugges to simply remove the {Comment}. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Sun Feb 9 04:51:32 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5192A1A02A7 for ; Sun, 9 Feb 2014 04:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2QjbLhtOmB6 for ; Sun, 9 Feb 2014 04:51:29 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id A7BB81A05FD for ; Sun, 9 Feb 2014 04:51:28 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqETAMN491KHCzI1/2dsb2JhbABZgkgjIThXqFgIlmGBBxZ0giUBAQEBAxILEF4BBgINBAEDAQELFgEGORQDBgkBBBMIARACB4djAQyMQ4xqhFKqbReOFRcBAQYHETcHgikPZoEUBJ8bizGDLYFpAQcXIg X-IronPort-AV: E=Sophos;i="4.95,812,1384318800"; d="scan'208,217";a="42273141" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Feb 2014 07:51:27 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 09 Feb 2014 07:38:40 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Sun, 9 Feb 2014 13:51:24 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] WGLC for http://www.ietf.org/id/draft-ietf-lmap-framework-03.txt Thread-Index: Ac8llZ2t3wYwrWpJTGCjDNczjsZoig== Date: Sun, 9 Feb 2014 12:51:23 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E3F5409@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5409AZFFEXMB04globa_" MIME-Version: 1.0 Subject: Re: [lmap] WGLC for http://www.ietf.org/id/draft-ietf-lmap-framework-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 12:51:32 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5409AZFFEXMB04globa_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, Please find below my comments =96 as a contributor =96 to draft-ietf-lmap-f= ramework-03.txt I focused my comments at this point on the content and mainly technical iss= ues. I put aside the editorial comments as it seems to me it=92s a little b= it early for these. 1. Juergen Schoenwaelder made in his review a comment (comment a) abo= ut the definition of channels between Controllers and MA which I fully supp= ort. 2. The MAs are described as =91pieces of code=92 that can reside in a= number of hosts, routers or devices deployed in the Internet. There is how= ever no indication about how these =91pieces of code=92 can be upgraded. Th= ere is also no mention about the implications of deploying these =91pieces = of code=92 on security and privacy. This may or may be not related to the c= omponents of the LMAP framework, but I feel this needs to be discussed and = maybe addressed in the text. 3. I do not know exactly what the following sentence in the Introduct= ion section means: =91The Measurement Tasks themselves may be on IPv4, IPv6= , and on various services (DNS, HTTP, XMPP, FTP, VoIP, etc.).=92 I suggest = to delete. 4. Also in the introduction =96 a standardized LMAP mechanism is just= ified by the fact that it =91enables the operator of a measurement system t= o buy the various components from different vendors.=92 I believe that what= is meant really here is that standardized mechanisms may provide =91criter= ia for evaluation of the different solutions that can be used for various p= urposes including buying decisions=92. 5. Several protocols which do not originate in the IETF are being men= tioned in the document =96 TR-069, UPnP, maybe other. Please provide Inform= ational References for these. 6. I do not understand what the following sentence in Section 2 means= : =91The operator's OAM (Operations, Administration, and Maintenance) uses = the results from the tools.=92 I suggest to delete. 7. I am confused by some of the terms in the Terminology section bei= ng labelled as (optional). I hope that it=92s not the description of the te= rm that is optional, and if what is meant is that the fields are optional i= n the LMAP protocols, this needs to be said someplace else. 8. I do not believe that the term =91metric=92 really needs a definit= ion =96 hopefully it has in LMAP the same meaning as used in other WGs In t= he IETF (IPPM, XRBLOCK, etc.) =96 especially as the description is problema= tic (what does =91carefully specified=92 mean?) 9. In Section 5.2 I found the following: In LMAP, the MA can inform the Controller about its Capabilities. This message could be sent in several circumstances: when the MA first communicates with a Controller; when the MA becomes capable of a new Measurement Method; when requested by the Controller (for example, if the Controller forgets what the MA can do or otherwise wants to resynchronize what it knows about the MA). Note that Capabilities do not include dynamic information like the MA's currently unused CPU, memory or battery life. My question is how does the MA inform the controller on asynchronous events= ? (for example the addition of capabilities). There is no hint about an asy= nchronous event passing from MAs to controllers in diagrams or further text= . 10. Also in Section 5.2: The MA can inform the Controller about a Failure. There are two broad categories of failure: (1) the MA cannot action the Instruction (for example, it doesn't include a parameter that is mandatory for the requested Measurement Method; or it is missing details of the target Collector). (2) the MA cannot execute the Measurement Task or deliver the Report (for example, the MA unexpectedly has no spare CPU cycles; or the Collector is not responding). How is the latest failure condition (collector not responding) detected by = the MA? Do we assume that the Report Protocol incorporates either an ACK me= chanism or some kind of keep-alive with each of the reporting MAs? If this = is the case, we should mention this when speaking about the Report Protocol= , I could not find anything on this respect. 11. In Section 5.4: The measurement system may define what happens if a Collector unexpectedly does not hear from a MA, for example the Controller could send a fresh Report Schedule to the MA. This implies an interaction between Collectors and Controllers which is not= present in the basic architecture diagram and declared out of scope in Sec= tion 5.6 (point 2). This requires some clarification in the text at best = =96 I am not sure that we need to define in the protocol option that relay = on a channel that is explicitly out of the scope of the framework. 12. In Section 6.2.2 - It is not clear why the first mechanism mentioned = for pre-provisioning firewalls for traversal is a non-IETF protocol (TR-069= ), while PCP and another non-IETF protocol UPnP are later mentioned as alte= rnatives. At least I would see them as part of the same enumeration. 13. The security considerations section should say something about the th= reats related to the storage on the Collectors 14. The security considerations section should say something about the th= reat of DoS attacks on collectors, for example by throttling them with dumm= y MA registrations and false reports. Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: =E9=E5=ED =E4 23 =E9=F0=E5=E0=F8 2014 15:31 To: lmap@ietf.org Subject: [lmap] WGLC for http://www.ietf.org/id/draft-ietf-lmap-framework-0= 3.txt This is a Working Group Last Call for the Internet-Draft =91A framework for= large-scale measurement platforms (LMAP)=92 which can be found at http://www.ietf.org/id/draft-ietf-lmap-framework-03.txt. Please send your = comments about this I-D to the WG mail list until 2/6/13. If you have no c= omments but you believe that the document is ready to be submitted to the I= ESG for consideration as Informational RFC a short mail stating this is als= o welcome. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5409AZFFEXMB04globa_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Please find below my c= omments =96 as a contributor =96 to draft-ietf-lmap-framework-03.txt

 

I focused my comments = at this point on the content and mainly technical issues. I put aside the e= ditorial comments as it seems to me it=92s a little bit early for these.

 

1.&= nbsp;      Juergen Schoenwaelder made in his review a comment (comment a) a= bout the definition of channels between Controllers and MA which I fully su= pport.

2.&= nbsp;      The MAs are described as =91pieces of code=92 that can reside in= a number of hosts, routers or devices deployed in the Internet. There is h= owever no indication about how these =91pieces of code=92 can be upgraded. There is also no mention about the implication= s of deploying these =91pieces of code=92 on security and privacy. This may= or may be not related to the components of the LMAP framework, but I feel = this needs to be discussed and maybe addressed in the text.

3.&= nbsp;      I do not know exactly what the following sentence in the Introdu= ction section means: =91The Measurement Tasks themselves may be on IPv4, IPv6, and on various services (DNS, HTTP, XMPP,= FTP, VoIP, etc.).=92 I suggest to del= ete.

4.&= nbsp;      Also in the introduction =96 a standardized LMAP mechanism is ju= stified by the fact that it =91enables the operator of a measurement system to buy the various compon= ents from different vendors.=92 I beli= eve that what is meant really here is that standardized mechanisms may provide =91criteria for evaluation of the diff= erent solutions that can be used for various purposes including buying deci= sions=92.

5.&= nbsp;      Several protocols which do not originate in the IETF are being m= entioned in the document =96 TR-069, UPnP, maybe other. Please provide Info= rmational References for these.

6.&= nbsp;      I do not understand what the following sentence in Section 2 mea= ns: =91The operator's OAM (Operations, Administration, and Maintenance) uses the= results from the tools.=92  I suggest to delete.

7.&= nbsp;       I am confused by some of the terms in the Terminology sect= ion being labelled as (optional). I hope that it=92s not the description of= the term that is optional, and if what is meant is that the fields are optional in the LMAP protocols, this needs to= be said someplace else.

8.&= nbsp;      I do not believe that the term =91metric=92 really needs a defin= ition =96 hopefully it has in LMAP the same meaning as used in other WGs In= the IETF (IPPM, XRBLOCK, etc.) =96 especially as the description is problematic (what does =91carefully specified=92 mea= n?)

9.&= nbsp;      In Section 5.2 I found the following:

 

   In LMAP, the MA can inform the

   Controller about its Capabilities.  This message could= be sent in

   several circumstances: when the MA first communicates with = a

   Controller; when the MA becomes capable of a new Measuremen= t Method;

   when requested by the Controller (for example, if the Contr= oller

   forgets what the MA can do or otherwise wants to resynchron= ize what

   it knows about the MA).  Note that Capabilities do not= include

   dynamic information like the MA's currently unused CPU, mem= ory or

   battery life.

 

My question is how doe= s the MA inform the controller on asynchronous events? (for example the add= ition of capabilities). There is no hint about an asynchronous event passin= g from MAs to controllers in diagrams or further text.

 

10.=    Also in Section 5.2:

 

     The = MA can inform the Controller about a Failure.  There are two

   broad categories of failure: (1) the MA cannot action the I= nstruction

   (for example, it doesn't include a parameter that is mandat= ory for

   the requested Measurement Method; or it is missing details = of the

   target Collector). (2) the MA cannot execute the Measuremen= t Task or

   deliver the Report (for example, the MA unexpectedly has no= spare CPU

   cycles; or the Collector is not responding).<= o:p>

 

How is the latest fail= ure condition (collector not responding) detected by the MA? Do we assume t= hat the Report Protocol incorporates either an ACK mechanism or some kind o= f keep-alive with each of the reporting MAs? If this is the case, we should mention this when speaking about the R= eport Protocol, I could not find anything on this respect.

 

11.=    In Section 5.4:

 

    The = measurement system may define what happens if a Collector=

   unexpectedly does not hear from a MA, for example the Contr= oller

   could send a fresh Report Schedule to the MA.

 

 

This implies an intera= ction between Collectors and Controllers which is not present in the basic = architecture diagram and declared out of scope in Section 5.6 (point 2). Th= is requires some clarification in the text at best =96 I am not sure that we need to define in the protocol opti= on that relay on a channel that is explicitly out of the scope of the frame= work.

 

12.=    In Section 6.2.2 - It is not clear why the first mechanism menti= oned for pre-provisioning firewalls for traversal is a non-IETF protocol (T= R-069), while PCP and another non-IETF protocol UPnP are later mentioned as alternatives. At least I would see th= em as part of the same enumeration.

13.=    The security considerations section should say something about t= he threats related to the storage on the Collectors

14.=    The security considerations section should say something about t= he threat of DoS attacks on collectors, for example by throttling them with= dummy MA registrations and false reports.

 

Thanks and Regards,

 

Dan<= /p>

 

 

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: =E9=E5=ED =E4 23 =E9=F0=E5=E0=F8<= /span><= /span> 2014 15:31
To: lmap@ietf.org
Subject: [lmap] WGLC for http://www.ietf.org/id/draft-ietf-lmap-fram= ework-03.txt

 

This is a Working Group Last Call for the Internet-Draft =91A framewor=
k for large-scale measurement platforms (LMAP)=92 which can be found at

 http://www.ietf.org/id/draft-ietf-lmap-framework-03.t= xt. Please send your comments about this I-D to the WG mail list until = 2/6/13.  If you have no comments but you believe that the document is ready to be submitted to the IESG for conside= ration as Informational RFC a short mail stating this is also welcome.

 

Thanks and Regards,

 

Dan

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5409AZFFEXMB04globa_-- From dromasca@avaya.com Mon Feb 10 02:09:18 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA9F1A07D5 for ; Mon, 10 Feb 2014 02:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty5Uz73F_FL1 for ; Mon, 10 Feb 2014 02:09:16 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id B95B31A05DE for ; Mon, 10 Feb 2014 02:09:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8GAFek+FLGmAcV/2dsb2JhbABZgkgjIThXqGWWZoEOFnSCJwEBAxIbXgEMCRVWJgEEGxqHYwGZBoRSqxEXjkyDXIEUBJ8bizGDLYIq X-IronPort-AV: E=Sophos;i="4.95,816,1384318800"; d="scan'208,217";a="48750050" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Feb 2014 05:09:16 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Feb 2014 04:57:54 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 11:09:06 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-use-cases-02 - ready for last call? Thread-Index: Ac8mSCDKemWMClcpRZCTsc/4H1yR0g== Date: Mon, 10 Feb 2014 10:09:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E3F5B54@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5B54AZFFEXMB04globa_" MIME-Version: 1.0 Subject: [lmap] draft-ietf-lmap-use-cases-02 - ready for last call? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 10:09:18 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5B54AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is draft-ietf-lmap-use-cases-02 - ready for working group last call? At lea= st one of the authors (Philip) believes that it is, I would like to hear ot= her opinions, especially if somebody has concerns. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5B54AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is draft-ietf-lmap-use-cases-02 - ready for working = group last call? At least one of the authors (Philip) believes that it is, = I would like to hear other opinions, especially if somebody has concerns.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5B54AZFFEXMB04globa_-- From trevor.burbridge@bt.com Mon Feb 10 02:10:32 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1614C1A07D5 for ; Mon, 10 Feb 2014 02:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35vVy6dWK2EF for ; Mon, 10 Feb 2014 02:10:29 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD2C1A06BF for ; Mon, 10 Feb 2014 02:10:28 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 10 Feb 2014 10:10:50 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.56]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 10 Feb 2014 10:10:18 +0000 From: To: , Date: Mon, 10 Feb 2014 10:10:16 +0000 Thread-Topic: [lmap] draft-ietf-lmap-use-cases-02 - ready for last call? Thread-Index: Ac8mSCDKemWMClcpRZCTsc/4H1yR0gAABkmA Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA2E3F5B54@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E3F5B54@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72C8067E868EMV64UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] draft-ietf-lmap-use-cases-02 - ready for last call? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 10:10:32 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72C8067E868EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd support going to last call. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 10 February 2014 10:09 To: lmap@ietf.org Subject: [lmap] draft-ietf-lmap-use-cases-02 - ready for last call? Is draft-ietf-lmap-use-cases-02 - ready for working group last call? At lea= st one of the authors (Philip) believes that it is, I would like to hear ot= her opinions, especially if somebody has concerns. Thanks and Regards, Dan --_000_ED51D9282D1D3942B9438CA8F3372EB72C8067E868EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d support going to last call.

 

Trevor.

 =

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romasca= nu, Dan (Dan)
Sent: 10 February 2014 10:09
To: lmap@iet= f.org
Subject: [lmap] draft-ietf-lmap-use-cases-02 - ready for la= st call?

 <= /o:p>

Is draft-ietf-lmap-use-cas= es-02 - ready for working group last call? At least one of the authors (Phi= lip) believes that it is, I would like to hear other opinions, especially i= f somebody has concerns.

 

Thanks and Regards,

 

Dan

&= nbsp;

= --_000_ED51D9282D1D3942B9438CA8F3372EB72C8067E868EMV64UKRDdoma_-- From dromasca@avaya.com Mon Feb 10 02:11:33 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14611A07DE for ; Mon, 10 Feb 2014 02:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAky7ZXaXSeH for ; Mon, 10 Feb 2014 02:11:28 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9346C1A05DE for ; Mon, 10 Feb 2014 02:11:28 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8GAMWk+FLGmAcV/2dsb2JhbABZgkgjIThXqGWWZoEOFnSCJwEBAxIbXgEMCRVWJgEEGxqHYwGZCYRSqxEXjikjg1yBFASfG4sxgy2CKg X-IronPort-AV: E=Sophos;i="4.95,817,1384318800"; d="scan'208,217";a="48885486" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Feb 2014 05:11:27 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Feb 2014 05:00:14 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 11:11:26 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-framework-03 - WGLC concluded Thread-Index: Ac8mSHQyv+sOFfu2Tx2kCkdPuWuOpw== Date: Mon, 10 Feb 2014 10:11:25 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E3F5B6F@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5B6FAZFFEXMB04globa_" MIME-Version: 1.0 Subject: [lmap] draft-ietf-lmap-framework-03 - WGLC concluded X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 10:11:33 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5B6FAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The WGLC on draft-ietf-lmap-framework-03 is now concluded. We received a se= t of consistent reviews, thanks to all commenters, and I expect the documen= t authors to prepare responses and proposals for resolution and the WG to e= ntertain a lovely and lively discussion in London. BTW - if you did not have the time to review but plan to do it sometimes so= on please keep on sending these comments. Of course, the sooner, the better= . Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5B6FAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WGLC on draft-ietf-lmap-framework-03 is now conc= luded. We received a set of consistent reviews, thanks to all commenters, a= nd I expect the document authors to prepare responses and proposals for res= olution and the WG to entertain a lovely and lively discussion in London.

 

BTW – if you did not have the time to review b= ut plan to do it sometimes soon please keep on sending these comments. Of c= ourse, the sooner, the better.

 

Thanks and Regards,

 

Dan

 

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E3F5B6FAZFFEXMB04globa_-- From frode.sorensen@npt.no Mon Feb 10 03:14:22 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276501A080B for ; Mon, 10 Feb 2014 03:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wV4VsI-Erdi for ; Mon, 10 Feb 2014 03:14:14 -0800 (PST) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.250]) by ietfa.amsl.com (Postfix) with ESMTP id 745721A080F for ; Mon, 10 Feb 2014 03:14:13 -0800 (PST) Received: from [85.158.143.35:15841] by server-3.bemta-4.messagelabs.com id CD/B6-11539-484B8F25; Mon, 10 Feb 2014 11:14:12 +0000 X-Env-Sender: frode.sorensen@npt.no X-Msg-Ref: server-3.tower-21.messagelabs.com!1392030847!4467193!1 X-Originating-IP: [213.225.64.154] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13027 invoked from network); 10 Feb 2014 11:14:08 -0000 Received: from unknown (HELO EXCAS.npta.no) (213.225.64.154) by server-3.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 10 Feb 2014 11:14:08 -0000 Received: from EXMBX01.npta.no ([10.10.2.97]) by EXCAS.npta.no ([fe80::b007:5474:dccd:c4dd%11]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 12:14:07 +0100 From: =?iso-8859-1?Q?S=F8rensen=2C_Frode?= To: "trevor.burbridge@bt.com" , "dromasca@avaya.com" , "lmap@ietf.org" Thread-Topic: [lmap] draft-ietf-lmap-use-cases-02 - ready for last call? Thread-Index: Ac8mSCDKemWMClcpRZCTsc/4H1yR0gAABkmAAAI6kkA= Date: Mon, 10 Feb 2014 11:14:06 +0000 Message-ID: <793D91975B99224DA9777562FF192808A27B4000@exmbx01> References: <9904FB1B0159DA42B0B887B7FA8119CA2E3F5B54@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: nb-NO X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.8.37] Content-Type: multipart/alternative; boundary="_000_793D91975B99224DA9777562FF192808A27B4000exmbx01_" MIME-Version: 1.0 Subject: Re: [lmap] draft-ietf-lmap-use-cases-02 - ready for last call? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 11:14:22 -0000 --_000_793D91975B99224DA9777562FF192808A27B4000exmbx01_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think it should be ready for last call too. Frode Fra: lmap [mailto:lmap-bounces@ietf.org] P=E5 vegne av trevor.burbridge@bt.= com Sendt: 10. februar 2014 11:10 Til: dromasca@avaya.com; lmap@ietf.org Emne: Re: [lmap] draft-ietf-lmap-use-cases-02 - ready for last call? I'd support going to last call. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 10 February 2014 10:09 To: lmap@ietf.org Subject: [lmap] draft-ietf-lmap-use-cases-02 - ready for last call? Is draft-ietf-lmap-use-cases-02 - ready for working group last call? At lea= st one of the authors (Philip) believes that it is, I would like to hear ot= her opinions, especially if somebody has concerns. Thanks and Regards, Dan --_000_793D91975B99224DA9777562FF192808A27B4000exmbx01_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think= it should be ready for last call too.

&n= bsp;

Frode

 

 

Fra: lmap [mai= lto:lmap-bounces@ietf.org] P=E5 vegne av trevor.burbridge@bt.com
Sendt: 10. februar 2014 11:10
Til: dromasca@avaya.com; lmap@ietf.org
Emne: Re: [lmap] draft-ietf-lmap-use-cases-02 - ready for last call?=

 

I’= ;d support going to last call.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

From: lmap [mailto= :lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: 10 February 2014 10:09
To: lmap@ietf.org
Subject: [lmap] draft-ietf-lmap-use-cases-02 - ready for last call?<= o:p>

 

Is draft-ietf-lmap-use-cases-02= - ready for working group last call? At least one of the authors (Philip) = believes that it is, I would like to hear other opinions, especially if som= ebody has concerns.

 

Thanks and Regards,<= /span>

 

Dan

 

--_000_793D91975B99224DA9777562FF192808A27B4000exmbx01_-- From jason.weil@twcable.com Mon Feb 10 16:08:39 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98B41A066E for ; Mon, 10 Feb 2014 16:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.887 X-Spam-Level: X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvmx4FFCyoIK for ; Mon, 10 Feb 2014 16:08:33 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9590C1A060E for ; Mon, 10 Feb 2014 16:08:32 -0800 (PST) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.95,821,1384318800"; d="scan'208,217";a="197647321" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 10 Feb 2014 19:06:45 -0500 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.33]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 10 Feb 2014 19:08:13 -0500 From: "Weil, Jason" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Date: Mon, 10 Feb 2014 19:08:11 -0500 Thread-Topic: [lmap] draft-ietf-lmap-framework-03 - WGLC concluded Thread-Index: Ac8mvVqFSCXkFs6NQ8+m7mMqx4qUFQ== Message-ID: In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E3F5B6F@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF1ECDF4269EDjasonweiltwcablecom_" MIME-Version: 1.0 Subject: Re: [lmap] draft-ietf-lmap-framework-03 - WGLC concluded X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 00:08:40 -0000 --_000_CF1ECDF4269EDjasonweiltwcablecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have a few chair comments that may already be addressed, but I will state= them here just to be sure. Overall I think the document is in good shape = and appreciate the responses we have received in Last Call. There are two p= oints I do want to raise with respect to making sure the document aligns wi= th our charter: 1) Multiple Address Family support The Charter states: "The LMAP architecture will allow for measurements that= utilize either IPv4 or IPv6, or possibly both. Devices containing Measurem= ent Agents may have several interfaces using different link technologies. M= ultiple address families and interfaces must be considered in the Control a= nd Report protocols." The Diversity bullet in the Intro begins to address this requirement and th= en a point in Section 6.2.3 dealing with consideration options in the MA go= es on to I believe suggest the recommended solution for this. I am to under= stand that the recommendation is to treat multiple address families as a mu= lti-homed device? It may also be useful to point out that a test may run in 3 different modes= : IPv4, IPv6 or dual-stack. I think it would be useful to make sure the sys= tem could measurement system could support all three with the goal that you= may want to explicitly test a certain protocol in some cases or just use w= hatever protocol is preferred in other cases when both are configured on a = device. 2) Reporting of Service Parameters by MA if available The Charter includes this sentence on the topic of Service Parameters: "How= ever, if the service parameters are available to the MAs, they could be rep= orted with the measurement results in the Report Protocol" Discovery of Service Parameters is out of scope per the Charter, but I beli= eve there has been some discussion on the list that if the MA has the infor= mation it may be included in the Reporting Protocol. It is stated as a 'cou= ld' but I think it would be useful to state this somewhere in the discussio= n of the Report Protocol. There currently is this bullet which seems to imp= ly that only the Results are to be delivered to the collector and not the S= ervice Parameters but I may be reading too much into this bullet: o a Report Protocol, which delivers a Report from the MA to a Collector. The Report contains the Measurement Results. Thanks, Jason From: , "Romascanu, Dan (Dan)" > Date: Monday, February 10, 2014 5:11 AM To: "lmap@ietf.org" > Subject: [lmap] draft-ietf-lmap-framework-03 - WGLC concluded The WGLC on draft-ietf-lmap-framework-03 is now concluded. We received a se= t of consistent reviews, thanks to all commenters, and I expect the documen= t authors to prepare responses and proposals for resolution and the WG to e= ntertain a lovely and lively discussion in London. BTW =96 if you did not have the time to review but plan to do it sometimes = soon please keep on sending these comments. Of course, the sooner, the bett= er. Thanks and Regards, Dan ________________________________ 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. --_000_CF1ECDF4269EDjasonweiltwcablecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I have a few chair comments that may already be addressed, but I will = state them here just to be sure. Overall I think  the document is= in good shape and appreciate the responses we have received in Last Call. = There are two points I do want to raise with respect to making sure the document aligns with our charter:

1) Multiple Address Family support 
The Charter states: "The LMAP archite= cture will allow for measurements that utilize either IPv4 or IPv6, or poss= ibly both. Devices containing Measurement Agents may have several interfaces using different link technologies. Mult= iple address families and interfaces must be considered in the Control and = Report protocols."

The Diversity bullet in the Intro begins to address this requirement a= nd then a point in Section 6.2.3 dealing with consideration options in the = MA goes on to I believe suggest the recommended solution for this. I am to = understand that the recommendation is to treat multiple address families as a multi-homed device? 

It may also be useful to point out that a test may run in 3 different = modes: IPv4, IPv6 or dual-stack. I think it would be useful to make sure th= e system could measurement system could support all three with the goal tha= t you may want to explicitly test a certain protocol in some cases or just use whatever protocol is preferre= d in other cases when both are configured on a device. 

2) Reporting of Service Parameters by MA if available 
The Charter includes this sentence on the topic of Service Parameters:= "However, if the service parameters are a= vailable to the MAs, they could be reported with the measurement results in the Report Protocol"

Discovery of Service Parameters is out of scope per the Charter, but I= believe there has been some discussion on the list that if the MA has the = information it may be included in the Reporting Protocol. It is stated as a= 'could' but I think it would be useful to state this somewhere in the discussion of the Report Protocol. T= here currently is this bullet which seems to imply that only the Results ar= e to be delivered to the collector and not the Service Parameters but I may= be reading too much into this bullet: 

   o  a Report Protocol, which delivers a Report from the MA to a
      Collector.  The Report contains the Measurement Results.

Thanks,

Jason


From: <Romascanu>, "Roma= scanu, Dan (Dan)" <dromasca@a= vaya.com>
Date: Monday, February 10, 2014 5:1= 1 AM
To: "lmap@ietf.org" <lmap@i= etf.org>
Subject: [lmap] draft-ietf-lmap-fra= mework-03 - WGLC concluded

The WGLC on draft-ietf-lmap-framework-03 is now conc= luded. We received a set of consistent reviews, thanks to all commenters, a= nd I expect the document authors to prepare responses and proposals for res= olution and the WG to entertain a lovely and lively discussion in London.

 

BTW =96 if you did not have the time to review but p= lan to do it sometimes soon please keep on sending these comments. Of cours= e, the sooner, the better.

 

Thanks and Regards,

 

Dan

 

 

 


This E-mail and any of its a= ttachments 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 a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_CF1ECDF4269EDjasonweiltwcablecom_-- From bs7652@att.com Tue Feb 11 06:16:15 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC111A0310 for ; Tue, 11 Feb 2014 06:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZUciyy1pD-n for ; Tue, 11 Feb 2014 06:16:13 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3350A1A032D for ; Tue, 11 Feb 2014 06:16:13 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id ca03af25.0.1629937.00-2358.4296702.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 11 Feb 2014 14:16:13 +0000 (UTC) X-MXL-Hash: 52fa30ad529a55d9-30da1694c25ca4ec0b82108f8e45b5cb88fe9c02 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1BEGCEO000383 for ; Tue, 11 Feb 2014 09:16:12 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1BEG3bn032724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Feb 2014 09:16:05 -0500 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (GAALPA1MSGHUB9A.itservices.sbc.com [130.8.36.87]) by alpi132.aldc.att.com (RSA Interceptor) for ; Tue, 11 Feb 2014 14:15:50 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 09:15:50 -0500 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: Question regarding MA and MP definitions Thread-Index: Ac8nM8OaXvGltRwsSXqfsH8CHnmK2g== Date: Tue, 11 Feb 2014 14:15:50 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.191.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=N9We4RBB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=4RmVLmWq-pUA:10 a=ofMgfj31e3cA:10 a=Flf1wRcSKQYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=Iyz1zF-eSWoA:10 a=kYKdCPbrIncQzLeWsNkA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Subject: [lmap] Question regarding MA and MP definitions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 14:16:15 -0000 Several of us have been having a very active discussion regarding nuances o= f the MA and MP definitions, and I'm curious as to what the opinions of oth= ers on the lmap list are. Regarding active measurements that involve the MA and an MP... The following sentence is in the framework: "For Active Measurement Tasks, = the MA (or Measurement Peer) generates Active Measurement Traffic...". Does this mean that it is possible for the MP to initiate the active measur= ement to the MA, or is the MA always the initiator? For example: Sometimes service providers will initiate measurement tests fr= om the access network to the service provider supplied residential gateway = (RG). Before running the test, the RG is first configured to respond to the= test appropriately.=20 If the MP can be the initiator in the lmap framework, we would still need t= o configure the MA to respond appropriately. Consistent with already-identi= fied MA functionality, we would need the Controller to know the MA is capab= le of doing this, and be able to send Instructions to properly configure th= e MA. There isn't a Measurement Schedule associated with this, and the MA d= oesn't necessarily have any results to include in a Report. Is that ok? So in the opinion of others on this list, is this scenario covered by and i= n-scope of the current framework, is it allowed but not in the current scop= e of work, or is it inconsistent with others' ideas of what MAs and MPs are= and should be capable of doing (i.e., MAs always initiate and MPs can only= respond)? Barbara From acmorton@att.com Tue Feb 11 06:28:53 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BBD1A03B4 for ; Tue, 11 Feb 2014 06:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6uG0nKBQpY8 for ; Tue, 11 Feb 2014 06:28:51 -0800 (PST) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3A21A03CC for ; Tue, 11 Feb 2014 06:28:51 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-red.research.att.com (Postfix) with ESMTP id 64626554453 for ; Tue, 11 Feb 2014 09:32:14 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-green.research.att.com (Postfix) with ESMTP id 5CF55E001E; Tue, 11 Feb 2014 09:28:00 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Tue, 11 Feb 2014 09:28:50 -0500 From: "MORTON, ALFRED C (AL)" To: "STARK, BARBARA H" , "lmap@ietf.org" Date: Tue, 11 Feb 2014 09:28:48 -0500 Thread-Topic: Question regarding MA and MP definitions Thread-Index: Ac8nM8OaXvGltRwsSXqfsH8CHnmK2gAAKPBg Message-ID: <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] Question regarding MA and MP definitions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 14:28:53 -0000 Hi Barbara, The key distinction is generate *Active measurement traffic*, which is not the same as the control messages that may be exchanged between a MA and MP. Some measurement protocols (o-o-scope for LMAP) can control a remote end-point to send back a one-way stream of active measurement traffic. The MA would initiate active measurement, telling the MP to send a one-way active measurement stream back to the receiving address/port at the MA. OWAMP can do it. If you want a device to initiate the measurement control protocol exchange, then I think that device is the MA, and right now that's the only device the Controller talks to, which is consistent. hth, Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Tuesday, February 11, 2014 9:16 AM > To: lmap@ietf.org > Subject: [lmap] Question regarding MA and MP definitions >=20 >=20 > Several of us have been having a very active discussion regarding nuances > of the MA and MP definitions, and I'm curious as to what the opinions of > others on the lmap list are. >=20 > Regarding active measurements that involve the MA and an MP... > The following sentence is in the framework: "For Active Measurement Tasks= , > the MA (or Measurement Peer) generates Active Measurement Traffic...". > Does this mean that it is possible for the MP to initiate the active > measurement to the MA, or is the MA always the initiator? > For example: Sometimes service providers will initiate measurement tests > from the access network to the service provider supplied residential > gateway (RG). Before running the test, the RG is first configured to > respond to the test appropriately. >=20 > If the MP can be the initiator in the lmap framework, we would still need > to configure the MA to respond appropriately. Consistent with already- > identified MA functionality, we would need the Controller to know the MA > is capable of doing this, and be able to send Instructions to properly > configure the MA. There isn't a Measurement Schedule associated with this= , > and the MA doesn't necessarily have any results to include in a Report. I= s > that ok? >=20 > So in the opinion of others on this list, is this scenario covered by and > in-scope of the current framework, is it allowed but not in the current > scope of work, or is it inconsistent with others' ideas of what MAs and > MPs are and should be capable of doing (i.e., MAs always initiate and MPs > can only respond)? >=20 > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From trammell@tik.ee.ethz.ch Tue Feb 11 06:36:17 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBE61A0336 for ; Tue, 11 Feb 2014 06:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gea4sCdhJXtk for ; Tue, 11 Feb 2014 06:36:14 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 20DD21A0320 for ; Tue, 11 Feb 2014 06:36:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 26354D930D; Tue, 11 Feb 2014 15:36:13 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LLjEl91oPHOp; Tue, 11 Feb 2014 15:36:12 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 961CFD9304; Tue, 11 Feb 2014 15:36:12 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_146C1703-0636-4A90-8886-3E0CB3CC8B41"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> Date: Tue, 11 Feb 2014 15:36:11 +0100 Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> To: Al Morton X-Mailer: Apple Mail (2.1827) Cc: "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] Question regarding MA and MP definitions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 14:36:18 -0000 --Apple-Mail=_146C1703-0636-4A90-8886-3E0CB3CC8B41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Barbara, Al, To take this a bit further, I think the main thing that distinguishes an = MA from the point of view of the framework is that it=92s the component = the Controller can send Instructions to. As long as sending an = Instruction to an MA causes the right thing to happen, then what happens = between the MA(s) and MP(s), how things are initiated internally and the = direction of active measurement traffic within the measurement protocol, = should to the extent possible be out of scope. On 11 Feb 2014, at 15:28, MORTON, ALFRED C (AL) = wrote: > Hi Barbara, >=20 > The key distinction is generate *Active measurement traffic*, > which is not the same as the control messages that may be > exchanged between a MA and MP. And these are (and should remain) out of scope, unless I=92ve = misunderstood something. > Some measurement protocols (o-o-scope for LMAP) can control > a remote end-point to send back a one-way stream of active > measurement traffic. The MA would initiate active measurement, > telling the MP to send a one-way active measurement stream > back to the receiving address/port at the MA. OWAMP can do it. >=20 > If you want a device to initiate the measurement control protocol > exchange, then I think that device is the MA, and right now > that's the only device the Controller talks to, which is consistent. One could certainly envision active measurement protocols where the MPs = poll active measurement control from the MAs. That=92s also consistent = with the present arrangement. Best regards, Brian > hth, > Al >=20 >> -----Original Message----- >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA = H >> Sent: Tuesday, February 11, 2014 9:16 AM >> To: lmap@ietf.org >> Subject: [lmap] Question regarding MA and MP definitions >>=20 >>=20 >> Several of us have been having a very active discussion regarding = nuances >> of the MA and MP definitions, and I'm curious as to what the opinions = of >> others on the lmap list are. >>=20 >> Regarding active measurements that involve the MA and an MP... >> The following sentence is in the framework: "For Active Measurement = Tasks, >> the MA (or Measurement Peer) generates Active Measurement = Traffic...". >> Does this mean that it is possible for the MP to initiate the active >> measurement to the MA, or is the MA always the initiator? >> For example: Sometimes service providers will initiate measurement = tests >> from the access network to the service provider supplied residential >> gateway (RG). Before running the test, the RG is first configured to >> respond to the test appropriately. >>=20 >> If the MP can be the initiator in the lmap framework, we would still = need >> to configure the MA to respond appropriately. Consistent with = already- >> identified MA functionality, we would need the Controller to know the = MA >> is capable of doing this, and be able to send Instructions to = properly >> configure the MA. There isn't a Measurement Schedule associated with = this, >> and the MA doesn't necessarily have any results to include in a = Report. Is >> that ok? >>=20 >> So in the opinion of others on this list, is this scenario covered by = and >> in-scope of the current framework, is it allowed but not in the = current >> scope of work, or is it inconsistent with others' ideas of what MAs = and >> MPs are and should be capable of doing (i.e., MAs always initiate and = MPs >> can only respond)? >>=20 >> Barbara >>=20 >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --Apple-Mail=_146C1703-0636-4A90-8886-3E0CB3CC8B41 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS+jVbAAoJENt3nsOmbNJchewH/As4yquQv1DQ2+YvBCpzO73Q BAl1wxSHTSSue1c0eY2Ppelo5Oj7TOYH7tS3tnB/4qgBC10A6uZ942NhlrqfNMbz VpEY0SZ2FCpMy+5To25efg7+JxrcAstKUEHac4Au6jPVld3f7KcdTHXQJIp7sGmq IeFI3/eHuy+u74NgMVRwWGY/lfkz0/X4GXKUkir1thv8p6WXDofnEtndOI6862wW pmDfuLdTisMnV+yznnlnHa+Hgz03M9fzplJxAFOd4xSr9o74sGWrrmwoDDeEJKAq qxKcmVLu5nS3/o3dr8drNJFUKrhyCkdkup+H+giG4ahaZSLkmcG4419AmLZSXME= =vBOh -----END PGP SIGNATURE----- --Apple-Mail=_146C1703-0636-4A90-8886-3E0CB3CC8B41-- From Michael.K.Bugenhagen@centurylink.com Tue Feb 11 06:39:50 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4ED1A0326 for ; Tue, 11 Feb 2014 06:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CejJlIMHMnav for ; Tue, 11 Feb 2014 06:39:48 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1628B1A030C for ; Tue, 11 Feb 2014 06:39:48 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1BEdjRx008048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Feb 2014 08:39:46 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id C0AD01E0067; Tue, 11 Feb 2014 07:39:40 -0700 (MST) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id A085A1E0060; Tue, 11 Feb 2014 07:39:40 -0700 (MST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1BEde63006426; Tue, 11 Feb 2014 07:39:40 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1BEddAr006417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 07:39:40 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 08:39:39 -0600 From: "Bugenhagen, Michael K" To: "'MORTON, ALFRED C (AL)'" , "'STARK, BARBARA H'" , "'lmap@ietf.org'" Thread-Topic: Question regarding MA and MP definitions Thread-Index: Ac8nM8OaXvGltRwsSXqfsH8CHnmK2gAAKPBgAABisWA= Date: Tue, 11 Feb 2014 14:39:39 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] Question regarding MA and MP definitions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 14:39:50 -0000 Barbara, My observations (until we have a list of tests from someone....) =20 Here's what I'm reading in the regulatory performance reports --- test wise= --- Both types (co-ordinated / non-coordinated) test are showing up in regulato= r reports - The first 3 aren't documented in a SDO anywhere I know of, the others are e= ither known test or documented in non-SDO locations... Non-coordinated MA tests=20 1) Multiple session TCP throughput (up and down) - with a stability factor = to cancel out burst 2) Single session TCP throughput (up and down) - with a stability factor to= cancel out burst 3) Some type of burst measurement (up and down) 4) Webpage load time=20 5) Ping response times Coordination required type MA tests 6) UDP in each direction =20 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Tuesday, February 11, 2014 8:29 AM To: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] Question regarding MA and MP definitions Hi Barbara, The key distinction is generate *Active measurement traffic*, which is not = the same as the control messages that may be exchanged between a MA and MP. Some measurement protocols (o-o-scope for LMAP) can control a remote end-po= int to send back a one-way stream of active measurement traffic. The MA wou= ld initiate active measurement, telling the MP to send a one-way active mea= surement stream back to the receiving address/port at the MA. OWAMP can do = it. If you want a device to initiate the measurement control protocol exchange,= then I think that device is the MA, and right now that's the only device t= he Controller talks to, which is consistent. hth, Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA=20 > H > Sent: Tuesday, February 11, 2014 9:16 AM > To: lmap@ietf.org > Subject: [lmap] Question regarding MA and MP definitions >=20 >=20 > Several of us have been having a very active discussion regarding=20 > nuances of the MA and MP definitions, and I'm curious as to what the=20 > opinions of others on the lmap list are. >=20 > Regarding active measurements that involve the MA and an MP... > The following sentence is in the framework: "For Active Measurement=20 > Tasks, the MA (or Measurement Peer) generates Active Measurement Traffic.= ..". > Does this mean that it is possible for the MP to initiate the active=20 > measurement to the MA, or is the MA always the initiator? > For example: Sometimes service providers will initiate measurement=20 > tests from the access network to the service provider supplied=20 > residential gateway (RG). Before running the test, the RG is first=20 > configured to respond to the test appropriately. >=20 > If the MP can be the initiator in the lmap framework, we would still=20 > need to configure the MA to respond appropriately. Consistent with=20 > already- identified MA functionality, we would need the Controller to=20 > know the MA is capable of doing this, and be able to send Instructions=20 > to properly configure the MA. There isn't a Measurement Schedule=20 > associated with this, and the MA doesn't necessarily have any results=20 > to include in a Report. Is that ok? >=20 > So in the opinion of others on this list, is this scenario covered by=20 > and in-scope of the current framework, is it allowed but not in the=20 > current scope of work, or is it inconsistent with others' ideas of=20 > what MAs and MPs are and should be capable of doing (i.e., MAs always=20 > initiate and MPs can only respond)? >=20 > Barbara >=20 > _______________________________________________ > 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 sharam.hakimi@exfo.com Tue Feb 11 06:46:48 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B7E1A0376 for ; Tue, 11 Feb 2014 06:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmDQcwWCzSbQ for ; Tue, 11 Feb 2014 06:46:45 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 3383E1A032D for ; Tue, 11 Feb 2014 06:46:45 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Feb 2014 09:46:44 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Feb 2014 09:46:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Feb 2014 09:46:44 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B232E9@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] Question regarding MA and MP definitions Thread-Index: Ac8nM8OaXvGltRwsSXqfsH8CHnmK2gAAKPBgAADPe7A= References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> From: "Sharam Hakimi" To: "MORTON, ALFRED C \(AL\)" , "STARK, BARBARA H" , X-OriginalArrivalTime: 11 Feb 2014 14:46:44.0118 (UTC) FILETIME=[1502A360:01CF2738] Subject: Re: [lmap] Question regarding MA and MP definitions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 14:46:48 -0000 That was my understanding also from the lmap text. MA is the only initiator of the test but traffic generation can be from either the MA to MP, MP to MA or MA to MP at the same time for a specific test. Thanks, Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL) Sent: Tuesday, February 11, 2014 9:29 AM To: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] Question regarding MA and MP definitions Hi Barbara, The key distinction is generate *Active measurement traffic*, which is not the same as the control messages that may be exchanged between a MA and MP. Some measurement protocols (o-o-scope for LMAP) can control a remote end-point to send back a one-way stream of active measurement traffic. The MA would initiate active measurement, telling the MP to send a one-way active measurement stream back to the receiving address/port at the MA. OWAMP can do it. If you want a device to initiate the measurement control protocol exchange, then I think that device is the MA, and right now that's the only device the Controller talks to, which is consistent. hth, Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Tuesday, February 11, 2014 9:16 AM > To: lmap@ietf.org > Subject: [lmap] Question regarding MA and MP definitions >=20 >=20 > Several of us have been having a very active discussion regarding nuances > of the MA and MP definitions, and I'm curious as to what the opinions of > others on the lmap list are. >=20 > Regarding active measurements that involve the MA and an MP... > The following sentence is in the framework: "For Active Measurement Tasks, > the MA (or Measurement Peer) generates Active Measurement Traffic...". > Does this mean that it is possible for the MP to initiate the active > measurement to the MA, or is the MA always the initiator? > For example: Sometimes service providers will initiate measurement tests > from the access network to the service provider supplied residential > gateway (RG). Before running the test, the RG is first configured to > respond to the test appropriately. >=20 > If the MP can be the initiator in the lmap framework, we would still need > to configure the MA to respond appropriately. Consistent with already- > identified MA functionality, we would need the Controller to know the MA > is capable of doing this, and be able to send Instructions to properly > configure the MA. There isn't a Measurement Schedule associated with this, > and the MA doesn't necessarily have any results to include in a Report. Is > that ok? >=20 > So in the opinion of others on this list, is this scenario covered by and > in-scope of the current framework, is it allowed but not in the current > scope of work, or is it inconsistent with others' ideas of what MAs and > MPs are and should be capable of doing (i.e., MAs always initiate and MPs > can only respond)? >=20 > Barbara >=20 > _______________________________________________ > 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 bs7652@att.com Tue Feb 11 06:47:36 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08611A0338 for ; Tue, 11 Feb 2014 06:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFIF0tpRzHpA for ; Tue, 11 Feb 2014 06:47:33 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2249C1A0332 for ; Tue, 11 Feb 2014 06:47:33 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 4083af25.0.74328.00-2389.212404.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 11 Feb 2014 14:47:33 +0000 (UTC) X-MXL-Hash: 52fa3805557e3379-c0fca1c929ca5a5e997d76b202c1e19a8915f8f0 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1BElW08002491; Tue, 11 Feb 2014 09:47:32 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1BElKAm002246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Feb 2014 09:47:24 -0500 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 11 Feb 2014 14:47:11 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 09:47:11 -0500 From: "STARK, BARBARA H" To: Brian Trammell , "MORTON JR., AL" Thread-Topic: [lmap] Question regarding MA and MP definitions Thread-Index: Ac8nM8OaXvGltRwsSXqfsH8CHnmK2gAAKPBgAAsHSIAACiyTAA== Date: Tue, 11 Feb 2014 14:47:10 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303DC58E@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.191.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Cbe/EsXl c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=G5zx4SYhz_cA:10 a=ofMgfj31e3cA:10 a=Flf1wRcSKQYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=3oxrLLzy6DcA:10 a=48vgC7mUAAAA:8 a=irJAtTIb3493rO] X-AnalysisOut: [kAU-QA:9 a=CjuIK1q_8ugA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=pYWMCOHTSpGSZcuq:21 a=ApBM-MhvG2EOwEkz:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Cc: "lmap@ietf.org" Subject: Re: [lmap] Question regarding MA and MP definitions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 14:47:36 -0000 Thank you Brian. I completely agree with what you wrote. This is my view as= well. Barbara =20 > hi Barbara, Al, >=20 > To take this a bit further, I think the main thing that distinguishes an = MA from > the point of view of the framework is that it's the component the Control= ler > can send Instructions to. As long as sending an Instruction to an MA caus= es > the right thing to happen, then what happens between the MA(s) and > MP(s), how things are initiated internally and the direction of active > measurement traffic within the measurement protocol, should to the extent > possible be out of scope. >=20 > On 11 Feb 2014, at 15:28, MORTON, ALFRED C (AL) > wrote: >=20 > > Hi Barbara, > > > > The key distinction is generate *Active measurement traffic*, which is > > not the same as the control messages that may be exchanged between a > > MA and MP. >=20 > And these are (and should remain) out of scope, unless I've misunderstood > something. >=20 > > Some measurement protocols (o-o-scope for LMAP) can control a remote > > end-point to send back a one-way stream of active measurement traffic. > > The MA would initiate active measurement, telling the MP to send a > > one-way active measurement stream back to the receiving address/port > > at the MA. OWAMP can do it. > > > > If you want a device to initiate the measurement control protocol > > exchange, then I think that device is the MA, and right now that's the > > only device the Controller talks to, which is consistent. >=20 > One could certainly envision active measurement protocols where the MPs > poll active measurement control from the MAs. That's also consistent with > the present arrangement. >=20 > Best regards, >=20 > Brian >=20 > > hth, > > Al > > > >> -----Original Message----- > >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, > BARBARA > >> H > >> Sent: Tuesday, February 11, 2014 9:16 AM > >> To: lmap@ietf.org > >> Subject: [lmap] Question regarding MA and MP definitions > >> > >> > >> Several of us have been having a very active discussion regarding > >> nuances of the MA and MP definitions, and I'm curious as to what the > >> opinions of others on the lmap list are. > >> > >> Regarding active measurements that involve the MA and an MP... > >> The following sentence is in the framework: "For Active Measurement > >> Tasks, the MA (or Measurement Peer) generates Active Measurement > Traffic...". > >> Does this mean that it is possible for the MP to initiate the active > >> measurement to the MA, or is the MA always the initiator? > >> For example: Sometimes service providers will initiate measurement > >> tests from the access network to the service provider supplied > >> residential gateway (RG). Before running the test, the RG is first > >> configured to respond to the test appropriately. > >> > >> If the MP can be the initiator in the lmap framework, we would still > >> need to configure the MA to respond appropriately. Consistent with > >> already- identified MA functionality, we would need the Controller to > >> know the MA is capable of doing this, and be able to send > >> Instructions to properly configure the MA. There isn't a Measurement > >> Schedule associated with this, and the MA doesn't necessarily have > >> any results to include in a Report. Is that ok? > >> > >> So in the opinion of others on this list, is this scenario covered by > >> and in-scope of the current framework, is it allowed but not in the > >> current scope of work, or is it inconsistent with others' ideas of > >> what MAs and MPs are and should be capable of doing (i.e., MAs always > >> initiate and MPs can only respond)? > >> > >> Barbara > >> > >> _______________________________________________ > >> 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 philip.eardley@bt.com Wed Feb 12 02:15:52 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7B11A091C for ; Wed, 12 Feb 2014 02:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hs0_LhpN_AwM for ; Wed, 12 Feb 2014 02:15:49 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 96C221A0914 for ; Wed, 12 Feb 2014 02:15:48 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 12 Feb 2014 10:15:23 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 12 Feb 2014 10:14:59 +0000 From: To: , , Date: Wed, 12 Feb 2014 10:14:58 +0000 Thread-Topic: [lmap] Question regarding MA and MP definitions Thread-Index: Ac8nM8OaXvGltRwsSXqfsH8CHnmK2gAAKPBgAAsHSIAACiyTAAAUcsBw Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <2D09D61DDFA73D4C884805CC7865E611303DC58E@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303DC58E@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] Question regarding MA and MP definitions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 10:15:52 -0000 Agree. >From this discussion, I take the lesson that us framework authors need to a= dd some more explanatory text on the lines suggested by you all phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: 11 February 2014 14:47 > To: Brian Trammell; MORTON JR., AL > Cc: lmap@ietf.org > Subject: Re: [lmap] Question regarding MA and MP definitions >=20 > Thank you Brian. I completely agree with what you wrote. This is my > view as well. > Barbara >=20 > > hi Barbara, Al, > > > > To take this a bit further, I think the main thing that distinguishes > > an MA from the point of view of the framework is that it's the > > component the Controller can send Instructions to. As long as sending > > an Instruction to an MA causes the right thing to happen, then what > > happens between the MA(s) and MP(s), how things are initiated > > internally and the direction of active measurement traffic within the > > measurement protocol, should to the extent possible be out of scope. > > > > On 11 Feb 2014, at 15:28, MORTON, ALFRED C (AL) > > wrote: > > > > > Hi Barbara, > > > > > > The key distinction is generate *Active measurement traffic*, which > > > is not the same as the control messages that may be exchanged > > > between a MA and MP. > > > > And these are (and should remain) out of scope, unless I've > > misunderstood something. > > > > > Some measurement protocols (o-o-scope for LMAP) can control a > remote > > > end-point to send back a one-way stream of active measurement > traffic. > > > The MA would initiate active measurement, telling the MP to send a > > > one-way active measurement stream back to the receiving > address/port > > > at the MA. OWAMP can do it. > > > > > > If you want a device to initiate the measurement control protocol > > > exchange, then I think that device is the MA, and right now that's > > > the only device the Controller talks to, which is consistent. > > > > One could certainly envision active measurement protocols where the > > MPs poll active measurement control from the MAs. That's also > > consistent with the present arrangement. > > > > Best regards, > > > > Brian > > > > > hth, > > > Al > > > > > >> -----Original Message----- > > >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, > > BARBARA > > >> H > > >> Sent: Tuesday, February 11, 2014 9:16 AM > > >> To: lmap@ietf.org > > >> Subject: [lmap] Question regarding MA and MP definitions > > >> > > >> > > >> Several of us have been having a very active discussion regarding > > >> nuances of the MA and MP definitions, and I'm curious as to what > > >> the opinions of others on the lmap list are. > > >> > > >> Regarding active measurements that involve the MA and an MP... > > >> The following sentence is in the framework: "For Active > Measurement > > >> Tasks, the MA (or Measurement Peer) generates Active Measurement > > Traffic...". > > >> Does this mean that it is possible for the MP to initiate the > > >> active measurement to the MA, or is the MA always the initiator? > > >> For example: Sometimes service providers will initiate measurement > > >> tests from the access network to the service provider supplied > > >> residential gateway (RG). Before running the test, the RG is first > > >> configured to respond to the test appropriately. > > >> > > >> If the MP can be the initiator in the lmap framework, we would > > >> still need to configure the MA to respond appropriately. > Consistent > > >> with > > >> already- identified MA functionality, we would need the Controller > > >> to know the MA is capable of doing this, and be able to send > > >> Instructions to properly configure the MA. There isn't a > > >> Measurement Schedule associated with this, and the MA doesn't > > >> necessarily have any results to include in a Report. Is that ok? > > >> > > >> So in the opinion of others on this list, is this scenario covered > > >> by and in-scope of the current framework, is it allowed but not in > > >> the current scope of work, or is it inconsistent with others' > ideas > > >> of what MAs and MPs are and should be capable of doing (i.e., MAs > > >> always initiate and MPs can only respond)? > > >> > > >> Barbara > > >> > > >> _______________________________________________ > > >> 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 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From ken.ko@adtran.com Wed Feb 12 06:56:59 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BC11A09B9 for ; Wed, 12 Feb 2014 06:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-mZ92h2dh5f for ; Wed, 12 Feb 2014 06:56:52 -0800 (PST) Received: from p02c11o148.mxlogic.net (p02c11o148.mxlogic.net [208.65.144.81]) by ietfa.amsl.com (Postfix) with ESMTP id A0ED11A01DA for ; Wed, 12 Feb 2014 06:56:29 -0800 (PST) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c11o148.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id d9b8bf25.2b2e7e410940.12659.00-521.31658.p02c11o148.mxlogic.net (envelope-from ); Wed, 12 Feb 2014 07:56:29 -0700 (MST) X-MXL-Hash: 52fb8b9d2ad32207-836c3fdc50309da6c6db103ffcc5faff7d5abcef Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c11o148.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id 68b8bf25.0.12379.00-353.30915.p02c11o148.mxlogic.net (envelope-from ); Wed, 12 Feb 2014 07:56:15 -0700 (MST) X-MXL-Hash: 52fb8b8f0dcb3686-0d4006da59529db9dc64a320b7af8d8c183aba1e Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0174.001; Wed, 12 Feb 2014 08:56:05 -0600 From: KEN KO To: Brian Trammell , Al Morton Thread-Topic: [lmap] Question regarding MA and MP definitions Thread-Index: Ac8nM8OaXvGltRwsSXqfsH8CHnmK2gAAKPBgAA0fuYAAJYuVIA== Date: Wed, 12 Feb 2014 14:56:05 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=ecKKic4H c=1 sm=1 a=0XgpNN2/4a34ymu16SVwsQ==:17 a] X-AnalysisOut: [=G5zx4SYhz_cA:10 a=qZHQZMT3apYA:10 a=FBzmcnhlJawA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=3oxrLLzy6DcA:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:] X-AnalysisOut: [8 a=IwwMPqpMVAgIjICiUXgA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=Hz7IrDYlS0cA:10 a=dyIs7D6KAo6ONj7T:21 a=Nz7MQL_srEM] X-AnalysisOut: [TMjof:21] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014021211); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Cc: "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] Question regarding MA and MP definitions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 14:56:59 -0000 Brian and Barbara, This is a very helpful discussion. I need to drill down into what may or ma= y not be an inconsistency below - please clarify. Brian 1: "... the main thing that distinguishes an MA from the point of vie= w of the framework is that it's the component the Controller can send Instr= uctions to. As long as sending an Instruction to an MA causes the right thi= ng to happen, then what happens between the MA(s) and MP(s), how things are= initiated internally and the direction of active measurement traffic withi= n the measurement protocol, should to the extent possible be out of scope." Brian 2: "One could certainly envision active measurement protocols where t= he MPs poll active measurement control from the MAs." Barbara: "Does this mean that it is possible for the MP to initiate the act= ive measurement to the MA, or is the MA always the initiator? For example: = Sometimes service providers will initiate measurement tests from the access= network to the service provider supplied residential gateway (RG). Before = running the test, the RG is first configured to respond to the test appropr= iately." I read Brian 1 as saying that the initiator of a Measurement Task is an MA,= because only an MA interacts with a Controller and receives an Instruction= that gets the ball rolling. Brian 2 extends that thought to what I would c= all a series of Measurement Tasks polled from an MP, but for it to be consi= stent with Brian 1 the series would still be initiated by an Instruction vi= a an MA. Barbara seems to be asking something different. An independently initiated = measurement test from the access network to an RG, if it is to be consisten= t with Brian 1, should be traceable back to an Instruction to an MA. That's= fine if the access network source is acting as MA, but I wouldn't phrase i= t as coming from an MP (no Controller, no Instruction) to an MA, at least n= ot as I read Brian's interpretation. And if the network source is acting as= MA, I would refer the RG as acting in the role of MP. I think lmap can define this consistent with what Brian said or with what B= arbara said, but not both. I also view the current wording in lmap to be co= nsistent with Brian's statements. Looking forward to your responses, Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell Sent: Tuesday, February 11, 2014 9:36 AM To: Al Morton Cc: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] Question regarding MA and MP definitions hi Barbara, Al, To take this a bit further, I think the main thing that distinguishes an MA= from the point of view of the framework is that it's the component the Con= troller can send Instructions to. As long as sending an Instruction to an M= A causes the right thing to happen, then what happens between the MA(s) and= MP(s), how things are initiated internally and the direction of active mea= surement traffic within the measurement protocol, should to the extent poss= ible be out of scope. On 11 Feb 2014, at 15:28, MORTON, ALFRED C (AL) wrote: > Hi Barbara, >=20 > The key distinction is generate *Active measurement traffic*, which is=20 > not the same as the control messages that may be exchanged between a=20 > MA and MP. And these are (and should remain) out of scope, unless I've misunderstood s= omething. > Some measurement protocols (o-o-scope for LMAP) can control a remote=20 > end-point to send back a one-way stream of active measurement traffic.=20 > The MA would initiate active measurement, telling the MP to send a=20 > one-way active measurement stream back to the receiving address/port=20 > at the MA. OWAMP can do it. >=20 > If you want a device to initiate the measurement control protocol=20 > exchange, then I think that device is the MA, and right now that's the=20 > only device the Controller talks to, which is consistent. One could certainly envision active measurement protocols where the MPs pol= l active measurement control from the MAs. That's also consistent with the = present arrangement. Best regards, Brian > hth, > Al >=20 >> -----Original Message----- >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA=20 >> H >> Sent: Tuesday, February 11, 2014 9:16 AM >> To: lmap@ietf.org >> Subject: [lmap] Question regarding MA and MP definitions >>=20 >>=20 >> Several of us have been having a very active discussion regarding=20 >> nuances of the MA and MP definitions, and I'm curious as to what the=20 >> opinions of others on the lmap list are. >>=20 >> Regarding active measurements that involve the MA and an MP... >> The following sentence is in the framework: "For Active Measurement=20 >> Tasks, the MA (or Measurement Peer) generates Active Measurement Traffic= ...". >> Does this mean that it is possible for the MP to initiate the active=20 >> measurement to the MA, or is the MA always the initiator? >> For example: Sometimes service providers will initiate measurement=20 >> tests from the access network to the service provider supplied=20 >> residential gateway (RG). Before running the test, the RG is first=20 >> configured to respond to the test appropriately. >>=20 >> If the MP can be the initiator in the lmap framework, we would still=20 >> need to configure the MA to respond appropriately. Consistent with=20 >> already- identified MA functionality, we would need the Controller to=20 >> know the MA is capable of doing this, and be able to send=20 >> Instructions to properly configure the MA. There isn't a Measurement=20 >> Schedule associated with this, and the MA doesn't necessarily have=20 >> any results to include in a Report. Is that ok? >>=20 >> So in the opinion of others on this list, is this scenario covered by=20 >> and in-scope of the current framework, is it allowed but not in the=20 >> current scope of work, or is it inconsistent with others' ideas of=20 >> what MAs and MPs are and should be capable of doing (i.e., MAs always=20 >> initiate and MPs can only respond)? >>=20 >> Barbara >>=20 >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From trammell@tik.ee.ethz.ch Wed Feb 12 07:56:57 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984851A09B9 for ; Wed, 12 Feb 2014 07:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5279gSQzyQjv for ; Wed, 12 Feb 2014 07:56:54 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B66FD1A0545 for ; Wed, 12 Feb 2014 07:56:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4AC14D9309; Wed, 12 Feb 2014 16:56:52 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6p+XRyzLPT9C; Wed, 12 Feb 2014 16:56:52 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 6FA68D9303; Wed, 12 Feb 2014 16:56:51 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_C6515062-30E1-486E-964B-FC7AA08B3C76"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: Date: Wed, 12 Feb 2014 16:56:50 +0100 Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> To: KEN KO X-Mailer: Apple Mail (2.1827) Cc: "lmap@ietf.org" , Al Morton , "STARK, BARBARA H" Subject: Re: [lmap] Question regarding MA and MP definitions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 15:56:57 -0000 --Apple-Mail=_C6515062-30E1-486E-964B-FC7AA08B3C76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Ken, all, On 12 Feb 2014, at 15:56, KEN KO wrote: > Brian and Barbara, >=20 > This is a very helpful discussion. I need to drill down into what may = or may not be an inconsistency below - please clarify. >=20 > Brian 1: "... the main thing that distinguishes an MA from the point = of view of the framework is that it's the component the Controller can = send Instructions to. As long as sending an Instruction to an MA causes = the right thing to happen, then what happens between the MA(s) and = MP(s), how things are initiated internally and the direction of active = measurement traffic within the measurement protocol, should to the = extent possible be out of scope." >=20 > Brian 2: "One could certainly envision active measurement protocols = where the MPs poll active measurement control from the MAs.=94 To clarify: I mentioned polling here only as an example. The point is = that the MA-MP relationship is completely out of the scope of LMAP=92s = control protocol. > Barbara: "Does this mean that it is possible for the MP to initiate = the active measurement to the MA, or is the MA always the initiator? For = example: Sometimes service providers will initiate measurement tests = from the access network to the service provider supplied residential = gateway (RG). Before running the test, the RG is first configured to = respond to the test appropriately.=94 Reading this, I presumed that the RG is an MP in this context, and that = the RG is configured to become an MP out of band; i.e. by the time the = Instruction is sent to the (central) MA, the MP is (from LMAP=92s point = of view) =93magically ready=94. > I read Brian 1 as saying that the initiator of a Measurement Task is = an MA, because only an MA interacts with a Controller and receives an = Instruction that gets the ball rolling. Brian 2 extends that thought to = what I would call a series of Measurement Tasks polled from an MP, but = for it to be consistent with Brian 1 the series would still be initiated = by an Instruction via an MA. I=92d prefer the word =93instigated=94 or =93enabled", because = =93initiated=94 to me implies that it opens a connection or sends the = first packet in an exchange or similar, which is not necessarily the = case. But this seems like getting down into terminological weeds, so = I=92ll stop. :) > Barbara seems to be asking something different. An independently = initiated measurement test from the access network to an RG, if it is to = be consistent with Brian 1, should be traceable back to an Instruction = to an MA. That's fine if the access network source is acting as MA, but = I wouldn't phrase it as coming from an MP (no Controller, no = Instruction) to an MA, at least not as I read Brian's interpretation. = And if the network source is acting as MA, I would refer the RG as = acting in the role of MP. This (final sentence) is how I understood what Barbara said. Cheers, Brian > I think lmap can define this consistent with what Brian said or with = what Barbara said, but not both. I also view the current wording in lmap = to be consistent with Brian's statements. >=20 > Looking forward to your responses, > Ken >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Tuesday, February 11, 2014 9:36 AM > To: Al Morton > Cc: STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] Question regarding MA and MP definitions >=20 > hi Barbara, Al, >=20 > To take this a bit further, I think the main thing that distinguishes = an MA from the point of view of the framework is that it's the component = the Controller can send Instructions to. As long as sending an = Instruction to an MA causes the right thing to happen, then what happens = between the MA(s) and MP(s), how things are initiated internally and the = direction of active measurement traffic within the measurement protocol, = should to the extent possible be out of scope. >=20 > On 11 Feb 2014, at 15:28, MORTON, ALFRED C (AL) = wrote: >=20 >> Hi Barbara, >>=20 >> The key distinction is generate *Active measurement traffic*, which = is=20 >> not the same as the control messages that may be exchanged between a=20= >> MA and MP. >=20 > And these are (and should remain) out of scope, unless I've = misunderstood something. >=20 >> Some measurement protocols (o-o-scope for LMAP) can control a remote=20= >> end-point to send back a one-way stream of active measurement = traffic.=20 >> The MA would initiate active measurement, telling the MP to send a=20 >> one-way active measurement stream back to the receiving address/port=20= >> at the MA. OWAMP can do it. >>=20 >> If you want a device to initiate the measurement control protocol=20 >> exchange, then I think that device is the MA, and right now that's = the=20 >> only device the Controller talks to, which is consistent. >=20 > One could certainly envision active measurement protocols where the = MPs poll active measurement control from the MAs. That's also consistent = with the present arrangement. >=20 > Best regards, >=20 > Brian >=20 >> hth, >> Al >>=20 >>> -----Original Message----- >>> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, = BARBARA=20 >>> H >>> Sent: Tuesday, February 11, 2014 9:16 AM >>> To: lmap@ietf.org >>> Subject: [lmap] Question regarding MA and MP definitions >>>=20 >>>=20 >>> Several of us have been having a very active discussion regarding=20 >>> nuances of the MA and MP definitions, and I'm curious as to what the=20= >>> opinions of others on the lmap list are. >>>=20 >>> Regarding active measurements that involve the MA and an MP... >>> The following sentence is in the framework: "For Active Measurement=20= >>> Tasks, the MA (or Measurement Peer) generates Active Measurement = Traffic...". >>> Does this mean that it is possible for the MP to initiate the active=20= >>> measurement to the MA, or is the MA always the initiator? >>> For example: Sometimes service providers will initiate measurement=20= >>> tests from the access network to the service provider supplied=20 >>> residential gateway (RG). Before running the test, the RG is first=20= >>> configured to respond to the test appropriately. >>>=20 >>> If the MP can be the initiator in the lmap framework, we would still=20= >>> need to configure the MA to respond appropriately. Consistent with=20= >>> already- identified MA functionality, we would need the Controller = to=20 >>> know the MA is capable of doing this, and be able to send=20 >>> Instructions to properly configure the MA. There isn't a Measurement=20= >>> Schedule associated with this, and the MA doesn't necessarily have=20= >>> any results to include in a Report. Is that ok? >>>=20 >>> So in the opinion of others on this list, is this scenario covered = by=20 >>> and in-scope of the current framework, is it allowed but not in the=20= >>> current scope of work, or is it inconsistent with others' ideas of=20= >>> what MAs and MPs are and should be capable of doing (i.e., MAs = always=20 >>> initiate and MPs can only respond)? >>>=20 >>> Barbara >>>=20 >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap >>=20 >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --Apple-Mail=_C6515062-30E1-486E-964B-FC7AA08B3C76 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS+5nCAAoJENt3nsOmbNJcDkgIAMf8oOcRtvdbTg2T4CZaQMnZ JpIFkGj8y+PvnpJfOiKwvesR8b72WoQ91WCGoXx7Xcr9hM3+RDB1q65AylsPVH9E M0YOm34acgKd+Qlh+8WZk+itdVgZYI/IdAAv5XEWDm+i3561o8hooM+kuXHlKJFn mMREnLBjuH6dRw3ho7VQBJxhEudfYA+jbwdcfZdE8yG65iqfDSZNUFUCCDuL4R5W BvhTMnzVPuheQobiTKcpIAD75TNj0m/4gDkHSsH8EZ9Wspqe0P1P58KiWD8kUT8X tpQPUBuZG1+xYOLcPnuKzBCJLa/HxKtOT/mkjIkt5TFhdcNZOoVgUeWQSt1HzbE= =/Axu -----END PGP SIGNATURE----- --Apple-Mail=_C6515062-30E1-486E-964B-FC7AA08B3C76-- From ken.ko@adtran.com Wed Feb 12 08:28:24 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4E21A05D5 for ; Wed, 12 Feb 2014 08:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75Zq1d2KDV60 for ; Wed, 12 Feb 2014 08:28:20 -0800 (PST) Received: from p02c11o149.mxlogic.net (p02c11o149.mxlogic.net [208.65.144.82]) by ietfa.amsl.com (Postfix) with ESMTP id CD4491A0310 for ; Wed, 12 Feb 2014 08:28:18 -0800 (PST) Received: from unknown [76.164.174.83] (EHLO p02c11o149.mxlogic.net) by p02c11o149.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 221abf25.2afd1ae4a940.61612.00-577.158491.p02c11o149.mxlogic.net (envelope-from ); Wed, 12 Feb 2014 09:28:18 -0700 (MST) X-MXL-Hash: 52fba1222eeb1052-7f0ab953687a7433e01beff6231fe06c70bfa805 Received: from unknown [76.164.174.83] by p02c11o149.mxlogic.net(mxl_mta-7.2.4-1) with SMTP id e80abf25.0.59681.00-343.153124.p02c11o149.mxlogic.net (envelope-from ); Wed, 12 Feb 2014 09:26:06 -0700 (MST) X-MXL-Hash: 52fba09e00371cfd-a4c6dc0cdf0e5070a1e202826b4244356d28123e Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0174.001; Wed, 12 Feb 2014 10:25:49 -0600 From: KEN KO To: Brian Trammell Thread-Topic: [lmap] Question regarding MA and MP definitions Thread-Index: Ac8nM8OaXvGltRwsSXqfsH8CHnmK2gAAKPBgAA0fuYAAJYuVIAAPkBYAAAw+87A= Date: Wed, 12 Feb 2014 16:25:48 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=SbFAgItu c=1 sm=1 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a] X-AnalysisOut: [=G5zx4SYhz_cA:10 a=qZHQZMT3apYA:10 a=FBzmcnhlJawA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=3oxrLLzy6DcA:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:] X-AnalysisOut: [8 a=v9jzeHeBptADCSmMnzUA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=DvnSUQUdWHYA:10 a=Hz7IrDYlS0cA:10 a=-_iUXe4jRGJF_br] X-AnalysisOut: [I:21 a=OvD61LYtiPDteHxn:21] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014021212); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Cc: "lmap@ietf.org" , Al Morton , "STARK, BARBARA H" Subject: Re: [lmap] Question regarding MA and MP definitions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 16:28:24 -0000 Brian, thanks. Following up below. Ken > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Wednesday, February 12, 2014 10:57 AM > To: KEN KO > Cc: Al Morton; STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] Question regarding MA and MP definitions >=20 > hi Ken, all, >=20 > On 12 Feb 2014, at 15:56, KEN KO wrote: >=20 > > Brian and Barbara, > > > > This is a very helpful discussion. I need to drill down into what may o= r may > not be an inconsistency below - please clarify. > > > > Brian 1: "... the main thing that distinguishes an MA from the point of= view > of the framework is that it's the component the Controller can send > Instructions to. As long as sending an Instruction to an MA causes the ri= ght > thing to happen, then what happens between the MA(s) and MP(s), how > things are initiated internally and the direction of active measurement t= raffic > within the measurement protocol, should to the extent possible be out of > scope." > > > > Brian 2: "One could certainly envision active measurement protocols whe= re > the MPs poll active measurement control from the MAs." >=20 > To clarify: I mentioned polling here only as an example. The point is tha= t the > MA-MP relationship is completely out of the scope of LMAP's control > protocol. Understood that polling is an example. But is my focus on the phrase "As lo= ng as sending an Instruction to an MA causes the right thing to happen, ...= " appropriate or misguided? My understanding of your comments is that withi= n the scope of lmap, it is the Instruction sent to the MA that instigates/e= nables measurement activity. And by that reasoning, measurement activity in= stigated/enabled within the access network means that lmap would refer to t= hat endpoint as the MA and to the RG as the MP, at least within the context= of that activity. The reason I'm harping on this is that I think Barbara (Barbara, I know you= 'll correct me if I'm wrong) is asking about a perspective in which the def= inition of MA is independent of where measurement activity is instigated/en= abled - "... it is possible for the MP to initiate the active measurement t= o the MA ...". That's a valid perspective but I'm not sure whether it is ho= w you are interpreting the draft. >=20 > > Barbara: "Does this mean that it is possible for the MP to initiate the= active > measurement to the MA, or is the MA always the initiator? For example: > Sometimes service providers will initiate measurement tests from the acce= ss > network to the service provider supplied residential gateway (RG). Before > running the test, the RG is first configured to respond to the test > appropriately." >=20 > Reading this, I presumed that the RG is an MP in this context, and that t= he RG > is configured to become an MP out of band; i.e. by the time the Instructi= on is > sent to the (central) MA, the MP is (from LMAP's point of view) "magicall= y > ready". >=20 > > I read Brian 1 as saying that the initiator of a Measurement Task is an= MA, > because only an MA interacts with a Controller and receives an Instructio= n > that gets the ball rolling. Brian 2 extends that thought to what I would = call a > series of Measurement Tasks polled from an MP, but for it to be consisten= t > with Brian 1 the series would still be initiated by an Instruction via an= MA. >=20 > I'd prefer the word "instigated" or "enabled", because "initiated" to me > implies that it opens a connection or sends the first packet in an exchan= ge or > similar, which is not necessarily the case. But this seems like getting d= own > into terminological weeds, so I'll stop. :) >=20 > > Barbara seems to be asking something different. An independently > initiated measurement test from the access network to an RG, if it is to = be > consistent with Brian 1, should be traceable back to an Instruction to an= MA. > That's fine if the access network source is acting as MA, but I wouldn't = phrase > it as coming from an MP (no Controller, no Instruction) to an MA, at leas= t not > as I read Brian's interpretation. And if the network source is acting as = MA, I > would refer the RG as acting in the role of MP. >=20 > This (final sentence) is how I understood what Barbara said. >=20 > Cheers, >=20 > Brian >=20 > > I think lmap can define this consistent with what Brian said or with wh= at > Barbara said, but not both. I also view the current wording in lmap to be > consistent with Brian's statements. > > > > Looking forward to your responses, > > Ken > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell > > Sent: Tuesday, February 11, 2014 9:36 AM > > To: Al Morton > > Cc: STARK, BARBARA H; lmap@ietf.org > > Subject: Re: [lmap] Question regarding MA and MP definitions > > > > hi Barbara, Al, > > > > To take this a bit further, I think the main thing that distinguishes a= n MA > from the point of view of the framework is that it's the component the > Controller can send Instructions to. As long as sending an Instruction to= an > MA causes the right thing to happen, then what happens between the > MA(s) and MP(s), how things are initiated internally and the direction of > active measurement traffic within the measurement protocol, should to the > extent possible be out of scope. > > > > On 11 Feb 2014, at 15:28, MORTON, ALFRED C (AL) > wrote: > > > >> Hi Barbara, > >> > >> The key distinction is generate *Active measurement traffic*, which > >> is not the same as the control messages that may be exchanged between > >> a MA and MP. > > > > And these are (and should remain) out of scope, unless I've misundersto= od > something. > > > >> Some measurement protocols (o-o-scope for LMAP) can control a remote > >> end-point to send back a one-way stream of active measurement traffic. > >> The MA would initiate active measurement, telling the MP to send a > >> one-way active measurement stream back to the receiving address/port > >> at the MA. OWAMP can do it. > >> > >> If you want a device to initiate the measurement control protocol > >> exchange, then I think that device is the MA, and right now that's > >> the only device the Controller talks to, which is consistent. > > > > One could certainly envision active measurement protocols where the MPs > poll active measurement control from the MAs. That's also consistent with > the present arrangement. > > > > Best regards, > > > > Brian > > > >> hth, > >> Al > >> > >>> -----Original Message----- > >>> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, > >>> BARBARA H > >>> Sent: Tuesday, February 11, 2014 9:16 AM > >>> To: lmap@ietf.org > >>> Subject: [lmap] Question regarding MA and MP definitions > >>> > >>> > >>> Several of us have been having a very active discussion regarding > >>> nuances of the MA and MP definitions, and I'm curious as to what the > >>> opinions of others on the lmap list are. > >>> > >>> Regarding active measurements that involve the MA and an MP... > >>> The following sentence is in the framework: "For Active Measurement > >>> Tasks, the MA (or Measurement Peer) generates Active Measurement > Traffic...". > >>> Does this mean that it is possible for the MP to initiate the active > >>> measurement to the MA, or is the MA always the initiator? > >>> For example: Sometimes service providers will initiate measurement > >>> tests from the access network to the service provider supplied > >>> residential gateway (RG). Before running the test, the RG is first > >>> configured to respond to the test appropriately. > >>> > >>> If the MP can be the initiator in the lmap framework, we would still > >>> need to configure the MA to respond appropriately. Consistent with > >>> already- identified MA functionality, we would need the Controller > >>> to know the MA is capable of doing this, and be able to send > >>> Instructions to properly configure the MA. There isn't a Measurement > >>> Schedule associated with this, and the MA doesn't necessarily have > >>> any results to include in a Report. Is that ok? > >>> > >>> So in the opinion of others on this list, is this scenario covered > >>> by and in-scope of the current framework, is it allowed but not in > >>> the current scope of work, or is it inconsistent with others' ideas > >>> of what MAs and MPs are and should be capable of doing (i.e., MAs > >>> always initiate and MPs can only respond)? > >>> > >>> Barbara > >>> > >>> _______________________________________________ > >>> 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 charles.cook2@centurylink.com Wed Feb 12 16:41:50 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676F61A0054 for ; Wed, 12 Feb 2014 16:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riDdztG1Ggyb for ; Wed, 12 Feb 2014 16:41:47 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 5608F1A0047 for ; Wed, 12 Feb 2014 16:41:47 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1D0fe9n029338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Feb 2014 17:41:41 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id B616A1E0076; Wed, 12 Feb 2014 18:41:35 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 9FEBC1E0074; Wed, 12 Feb 2014 18:41:35 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1D0fZ6H022388; Wed, 12 Feb 2014 18:41:35 -0600 (CST) Received: from [10.183.212.222] (X1069818.dhcp.intranet [10.183.212.222]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1D0fXpX022365; Wed, 12 Feb 2014 18:41:34 -0600 (CST) Message-ID: <52FC14BD.8040403@centurylink.com> Date: Wed, 12 Feb 2014 17:41:33 -0700 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: KEN KO References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------010505020701070008070904" X-CFilter-Loop: Reflected Cc: "STARK, BARBARA H" , "lmap@ietf.org" , Al Morton , Brian Trammell Subject: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: charles.cook2@centurylink.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 00:41:50 -0000 This is a multi-part message in MIME format. --------------010505020701070008070904 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This should generate some discussion. Here is my crack at an MA vs MP comparison. Note that in doing this comparison, I made the assumption that in addition to the MA registering with the Controller, an MP also needs to be made known to the Controller so that the Controller can take into consideration the capabilities of the MP in constructing Measurement Tasks. This also makes it possible for the Controller to suppress MPs. Red text highlight differences between MAs and MPs. Device Functionality --May have MA, MP, or both MA and MP functionality MA Functionality --Registers with a Controller --Receives Instructions from a Controller --Contacts a MP to execute Measurement Tasks --Performs access control (if needed) with the MP --Can either transmit or receive active measurement traffic (depending on the Measurement Task) --Must honor reception of suppression messages from a Controller --May run certain tests against non-LMAP compliant targets (e.g., ping a content server) MP Functionality --Registers with a Controller --Does _not_receive Instructions from a Controller --Responds to Measurement Task directed to it from an MA (MP does _not_initiate contact with MA) --Performs access control (if needed) with the MA --Can either transmit or receive active measurement traffic (depending on the Measurement Task) --Must honor reception of suppression messages from a Controller Charles -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com --------------010505020701070008070904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This should generate some discussion.

Here is my crack at an MA vs MP comparison.  Note that in doing this comparison, I made the assumption that in addition to the MA registering with the Controller, an MP also needs to be made known to the Controller so that the Controller can take into consideration the capabilities of the MP in constructing Measurement Tasks.  This also makes it possible for the Controller to suppress MPs.  Red text highlight differences between MAs and MPs.

Device Functionality
–May have MA, MP, or both MA and MP functionality
MA Functionality
–Registers with a Controller
–Receives Instructions from a Controller
–Contacts a MP to execute Measurement Tasks
–Performs access control (if needed) with the MP
–Can either transmit or receive active measurement traffic (depending on the Measurement Task)
–Must honor reception of suppression messages from a Controller
–May run certain tests against non-LMAP compliant targets (e.g., ping a content server)
MP Functionality
–Registers with a Controller
–Does not receive Instructions from a Controller
–Responds to Measurement Task directed to it from an MA (MP does not initiate contact with MA)
–Performs access control (if needed) with the MA
–Can either transmit or receive active measurement traffic (depending on the Measurement Task)
–Must honor reception of suppression messages from a Controller

Charles
-- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
charles.cook2@centurylink.com
--------------010505020701070008070904-- From acmorton@att.com Wed Feb 12 19:16:59 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B2D1A00AB for ; Wed, 12 Feb 2014 19:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4cKWYq4wr_U for ; Wed, 12 Feb 2014 19:16:56 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2471A0028 for ; Wed, 12 Feb 2014 19:16:56 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id D46721204EF; Wed, 12 Feb 2014 22:20:14 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-green.research.att.com (Postfix) with ESMTP id ADBE3E0365; Wed, 12 Feb 2014 22:16:03 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Wed, 12 Feb 2014 22:16:54 -0500 From: "MORTON, ALFRED C (AL)" To: "charles.cook2@centurylink.com" , KEN KO Date: Wed, 12 Feb 2014 22:16:53 -0500 Thread-Topic: MA vs MP Thread-Index: Ac8oVGbdNu5CaBKaQpyjp5BY0TEkLQAFNL+g Message-ID: <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> In-Reply-To: <52FC14BD.8040403@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8BC23F39Cnjfpsrvexg8rese_" MIME-Version: 1.0 Cc: "lmap@ietf.org" , "STARK, BARBARA H" , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 03:16:59 -0000 --_000_2845723087023D4CB5114223779FA9C8BC23F39Cnjfpsrvexg8rese_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Charles, * MP Functionality - Registers with a Controller Not necessary, if I understand what you mean by registration (as MP to Cont= roller communication) - Controller can get a list of MP and capabilities through other means. I think this is worth clarifying in the text. Also, I don't see the MP as a recipient of Suppression message from Control= ler, especially if there's no communications planned between them. Al From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Wednesday, February 12, 2014 7:42 PM To: KEN KO Cc: Brian Trammell; lmap@ietf.org; MORTON, ALFRED C (AL); STARK, BARBARA H Subject: MA vs MP This should generate some discussion. Here is my crack at an MA vs MP comparison. Note that in doing this compar= ison, I made the assumption that in addition to the MA registering with the= Controller, an MP also needs to be made known to the Controller so that th= e Controller can take into consideration the capabilities of the MP in cons= tructing Measurement Tasks. This also makes it possible for the Controller= to suppress MPs. Red text highlight differences between MAs and MPs. * Device Functionality - May have MA, MP, or both MA and MP functionality * MA Functionality - Registers with a Controller - Receives Instructions from a Controller - Contacts a MP to execute Measurement Tasks - Performs access control (if needed) with the MP - Can either transmit or receive active measurement traffic (dependi= ng on the Measurement Task) - Must honor reception of suppression messages from a Controller - May run certain tests against non-LMAP compliant targets (e.g., pi= ng a content server) * MP Functionality - Registers with a Controller - Does not receive Instructions from a Controller - Responds to Measurement Task directed to it from an MA (MP does no= t initiate contact with MA) - Performs access control (if needed) with the MA - Can either transmit or receive active measurement traffic (dependi= ng on the Measurement Task) - Must honor reception of suppression messages from a Controller Charles -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com --_000_2845723087023D4CB5114223779FA9C8BC23F39Cnjfpsrvexg8rese_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Charles,

 

·        = MP Functionality

–        Register= s with a Controller<= /p>

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:windowtext'>= Not necessary, if I understand what you mean by registration (as MP to Cont= roller communication)

- Control= ler can get a list of MP and capabilities through other means.

 

I think this is worth clarifying in the text. 

 

especially if there's no = communications planned between them.

Al

 =

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:wind= owtext'> Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: Wednesday, February 12, 2014 7:42 PM
To: KEN KO
Cc: = Brian Trammell; lmap@ietf.org; MORTON, ALFRED C (AL); STARK, BARBARA H
<= b>Subject: MA vs MP

 

This should generate some discussion.

Here is my crack at an MA vs = MP comparison.  Note that in doing this comparison, I made the assumpt= ion that in addition to the MA registering with the Controller, an MP also = needs to be made known to the Controller so that the Controller can take in= to consideration the capabilities of the MP in constructing Measurement Tas= ks.  This also makes it possible for the Controller to suppress MPs.&n= bsp; Red text highlight differences between MAs and MPs.

· = ;        = Device Fu= nctionality

R= 11;    &nb= sp;   May have MA, MP, or both MA and MP functionality

·   = ;      MA Functionality

=

–       = ; Registers with a Controller

=

–       = ; Receives Instructions from a Controller

–=      =    Contacts a MP to execute Measurement Tasks

<= ![if !supportLists]>–  &nbs= p;     Performs access control (if needed) with th= e MP

–Can either transmit or r= eceive active measurement traffic (depending on the Measurement Task)

– &= nbsp;      Must honor reception of suppressio= n messages from a Controller

–        May run certain tests against non-LMAP compliant targets (e.g., ping a con= tent server)

·         MP = Functionality

&#= 8211;    &= nbsp;   Registers with a Controller

= 211;    &n= bsp;   Does not receive Instructions from a Controlle= r

–=         <= span style=3D'font-family:"Arial","sans-serif"'>Responds to Measurement Tas= k directed to it from an MA (MP does not initiate contact with MA)

–   &= nbsp;    Performs access control (if needed) with the M= A

–=         <= span style=3D'font-family:"Arial","sans-serif"'>Can either transmit or rece= ive active measurement traffic (depending on the Measurement Task)

– &nbs= p;      Must honor reception of suppression m= essages from a Controller


Charles

=
-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  8=
0221
Tel:  303.992.8952  Fax:  925.281.=
0662
=
charles.cook2@centurylink.com
= --_000_2845723087023D4CB5114223779FA9C8BC23F39Cnjfpsrvexg8rese_-- From philip.eardley@bt.com Thu Feb 13 02:09:08 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3076E1A0123 for ; Thu, 13 Feb 2014 02:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yISMQuWdQgE for ; Thu, 13 Feb 2014 02:09:01 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id CDE281A011C for ; Thu, 13 Feb 2014 02:09:00 -0800 (PST) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 13 Feb 2014 10:08:30 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Thu, 13 Feb 2014 10:08:36 +0000 From: To: , , Date: Thu, 13 Feb 2014 10:08:35 +0000 Thread-Topic: MA vs MP Thread-Index: Ac8oVGbdNu5CaBKaQpyjp5BY0TEkLQAFNL+gAA4eYLA= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABE62FEMV67UKRDdoma_" MIME-Version: 1.0 Cc: trammell@tik.ee.ethz.ch, bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:09:08 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABE62FEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree with Al. Suppression is part of the Instruction. The Instruction is the set of measu= rement methods, schedules and perhaps suppression information which the Con= troller tells the MA. if the controller was telling the MP about suppressio= n, then it would be sending it an instruction I don't think sending a suppress to the MP is really needed. Suppress is (mainly) about not starting new Tasks. Since the MA starts the = Task (potentially with a control msg to the MP asking it to start sending a= file, say) then it doesn't help to tell the MP. It's also been suggested to add to the current suppression description an o= ption meaning "also stop Tasks that are in progress" (I am happy to add thi= s as an option) (option =3D optional to use). I think it's Task specific ho= w this would be done. For instance for a TCP file download from the MP to M= A, the MA can end the TCP connection. Similarly, I don't see the need for the MP to register with the controller. Side note: often the same device will have both MA and MP functionality. Th= en there may well be the possibility of doing something clever. Don't think= we should work on that in lmap1.0 phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: 13 February 2014 03:17 To: charles.cook2@centurylink.com; KEN KO Cc: lmap@ietf.org; STARK, BARBARA H; Brian Trammell Subject: Re: [lmap] MA vs MP Charles, * MP Functionality - Registers with a Controller Not necessary, if I understand what you mean by registration (as MP to Cont= roller communication) - Controller can get a list of MP and capabilities through other means. I think this is worth clarifying in the text. Also, I don't see the MP as a recipient of Suppression message from Control= ler, especially if there's no communications planned between them. Al From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Wednesday, February 12, 2014 7:42 PM To: KEN KO Cc: Brian Trammell; lmap@ietf.org; MORTON, ALFRED C (= AL); STARK, BARBARA H Subject: MA vs MP This should generate some discussion. Here is my crack at an MA vs MP comparison. Note that in doing this compar= ison, I made the assumption that in addition to the MA registering with the= Controller, an MP also needs to be made known to the Controller so that th= e Controller can take into consideration the capabilities of the MP in cons= tructing Measurement Tasks. This also makes it possible for the Controller= to suppress MPs. Red text highlight differences between MAs and MPs. * Device Functionality - May have MA, MP, or both MA and MP functionality * MA Functionality - Registers with a Controller - Receives Instructions from a Controller - Contacts a MP to execute Measurement Tasks - Performs access control (if needed) with the MP - Can either transmit or receive active measurement traffic (dependi= ng on the Measurement Task) - Must honor reception of suppression messages from a Controller - May run certain tests against non-LMAP compliant targets (e.g., pi= ng a content server) * MP Functionality - Registers with a Controller - Does not receive Instructions from a Controller - Responds to Measurement Task directed to it from an MA (MP does no= t initiate contact with MA) - Performs access control (if needed) with the MA - Can either transmit or receive active measurement traffic (dependi= ng on the Measurement Task) - Must honor reception of suppression messages from a Controller Charles -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABE62FEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Agree with Al. =

Suppression is part of the Instruction. The Ins= truction is the set of measurement methods, schedules and perhaps suppressi= on information which the Controller tells the MA. if the controller was tel= ling the MP about suppression, then it would be sending it an instruction

 

= I don’t t= hink sending a suppress to the MP is really needed.

<= p class=3DMsoNormal>Suppress is (mainly) about not starting new Tasks. Since the MA starts= the Task (potentially with a control msg to the MP asking it to start send= ing a file, say) then it doesn’t help to tell the MP.

 

It’s also been suggeste= d to add to the current suppression description an option meaning “al= so stop Tasks that are in progress” (I am happy to add this as an opt= ion) (option =3D optional to use). I think it’s Task specific how thi= s would be done. For instance for a TCP file download from the MP to MA, th= e MA can end the TCP connection.

 

Similarly, I don’t see the need for the MP to reg= ister with the controller.

 

Side note: often the same device will have both MA and MP func= tionality. Then there may well be the possibility of doing something clever= . Don’t think we should work on that in lmap1.0

=

 

phil

 

From: lmap [mailto:lmap-= bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL)
Sent:= 13 February 2014 03:17
To: charles.cook2@centurylink.com; KEN KO=
Cc: lmap@ietf.org; STARK, BARBARA H; Brian Trammell
Subjec= t: Re: [lmap] MA vs MP

 

Charles,=

 

·     MP Functionality

–  &= nbsp;  Registers with a Controller

 

Not necessary, if I understand what you mean by registration (as MP to = Controller communication)

- Controller can get a list of MP and capabilities through other mea= ns.

 

I think this is worth clari= fying in the text. 

 

Also,= I don't see the MP as a recipient of Suppression message from Controller,<= o:p>

especially if there= 's no communications planned between them.

Al

 

From: Charles = Cook [mailto:charles.cook2= @centurylink.com]
Sent: Wednesday, February 12, 2014 7:42 PM=
To: KEN KO
Cc: Brian Trammell; lmap@ietf.org; MORTON, ALFRED C (AL); STARK, BARBARA H
= Subject: MA vs MP

 

This should generate some disc= ussion.

Here is my crack at an MA vs MP comparison.  Note that = in doing this comparison, I made the assumption that in addition to the MA = registering with the Controller, an MP also needs to be made known to the C= ontroller so that the Controller can take into consideration the capabiliti= es of the MP in constructing Measurement Tasks.  This also makes it po= ssible for the Controller to suppress MPs.  Red text highlight differe= nces between MAs and MPs.

·  &nb= sp;      Device= Functionality

–        <= /span>May have MA, MP, or both MA and MP functionality

· &n= bsp;       MA Functionality

–        Registers with a Controller

–  &nb= sp;     Receives Instructions from a = Controller

–      &n= bsp; Contacts a MP to execute Measurement Tasks

–        <= /span>Performs access control (if needed) with the MP

–Can either t= ransmit or receive active measurement traffic (depending on the Measurement= Task)<= /p>

–       = ; Must honor reception of suppression messages from a Con= troller=

–       = ; May run certain tests against non-LMAP compliant target= s (e.g., ping a content server)

&midd= ot;    &nb= sp;    MP Functionality

–        = Registers wit= h a Controller=

–     &nb= sp;  Does not receive Instructions from a Con= troller=

–       = ; Responds to Measurement Task directed to it from an MA = (MP does not initiate contact with MA)

–        Performs = access control (if needed) with the MA

– &nbs= p;      Can either transmit or = receive active measurement traffic (depending on the Measurement Task)

–        Must honor reception of suppression messages from a Controller


Ch= arles

-- 
 
Charles Cook 
Principa=
l Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  =
925.281.0662
charles.cook2@centurylink.com
= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABE62FEMV67UKRDdoma_-- From j.schoenwaelder@jacobs-university.de Thu Feb 13 02:23:04 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015F81A01D1 for ; Thu, 13 Feb 2014 02:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKpTtKTsdWeG for ; Thu, 13 Feb 2014 02:23:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0C09B1A01CE for ; Thu, 13 Feb 2014 02:23:00 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E69120067; Thu, 13 Feb 2014 11:22:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1WEe9d-BbNHO; Thu, 13 Feb 2014 11:22:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC39F20062; Thu, 13 Feb 2014 11:22:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 68A982B48917; Thu, 13 Feb 2014 11:22:57 +0100 (CET) Date: Thu, 13 Feb 2014 11:22:57 +0100 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20140213102257.GB84169@elstar.local> Mail-Followup-To: philip.eardley@bt.com, acmorton@att.com, charles.cook2@centurylink.com, KEN.KO@adtran.com, trammell@tik.ee.ethz.ch, bs7652@att.com, lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: charles.cook2@centurylink.com, acmorton@att.com, lmap@ietf.org, KEN.KO@adtran.com, bs7652@att.com, trammell@tik.ee.ethz.ch Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:23:04 -0000 On Thu, Feb 13, 2014 at 10:08:35AM +0000, philip.eardley@bt.com wrote: > Side note: often the same device will have both MA and MP > functionality. Then there may well be the possibility of doing > something clever. Don't think we should work on that in lmap1.0 Perhaps we need to add text that clarifies that you can have an MA configured to run an active measurement test originating measurement traffic towards a second MA configured to run a passive measurement test consuming the measurement traffic. My understanding is that the current framework allows this. An MP, in contrast to an MA, is something involved in a measurement but not under the control of an LMAP controller. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From trammell@tik.ee.ethz.ch Thu Feb 13 02:28:53 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87301A01C2 for ; Thu, 13 Feb 2014 02:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyPhczGYLjg2 for ; Thu, 13 Feb 2014 02:28:49 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3095D1A0159 for ; Thu, 13 Feb 2014 02:28:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9D73AD9315; Thu, 13 Feb 2014 11:28:47 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k6HZY04sMHtQ; Thu, 13 Feb 2014 11:28:47 +0100 (MET) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 79975D9303; Thu, 13 Feb 2014 11:28:46 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_DEB28865-2B96-4D74-8131-E61835C766F0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: Date: Thu, 13 Feb 2014 11:28:45 +0100 Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> To: "philip.eardley@bt.com EARDLEY" X-Mailer: Apple Mail (2.1827) Cc: "STARK, BARBARA H" , charles.cook2@centurylink.com, Al Morton , KEN KO , lmap@ietf.org Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:28:54 -0000 --Apple-Mail=_DEB28865-2B96-4D74-8131-E61835C766F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Agree with Al and Phil on this onw. I'd go so far as to say that if = you're registering what you think is an MP with a Controller, then it's = actually an MA. That's what "agent" means: it acts on behalf of the = controller to make things happen. While it almost certainly makes sense for some edge devices to be able = to be used as an MP or an MA depending on the measurement, it seems to = greatly simplify the framework to (1) assume for any given measurement = with an MA/MP infrastructure behind the controller-MA interface that = there is a _single_ MA responsible for acting on instructions.=20 As for suppression, if LMAP doesn't regulate the MA-MP protocol (which = IMO it really shouldn't), this protocol must be capable of ensuring that = any activity by the MP is suppressed when the MA is suppressed, so I = don't see an issue here either. To Juergen's point on preview: > Perhaps we need to add text that clarifies that you can have an MA > configured to run an active measurement test originating measurement > traffic towards a second MA configured to run a passive measurement > test consuming the measurement traffic. Within the context of this particular measurement, isn't this second MA = really an MP? In other words, is the fact that the MP is also in contact = with the Controller (for other measurements) just a coincidence? Cheers, Brian On 13 Feb 2014, at 11:08, philip.eardley@bt.com wrote: > Agree with Al. > Suppression is part of the Instruction. The Instruction is the set of = measurement methods, schedules and perhaps suppression information which = the Controller tells the MA. if the controller was telling the MP about = suppression, then it would be sending it an instruction > =20 > I don=92t think sending a suppress to the MP is really needed. > Suppress is (mainly) about not starting new Tasks. Since the MA starts = the Task (potentially with a control msg to the MP asking it to start = sending a file, say) then it doesn=92t help to tell the MP. > =20 > It=92s also been suggested to add to the current suppression = description an option meaning =93also stop Tasks that are in progress=94 = (I am happy to add this as an option) (option =3D optional to use). I = think it=92s Task specific how this would be done. For instance for a = TCP file download from the MP to MA, the MA can end the TCP connection. > =20 > Similarly, I don=92t see the need for the MP to register with the = controller. > =20 > Side note: often the same device will have both MA and MP = functionality. Then there may well be the possibility of doing something = clever. Don=92t think we should work on that in lmap1.0 > =20 > phil > =20 > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED = C (AL) > Sent: 13 February 2014 03:17 > To: charles.cook2@centurylink.com; KEN KO > Cc: lmap@ietf.org; STARK, BARBARA H; Brian Trammell > Subject: Re: [lmap] MA vs MP > =20 > Charles, > =20 > =B7 MP Functionality > =96 Registers with a Controller > =20 > Not necessary, if I understand what you mean by registration (as MP to = Controller communication) > - Controller can get a list of MP and capabilities through other = means. > =20 > I think this is worth clarifying in the text.=20 > =20 > Also, I don't see the MP as a recipient of Suppression message from = Controller, > especially if there's no communications planned between them. > Al > =20 > From: Charles Cook [mailto:charles.cook2@centurylink.com]=20 > Sent: Wednesday, February 12, 2014 7:42 PM > To: KEN KO > Cc: Brian Trammell; lmap@ietf.org; MORTON, ALFRED C (AL); STARK, = BARBARA H > Subject: MA vs MP > =20 > This should generate some discussion. >=20 > Here is my crack at an MA vs MP comparison. Note that in doing this = comparison, I made the assumption that in addition to the MA registering = with the Controller, an MP also needs to be made known to the Controller = so that the Controller can take into consideration the capabilities of = the MP in constructing Measurement Tasks. This also makes it possible = for the Controller to suppress MPs. Red text highlight differences = between MAs and MPs. >=20 > =B7 Device Functionality > =96 May have MA, MP, or both MA and MP functionality > =B7 MA Functionality > =96 Registers with a Controller > =96 Receives Instructions from a Controller > =96 Contacts a MP to execute Measurement Tasks > =96 Performs access control (if needed) with the MP > =96 Can either transmit or receive active measurement traffic = (depending on the Measurement Task) > =96 Must honor reception of suppression messages from a = Controller > =96 May run certain tests against non-LMAP compliant targets = (e.g., ping a content server) > =B7 MP Functionality > =96 Registers with a Controller > =96 Does not receive Instructions from a Controller > =96 Responds to Measurement Task directed to it from an MA (MP = does not initiate contact with MA) > =96 Performs access control (if needed) with the MA > =96 Can either transmit or receive active measurement traffic = (depending on the Measurement Task) > =96 Must honor reception of suppression messages from a = Controller >=20 > Charles >=20 > --=20 > =20 > Charles Cook=20 > Principal Architect > Network > 5325 Zuni Street; Suite 224 > Denver, CO 80221 > Tel: 303.992.8952 Fax: 925.281.0662 > charles.cook2@centurylink.com --Apple-Mail=_DEB28865-2B96-4D74-8131-E61835C766F0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS/J5dAAoJENt3nsOmbNJcqmAH/3B8vDGX3gIaqKwy9aJy37iM deK5tkSx1FI26N2nIOLfQyRvvVgt2VpRSbTf17x4HNeCYOHV5z2cCG4V+mpOwP/x g7nHQX/r5z9eMY5aB3Aj1KzVNFExD01f7R8EsWZjeDRYjOOgLF24I6mThRPSUMJE ONiFdvM8Ev1abh5oJFheCzUxIvtm7kuC0YNDSgAknUq9RppRHL+f9peRAwuwW/+7 JOz6DotiJ3yNyfg5c/Yj9INjMFWh5YcO6ZSiTeZfRMOU1V4psZOq4HRff5hSxTb7 C9rz0m8ALZqXr2dw4rHLoZqE6IO0418/jLDow4yXU1TBLkPzBXEUe2vNGHLE014= =/C3h -----END PGP SIGNATURE----- --Apple-Mail=_DEB28865-2B96-4D74-8131-E61835C766F0-- From j.schoenwaelder@jacobs-university.de Thu Feb 13 02:59:40 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFE51A01B0 for ; Thu, 13 Feb 2014 02:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoKucmLD2rCh for ; Thu, 13 Feb 2014 02:59:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 627AA1A00D9 for ; Thu, 13 Feb 2014 02:59:38 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DDC420069; Thu, 13 Feb 2014 11:59:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uFay_fb0S7u2; Thu, 13 Feb 2014 11:59:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39E8220066; Thu, 13 Feb 2014 11:59:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 41DB32B48B4B; Thu, 13 Feb 2014 11:59:32 +0100 (CET) Date: Thu, 13 Feb 2014 11:59:31 +0100 From: Juergen Schoenwaelder To: Brian Trammell Message-ID: <20140213105931.GA84319@elstar.local> Mail-Followup-To: Brian Trammell , "philip.eardley@bt.com EARDLEY" , "STARK, BARBARA H" , charles.cook2@centurylink.com, Al Morton , KEN KO , lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: charles.cook2@centurylink.com, Al Morton , lmap@ietf.org, "philip.eardley@bt.com EARDLEY" , KEN KO , "STARK, BARBARA H" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:59:40 -0000 On Thu, Feb 13, 2014 at 11:28:45AM +0100, Brian Trammell wrote: > > To Juergen's point on preview: > > > Perhaps we need to add text that clarifies that you can have an MA > > configured to run an active measurement test originating measurement > > traffic towards a second MA configured to run a passive measurement > > test consuming the measurement traffic. > > Within the context of this particular measurement, isn't this second MA really an MP? In other words, is the fact that the MP is also in contact with the Controller (for other measurements) just a coincidence? > If we use MA = controlled by LMAP controller MP = not controlled by LMAP controller then both are MAs. The first one is running a somewhat degenerated measurement test that generates traffic, the second one is running a passive measurement test observing the traffic and generating results. Measurement tests can vary widely and we do not make any specific assumptions architecturally. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From trammell@tik.ee.ethz.ch Thu Feb 13 03:35:30 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48831A01EA for ; Thu, 13 Feb 2014 03:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oSG02OEwM2C for ; Thu, 13 Feb 2014 03:35:27 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6656A1A01F0 for ; Thu, 13 Feb 2014 03:35:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 10312D930A; Thu, 13 Feb 2014 12:35:25 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id imjFNW7UUspm; Thu, 13 Feb 2014 12:35:24 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 15743D9300; Thu, 13 Feb 2014 12:35:23 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_2D6654FD-8D09-44C7-9D27-29389595073A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <20140213105931.GA84319@elstar.local> Date: Thu, 13 Feb 2014 12:35:23 +0100 Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213105931.GA84319@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1827) Cc: charles.cook2@centurylink.com, Al Morton , lmap@ietf.org, "philip.eardley@bt.com EARDLEY" , KEN KO , "STARK, BARBARA H" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:35:30 -0000 --Apple-Mail=_2D6654FD-8D09-44C7-9D27-29389595073A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Juergen, Sorry, I read this wrong. Yep, you=92re right. But I=92d still say from = an architectural point of view, you=92re running two measurements at the = same time with two MAs which, due to a coincidence arranged by the = controller, will have related results. Cheers, Brian On 13 Feb 2014, at 11:59, Juergen Schoenwaelder = wrote: > On Thu, Feb 13, 2014 at 11:28:45AM +0100, Brian Trammell wrote: >>=20 >> To Juergen's point on preview: >>=20 >>> Perhaps we need to add text that clarifies that you can have an MA >>> configured to run an active measurement test originating measurement >>> traffic towards a second MA configured to run a passive measurement >>> test consuming the measurement traffic. >>=20 >> Within the context of this particular measurement, isn't this second = MA really an MP? In other words, is the fact that the MP is also in = contact with the Controller (for other measurements) just a coincidence? >>=20 >=20 > If we use >=20 > MA =3D controlled by LMAP controller > MP =3D not controlled by LMAP controller >=20 > then both are MAs. The first one is running a somewhat degenerated > measurement test that generates traffic, the second one is running a > passive measurement test observing the traffic and generating results. > Measurement tests can vary widely and we do not make any specific > assumptions architecturally. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 --Apple-Mail=_2D6654FD-8D09-44C7-9D27-29389595073A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS/K37AAoJENt3nsOmbNJcSC0H/0OZEr5E2BV8B3uH729C2OBb tbzeVgUm8DRr+73n06YDIUpFXYthpo3v90MfWQAMuAIlsIazOqhQ6iEKLoovh/HO nDQC6dvUjHslVTXqi9wG+s9bm9K2gwdx/giGmzC1YSEs0+KpgI5ACrgst+9Sn/Ew kBr/+VkHBWno9mKdevFCZvyuEVN4aNmHa2Fr2/7nr1M8m3ESUURZ0upc3R+oP2gO ze2BVAbecJNNHFvMeaKmw+/Hz1c7V5YF4TRtMDVbxXA8hwMo3kgqsPl1jylaUS0k +P9pH8yKtHCGRsBMnKUq0mkMzlbs5IkevieIiE65IrStO2jUNM6kN6xAqTX39A8= =ugwN -----END PGP SIGNATURE----- --Apple-Mail=_2D6654FD-8D09-44C7-9D27-29389595073A-- From Michael.K.Bugenhagen@centurylink.com Thu Feb 13 05:53:18 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84601A024D for ; Thu, 13 Feb 2014 05:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEI8wV3TA5mg for ; Thu, 13 Feb 2014 05:53:13 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id F252F1A0276 for ; Thu, 13 Feb 2014 05:53:12 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1DDr7hS019809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Feb 2014 06:53:07 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 4B8FB1E0049; Thu, 13 Feb 2014 06:53:02 -0700 (MST) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 2A9E21E0035; Thu, 13 Feb 2014 06:53:02 -0700 (MST) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1DDr1Pa005758; Thu, 13 Feb 2014 06:53:01 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1DDr1tk005745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 06:53:01 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 07:53:00 -0600 From: "Bugenhagen, Michael K" To: "'MORTON, ALFRED C (AL)'" , "Cook, Charles" , "'KEN KO'" Thread-Topic: MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihk5qzMQ0Q Date: Thu, 13 Feb 2014 13:53:00 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E04A7F832podcwmbxex505ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'Brian Trammell' , "'STARK, BARBARA H'" , "'lmap@ietf.org'" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 13:53:19 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E04A7F832podcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Charles - We may have some hidden assumptions just undernieth the surface - I'll offer this as a litmus test.... IF the MA/MP are functions only - We may need a "entity" definition of a= Probe That's why I like MA responder / MA initiator functions early on.. and the= MA itself was the entity --- It sounds like we're discussing a split enti= ty vs. sub functionality... Functionally - I think Al has a good point - Although the MA/MP's can act w= ithout getting permission from the controller per test cycle, it would be = advantageous to have them register with the Controller (self discovery type= of thing). It would also be good for the controller to set a "test policy" for MP's - = in which the controller could tell the MP to "not respond" to certain tests= .. Of course this depends upon the existence of logic above the MA/MP function= level... or are they equivalent (MA =3D Probe and functionally type or jus= t the function and there is probe logic above it). So are MA / MP to different entities or two different functions under an en= tity.. ? Just checking to make sure I'm tracking From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Wednesday, February 12, 2014 9:17 PM To: Cook, Charles; KEN KO Cc: lmap@ietf.org; STARK, BARBARA H; Brian Trammell Subject: Re: [lmap] MA vs MP Charles, * MP Functionality - Registers with a Controller Not necessary, if I understand what you mean by registration (as MP to Cont= roller communication) - Controller can get a list of MP and capabilities through other means. I think this is worth clarifying in the text. Also, I don't see the MP as a recipient of Suppression message from Control= ler, especially if there's no communications planned between them. Al From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Wednesday, February 12, 2014 7:42 PM To: KEN KO Cc: Brian Trammell; lmap@ietf.org; MORTON, ALFRED C (= AL); STARK, BARBARA H Subject: MA vs MP This should generate some discussion. Here is my crack at an MA vs MP comparison. Note that in doing this compar= ison, I made the assumption that in addition to the MA registering with the= Controller, an MP also needs to be made known to the Controller so that th= e Controller can take into consideration the capabilities of the MP in cons= tructing Measurement Tasks. This also makes it possible for the Controller= to suppress MPs. Red text highlight differences between MAs and MPs. * Device Functionality - May have MA, MP, or both MA and MP functionality * MA Functionality - Registers with a Controller - Receives Instructions from a Controller - Contacts a MP to execute Measurement Tasks - Performs access control (if needed) with the MP - Can either transmit or receive active measurement traffic (dependi= ng on the Measurement Task) - Must honor reception of suppression messages from a Controller - May run certain tests against non-LMAP compliant targets (e.g., pi= ng a content server) * MP Functionality - Registers with a Controller - Does not receive Instructions from a Controller - Responds to Measurement Task directed to it from an MA (MP does no= t initiate contact with MA) - Performs access control (if needed) with the MA - Can either transmit or receive active measurement traffic (dependi= ng on the Measurement Task) - Must honor reception of suppression messages from a Controller Charles -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com --_000_A68F3CAC468B2E48BB775ACE2DD99B5E04A7F832podcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Charles –

 <= /p>

  We may have s= ome hidden assumptions just undernieth the surface –

 <= /p>

I’ll offer this as = a litmus test….

 <= /p>

   IF the = MA/MP are functions only – We may need a “entity” definit= ion of a Probe

That’s why I like M= A responder / MA initiator functions early on..  and the MA itself was= the entity ---  It sounds like we’re discussing a split entity = vs.  sub functionality…

 <= /p>

Functionally - I think Al= has a good point – Although the MA/MP’s can act without gettin= g permission from the controller per test cycle,  it would be advantag= eous to have them register with the Controller (self discovery type of thing).<= o:p>

It would also be good for= the controller to set a “test policy” for MP’s – i= n which the controller could tell the MP to “not respond” to ce= rtain tests ..  

 <= /p>

 <= /p>

Of course this depends up= on the existence of logic above the MA/MP function level… or are they= equivalent (MA =3D Probe and functionally type or just the function and there is probe logic above it).

 <= /p>

So are MA / MP to differe= nt entities or two different functions under an entity.. ?

 <= /p>

Just checking to make sur= e I’m tracking

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL)
Sent: Wednesday, February 12, 2014 9:17 PM
To: Cook, Charles; KEN KO
Cc: lmap@ietf.org; STARK, BARBARA H; Brian Trammell
Subject: Re: [lmap] MA vs MP

 

Charles,

 

·         MP Functionality

– = ;       Registers with a Controller

 

Not necessary, if I understand what you m= ean by registration (as MP to Controller communication)

- Controller can get a list of MP and cap= abilities through other means.

 

I think this is worth clarifying in the t= ext. 

 

Also, I don't see the MP as a recipient o= f Suppression message from Controller,

especially if there's no communications p= lanned between them.

Al

 

From: Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: Wednesday, February 12, 2014 7:42 PM
To: KEN KO
Cc: Brian Trammell; lmap@ietf.org; MORTON, ALFRED C (AL); STARK, BARBARA H
Subject: MA vs MP

 

This should generate = some discussion.

Here is my crack at an MA vs MP comparison.  Note that in doing this c= omparison, I made the assumption that in addition to the MA registering wit= h the Controller, an MP also needs to be made known to the Controller so th= at the Controller can take into consideration the capabilities of the MP in constructing Measurement Tasks.  This a= lso makes it possible for the Controller to suppress MPs.  Red text hi= ghlight differences between MAs and MPs.

·         Device Functionality<= /o:p>

– = ;       May have MA, MP, or both MA and MP functionality

·         MA Functionality

– = ;       Registers with a Controller

– = ;       Receives Instructions from a Controller

– = ;       Contacts a MP to execute Measurement Tasks<= span style=3D"color:#006032">

– = ;       Performs access control (if needed) with the MP

– = ;       Can either transmit or receive active measurement = traffic (depending on the Measurement Task)

– = ;       Must honor reception of suppression messages from = a Controller

– = ;       May run certain tests against non-LMAP compliant t= argets (e.g., ping a content server)

·         MP Functionality

– = ;       Registers with a Controller

– = ;       Does not receive Instructions from a Controller

– = ;       Responds to Measurement Task directed to it from a= n MA (MP does not initiate contact with MA)

– = ;       Performs access control (if needed) with the MA

– = ;       Can either transmit or receive active measurement = traffic (depending on the Measurement Task)

– = ;       Must honor reception of suppression messages from = a Controller


Charles

-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
charles.cook2@century=
link.com
--_000_A68F3CAC468B2E48BB775ACE2DD99B5E04A7F832podcwmbxex505ct_-- From j.schoenwaelder@jacobs-university.de Thu Feb 13 06:30:20 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71661A0293 for ; Thu, 13 Feb 2014 06:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-VfZD7h_z-m for ; Thu, 13 Feb 2014 06:30:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 327691A0252 for ; Thu, 13 Feb 2014 06:30:17 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7EFDA2006C; Thu, 13 Feb 2014 15:30:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8PARHt1N40GW; Thu, 13 Feb 2014 15:30:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDCC92006B; Thu, 13 Feb 2014 15:30:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 02FA12B49781; Thu, 13 Feb 2014 15:30:12 +0100 (CET) Date: Thu, 13 Feb 2014 15:30:12 +0100 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20140213143012.GA85019@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , "'MORTON, ALFRED C (AL)'" , "Cook, Charles" , 'KEN KO' , 'Brian Trammell' , "'STARK, BARBARA H'" , "'lmap@ietf.org'" References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Cook, Charles" , "'MORTON, ALFRED C \(AL\)'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:30:21 -0000 On Thu, Feb 13, 2014 at 01:53:00PM +0000, Bugenhagen, Michael K wrote: > Charles - > > We may have some hidden assumptions just undernieth the surface - > > I'll offer this as a litmus test.... > > IF the MA/MP are functions only - We may need a "entity" definition of a Probe > That's why I like MA responder / MA initiator functions early on.. and the MA itself was the entity --- It sounds like we're discussing a split entity vs. sub functionality... > > Functionally - I think Al has a good point - Although the MA/MP's can act without getting permission from the controller per test cycle, it would be advantageous to have them register with the Controller (self discovery type of thing). > It would also be good for the controller to set a "test policy" for MP's - in which the controller could tell the MP to "not respond" to certain tests .. > A controller does not talk to MPs. > Of course this depends upon the existence of logic above the MA/MP function level... or are they equivalent (MA = Probe and functionally type or just the function and there is probe logic above it). > > So are MA / MP to different entities or two different functions under an entity.. ? > An MA talks to a controller and receives and executes instructions received from the controller. An MP does not talk to a controller but may be involved in a measurement. The MP and MA may coordinate/control a measurement via a separate mechanism (e.g. TWAMP) or the MP may even be completely unaware of being an MP. LMAP is not definiting the semantics of specific tests and hence your question is not possible to answer in general. If you want an MP controlled by an LMAP controller, then it is an MA. KISS. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Michael.K.Bugenhagen@centurylink.com Thu Feb 13 06:43:52 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212B11A027A for ; Thu, 13 Feb 2014 06:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv20vijulkFs for ; Thu, 13 Feb 2014 06:43:45 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 37B921A02B5 for ; Thu, 13 Feb 2014 06:43:45 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1DEheH1025571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Feb 2014 08:43:40 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 0F28C1E0073; Thu, 13 Feb 2014 08:43:35 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id E70361E0071; Thu, 13 Feb 2014 08:43:34 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s1DEhYJe006618; Thu, 13 Feb 2014 08:43:34 -0600 (CST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s1DEhXTV006608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 08:43:34 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 08:43:33 -0600 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihk5qzMQ0QgABy6QD//55fIA== Date: Thu, 13 Feb 2014 14:43:33 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> In-Reply-To: <20140213143012.GA85019@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Cook, Charles" , "'MORTON, ALFRED C \(AL\)'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:43:52 -0000 Juergen - You state a controller doesn't talk to a MP ... How about that Test server on the Internet that all the tests run too ? Would you classify that as a MA or a MP ? Thanks, Mike -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, February 13, 2014 8:30 AM To: Bugenhagen, Michael K Cc: 'MORTON, ALFRED C (AL)'; Cook, Charles; 'KEN KO'; 'Brian Trammell'; 'ST= ARK, BARBARA H'; 'lmap@ietf.org' Subject: Re: [lmap] MA vs MP On Thu, Feb 13, 2014 at 01:53:00PM +0000, Bugenhagen, Michael K wrote: > Charles - >=20 > We may have some hidden assumptions just undernieth the surface - >=20 > I'll offer this as a litmus test.... >=20 > IF the MA/MP are functions only - We may need a "entity" definition=20 > of a Probe That's why I like MA responder / MA initiator functions early = on.. and the MA itself was the entity --- It sounds like we're discussing= a split entity vs. sub functionality... >=20 > Functionally - I think Al has a good point - Although the MA/MP's can act= without getting permission from the controller per test cycle, it would b= e advantageous to have them register with the Controller (self discovery ty= pe of thing). > It would also be good for the controller to set a "test policy" for MP's = - in which the controller could tell the MP to "not respond" to certain tes= ts .. >=20 A controller does not talk to MPs. =20 > Of course this depends upon the existence of logic above the MA/MP functi= on level... or are they equivalent (MA =3D Probe and functionally type or j= ust the function and there is probe logic above it). >=20 > So are MA / MP to different entities or two different functions under an = entity.. ? >=20 An MA talks to a controller and receives and executes instructions received= from the controller. An MP does not talk to a controller but may be involved in a measurement. T= he MP and MA may coordinate/control a measurement via a separate mechanism = (e.g. TWAMP) or the MP may even be completely unaware of being an MP. LMAP is not definiting the semantics of specific tests and hence your quest= ion is not possible to answer in general. If you want an MP controlled by a= n LMAP controller, then it is an MA. KISS. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Feb 13 06:53:04 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162A91A02C8 for ; Thu, 13 Feb 2014 06:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxw-hNm-7ZUo for ; Thu, 13 Feb 2014 06:53:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B53B71A02C5 for ; Thu, 13 Feb 2014 06:52:59 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 517EB2006B; Thu, 13 Feb 2014 15:52:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 270uYseJSsl4; Thu, 13 Feb 2014 15:52:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8AD4820062; Thu, 13 Feb 2014 15:52:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CB45B2B498D9; Thu, 13 Feb 2014 15:52:55 +0100 (CET) Date: Thu, 13 Feb 2014 15:52:55 +0100 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20140213145255.GC85019@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , "Cook, Charles" , "'MORTON, ALFRED C (AL)'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' References: <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Cook, Charles" , "'MORTON, ALFRED C \(AL\)'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:53:04 -0000 On Thu, Feb 13, 2014 at 02:43:33PM +0000, Bugenhagen, Michael K wrote: > Juergen - > > You state a controller doesn't talk to a MP ... > > How about that Test server on the Internet that all the tests run too ? > > Would you classify that as a MA or a MP ? If it talks to a Contoller and receives and executes instructions, it is an MA. Otherwise, it is an MP. I really do not understand why this is complicated. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Michael.K.Bugenhagen@centurylink.com Thu Feb 13 07:13:29 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D991A1A0296 for ; Thu, 13 Feb 2014 07:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TFxQd24lK3y for ; Thu, 13 Feb 2014 07:13:28 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id BA5581A02AA for ; Thu, 13 Feb 2014 07:13:26 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1DFDKmB027024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Feb 2014 08:13:21 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id C528E1E007C; Thu, 13 Feb 2014 09:13:15 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 9FF011E0079; Thu, 13 Feb 2014 09:13:15 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s1DFDFw9028734; Thu, 13 Feb 2014 09:13:15 -0600 (CST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s1DFDEZt028720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 09:13:14 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 09:13:14 -0600 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihk5qzMQ0QgABy6QD//55fIIAAZ/mA//+bioA= Date: Thu, 13 Feb 2014 15:13:13 +0000 Message-ID: References: <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> In-Reply-To: <20140213145255.GC85019@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Cook, Charles" , "'MORTON, ALFRED C \(AL\)'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:13:30 -0000 So here I agree with Al. I want to register the MP with the Controller so I can - 1) Tell the Controller my capabilities (especially when the change - like a= port goes down) =09 Examples - So that I can=20 - Tell the Controller which tests my test server can support so the contr= oller doesn't create non-runnable tests - So the Controller has some state awareness of the test server(s) state = - remember scale means we could have many test servers going up and down, e= specially in cloud platforms - So I can tell the Test server what MA's we like vs. don't want to talk = to (host the world or only my MA's) Getting users to state their requirements is always tough... but shouldn't = be... IMO -- Somewhat of a cap statement - MC to MA/MP -- Scheduling goes to MA's only, but admin and control goe= s to both Does this sound agreeable ? -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, February 13, 2014 8:53 AM To: Bugenhagen, Michael K Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; 'STA= RK, BARBARA H'; 'Brian Trammell' Subject: Re: [lmap] MA vs MP On Thu, Feb 13, 2014 at 02:43:33PM +0000, Bugenhagen, Michael K wrote: > Juergen - >=20 > You state a controller doesn't talk to a MP ... >=20 > How about that Test server on the Internet that all the tests run too ? >=20 > Would you classify that as a MA or a MP ? If it talks to a Contoller and receives and executes instructions, it is an= MA. Otherwise, it is an MP. I really do not understand why this is complic= ated. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Feb 13 07:23:03 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5C31A02D2 for ; Thu, 13 Feb 2014 07:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Evf5OYDheqL for ; Thu, 13 Feb 2014 07:22:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 211011A01F1 for ; Thu, 13 Feb 2014 07:22:57 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8C072006A; Thu, 13 Feb 2014 16:22:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sBTRx-1lnCO2; Thu, 13 Feb 2014 16:22:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB9872003A; Thu, 13 Feb 2014 16:22:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EECB12B49A3C; Thu, 13 Feb 2014 16:22:52 +0100 (CET) Date: Thu, 13 Feb 2014 16:22:52 +0100 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20140213152252.GA85206@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , "Cook, Charles" , "'MORTON, ALFRED C (AL)'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Cook, Charles" , "'MORTON, ALFRED C \(AL\)'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:23:03 -0000 On Thu, Feb 13, 2014 at 03:13:13PM +0000, Bugenhagen, Michael K wrote: > IMO -- Somewhat of a cap statement - > > MC to MA/MP -- Scheduling goes to MA's only, but admin and control goes to both > By definition, the LMAP controller does not talk to an MP and hence the above statement is false. You are talking about a case where the controller talks to two MAs that carry out a measurement between them. I believe the framework allows for this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From trevor.burbridge@bt.com Thu Feb 13 07:25:32 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210C41A0209 for ; Thu, 13 Feb 2014 07:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl8ni3nzG1dg for ; Thu, 13 Feb 2014 07:25:28 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3C1A01DA for ; Thu, 13 Feb 2014 07:25:28 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 13 Feb 2014 15:25:55 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.56]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Thu, 13 Feb 2014 15:25:21 +0000 From: To: , Date: Thu, 13 Feb 2014 15:25:21 +0000 Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihk5qzMQ0QgABy6QD//55fIIAAZ/mA//+bioCAAAYy8A== Message-ID: References: <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Charles.Cook2@centurylink.com, acmorton@att.com, lmap@ietf.org, KEN.KO@adtran.com, bs7652@att.com, trammell@tik.ee.ethz.ch Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:25:32 -0000 Al said: "Not necessary, if I understand what you mean by registration (as = MP to Controller communication) - Controller can get a list of MP and capab= ilities through other means". So NOT what you are proposing. I think everyone understands both sides of the discussion. Just that a grou= p of us want to keep things simple and don't see it as a requirement to sta= ndardise how a Controller knows about Measurement Peers and therefore certa= inly don't want to get into a subsequent discussion about controlling them. Some re-iterated reasons: - a MP is often a basic server with standard functionality (e.g. web server= , router) - if the MAs and MPs are under one domain, MA control is completely suffici= ent to stop testing - if the MP is under another domain, then it certainly won't be talking to = your controller anyway - MPs can be considered to have their own control infrastructure already (e= .g. network or server management) Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000=20 >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael >K >Sent: 13 February 2014 15:13 >To: 'Juergen Schoenwaelder' >Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; 'ST= ARK, >BARBARA H'; 'Brian Trammell' >Subject: Re: [lmap] MA vs MP > >So here I agree with Al. > >I want to register the MP with the Controller so I can - > >1) Tell the Controller my capabilities (especially when the change - like = a port >goes down) > > Examples - So that I can > - Tell the Controller which tests my test server can support so the >controller doesn't create non-runnable tests > - So the Controller has some state awareness of the test server(s) state= - >remember scale means we could have many test servers going up and down, >especially in cloud platforms > - So I can tell the Test server what MA's we like vs. don't want to talk= to >(host the world or only my MA's) > > >Getting users to state their requirements is always tough... but shouldn't= be... > > >IMO -- Somewhat of a cap statement - > > MC to MA/MP -- Scheduling goes to MA's only, but admin and control go= es to >both > > > Does this sound agreeable ? > > > > > > > > > > > >-----Original Message----- >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >Sent: Thursday, February 13, 2014 8:53 AM >To: Bugenhagen, Michael K >Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; 'ST= ARK, >BARBARA H'; 'Brian Trammell' >Subject: Re: [lmap] MA vs MP > >On Thu, Feb 13, 2014 at 02:43:33PM +0000, Bugenhagen, Michael K wrote: >> Juergen - >> >> You state a controller doesn't talk to a MP ... >> >> How about that Test server on the Internet that all the tests run too ? >> >> Would you classify that as a MA or a MP ? > >If it talks to a Contoller and receives and executes instructions, it is a= n MA. >Otherwise, it is an MP. I really do not understand why this is complicated= . > >/js > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From Michael.K.Bugenhagen@centurylink.com Thu Feb 13 07:28:24 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA6C1A01DA for ; Thu, 13 Feb 2014 07:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZBFuHfml__5 for ; Thu, 13 Feb 2014 07:28:21 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id B36481A02AA for ; Thu, 13 Feb 2014 07:28:19 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1DFSFWC028262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Feb 2014 09:28:15 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 24C041E0071; Thu, 13 Feb 2014 09:28:10 -0600 (CST) Received: from sudnp797.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id DB1C71E006F; Thu, 13 Feb 2014 09:28:09 -0600 (CST) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1DFS9mI001248; Thu, 13 Feb 2014 08:28:09 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1DFS8pe001229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 08:28:09 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 09:28:08 -0600 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihk5qzMQ0QgABy6QD//55fIIAAZ/mA//+j05CAAAAq8A== Date: Thu, 13 Feb 2014 15:28:08 +0000 Message-ID: References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> In-Reply-To: <20140213152252.GA85206@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Cook, Charles" , "'MORTON, ALFRED C \(AL\)'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:28:24 -0000 Juergen - If we are academically bound to a definition vs. use case requirements = you are correct. This also indicates that MP's are just an abstract name for anything that r= esponds to a test that isn't under the control of the MC (if you follow use= case requirements). So MP's are existing artifacts like ping responders, TWAMP responders, ..= . anything that can be a test peer that isn't talking to the MA... So MP's are not LMAP artifacts per say in your definition ? Agreed ? - I'm ok with that=20 However - many people classify the MP as ALL and ANY test peer so that defi= nition breaks in that context and use... -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, February 13, 2014 9:23 AM To: Bugenhagen, Michael K Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; 'STA= RK, BARBARA H'; 'Brian Trammell' Subject: Re: [lmap] MA vs MP On Thu, Feb 13, 2014 at 03:13:13PM +0000, Bugenhagen, Michael K wrote: > IMO -- Somewhat of a cap statement - >=20 > MC to MA/MP -- Scheduling goes to MA's only, but admin and=20 > control goes to both >=20 By definition, the LMAP controller does not talk to an MP and hence the abo= ve statement is false. You are talking about a case where the controller talks to two MAs that car= ry out a measurement between them. I believe the framework allows for this. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bs7652@att.com Thu Feb 13 07:35:22 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4451A02C6 for ; Thu, 13 Feb 2014 07:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84eCO92r5X0z for ; Thu, 13 Feb 2014 07:35:19 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9B00E1A02B4 for ; Thu, 13 Feb 2014 07:35:19 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 636ecf25.2abd54439940.2939995.00-2432.7620189.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 13 Feb 2014 15:35:18 +0000 (UTC) X-MXL-Hash: 52fce6361f142d21-c2fca2182180f19d8c4f2b15a4c4dea7ed9c3b1c Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 336ecf25.0.2939972.00-2300.7620100.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 13 Feb 2014 15:35:16 +0000 (UTC) X-MXL-Hash: 52fce63405895a45-d6b3cf0f897672058570a3c0e5c0bedeb30197a6 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1DFZEpq009744; Thu, 13 Feb 2014 10:35:14 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1DFZ8wm009692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Feb 2014 10:35:10 -0500 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (GAALPA1MSGHUB9E.itservices.sbc.com [130.8.36.91]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 13 Feb 2014 15:34:52 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 10:34:52 -0500 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , "Brian Trammell" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRkqyuqLftGYUCRyHP6AveWe5qy1z6AgABzB4CAAAWjgIAACJiA///jRDA= Date: Thu, 13 Feb 2014 15:34:51 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303E590B@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213105931.GA84319@elstar.local> In-Reply-To: <20140213105931.GA84319@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.165.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=N9We4RBB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=-ayHiJ6liBIA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=_fbRkOfxO] X-AnalysisOut: [ZYA:10 a=PWdwRkILOZ_7FTcZfl8A:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Cc: "philip.eardley@bt.com EARDLEY" , "charles.cook2@centurylink.com" , "MORTON JR., AL" , KEN KO , "lmap@ietf.org" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:35:22 -0000 > > > Perhaps we need to add text that clarifies that you can have an MA > > > configured to run an active measurement test originating measurement > > > traffic towards a second MA configured to run a passive measurement > > > test consuming the measurement traffic. > > > > Within the context of this particular measurement, isn't this second MA > really an MP? In other words, is the fact that the MP is also in contact = with > the Controller (for other measurements) just a coincidence? > > >=20 > If we use >=20 > MA =3D controlled by LMAP controller > MP =3D not controlled by LMAP controller >=20 > then both are MAs. The first one is running a somewhat degenerated > measurement test that generates traffic, the second one is running a pass= ive > measurement test observing the traffic and generating results. > Measurement tests can vary widely and we do not make any specific > assumptions architecturally. I think this is a workable definition, but in order to consider multiple op= tions before settling on any particular, I'd like to suggest something just= a little different. MA =3D as defined in framework: "The function that receives Instructions fr= om a Controller, performs Measurement Tasks (perhaps in concert with a M= easurement Peer) and reports Measurement Results to a Collector." MP =3D any endpoint that an MA communicates with as part of an Active Measu= rement Task. In this context, the MP is defined from the perspective of the MA as being = "the other end of an Active Measurement Task from me (the MA)". As such, the MP is not a function that has "functional requirements" of any= sort nor is it a role that an MA has (because the MP is *always* not in th= e MA we are looking at). If we focus our attention on an MA and look at thi= ngs from its perspective, then the MA is "here" and the MP is "not here". M= P is an unknown (other than the IP address) "something". This "something" m= ight not even really know how to do the Active Measurement Task. The MA can= make no a priori assumptions about this "something" and a robust MA should= be designed with that in mind. This "something" and the fact that details = about it are unknown to the MA is an important concept. Whether the MA's Controller (or the entity operating the MA's Controller) k= nows about these "somethings" is unknown to the MA. The MA doesn't know wha= t the Controller or the entity knows. Now consider 2 MAs (MA1 and MA2), each living in its own little world. Each= knows who its Controller is, knows its Measurement Methods, Reports and Me= asures according to Instructions, and in all ways behaves like a perfect li= ttle MA. There is an Active Measurement Task that occurs with these 2 MAs a= s endpoints. What I am proposing is that MA1 sees MA2 as its MP, and MA2 se= es MA1 as its MP. MP has no functional requirements and cannot be embodied = as a role or function, because whatever MA we are focusing our attention on= (designing, Controlling, Instructing, getting Reports from, etc.), the MP = is somewhere else. If these 2 MAs are controlled by the same Controller, then that's fine. Nei= ther MA knows or cares. The Controller sees "MPs" as being whatever one of = its MAs is interacting with for an Active Measurement Task. It's also fine if the 2 MAs have different Controllers operated by distinct= entities. Neither MA cares or knows. If an entity wants to ensure that all endpoints involved in Active Measurem= ent Tasks are well-behaved and appropriately Controlled and Instructed (i.e= ., they are all MAs), then that is something the entity has to do. How the = entity does this is not in scope of lmap. And MAs do not care or know wheth= er its operating entity is doing this. Barbara From sharam.hakimi@exfo.com Thu Feb 13 07:46:11 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38521A02AC for ; Thu, 13 Feb 2014 07:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6Ak5xVEUi4L for ; Thu, 13 Feb 2014 07:46:09 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABE01A020D for ; Thu, 13 Feb 2014 07:46:08 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 10:46:07 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 10:46:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Feb 2014 10:46:03 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B2362B@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihk5qzMQ0QgABy6QD//55fIIAAZ/mA//+j05CAAAAq8IAAA6Iw References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> From: "Sharam Hakimi" To: "Bugenhagen, Michael K" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 13 Feb 2014 15:46:07.0632 (UTC) FILETIME=[B5DB3900:01CF28D2] Cc: "Cook, Charles" , "MORTON, ALFRED C \(AL\)" , lmap@ietf.org, KEN KO , "STARK, BARBARA H" , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:46:12 -0000 All, I agree with Al, MP is a responder function and not under control of MC or MA. MA uses an MP to perform a measurement task.=20 However, I would caution greatly on having a same device to have a MA and MP function. These are two independent functions with no communications between them. Two TCP-throughput test running at the same time can easily overwhelm the network if not the single device and the two functions (MA,MP ) will not have any information that the other one is running. Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael K Sent: Thursday, February 13, 2014 10:28 AM To: 'Juergen Schoenwaelder' Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; 'STARK, BARBARA H'; 'Brian Trammell' Subject: Re: [lmap] MA vs MP Juergen - If we are academically bound to a definition vs. use case requirements you are correct. This also indicates that MP's are just an abstract name for anything that responds to a test that isn't under the control of the MC (if you follow use case requirements). So MP's are existing artifacts like ping responders, TWAMP responders, ... anything that can be a test peer that isn't talking to the MA... So MP's are not LMAP artifacts per say in your definition ? Agreed ? - I'm ok with that=20 However - many people classify the MP as ALL and ANY test peer so that definition breaks in that context and use... -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, February 13, 2014 9:23 AM To: Bugenhagen, Michael K Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; 'STARK, BARBARA H'; 'Brian Trammell' Subject: Re: [lmap] MA vs MP On Thu, Feb 13, 2014 at 03:13:13PM +0000, Bugenhagen, Michael K wrote: > IMO -- Somewhat of a cap statement - >=20 > MC to MA/MP -- Scheduling goes to MA's only, but admin and=20 > control goes to both >=20 By definition, the LMAP controller does not talk to an MP and hence the above statement is false. You are talking about a case where the controller talks to two MAs that carry out a measurement between them. I believe the framework allows for this. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From ken.ko@adtran.com Thu Feb 13 07:46:32 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC671A02AC for ; Thu, 13 Feb 2014 07:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVg8DnOyF0sw for ; Thu, 13 Feb 2014 07:46:30 -0800 (PST) Received: from p02c12o149.mxlogic.net (p02c12o149.mxlogic.net [208.65.145.82]) by ietfa.amsl.com (Postfix) with ESMTP id BECC71A020D for ; Thu, 13 Feb 2014 07:46:29 -0800 (PST) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o149.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 4d8ecf25.2b7107244940.165391.00-525.399307.p02c12o149.mxlogic.net (envelope-from ); Thu, 13 Feb 2014 08:46:28 -0700 (MST) X-MXL-Hash: 52fce8d413efe733-717ba0f8214a4e159cdf3f2371b4d0b8d631b5d5 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o149.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id bc8ecf25.0.165260.00-211.398984.p02c12o149.mxlogic.net (envelope-from ); Thu, 13 Feb 2014 08:46:25 -0700 (MST) X-MXL-Hash: 52fce8d1640cea9f-2221dc55058bcff549709ab332295409b7411c61 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 09:46:18 -0600 From: KEN KO To: "STARK, BARBARA H" , Juergen Schoenwaelder , Brian Trammell Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRdZ+UYn/wQ5EuM8kKUQT8gipqy6AKAgABzB4CAAAWigIAACJmAgABM7YD//51akA== Date: Thu, 13 Feb 2014 15:46:17 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303DC527@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC23F075@njfpsrvexg8.research.att.com> <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213105931.GA84319@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E590B@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303E590B@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=LLLRtuq9 c=1 sm=1 a=0XgpNN2/4a34ymu16SVwsQ==:17 a] X-AnalysisOut: [=qZHQZMT3apYA:10 a=FBzmcnhlJawA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=_fbRkOfx] X-AnalysisOut: [OZYA:10 a=zQP7CpKOAAAA:8 a=e9qsufxtAAAA:8 a=J_N6KFswAAAA:8] X-AnalysisOut: [ a=48vgC7mUAAAA:8 a=xDUD76OC6X6vKJ8kPrQA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=Hz7IrDYlS0cA:10 a=W1qU_X6G3J8A:10 a=Pwbduc0PQ3sA:10 a] X-AnalysisOut: [=lZB815dzVvQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014021308); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Cc: "philip.eardley@bt.com EARDLEY" , "charles.cook2@centurylink.com" , "MORTON JR., AL" , "lmap@ietf.org" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:46:32 -0000 +1 I do think that if this interpretation has a consensus in lmap, it will nee= d a few text edits beyond just the definition of a Measurement Peer in Term= inology. Figure 1 and other instances in the draft have led some of us (or = at least one of us) to interpret MA and MP in lmap as functions that may (o= r may not) coexist side by side in a measurement "container."=20 Ken > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Thursday, February 13, 2014 10:35 AM > To: Juergen Schoenwaelder; Brian Trammell > Cc: philip.eardley@bt.com EARDLEY; charles.cook2@centurylink.com; > MORTON JR., AL; KEN KO; lmap@ietf.org > Subject: RE: [lmap] MA vs MP >=20 > > > > Perhaps we need to add text that clarifies that you can have an MA > > > > configured to run an active measurement test originating > > > > measurement traffic towards a second MA configured to run a > > > > passive measurement test consuming the measurement traffic. > > > > > > Within the context of this particular measurement, isn't this second > > > MA > > really an MP? In other words, is the fact that the MP is also in > > contact with the Controller (for other measurements) just a coincidence= ? > > > > > > > If we use > > > > MA =3D controlled by LMAP controller > > MP =3D not controlled by LMAP controller > > > > then both are MAs. The first one is running a somewhat degenerated > > measurement test that generates traffic, the second one is running a > > passive measurement test observing the traffic and generating results. > > Measurement tests can vary widely and we do not make any specific > > assumptions architecturally. >=20 > I think this is a workable definition, but in order to consider multiple = options > before settling on any particular, I'd like to suggest something just a l= ittle > different. > MA =3D as defined in framework: "The function that receives Instructions = from > a Controller, performs Measurement Tasks (perhaps in concert with a > Measurement Peer) and reports Measurement Results to a Collector." > MP =3D any endpoint that an MA communicates with as part of an Active > Measurement Task. >=20 > In this context, the MP is defined from the perspective of the MA as bein= g > "the other end of an Active Measurement Task from me (the MA)". > As such, the MP is not a function that has "functional requirements" of a= ny > sort nor is it a role that an MA has (because the MP is *always* not in t= he MA > we are looking at). If we focus our attention on an MA and look at things > from its perspective, then the MA is "here" and the MP is "not here". MP = is > an unknown (other than the IP address) "something". This "something" > might not even really know how to do the Active Measurement Task. The > MA can make no a priori assumptions about this "something" and a robust > MA should be designed with that in mind. This "something" and the fact th= at > details about it are unknown to the MA is an important concept. >=20 > Whether the MA's Controller (or the entity operating the MA's Controller) > knows about these "somethings" is unknown to the MA. The MA doesn't > know what the Controller or the entity knows. >=20 > Now consider 2 MAs (MA1 and MA2), each living in its own little world. Ea= ch > knows who its Controller is, knows its Measurement Methods, Reports and > Measures according to Instructions, and in all ways behaves like a perfec= t > little MA. There is an Active Measurement Task that occurs with these 2 M= As > as endpoints. What I am proposing is that MA1 sees MA2 as its MP, and MA2 > sees MA1 as its MP. MP has no functional requirements and cannot be > embodied as a role or function, because whatever MA we are focusing our > attention on (designing, Controlling, Instructing, getting Reports from, = etc.), > the MP is somewhere else. >=20 > If these 2 MAs are controlled by the same Controller, then that's fine. > Neither MA knows or cares. The Controller sees "MPs" as being whatever > one of its MAs is interacting with for an Active Measurement Task. >=20 > It's also fine if the 2 MAs have different Controllers operated by distin= ct > entities. Neither MA cares or knows. >=20 > If an entity wants to ensure that all endpoints involved in Active > Measurement Tasks are well-behaved and appropriately Controlled and > Instructed (i.e., they are all MAs), then that is something the entity ha= s to do. > How the entity does this is not in scope of lmap. And MAs do not care or > know whether its operating entity is doing this. > Barbara From ken.ko@adtran.com Thu Feb 13 07:55:31 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79AD1A02EE for ; Thu, 13 Feb 2014 07:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JI0KJJfvJtS for ; Thu, 13 Feb 2014 07:55:28 -0800 (PST) Received: from p02c11o145.mxlogic.net (p02c11o145.mxlogic.net [208.65.144.78]) by ietfa.amsl.com (Postfix) with ESMTP id 93AEC1A02E6 for ; Thu, 13 Feb 2014 07:55:28 -0800 (PST) Received: from unknown [76.164.174.83] (EHLO p02c11o145.mxlogic.net) by p02c11o145.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id feaecf25.2b49ce776940.71956.00-587.181397.p02c11o145.mxlogic.net (envelope-from ); Thu, 13 Feb 2014 08:55:27 -0700 (MST) X-MXL-Hash: 52fceaef73b93f1d-be0a29cbccb09ff04ce2ef00344d020ca38cccb7 Received: from unknown [76.164.174.83] by p02c11o145.mxlogic.net(mxl_mta-7.2.4-1) with SMTP id 9eaecf25.0.71356.00-165.181242.p02c11o145.mxlogic.net (envelope-from ); Thu, 13 Feb 2014 08:55:26 -0700 (MST) X-MXL-Hash: 52fceaee49ebc702-eb6fc7d5754e9474bf432116c88281bfb64ad6de Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 09:55:08 -0600 From: KEN KO To: Sharam Hakimi , "Bugenhagen, Michael K" , Juergen Schoenwaelder Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRdZ+UYn/wQ5EuM8kKUQT8gipqzMQ0QgABy6QD//55fIIAAZ/mA//+j05CAAAAq8IAAA6IwgAAD9jA= Date: Thu, 13 Feb 2014 15:55:07 +0000 Message-ID: References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B2362B@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02B2362B@spboexc01.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=VsOU9ZKn c=1 sm=1 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a] X-AnalysisOut: [=qZHQZMT3apYA:10 a=FBzmcnhlJawA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=_fbRkOfx] X-AnalysisOut: [OZYA:10 a=pTHmISxBAAAA:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8] X-AnalysisOut: [ a=bApCw-3XRBKkrRRokR4A:9 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA] X-AnalysisOut: [:10 a=JrSEOxZJtCQA:10 a=DAs2C8GDBtAA:10 a=lZB815dzVvQA:10 ] X-AnalysisOut: [a=zeshHG33Dl4A:10 a=r7riIz2-Wlj8g9Qe:21 a=elwzEimY_x0XXvGd] X-AnalysisOut: [:21] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014021308); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Cc: "STARK, BARBARA H" , Brian Trammell , "Cook, Charles" , "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:55:31 -0000 Sharam, I think the view you are expressing exposes a problem with interpreting MA = and MP as functions that are isolated from each other, more so than a cauti= on about whether to implement them in the same device. Even if you interpre= t them as functions (and I think a better model is the one proposed recentl= y by Barbara), if they are implemented together there should be nothing pre= venting them from coordinating with each other. Ken > -----Original Message----- > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: Thursday, February 13, 2014 10:46 AM > To: Bugenhagen, Michael K; Juergen Schoenwaelder > Cc: Cook, Charles; MORTON, ALFRED C (AL); lmap@ietf.org; KEN KO; STARK, > BARBARA H; Brian Trammell > Subject: RE: [lmap] MA vs MP >=20 > All, > I agree with Al, MP is a responder function and not under control of MC o= r > MA. MA uses an MP to perform a measurement task. >=20 > However, I would caution greatly on having a same device to have a MA and > MP function. These are two independent functions with no communications > between them. Two TCP-throughput test running at the same time can easily > overwhelm the network if not the single device and the two functions > (MA,MP ) will not have any information that the other one is running. >=20 > Sharam >=20 >=20 >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, > Michael K > Sent: Thursday, February 13, 2014 10:28 AM > To: 'Juergen Schoenwaelder' > Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; > 'STARK, BARBARA H'; 'Brian Trammell' > Subject: Re: [lmap] MA vs MP >=20 > Juergen - >=20 > If we are academically bound to a definition vs. use case requirement= s you > are correct. > This also indicates that MP's are just an abstract name for anything that > responds to a test that isn't under the control of the MC (if you follow = use > case requirements). > So MP's are existing artifacts like ping responders, TWAMP responders, = ... > anything that can be a test peer that isn't talking to the MA... >=20 > So MP's are not LMAP artifacts per say in your definition ? >=20 > Agreed ? - I'm ok with that >=20 > However - many people classify the MP as ALL and ANY test peer so that > definition breaks in that context and use... >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, February 13, 2014 9:23 AM > To: Bugenhagen, Michael K > Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; > 'STARK, BARBARA H'; 'Brian Trammell' > Subject: Re: [lmap] MA vs MP >=20 > On Thu, Feb 13, 2014 at 03:13:13PM +0000, Bugenhagen, Michael K wrote: >=20 > > IMO -- Somewhat of a cap statement - > > > > MC to MA/MP -- Scheduling goes to MA's only, but admin and > > control goes to both > > >=20 > By definition, the LMAP controller does not talk to an MP and hence the > above statement is false. >=20 > You are talking about a case where the controller talks to two MAs that c= arry > out a measurement between them. I believe the framework allows for this. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From Michael.K.Bugenhagen@centurylink.com Thu Feb 13 07:56:36 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EB21A02EE for ; Thu, 13 Feb 2014 07:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO2xIA9hMdQd for ; Thu, 13 Feb 2014 07:56:34 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 978CC1A02E6 for ; Thu, 13 Feb 2014 07:56:34 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1DFuSvc000635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Feb 2014 08:56:29 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 9483B1E005F; Thu, 13 Feb 2014 09:56:23 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 78C491E0074; Thu, 13 Feb 2014 09:56:23 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1DFuNtK012546; Thu, 13 Feb 2014 09:56:23 -0600 (CST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1DFuMBe012482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 09:56:22 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 09:56:21 -0600 From: "Bugenhagen, Michael K" To: "'Sharam Hakimi'" , "'Juergen Schoenwaelder'" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihk5qzMQ0QgABy6QD//55fIIAAZ/mA//+j05CAAAAq8IAAA6IwgAAEERA= Date: Thu, 13 Feb 2014 15:56:20 +0000 Message-ID: References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B2362B@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02B2362B@spboexc01.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Cook, Charles" , "'MORTON, ALFRED C \(AL\)'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:56:37 -0000 I wish we hadn't called it a Measurement Peer (MP)... Contextually that stomps all over different naming conventions and defie= s logic for many=20 MP is a very high level abstraction... that covers too much I would prefer some naming that actually reflects what it does - AMP (a= utonomous Measurement Peer)...=20 Which means it acts on it's one... So you'd have=20 LMAP MP's (which are MA's under the controller) Autonomous MP's (Which aren't under a MA or the Controller) Tongue in cheek - Depends how much job security you want - if they can't = understand it with plane old semantics don't change it :) I'm good now that we're all on the same page - What are the group's druthers (what definition does the group want / think= is appropriate). Mike -----Original Message----- From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]=20 Sent: Thursday, February 13, 2014 9:46 AM To: Bugenhagen, Michael K; Juergen Schoenwaelder Cc: Cook, Charles; MORTON, ALFRED C (AL); lmap@ietf.org; KEN KO; STARK, BAR= BARA H; Brian Trammell Subject: RE: [lmap] MA vs MP All, I agree with Al, MP is a responder function and not under control of MC or = MA. MA uses an MP to perform a measurement task.=20 However, I would caution greatly on having a same device to have a MA and M= P function. These are two independent functions with no communications betw= een them. Two TCP-throughput test running at the same time can easily overw= helm the network if not the single device and the two functions (MA,MP ) wi= ll not have any information that the other one is running. Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael = K Sent: Thursday, February 13, 2014 10:28 AM To: 'Juergen Schoenwaelder' Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; 'STA= RK, BARBARA H'; 'Brian Trammell' Subject: Re: [lmap] MA vs MP Juergen - If we are academically bound to a definition vs. use case requirements = you are correct. This also indicates that MP's are just an abstract name for anything that r= esponds to a test that isn't under the control of the MC (if you follow use= case requirements). So MP's are existing artifacts like ping responders, TWAMP responders, ..= . anything that can be a test peer that isn't talking to the MA... So MP's are not LMAP artifacts per say in your definition ? Agreed ? - I'm ok with that=20 However - many people classify the MP as ALL and ANY test peer so that defi= nition breaks in that context and use... -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, February 13, 2014 9:23 AM To: Bugenhagen, Michael K Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; 'STA= RK, BARBARA H'; 'Brian Trammell' Subject: Re: [lmap] MA vs MP On Thu, Feb 13, 2014 at 03:13:13PM +0000, Bugenhagen, Michael K wrote: > IMO -- Somewhat of a cap statement - >=20 > MC to MA/MP -- Scheduling goes to MA's only, but admin and=20 > control goes to both >=20 By definition, the LMAP controller does not talk to an MP and hence the abo= ve statement is false. You are talking about a case where the controller talks to two MAs that car= ry out a measurement between them. I believe the framework allows for this. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From sharam.hakimi@exfo.com Thu Feb 13 08:24:06 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360E41A031A for ; Thu, 13 Feb 2014 08:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B1E329ntwC4 for ; Thu, 13 Feb 2014 08:24:03 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id C80CD1A0314 for ; Thu, 13 Feb 2014 08:24:02 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 11:24:01 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 11:24:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Feb 2014 11:15:17 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B23647@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRdZ+UYn/wQ5EuM8kKUQT8gipqzMQ0QgABy6QD//55fIIAAZ/mA//+j05CAAAAq8IAAA6IwgAAD9jCAAAUHwA== References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B2362B@spboexc01.exfo.com> From: "Sharam Hakimi" To: "KEN KO" , "Bugenhagen, Michael K" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 13 Feb 2014 16:24:01.0489 (UTC) FILETIME=[012E4410:01CF28D8] Cc: "STARK, BARBARA H" , Brian Trammell , "Cook, Charles" , "MORTON, ALFRED C \(AL\)" , lmap@ietf.org Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:24:06 -0000 Ken, Maybe it would be good to have three entities: MA MP=20 MA and MP Combination Cautions, or warnings will not work in my opinion and forcing users to only use one function in a single device will most likely not be acceptable. This way a combination device will be aware of the other and effectively execute one test at a time (internally sequenced). Sharam -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com]=20 Sent: Thursday, February 13, 2014 10:55 AM To: Sharam Hakimi; Bugenhagen, Michael K; Juergen Schoenwaelder Cc: Cook, Charles; MORTON, ALFRED C (AL); lmap@ietf.org; STARK, BARBARA H; Brian Trammell Subject: RE: [lmap] MA vs MP Sharam, I think the view you are expressing exposes a problem with interpreting MA and MP as functions that are isolated from each other, more so than a caution about whether to implement them in the same device. Even if you interpret them as functions (and I think a better model is the one proposed recently by Barbara), if they are implemented together there should be nothing preventing them from coordinating with each other. Ken > -----Original Message----- > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: Thursday, February 13, 2014 10:46 AM > To: Bugenhagen, Michael K; Juergen Schoenwaelder > Cc: Cook, Charles; MORTON, ALFRED C (AL); lmap@ietf.org; KEN KO; STARK, > BARBARA H; Brian Trammell > Subject: RE: [lmap] MA vs MP >=20 > All, > I agree with Al, MP is a responder function and not under control of MC or > MA. MA uses an MP to perform a measurement task. >=20 > However, I would caution greatly on having a same device to have a MA and > MP function. These are two independent functions with no communications > between them. Two TCP-throughput test running at the same time can easily > overwhelm the network if not the single device and the two functions > (MA,MP ) will not have any information that the other one is running. >=20 > Sharam >=20 >=20 >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, > Michael K > Sent: Thursday, February 13, 2014 10:28 AM > To: 'Juergen Schoenwaelder' > Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; > 'STARK, BARBARA H'; 'Brian Trammell' > Subject: Re: [lmap] MA vs MP >=20 > Juergen - >=20 > If we are academically bound to a definition vs. use case requirements you > are correct. > This also indicates that MP's are just an abstract name for anything that > responds to a test that isn't under the control of the MC (if you follow use > case requirements). > So MP's are existing artifacts like ping responders, TWAMP responders, ... > anything that can be a test peer that isn't talking to the MA... >=20 > So MP's are not LMAP artifacts per say in your definition ? >=20 > Agreed ? - I'm ok with that >=20 > However - many people classify the MP as ALL and ANY test peer so that > definition breaks in that context and use... >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, February 13, 2014 9:23 AM > To: Bugenhagen, Michael K > Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN KO'; > 'STARK, BARBARA H'; 'Brian Trammell' > Subject: Re: [lmap] MA vs MP >=20 > On Thu, Feb 13, 2014 at 03:13:13PM +0000, Bugenhagen, Michael K wrote: >=20 > > IMO -- Somewhat of a cap statement - > > > > MC to MA/MP -- Scheduling goes to MA's only, but admin and > > control goes to both > > >=20 > By definition, the LMAP controller does not talk to an MP and hence the > above statement is false. >=20 > You are talking about a case where the controller talks to two MAs that carry > out a measurement between them. I believe the framework allows for this. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From dromasca@avaya.com Thu Feb 13 08:24:13 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686BD1A0315 for ; Thu, 13 Feb 2014 08:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCJMpr8s92Oa for ; Thu, 13 Feb 2014 08:24:10 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8B21A033F for ; Thu, 13 Feb 2014 08:24:10 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIOAFLw/FLGmAcV/2dsb2JhbABZgkIjIThXqCkDBZcbgRcWdIInAQEDEgsQXgEMCRVWJgEEGwEZh2MBDJZThFKtAo4oAQEegmcPZoEUBJ8bizSBb4E+gXE5 X-IronPort-AV: E=Sophos;i="4.95,839,1384318800"; d="scan'208,217";a="42861818" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Feb 2014 11:24:06 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 13 Feb 2014 11:12:40 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 17:24:04 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Working Group Last Call for http://www.ietf.org/id/draft-ietf-lmap-use-cases-02.txt Thread-Index: Ac8o2AJS6aCwsIm0Qm+Xzcg0odywXw== Date: Thu, 13 Feb 2014 16:24:03 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E40ADF3@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E40ADF3AZFFEXMB04globa_" MIME-Version: 1.0 Subject: [lmap] Working Group Last Call for http://www.ietf.org/id/draft-ietf-lmap-use-cases-02.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:24:13 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E40ADF3AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a Working Group Last Call for the Internet-Draft 'Large-Scale Broad= band Measurement Use Cases' which can be found at http://www.ietf.org/id/draft-ietf-lmap-use-cases-02.txt. Please send your c= omments about this I-D to the WG mail list until 2/27/13. If you have no c= omments but you believe that the document is ready to be submitted to the I= ESG for consideration as Informational RFC a short mail stating this is als= o welcome. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E40ADF3AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
This is a Working Group Last Call for the Internet-Draft ‘Large-=
Scale Broadband Measurement Use Cases’ which can be found at

http://www.ietf.org/id/draft-ietf-lmap-use-cases-02.= txt. Please send your comments about this I-D to the WG mail list until 2/2= 7/13.  If you have no comments but you believe that the document is re= ady to be submitted to the IESG for consideration as Informational RFC a short mail stating this is also welcome.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E40ADF3AZFFEXMB04globa_-- From dromasca@avaya.com Thu Feb 13 08:38:32 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0271A035F for ; Thu, 13 Feb 2014 08:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Mhm9U8xB4SO for ; Thu, 13 Feb 2014 08:38:27 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 37D6F1A035C for ; Thu, 13 Feb 2014 08:38:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwOALX0/FKHCzI1/2dsb2JhbABZgkIjIThXqCkIlxuBGBZ0gicBAQMSG14BDAkVViYBBBsBGYdjAQyWWoRSrGkXjkiCZw9mgRQEnxuLNIMtgio X-IronPort-AV: E=Sophos;i="4.95,839,1384318800"; d="scan'208,217";a="49336492" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Feb 2014 11:37:52 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 13 Feb 2014 11:24:57 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 17:37:51 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: preliminary agenda for the ietf-89 lmap wg meeting Thread-Index: Ac8o2e6qDOmWXH4YTqyO2FUENnnaSw== Date: Thu, 13 Feb 2014 16:37:49 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E40AE5E@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AE5EAZFFEXMB04globa_" MIME-Version: 1.0 Subject: [lmap] preliminary agenda for the ietf-89 lmap wg meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:38:32 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AE5EAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have uploaded a preliminary agenda for the lmap wg meeting at ietf-89 at = http://www.ietf.org/proceedings/89/agenda/agenda-89-lmap. We are scheduled = to meet on Friday 3/7, 0900-1130. Please adjust your travel plans according= ly. If there are other items which would benefit from discussion at the mee= ting please let Jason and me know. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AE5EAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have uploaded a preliminary agenda for the lmap wg= meeting at ietf-89 at http:/= /www.ietf.org/proceedings/89/agenda/agenda-89-lmap. We are scheduled to= meet on Friday 3/7, 0900-1130. Please adjust your travel plans accordingly= . If there are other items which would benefit from discussion at the meeting please let Jason and me know. =

 

Thanks and Regards,


Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AE5EAZFFEXMB04globa_-- From nobody Thu Feb 13 09:52:03 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0B81A038F for ; Thu, 13 Feb 2014 09:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzFPDNnhY43b for ; Thu, 13 Feb 2014 09:51:58 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id DA27F1A03AA for ; Thu, 13 Feb 2014 09:51:57 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 13 Feb 2014 17:51:33 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Thu, 13 Feb 2014 17:51:51 +0000 From: To: , , , Date: Thu, 13 Feb 2014 17:51:50 +0000 Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRdZ+UYn/wQ5EuM8kKUQT8gipqzMQ0QgABy6QD//55fIIAAZ/mA//+j05CAAAAq8IAAA6IwgAAD9jCAAAUHwIAAGaaw Message-ID: References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B2362B@spboexc01.exfo.com> <084CDC75FEC1E640B60338273BEACDFA02B23647@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02B23647@spboexc01.exfo.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Rjv4keIGfXIfyOB7nwTuYiHwC28 Cc: acmorton@att.com, Charles.Cook2@centurylink.com, bs7652@att.com, lmap@ietf.org, trammell@tik.ee.ethz.ch Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:52:01 -0000 I don't think we need to define a combined MA-MP function. In a subsequent phase of LMAP we might work on an intra-device interface, i= e between MA & MP on the same device - think it's quite likely this could e= nable some fun things (such as sharam's example).=20 At the moment we're not working on such an intra-device interface, so I don= 't see the need to define a combined MA-MP function. re sharam's problem scenario - I think this will largely be avoided because= we assume single party control (and that party designs the measurement sys= tem carefully). Best wishes phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi > Sent: 13 February 2014 16:15 > To: KEN KO; Bugenhagen, Michael K; Juergen Schoenwaelder > Cc: STARK, BARBARA H; Brian Trammell; Cook, Charles; MORTON, ALFRED C > (AL); lmap@ietf.org > Subject: Re: [lmap] MA vs MP >=20 > Ken, > Maybe it would be good to have three entities: >=20 > MA > MP > MA and MP Combination >=20 >=20 > Cautions, or warnings will not work in my opinion and forcing users to > only use one function in a single device will most likely not be > acceptable. >=20 > This way a combination device will be aware of the other and > effectively execute one test at a time (internally sequenced). >=20 >=20 > Sharam >=20 >=20 >=20 > -----Original Message----- > From: KEN KO [mailto:KEN.KO@adtran.com] > Sent: Thursday, February 13, 2014 10:55 AM > To: Sharam Hakimi; Bugenhagen, Michael K; Juergen Schoenwaelder > Cc: Cook, Charles; MORTON, ALFRED C (AL); lmap@ietf.org; STARK, BARBARA > H; Brian Trammell > Subject: RE: [lmap] MA vs MP >=20 > Sharam, >=20 > I think the view you are expressing exposes a problem with interpreting > MA and MP as functions that are isolated from each other, more so than > a caution about whether to implement them in the same device. Even if > you interpret them as functions (and I think a better model is the one > proposed recently by Barbara), if they are implemented together there > should be nothing preventing them from coordinating with each other. >=20 > Ken >=20 > > -----Original Message----- > > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > Sent: Thursday, February 13, 2014 10:46 AM > > To: Bugenhagen, Michael K; Juergen Schoenwaelder > > Cc: Cook, Charles; MORTON, ALFRED C (AL); lmap@ietf.org; KEN KO; > STARK, > > BARBARA H; Brian Trammell > > Subject: RE: [lmap] MA vs MP > > > > All, > > I agree with Al, MP is a responder function and not under control of > MC or > > MA. MA uses an MP to perform a measurement task. > > > > However, I would caution greatly on having a same device to have a MA > and > > MP function. These are two independent functions with no > communications > > between them. Two TCP-throughput test running at the same time can > easily > > overwhelm the network if not the single device and the two functions > > (MA,MP ) will not have any information that the other one is running. > > > > Sharam > > > > > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, > > Michael K > > Sent: Thursday, February 13, 2014 10:28 AM > > To: 'Juergen Schoenwaelder' > > Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN > KO'; > > 'STARK, BARBARA H'; 'Brian Trammell' > > Subject: Re: [lmap] MA vs MP > > > > Juergen - > > > > If we are academically bound to a definition vs. use case > requirements you > > are correct. > > This also indicates that MP's are just an abstract name for anything > that > > responds to a test that isn't under the control of the MC (if you > follow use > > case requirements). > > So MP's are existing artifacts like ping responders, TWAMP > responders, ... > > anything that can be a test peer that isn't talking to the MA... > > > > So MP's are not LMAP artifacts per say in your definition ? > > > > Agreed ? - I'm ok with that > > > > However - many people classify the MP as ALL and ANY test peer so > that > > definition breaks in that context and use... > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, February 13, 2014 9:23 AM > > To: Bugenhagen, Michael K > > Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN > KO'; > > 'STARK, BARBARA H'; 'Brian Trammell' > > Subject: Re: [lmap] MA vs MP > > > > On Thu, Feb 13, 2014 at 03:13:13PM +0000, Bugenhagen, Michael K > wrote: > > > > > IMO -- Somewhat of a cap statement - > > > > > > MC to MA/MP -- Scheduling goes to MA's only, but admin and > > > control goes to both > > > > > > > By definition, the LMAP controller does not talk to an MP and hence > the > > above statement is false. > > > > You are talking about a case where the controller talks to two MAs > that carry > > out a measurement between them. I believe the framework allows for > this. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Feb 13 10:11:51 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C7B1A039D for ; Thu, 13 Feb 2014 10:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dao5_g09GAay for ; Thu, 13 Feb 2014 10:11:41 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 30FC61A03AF for ; Thu, 13 Feb 2014 10:11:39 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1DIBTha008111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Feb 2014 12:11:30 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id BAFCB1E006F; Thu, 13 Feb 2014 12:11:24 -0600 (CST) Received: from sudnp797.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 77B3D1E005B; Thu, 13 Feb 2014 12:11:24 -0600 (CST) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1DIBNM6018755; Thu, 13 Feb 2014 11:11:24 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1DIBNZO018742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 11:11:23 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 12:11:22 -0600 From: "Bugenhagen, Michael K" To: "'philip.eardley@bt.com'" , "'sharam.hakimi@exfo.com'" , "'KEN.KO@adtran.com'" , "'j.schoenwaelder@jacobs-university.de'" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihk5qzMQ0QgABy6QD//55fIIAAZ/mA//+j05CAAAAq8IAAA6IwgAAD9jCAAAUHwIAAGaawgAAE0kA= Date: Thu, 13 Feb 2014 18:11:21 +0000 Message-ID: References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B2362B@spboexc01.exfo.com> <084CDC75FEC1E640B60338273BEACDFA02B23647@spboexc01.exfo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2gX3bR9dmxxsZOy72JUXTIOYUVI Cc: "'acmorton@att.com'" , "Cook, Charles" , "'bs7652@att.com'" , "'lmap@ietf.org'" , "'trammell@tik.ee.ethz.ch'" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:11:49 -0000 What we do is up to the group -- but just a thought... When choosing naming - some advice for Cloud... Cloud API's use "abstractions" to handle when two different vendors, SDO's,= or Service providers naming don't align for a given network function or ro= le... So IF... IF you want to grab the "cloud" API place holder you MUST have ver= y, very tight hierarchical naming conventions that bind very clearly to spe= cific levels and roles. As they told Indiana Jones in the Movie - Choose well.... Example - EVC generically covers all VLANS of all types... The MEF assigned EVC as being terminated ONLY on UNI's...=20 So when they added Ethernet ACCES we had to say it's an OVC. BUT - in the API object model used between companies a EVC was the abstract= construct for everything. So now we're faced with fixing that mess as we move to a NaaS API ... what = to call an Ethernet Segment - EVC ? one of the SDO's used that abstract co= ntextually so we have breakage. So.... Sorry for the preaching - but choose naming ("abstractions") nomenclature = very carefully - if it doesn't fit as ubiquitous in the industry it will fa= il when applied in a Service Construct API, .which is why I offered the Hierarchical view of doing the naming conventio= n - Given NFV is about to break loose - I think all going for the ride should keep their arms and legs inside th= e car at all times... =20 Which is a great metaphor for an amusement park ride rules for observing no= n-cloud portable abstractions that could get sheared off - you can do it...= the result may be fun, or not so fun. Maybe my example will be lost in translation - but it might be worth observ= ing. I have said enough on it so unless someone asks specifically I'm good. Thanks, Mike -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Thursday, February 13, 2014 11:52 AM To: sharam.hakimi@exfo.com; KEN.KO@adtran.com; Bugenhagen, Michael K; j.sch= oenwaelder@jacobs-university.de Cc: bs7652@att.com; trammell@tik.ee.ethz.ch; Cook, Charles; acmorton@att.co= m; lmap@ietf.org Subject: RE: [lmap] MA vs MP I don't think we need to define a combined MA-MP function. In a subsequent phase of LMAP we might work on an intra-device interface, i= e between MA & MP on the same device - think it's quite likely this could e= nable some fun things (such as sharam's example).=20 At the moment we're not working on such an intra-device interface, so I don= 't see the need to define a combined MA-MP function. re sharam's problem scenario - I think this will largely be avoided because= we assume single party control (and that party designs the measurement sys= tem carefully). Best wishes phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi > Sent: 13 February 2014 16:15 > To: KEN KO; Bugenhagen, Michael K; Juergen Schoenwaelder > Cc: STARK, BARBARA H; Brian Trammell; Cook, Charles; MORTON, ALFRED C=20 > (AL); lmap@ietf.org > Subject: Re: [lmap] MA vs MP >=20 > Ken, > Maybe it would be good to have three entities: >=20 > MA > MP > MA and MP Combination >=20 >=20 > Cautions, or warnings will not work in my opinion and forcing users to=20 > only use one function in a single device will most likely not be=20 > acceptable. >=20 > This way a combination device will be aware of the other and=20 > effectively execute one test at a time (internally sequenced). >=20 >=20 > Sharam >=20 >=20 >=20 > -----Original Message----- > From: KEN KO [mailto:KEN.KO@adtran.com] > Sent: Thursday, February 13, 2014 10:55 AM > To: Sharam Hakimi; Bugenhagen, Michael K; Juergen Schoenwaelder > Cc: Cook, Charles; MORTON, ALFRED C (AL); lmap@ietf.org; STARK,=20 > BARBARA H; Brian Trammell > Subject: RE: [lmap] MA vs MP >=20 > Sharam, >=20 > I think the view you are expressing exposes a problem with=20 > interpreting MA and MP as functions that are isolated from each other,=20 > more so than a caution about whether to implement them in the same=20 > device. Even if you interpret them as functions (and I think a better=20 > model is the one proposed recently by Barbara), if they are=20 > implemented together there should be nothing preventing them from coordin= ating with each other. >=20 > Ken >=20 > > -----Original Message----- > > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > Sent: Thursday, February 13, 2014 10:46 AM > > To: Bugenhagen, Michael K; Juergen Schoenwaelder > > Cc: Cook, Charles; MORTON, ALFRED C (AL); lmap@ietf.org; KEN KO; > STARK, > > BARBARA H; Brian Trammell > > Subject: RE: [lmap] MA vs MP > > > > All, > > I agree with Al, MP is a responder function and not under control of > MC or > > MA. MA uses an MP to perform a measurement task. > > > > However, I would caution greatly on having a same device to have a=20 > > MA > and > > MP function. These are two independent functions with no > communications > > between them. Two TCP-throughput test running at the same time can > easily > > overwhelm the network if not the single device and the two functions=20 > > (MA,MP ) will not have any information that the other one is running. > > > > Sharam > > > > > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen,=20 > > Michael K > > Sent: Thursday, February 13, 2014 10:28 AM > > To: 'Juergen Schoenwaelder' > > Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN > KO'; > > 'STARK, BARBARA H'; 'Brian Trammell' > > Subject: Re: [lmap] MA vs MP > > > > Juergen - > > > > If we are academically bound to a definition vs. use case > requirements you > > are correct. > > This also indicates that MP's are just an abstract name for anything > that > > responds to a test that isn't under the control of the MC (if you > follow use > > case requirements). > > So MP's are existing artifacts like ping responders, TWAMP > responders, ... > > anything that can be a test peer that isn't talking to the MA... > > > > So MP's are not LMAP artifacts per say in your definition ? > > > > Agreed ? - I'm ok with that > > > > However - many people classify the MP as ALL and ANY test peer so > that > > definition breaks in that context and use... > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, February 13, 2014 9:23 AM > > To: Bugenhagen, Michael K > > Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN > KO'; > > 'STARK, BARBARA H'; 'Brian Trammell' > > Subject: Re: [lmap] MA vs MP > > > > On Thu, Feb 13, 2014 at 03:13:13PM +0000, Bugenhagen, Michael K > wrote: > > > > > IMO -- Somewhat of a cap statement - > > > > > > MC to MA/MP -- Scheduling goes to MA's only, but admin and=20 > > > control goes to both > > > > > > > By definition, the LMAP controller does not talk to an MP and hence > the > > above statement is false. > > > > You are talking about a case where the controller talks to two MAs > that carry > > out a measurement between them. I believe the framework allows for > this. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Feb 13 11:13:47 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D7B1A0430 for ; Thu, 13 Feb 2014 11:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaOlUcU5vuxU for ; Thu, 13 Feb 2014 11:13:42 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id D61221A0427 for ; Thu, 13 Feb 2014 11:13:41 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 14:13:40 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 14:13:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Feb 2014 14:13:40 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B236B4@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihk5qzMQ0QgABy6QD//55fIIAAZ/mA//+j05CAAAAq8IAAA6IwgAAD9jCAAAUHwIAAGaawgAAE0kCAABIlcA== References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B2362B@spboexc01.exfo.com> <084CDC75FEC1E640B60338273BEACDFA02B23647@spboexc01.exfo.com> From: "Sharam Hakimi" To: "Bugenhagen, Michael K" , , , X-OriginalArrivalTime: 13 Feb 2014 19:13:40.0113 (UTC) FILETIME=[B41D0810:01CF28EF] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/27EmK9yDA17QDpTBg1GgRjC9ZRI Cc: acmorton@att.com, "Cook, Charles" , bs7652@att.com, lmap@ietf.org, trammell@tik.ee.ethz.ch Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:13:45 -0000 Phil, We can kick the can down the road and try to deal with it later, however, even if one entity is designing the network this is a very easy thing to do. All one would have to do is to set the device to be an MP and that device is at the mercy of all other MAs that will use it as a responder at any time. When that device is set to be an MA also, then we are asking the user to coordinate all other schedules that use that device as an MP to not to clash with the MA schedule running on that device. Are you still following me? I personally do not believe that the user will have the necessary information to be able to make that decision even if they really tried, but that is my opinion. Cheers, Sharam =20 -----Original Message----- From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com]=20 Sent: Thursday, February 13, 2014 1:11 PM To: 'philip.eardley@bt.com'; Sharam Hakimi; 'KEN.KO@adtran.com'; 'j.schoenwaelder@jacobs-university.de' Cc: 'bs7652@att.com'; 'trammell@tik.ee.ethz.ch'; Cook, Charles; 'acmorton@att.com'; 'lmap@ietf.org' Subject: RE: [lmap] MA vs MP What we do is up to the group -- but just a thought... When choosing naming - some advice for Cloud... Cloud API's use "abstractions" to handle when two different vendors, SDO's, or Service providers naming don't align for a given network function or role... So IF... IF you want to grab the "cloud" API place holder you MUST have very, very tight hierarchical naming conventions that bind very clearly to specific levels and roles. As they told Indiana Jones in the Movie - Choose well.... Example - EVC generically covers all VLANS of all types... The MEF assigned EVC as being terminated ONLY on UNI's...=20 So when they added Ethernet ACCES we had to say it's an OVC. BUT - in the API object model used between companies a EVC was the abstract construct for everything. So now we're faced with fixing that mess as we move to a NaaS API ... what to call an Ethernet Segment - EVC ? one of the SDO's used that abstract contextually so we have breakage. So.... Sorry for the preaching - but choose naming ("abstractions") nomenclature very carefully - if it doesn't fit as ubiquitous in the industry it will fail when applied in a Service Construct API, .which is why I offered the Hierarchical view of doing the naming convention - Given NFV is about to break loose - I think all going for the ride should keep their arms and legs inside the car at all times... =20 Which is a great metaphor for an amusement park ride rules for observing non-cloud portable abstractions that could get sheared off - you can do it... the result may be fun, or not so fun. Maybe my example will be lost in translation - but it might be worth observing. I have said enough on it so unless someone asks specifically I'm good. Thanks, Mike -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Thursday, February 13, 2014 11:52 AM To: sharam.hakimi@exfo.com; KEN.KO@adtran.com; Bugenhagen, Michael K; j.schoenwaelder@jacobs-university.de Cc: bs7652@att.com; trammell@tik.ee.ethz.ch; Cook, Charles; acmorton@att.com; lmap@ietf.org Subject: RE: [lmap] MA vs MP I don't think we need to define a combined MA-MP function. In a subsequent phase of LMAP we might work on an intra-device interface, ie between MA & MP on the same device - think it's quite likely this could enable some fun things (such as sharam's example).=20 At the moment we're not working on such an intra-device interface, so I don't see the need to define a combined MA-MP function. re sharam's problem scenario - I think this will largely be avoided because we assume single party control (and that party designs the measurement system carefully). Best wishes phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi > Sent: 13 February 2014 16:15 > To: KEN KO; Bugenhagen, Michael K; Juergen Schoenwaelder > Cc: STARK, BARBARA H; Brian Trammell; Cook, Charles; MORTON, ALFRED C=20 > (AL); lmap@ietf.org > Subject: Re: [lmap] MA vs MP >=20 > Ken, > Maybe it would be good to have three entities: >=20 > MA > MP > MA and MP Combination >=20 >=20 > Cautions, or warnings will not work in my opinion and forcing users to > only use one function in a single device will most likely not be=20 > acceptable. >=20 > This way a combination device will be aware of the other and=20 > effectively execute one test at a time (internally sequenced). >=20 >=20 > Sharam >=20 >=20 >=20 > -----Original Message----- > From: KEN KO [mailto:KEN.KO@adtran.com] > Sent: Thursday, February 13, 2014 10:55 AM > To: Sharam Hakimi; Bugenhagen, Michael K; Juergen Schoenwaelder > Cc: Cook, Charles; MORTON, ALFRED C (AL); lmap@ietf.org; STARK,=20 > BARBARA H; Brian Trammell > Subject: RE: [lmap] MA vs MP >=20 > Sharam, >=20 > I think the view you are expressing exposes a problem with=20 > interpreting MA and MP as functions that are isolated from each other, > more so than a caution about whether to implement them in the same=20 > device. Even if you interpret them as functions (and I think a better=20 > model is the one proposed recently by Barbara), if they are=20 > implemented together there should be nothing preventing them from coordinating with each other. >=20 > Ken >=20 > > -----Original Message----- > > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > Sent: Thursday, February 13, 2014 10:46 AM > > To: Bugenhagen, Michael K; Juergen Schoenwaelder > > Cc: Cook, Charles; MORTON, ALFRED C (AL); lmap@ietf.org; KEN KO; > STARK, > > BARBARA H; Brian Trammell > > Subject: RE: [lmap] MA vs MP > > > > All, > > I agree with Al, MP is a responder function and not under control of > MC or > > MA. MA uses an MP to perform a measurement task. > > > > However, I would caution greatly on having a same device to have a=20 > > MA > and > > MP function. These are two independent functions with no > communications > > between them. Two TCP-throughput test running at the same time can > easily > > overwhelm the network if not the single device and the two functions > > (MA,MP ) will not have any information that the other one is running. > > > > Sharam > > > > > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen,=20 > > Michael K > > Sent: Thursday, February 13, 2014 10:28 AM > > To: 'Juergen Schoenwaelder' > > Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN > KO'; > > 'STARK, BARBARA H'; 'Brian Trammell' > > Subject: Re: [lmap] MA vs MP > > > > Juergen - > > > > If we are academically bound to a definition vs. use case > requirements you > > are correct. > > This also indicates that MP's are just an abstract name for anything > that > > responds to a test that isn't under the control of the MC (if you > follow use > > case requirements). > > So MP's are existing artifacts like ping responders, TWAMP > responders, ... > > anything that can be a test peer that isn't talking to the MA... > > > > So MP's are not LMAP artifacts per say in your definition ? > > > > Agreed ? - I'm ok with that > > > > However - many people classify the MP as ALL and ANY test peer so > that > > definition breaks in that context and use... > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, February 13, 2014 9:23 AM > > To: Bugenhagen, Michael K > > Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; 'lmap@ietf.org'; 'KEN > KO'; > > 'STARK, BARBARA H'; 'Brian Trammell' > > Subject: Re: [lmap] MA vs MP > > > > On Thu, Feb 13, 2014 at 03:13:13PM +0000, Bugenhagen, Michael K > wrote: > > > > > IMO -- Somewhat of a cap statement - > > > > > > MC to MA/MP -- Scheduling goes to MA's only, but admin and=20 > > > control goes to both > > > > > > > By definition, the LMAP controller does not talk to an MP and hence > the > > above statement is false. > > > > You are talking about a case where the controller talks to two MAs > that carry > > out a measurement between them. I believe the framework allows for > this. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Feb 13 13:08:06 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870AA1A0376 for ; Thu, 13 Feb 2014 13:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm_ovPGOAopq for ; Thu, 13 Feb 2014 13:08:02 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id F1DCD1A04EC for ; Thu, 13 Feb 2014 13:08:01 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 1343df25.2ac0ba22f940.1332879.00-2475.3739053.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 13 Feb 2014 21:08:01 +0000 (UTC) X-MXL-Hash: 52fd343163c3f3f9-a255649024943cef6f55cf7d0d7ab8be228c8b46 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 3e33df25.0.1331877.00-2018.3736265.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 13 Feb 2014 21:06:45 +0000 (UTC) X-MXL-Hash: 52fd33e52c156a47-79a714a292311ebdc972d1f7fc80880222b46ec5 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1DL6gYp019683; Thu, 13 Feb 2014 16:06:42 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1DL6XLA019562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Feb 2014 16:06:38 -0500 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 13 Feb 2014 21:06:22 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 16:06:22 -0500 From: "STARK, BARBARA H" To: Sharam Hakimi , "Bugenhagen, Michael K" , "philip.eardley@bt.com" , "KEN.KO@adtran.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRkqyuqLftGYUCRyHP6AveWe5qzMQ0QgABy6QD//55fIIAAZ/mA//+j05CAAAAq8IAAA6IwgAAD9jCAAAUHwIAAGaawgAAE0kCAABIlcIAAFqvQ Date: Thu, 13 Feb 2014 21:06:21 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303E6EB2@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B2362B@spboexc01.exfo.com> <084CDC75FEC1E640B60338273BEACDFA02B23647@spboexc01.exfo.com> <084CDC75FEC1E640B60338273BEACDFA02B236B4@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02B236B4@spboexc01.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.165.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=-ayHiJ6liBIA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=_fbRkOfxO] X-AnalysisOut: [ZYA:10 a=MpgoyGSYCithm_OGlDsA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/17xNA31RQrvZpuU2h9sqzXq8gJw Cc: "lmap@ietf.org" , "Cook, Charles" , "MORTON JR., AL" , "trammell@tik.ee.ethz.ch" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:08:04 -0000 > We can kick the can down the road and try to deal with it later, however, > even if one entity is designing the network this is a very easy thing to = do. All > one would have to do is to set the device to be an MP and that device is = at > the mercy of all other MAs that will use it as a responder at any time. W= hen > that device is set to be an MA also, then we are asking the user to coord= inate > all other schedules that use that device as an MP to not to clash with th= e MA > schedule running on that device. Are you still following me? >=20 > I personally do not believe that the user will have the necessary informa= tion > to be able to make that decision even if they really tried, but that is m= y > opinion. I didn't think we were asking the user to do anything at all. We have speci= fied things we expect of an MA. For example, we want an MA to either report= if "other" things happened during a Measurement Task that could impact the= Measurement Task (e.g., other packets were transmitted/received during thi= s Measurement Task) or to hold off starting a scheduled Measurement Task if= "other" things are happening or to refuse to participate in a Measurement = Task with some other MA if it is busy doing its own Measurement Task. Such = behavior might be hard-coded (in a simple MA) or a configuration option in = a more capable MA. If it could be a configuration option, then this would n= eed to be reflected in an Information Model of some sort. For example, let's say MA1 is participating in an Active Measurement Task t= hat was initiated by MA2. MA1 is now MA2's MP and MA2 is MA1's MP (accordin= g to my proposed viewpoint). MA1 told its Controller that it was capable of= participating in this Active Measurement Method in this manner and was con= figured by its Controller to enable such participation, and also to collect= and subsequently report certain passive measurements when it was participa= ting in a Task of this Method. MA2 told its Controller about its ability to= do this Active Measurement Method and its Controller scheduled it to initi= ate an Active Measurement Task at a particular time and report results. MA1= may also be scheduled to initiate a different Active Measurement Task whil= e it is busy with MA2. MA1 knows it is busy with MA2. MA1 is hard-coded to = delay its own scheduled Tasks in such an event and to refuse any requests t= o participate in other Tasks that it receives during its own scheduled Task= s. This isn't that hard to code, as long as the MA knows everything it's do= ing (and the functionality isn't split unnecessarily into separate Function= s that potentially have no visibility into what the other is doing). A simpler MA may not support any Active Measurement Methods initiated by ot= her MAs. That's ok. Or it may only support Active Measurements initiated by= other MAs and have no ability to initiate (schedule) its own Measurement T= asks. That's ok, too. There is no mandatory-to-implement Measurement Method= . Now consider the case where MA1 and MA2 are within the same operational dom= ain (and potentially, but not necessarily, under the same Controller). The = operator of this domain could potentially configure the 2 MAs so MA1 is abl= e to authenticate MA2 before proceeding with a Measurement Task (if that's = something that can be done for that Measurement Method). Or so that MA1 and= MA2 schedules are coordinated and won't overlap. Nothing in lmap defines h= ow the operator coordinates the schedules of its MAs (because it's not in s= cope of lmap). But nothing in lmap precludes an operator from doing this. I= t's left as an exercise to the operator. (Not the end user.) We don't need functional requirements for a second Measurement-Method-capab= le, Controller-managed, Collector-reporting function. One term (MA) is enou= gh. More than one is redundant and confusing. Barbara From nobody Fri Feb 14 00:10:49 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75EF1A0121 for ; Fri, 14 Feb 2014 00:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vc3yUVEO2HsK for ; Fri, 14 Feb 2014 00:10:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D796F1A0114 for ; Fri, 14 Feb 2014 00:10:45 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E9AE20034; Fri, 14 Feb 2014 09:10:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dqqQ-xg21Skp; Fri, 14 Feb 2014 09:10:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDA2A20054; Fri, 14 Feb 2014 09:10:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8ADDF2B4BC00; Fri, 14 Feb 2014 08:18:21 +0100 (CET) Date: Fri, 14 Feb 2014 08:18:21 +0100 From: Juergen Schoenwaelder To: KEN KO Message-ID: <20140214071821.GB87161@elstar.local> Mail-Followup-To: KEN KO , "lmap@ietf.org" References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213105931.GA84319@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E590B@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/TSqEKcazzDceTf1DvmxccKyjUpY Cc: "lmap@ietf.org" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 08:10:48 -0000 On Thu, Feb 13, 2014 at 03:46:17PM +0000, KEN KO wrote: > +1 > > I do think that if this interpretation has a consensus in lmap, it will need a few text edits beyond just the definition of a Measurement Peer in Terminology. Figure 1 and other instances in the draft have led some of us (or at least one of us) to interpret MA and MP in lmap as functions that may (or may not) coexist side by side in a measurement "container." > It is a feature to be agnostic about how things are packaged. Yes, MAs and MPs may (or may not) coexist side by side. This is a feature, not a bug. It is an implementation and deployment decision whether you want them to coexist side by side or not. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 14 00:10:53 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1B41A0121 for ; Fri, 14 Feb 2014 00:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQvOI_yaYtxH for ; Fri, 14 Feb 2014 00:10:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8841A0136 for ; Fri, 14 Feb 2014 00:10:46 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A893220035; Fri, 14 Feb 2014 09:10:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Hf9l50dOls0U; Fri, 14 Feb 2014 09:10:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDC2120055; Fri, 14 Feb 2014 09:10:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 13ED12B4BB80; Fri, 14 Feb 2014 08:04:48 +0100 (CET) Date: Fri, 14 Feb 2014 08:04:48 +0100 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20140214070448.GA87161@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , "Cook, Charles" , "'MORTON, ALFRED C (AL)'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/3kXQI-C5aPnoZdgTKXtdUYDuTC8 Cc: "Cook, Charles" , "'MORTON, ALFRED C \(AL\)'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 08:10:49 -0000 On Thu, Feb 13, 2014 at 03:28:08PM +0000, Bugenhagen, Michael K wrote: > Juergen - > > If we are academically bound to a definition vs. use case requirements you are correct. > This also indicates that MP's are just an abstract name for anything that responds to a test that isn't under the control of the MC (if you follow use case requirements). Yep. > So MP's are existing artifacts like ping responders, TWAMP responders, ... anything that can be a test peer that isn't talking to the MA... Nope. A ping responder talks to the MA. Perhaps you meant MC. > So MP's are not LMAP artifacts per say in your definition ? > > Agreed ? - I'm ok with that Depends how you define "LMAP artifacts". They are surely not involved in any LMAP 1.0 protocols. This is what the current framework says. > However - many people classify the MP as ALL and ANY test peer so > that definition breaks in that context and use... But this is not the LMAP definition of MP as written down in the framework document. If people come with different definitions of terms in their heads and then start debates because the framework seems odd, then we do not really make progress. There is a reason why the LMAP terminology got written down as part of the framework document - so lets simply use it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 14 05:31:18 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507421A0257 for ; Fri, 14 Feb 2014 05:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfrp40h5wsFe for ; Fri, 14 Feb 2014 05:31:14 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1561A0223 for ; Fri, 14 Feb 2014 05:31:14 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 1aa1ef25.2ac1110ba940.1660811.00-2403.4651741.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 14 Feb 2014 13:31:13 +0000 (UTC) X-MXL-Hash: 52fe1aa13a3085e1-873952ac7542d1511b690d0bd9ee907bdf807643 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id f7a1ef25.0.1660511.00-2276.4650852.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 14 Feb 2014 13:30:41 +0000 (UTC) X-MXL-Hash: 52fe1a813b3a5489-dbd50a75cb91dac982267f0dcc93a32aec5d8c3a Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1EDUdVA001962; Fri, 14 Feb 2014 08:30:39 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1EDUU3a001682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Feb 2014 08:30:32 -0500 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (GAALPA1MSGHUB9A.itservices.sbc.com [130.8.36.87]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 14 Feb 2014 13:30:19 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 08:30:19 -0500 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , "Bugenhagen, Michael K" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRkqyuqLftGYUCRyHP6AveWe5qy1z6AgACxuwCAAApkAIAAA7uAgAACnoCAAAWsgIAAArIAgAABeQCAAQW0AIAADyYw Date: Fri, 14 Feb 2014 13:30:18 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> In-Reply-To: <20140214070448.GA87161@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.96.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=qKIRVI71focA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=_fbRkOfxO] X-AnalysisOut: [ZYA:10 a=A89u3Nzm81NoBfKYkkcA:9 a=CjuIK1q_8ugA:10 a=vKRttB] X-AnalysisOut: [6B8dU2yFJn:21 a=-riTW4aTL18S_Lt0:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/EUKyil_MVJhmkXoR512kftarg4I Cc: 'Brian Trammell' , "Cook, Charles" , "MORTON JR., AL" , 'KEN KO' , "'lmap@ietf.org'" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 13:31:16 -0000 > > This also indicates that MP's are just an abstract name for anything th= at > responds to a test that isn't under the control of the MC (if you follow = use > case requirements). >=20 > Yep. So only Ken said +1 for my alternative suggestion of MP as simply being wha= tever an MA interacts with for an Active Measurement Task. While Ken may curse me for doing this, let me see then if I can make an alt= ernate suggestion that would take my interpretation of Juergen's statements= a bit further. Going back to a previous posting where Juergen said: MA =3D controlled by LMAP controller MP =3D not controlled by LMAP controller This to me means that an Active Measurement Task could occur between any co= mbination of 2 or more MAs and MPs (because an Active Measurement Task shou= ldn't be dependent on whether or not an endpoint is Controlled). In a 2-end= point Active Measurement Task, this could be MA-MA, MA-MP, or MP-MP. I reco= gnize that lmap doesn't care about MP-MP (active measurement task between u= ncontrolled measurement endpoints), but part of the problem we're facing is= the desire on the part of some to harmonize BBF and LMAP terminology. BBF = service providers care about understanding the impact that active measureme= nts between uncontrolled measurement endpoints has on the network and on ot= her measurements and traffic running across the network. So we need termino= logy that allows us to talk about this. I think perhaps that defining Activ= e Measurement Methods (Tasks) in lmap in a way that does not make it depend= on one of the endpoints being controlled and the other not being controlle= d could solve our BBF / LMAP terminology issue. If the Active Measurement Method (Task) definition were changed from Active Measurement Method (Task): A type of Measurement Method (Task) that involves a Measurement Agent and a Measurement Peer (or possibly Peers), where either the Measurement Agent or the Measurement Peer injects Active Measurement Traffic into the network destined for the other, and which involves one of them measuring some performance or reliability parameter associated with the transfer of the traffic. To something along the lines of Active Measurement Method (Task): A type of Measurement Method (Task) that involves any combination of two or more Measurement Agents and Meas= urement Peers ,=20 where any endpoint injects Active Measurement Traffic into the network destined for the other(s), and which involves at least one of them measuring some perform= ance or reliability parameter associated with the transfer of the traffic. MAs and MPs are only distinguished by their controllability and can potenti= ally support identical Measurement Methods. The MA definition would change slightly from Measurement Agent (MA): The function that receives Instructions from a Controller, performs Measurement Tasks (perhaps in concert with a Measurement Peer) and reports Measurement Results to a Collector. to Measurement Agent (MA): The function that receives Instructions from a Controller, performs Measurement Tasks (perhaps in concert with one or= more other Measurement Agents or=20 Measurement Peers) and reports Measurement Results to a Collector. And MP would change from Measurement Peer: The function that receives control messages and Active Measurement Traffic from a Measurement Agent and may reply to the Measurement Agent as defined by the Active Measurement Method. to Measurement Peer: A function that has no Controller interface and=20 performs Measurement Tasks (perhaps in concert with one or more other Me= asurement Peers or=20 Measurement Agents). Would this work? Barbara From nobody Fri Feb 14 06:05:39 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2491A0272 for ; Fri, 14 Feb 2014 06:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUv_VeUfTDTF for ; Fri, 14 Feb 2014 06:05:34 -0800 (PST) Received: from p02c12o147.mxlogic.net (p02c12o147.mxlogic.net [208.65.145.80]) by ietfa.amsl.com (Postfix) with ESMTP id 38A8B1A026B for ; Fri, 14 Feb 2014 06:05:34 -0800 (PST) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o147.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id da22ef25.2b51c2a30940.79201.00-579.185057.p02c12o147.mxlogic.net (envelope-from ); Fri, 14 Feb 2014 07:05:33 -0700 (MST) X-MXL-Hash: 52fe22ad21b8f551-d11f7687b733f4caf1d30ae021cf97df3e56ec1e Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o147.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id 6a22ef25.0.79135.00-329.184884.p02c12o147.mxlogic.net (envelope-from ); Fri, 14 Feb 2014 07:05:31 -0700 (MST) X-MXL-Hash: 52fe22ab12be3b83-a7e4e14f1e76798f6080e3df8d949d0da2125280 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 08:05:25 -0600 From: KEN KO To: "STARK, BARBARA H" , Juergen Schoenwaelder , "Bugenhagen, Michael K" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRdZ+UYn/wQ5EuM8kKUQT8gipqy6AKAgACxugCAAAplAIAAA7uAgAACnoCAAAWsgIAAArIAgAABeQCAAQWzAIAAa7UA//+fgTA= Date: Fri, 14 Feb 2014 14:05:25 +0000 Message-ID: References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=ZPVgbwHb c=1 sm=1 a=0XgpNN2/4a34ymu16SVwsQ==:17 a] X-AnalysisOut: [=qZHQZMT3apYA:10 a=FBzmcnhlJawA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=_fbRkOfx] X-AnalysisOut: [OZYA:10 a=rUglT5sIoye-XzxNjyAA:9 a=CjuIK1q_8ugA:10 a=pghXR] X-AnalysisOut: [_X0iMZEe5JO:21 a=5iSk5gj4FdVPQ-1s:21] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014021407); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/iahavuT_odLmpPlzvdN_Xv6PDUg Cc: 'Brian Trammell' , "Cook, Charles" , "MORTON JR., AL" , "'lmap@ietf.org'" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:05:36 -0000 > So only Ken said +1 for my alternative suggestion of MP as simply being > whatever an MA interacts with for an Active Measurement Task. > While Ken may curse me for doing this, let me see then if I can make an > alternate suggestion that would take my interpretation of Juergen's > statements a bit further. No cursing. Maybe a little muttering, but that only relates to the minor wo= rdsmithing I would suggest if this leads towards consensus. > Going back to a previous posting where Juergen said: > MA =3D controlled by LMAP controller > MP =3D not controlled by LMAP controller Brian said something similar that resonated with me: "That's what 'agent' m= eans: it acts on behalf of the controller to make things happen." If MA and MP can be defined strictly in terms of their relationship or lack= thereof to the Controller, without any dependency on who does what in a Me= asurement Task: - It eliminates unnecessary restrictions (real or implied) in the definitio= n of Measurement Methods. - It leads the way to clarifying the draft. As recent emails on the list sh= ow, the current language seems to allow too many interpretations. Ken From nobody Fri Feb 14 07:06:03 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC97E1A02A2 for ; Fri, 14 Feb 2014 07:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J5B5kKbVH6c for ; Fri, 14 Feb 2014 07:05:56 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id D6F7F1A027F for ; Fri, 14 Feb 2014 07:05:56 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1EF5mqF007293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Feb 2014 08:05:48 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 327B91E005B; Fri, 14 Feb 2014 09:05:43 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id E3EA91E006C; Fri, 14 Feb 2014 09:05:42 -0600 (CST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1EF5gJX027875; Fri, 14 Feb 2014 08:05:42 -0700 (MST) Received: from [10.183.220.214] (X1069818.dhcp.intranet [10.183.220.214]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1EF5fkj027827; Fri, 14 Feb 2014 08:05:41 -0700 (MST) Message-ID: <52FE30C5.8020005@centurylink.com> Date: Fri, 14 Feb 2014 08:05:41 -0700 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: "STARK, BARBARA H" References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/JxHL0AapWlhf2DcVF90i3bP6XcQ Cc: "MORTON JR., AL" , "'lmap@ietf.org'" , Juergen Schoenwaelder , "Bugenhagen, Michael K" , 'KEN KO' , 'Brian Trammell' Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: charles.cook2@centurylink.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:06:00 -0000 I can work with Barbara's proposed definitions. I would like to hear what others have to say. Bottom line is that, like Ken, I want to see something that leads to consensus. Charles On 2/14/2014 6:30 AM, STARK, BARBARA H wrote: >>> This also indicates that MP's are just an abstract name for anything = that >> responds to a test that isn't under the control of the MC (if you foll= ow use >> case requirements). >> >> Yep. > So only Ken said +1 for my alternative suggestion of MP as simply being= whatever an MA interacts with for an Active Measurement Task. > While Ken may curse me for doing this, let me see then if I can make an= alternate suggestion that would take my interpretation of Juergen's stat= ements a bit further. > > Going back to a previous posting where Juergen said: > MA =3D controlled by LMAP controller > MP =3D not controlled by LMAP controller > > This to me means that an Active Measurement Task could occur between an= y combination of 2 or more MAs and MPs (because an Active Measurement Tas= k shouldn't be dependent on whether or not an endpoint is Controlled). In= a 2-endpoint Active Measurement Task, this could be MA-MA, MA-MP, or MP-= MP. I recognize that lmap doesn't care about MP-MP (active measurement ta= sk between uncontrolled measurement endpoints), but part of the problem w= e're facing is the desire on the part of some to harmonize BBF and LMAP t= erminology. BBF service providers care about understanding the impact tha= t active measurements between uncontrolled measurement endpoints has on t= he network and on other measurements and traffic running across the netwo= rk. So we need terminology that allows us to talk about this. I think per= haps that defining Active Measurement Methods (Tasks) in lmap in a way th= at does not make it depend on one of the endpoints being controlled and t= he other not being controlled could solve our BBF / LMAP terminology issu= e. > > If the Active Measurement Method (Task) definition were changed from > Active Measurement Method (Task): A type of Measurement Method (Task= ) > that involves a Measurement Agent and a Measurement Peer (or possibl= y > Peers), where either the Measurement Agent or the Measurement Peer > injects Active Measurement Traffic into the network destined for the= > other, and which involves one of them measuring some performance or > reliability parameter associated with the transfer of the traffic. > > To something along the lines of > Active Measurement Method (Task): A type of Measurement Method (Task= ) > that involves any combination of two or more Measurement Agents and = Measurement Peers ,=20 > where any endpoint > injects Active Measurement Traffic into the network destined for the= > other(s), and which involves at least one of them measuring some per= formance or > reliability parameter associated with the transfer of the traffic. > > MAs and MPs are only distinguished by their controllability and can pot= entially support identical Measurement Methods. > > The MA definition would change slightly from > Measurement Agent (MA): The function that receives Instructions from= > a Controller, performs Measurement Tasks (perhaps in concert with a > Measurement Peer) and reports Measurement Results to a Collector. > to > Measurement Agent (MA): The function that receives Instructions from= > a Controller, performs Measurement Tasks (perhaps in concert with on= e or more other Measurement Agents or=20 > Measurement Peers) and reports Measurement Results to a Collector. > > And MP would change from > Measurement Peer: The function that receives control messages and > Active Measurement Traffic from a Measurement Agent and may reply to= > the Measurement Agent as defined by the Active Measurement Method. > to > Measurement Peer: A function that has no Controller interface and=20 > performs Measurement Tasks (perhaps in concert with one or more othe= r Measurement Peers or=20 > Measurement Agents). > > Would this work? > Barbara > > --=20 Charles Cook=20 Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com From nobody Fri Feb 14 07:56:57 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CD11A0242 for ; Fri, 14 Feb 2014 07:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoZaUKd3Zxom for ; Fri, 14 Feb 2014 07:56:49 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2A01A02C7 for ; Fri, 14 Feb 2014 07:56:49 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 10:56:47 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 10:56:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Feb 2014 10:57:33 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] MA vs MP Thread-Index: Ac8plkhT/0UxsTTwSPO2m42k0q8j6wABRf9w References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> From: "Sharam Hakimi" To: , "STARK, BARBARA H" X-OriginalArrivalTime: 14 Feb 2014 15:56:47.0751 (UTC) FILETIME=[5DCF6170:01CF299D] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/RQ0-PDgwde7k9dS0TY9Ju6IOjfs Cc: "MORTON JR., AL" , lmap@ietf.org, Juergen Schoenwaelder , "Bugenhagen, Michael K" , KEN KO , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:56:54 -0000 MPs are effectively Measurement Responders. Two Measurement responders could not perform a test by the current definitions. This would mean that I could assign a test to two entities that I do not even control. Can we call a spade a spade. MP should really be called a measurement Responder (MR) and I believe the term Responder is well understood ( it does not initiate tests). As an example two OWAMP or TWAMP responders cannot initiate a test between themselves. Nor can a TWAMP initiator can start a test between two TWAMP Responders. In my opinion the current definitions are ok and Measurement tasks are sent to the MA and the test is between the MA and the MP (MR). The main question is what happens when these two functions within the same device. I believe we need to solve that and provide either control or text as to the consequences. Thanks, Sharam =20 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook Sent: Friday, February 14, 2014 10:06 AM To: STARK, BARBARA H Cc: MORTON JR., AL; 'lmap@ietf.org'; Juergen Schoenwaelder; Bugenhagen, Michael K; 'KEN KO'; 'Brian Trammell' Subject: Re: [lmap] MA vs MP I can work with Barbara's proposed definitions. I would like to hear what others have to say. Bottom line is that, like Ken, I want to see something that leads to consensus. Charles On 2/14/2014 6:30 AM, STARK, BARBARA H wrote: >>> This also indicates that MP's are just an abstract name for anything that >> responds to a test that isn't under the control of the MC (if you follow use >> case requirements). >> >> Yep. > So only Ken said +1 for my alternative suggestion of MP as simply being whatever an MA interacts with for an Active Measurement Task. > While Ken may curse me for doing this, let me see then if I can make an alternate suggestion that would take my interpretation of Juergen's statements a bit further. > > Going back to a previous posting where Juergen said: > MA =3D controlled by LMAP controller > MP =3D not controlled by LMAP controller > > This to me means that an Active Measurement Task could occur between any combination of 2 or more MAs and MPs (because an Active Measurement Task shouldn't be dependent on whether or not an endpoint is Controlled). In a 2-endpoint Active Measurement Task, this could be MA-MA, MA-MP, or MP-MP. I recognize that lmap doesn't care about MP-MP (active measurement task between uncontrolled measurement endpoints), but part of the problem we're facing is the desire on the part of some to harmonize BBF and LMAP terminology. BBF service providers care about understanding the impact that active measurements between uncontrolled measurement endpoints has on the network and on other measurements and traffic running across the network. So we need terminology that allows us to talk about this. I think perhaps that defining Active Measurement Methods (Tasks) in lmap in a way that does not make it depend on one of the endpoints being controlled and the other not being controlled could solve our BBF / LMAP terminology issue. > > If the Active Measurement Method (Task) definition were changed from > Active Measurement Method (Task): A type of Measurement Method (Task) > that involves a Measurement Agent and a Measurement Peer (or possibly > Peers), where either the Measurement Agent or the Measurement Peer > injects Active Measurement Traffic into the network destined for the > other, and which involves one of them measuring some performance or > reliability parameter associated with the transfer of the traffic. > > To something along the lines of > Active Measurement Method (Task): A type of Measurement Method (Task) > that involves any combination of two or more Measurement Agents and Measurement Peers ,=20 > where any endpoint > injects Active Measurement Traffic into the network destined for the > other(s), and which involves at least one of them measuring some performance or > reliability parameter associated with the transfer of the traffic. > > MAs and MPs are only distinguished by their controllability and can potentially support identical Measurement Methods. > > The MA definition would change slightly from > Measurement Agent (MA): The function that receives Instructions from > a Controller, performs Measurement Tasks (perhaps in concert with a > Measurement Peer) and reports Measurement Results to a Collector. > to > Measurement Agent (MA): The function that receives Instructions from > a Controller, performs Measurement Tasks (perhaps in concert with one or more other Measurement Agents or=20 > Measurement Peers) and reports Measurement Results to a Collector. > > And MP would change from > Measurement Peer: The function that receives control messages and > Active Measurement Traffic from a Measurement Agent and may reply to > the Measurement Agent as defined by the Active Measurement Method. > to > Measurement Peer: A function that has no Controller interface and=20 > performs Measurement Tasks (perhaps in concert with one or more other Measurement Peers or=20 > Measurement Agents). > > Would this work? > Barbara > > --=20 Charles Cook=20 Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Feb 14 08:13:18 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF271A0301 for ; Fri, 14 Feb 2014 08:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF__DLBmMHZG for ; Fri, 14 Feb 2014 08:13:13 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 37BED1A02EA for ; Fri, 14 Feb 2014 08:13:13 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 35F6CFA7; Fri, 14 Feb 2014 17:13:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uw6Sv1skgjj5; Fri, 14 Feb 2014 17:13:09 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 14 Feb 2014 17:13:09 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFCD420014; Fri, 14 Feb 2014 17:13:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GZjpw3sZN8Je; Fri, 14 Feb 2014 17:13:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 229D220013; Fri, 14 Feb 2014 17:13:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EBF442B4E9D6; Fri, 14 Feb 2014 17:13:06 +0100 (CET) Date: Fri, 14 Feb 2014 17:13:06 +0100 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20140214161306.GA89378@elstar.local> Mail-Followup-To: Sharam Hakimi , charles.cook2@centurylink.com, "STARK, BARBARA H" , "MORTON JR., AL" , lmap@ietf.org, "Bugenhagen, Michael K" , KEN KO , Brian Trammell References: <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/bfD2BtcTj06TIzarGixPsq5XnSE Cc: charles.cook2@centurylink.com, "MORTON JR., AL" , lmap@ietf.org, "Bugenhagen, Michael K" , KEN KO , "STARK, BARBARA H" , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:13:15 -0000 On Fri, Feb 14, 2014 at 10:57:33AM -0500, Sharam Hakimi wrote: > MPs are effectively Measurement Responders. Two Measurement responders > could not perform a test by the current definitions. This would mean > that I could assign a test to two entities that I do not even control. > > Can we call a spade a spade. MP should really be called a measurement > Responder (MR) and I believe the term Responder is well understood ( it > does not initiate tests). This is not true or may be confusing. You can have an MA using a non-LMAP control protocol to trigger an MP sending traffic to an MA. > As an example two OWAMP or TWAMP responders cannot initiate a test > between themselves. Nor can a TWAMP initiator can start a test between > two TWAMP Responders. > > In my opinion the current definitions are ok and Measurement tasks are > sent to the MA and the test is between the MA and the MP (MR). > The main question is what happens when these two functions within the > same device. I believe we need to solve that and provide either control > or text as to the consequences. I fail to see why it matters how you bundle stuff into devices. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 14 08:27:56 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B021A02DE for ; Fri, 14 Feb 2014 08:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2R_Y9Z7CE_D for ; Fri, 14 Feb 2014 08:27:52 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2052E1A02A3 for ; Fri, 14 Feb 2014 08:27:52 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id A7D76120538; Fri, 14 Feb 2014 11:31:14 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-green.research.att.com (Postfix) with ESMTP id DFAE1E020C; Fri, 14 Feb 2014 11:26:57 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Fri, 14 Feb 2014 11:27:50 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , Sharam Hakimi Date: Fri, 14 Feb 2014 11:27:48 -0500 Thread-Topic: [lmap] MA vs MP Thread-Index: Ac8pn7Ix99r/enL7RW6SeGcLaPEIewAAcHLQ Message-ID: <2845723087023D4CB5114223779FA9C8BC5B9A77@njfpsrvexg8.research.att.com> References: <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <20140214161306.GA89378@elstar.local> In-Reply-To: <20140214161306.GA89378@elstar.local> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/7gIg_9LdX92p7qPH76_0KXlW8XM Cc: "charles.cook2@centurylink.com" , "lmap@ietf.org" , "Bugenhagen, Michael K" , KEN KO , "STARK, BARBARA H" , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:27:54 -0000 > On Fri, Feb 14, 2014 at 10:57:33AM -0500, Sharam Hakimi wrote: > > MPs are effectively Measurement Responders. Two Measurement responders > > could not perform a test by the current definitions. This would mean > > that I could assign a test to two entities that I do not even control. > > > > Can we call a spade a spade. MP should really be called a measurement > > Responder (MR) and I believe the term Responder is well understood ( it > > does not initiate tests). >=20 > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > This is not true or may be confusing. You can have an MA using a > non-LMAP control protocol to trigger an MP sending traffic to an MA. yes, said this just recently: "OWAMP can do it." Al From nobody Fri Feb 14 08:52:14 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F6F1A02CF for ; Fri, 14 Feb 2014 08:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i96b0YXmODRG for ; Fri, 14 Feb 2014 08:52:08 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE381A02BA for ; Fri, 14 Feb 2014 08:52:02 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 1b94ef25.2ac0e7c78940.1791563.00-2469.5026928.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 14 Feb 2014 16:52:01 +0000 (UTC) X-MXL-Hash: 52fe49b135e3ee3f-6b3345828159f3fd4906cc1fa4010bea116a9c5d Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 4a94ef25.0.1791422.00-2360.5026563.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 14 Feb 2014 16:51:49 +0000 (UTC) X-MXL-Hash: 52fe49a518c48bac-27e27f5feb3bcc232605277446ef15df68f2ff7a Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1EGpliQ020579; Fri, 14 Feb 2014 11:51:48 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1EGpeWC020483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Feb 2014 11:51:41 -0500 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (GAALPA1MSGHUB9F.itservices.sbc.com [130.8.36.92]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 14 Feb 2014 16:51:35 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 11:51:35 -0500 From: "STARK, BARBARA H" To: Sharam Hakimi , "charles.cook2@centurylink.com" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRkqyuqLftGYUCRyHP6AveWewABRf9wmrTseTA= Date: Fri, 14 Feb 2014 16:51:34 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=uXQnFqASuNsA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=_fbRkOfxO] X-AnalysisOut: [ZYA:10 a=ZhoiyS1_7ypW-hwRdyMA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/0GZzlu2z4TI8dbhFJJJ23Neb614 Cc: "MORTON JR., AL" , "lmap@ietf.org" , Juergen Schoenwaelder , "Bugenhagen, Michael K" , KEN KO , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:52:11 -0000 > MPs are effectively Measurement Responders. Two Measurement > responders could not perform a test by the current definitions. This woul= d > mean that I could assign a test to two entities that I do not even contro= l. I disagree with this definition of MP. I believe lmap is an operational fra= mework and that its key functions need to be defined in operational terms, = and not in terms of their roles in active measurement tasks. I find Juergen's proposed distinction between MA and MP (whether or not the= y have a Controller interface) to be very workable. But this means that an = MA and an MP can potentially perform identical roles in an active Measureme= nt Task. The set of Measurement Methods that can be implemented in an MA an= d MP are the same. The Information Model should take into account that not = all Measurement Tasks are scheduled -- some may occur in reaction to extern= al stimuli. It will need to be possible for the Controller to enable/disabl= e these. Barbara From nobody Fri Feb 14 09:12:17 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722851A02EF for ; Fri, 14 Feb 2014 09:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cN69jvws1YW for ; Fri, 14 Feb 2014 09:12:12 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id CC9591A0270 for ; Fri, 14 Feb 2014 09:12:11 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 12:12:10 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 12:12:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Feb 2014 12:12:19 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B23775@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] MA vs MP Thread-Index: Ac8pn7Ix99r/enL7RW6SeGcLaPEIewAAcHLQAAGTv2A= References: <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <20140214161306.GA89378@elstar.local> <2845723087023D4CB5114223779FA9C8BC5B9A77@njfpsrvexg8.research.att.com> From: "Sharam Hakimi" To: "MORTON, ALFRED C \(AL\)" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 14 Feb 2014 17:12:10.0028 (UTC) FILETIME=[E54C16C0:01CF29A7] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/KN2LrGmxOXCGJGzuPi3cYtkwwEE Cc: charles.cook2@centurylink.com, lmap@ietf.org, "Bugenhagen, Michael K" , KEN KO , "STARK, BARBARA H" , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 17:12:14 -0000 -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Friday, February 14, 2014 11:28 AM To: Juergen Schoenwaelder; Sharam Hakimi Cc: charles.cook2@centurylink.com; STARK, BARBARA H; lmap@ietf.org; Bugenhagen, Michael K; KEN KO; Brian Trammell Subject: RE: [lmap] MA vs MP > On Fri, Feb 14, 2014 at 10:57:33AM -0500, Sharam Hakimi wrote: > > MPs are effectively Measurement Responders. Two Measurement responders > > could not perform a test by the current definitions. This would mean > > that I could assign a test to two entities that I do not even control. > > > > Can we call a spade a spade. MP should really be called a measurement > > Responder (MR) and I believe the term Responder is well understood ( it > > does not initiate tests). >=20 > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > This is not true or may be confusing. You can have an MA using a > non-LMAP control protocol to trigger an MP sending traffic to an MA. yes, said this just recently: "OWAMP can do it." Al My point was between an MP and another MP, not between an MP and MA.=20 Sharam From nobody Fri Feb 14 09:31:34 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476F01A034C for ; Fri, 14 Feb 2014 09:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6om5olr9aHn for ; Fri, 14 Feb 2014 09:31:30 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 18E541A034E for ; Fri, 14 Feb 2014 09:31:25 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2D49EF65; Fri, 14 Feb 2014 18:31:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Djk_cImlRr1X; Fri, 14 Feb 2014 18:31:21 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 14 Feb 2014 18:31:21 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D00A720014; Fri, 14 Feb 2014 18:31:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 764KLm8kto3t; Fri, 14 Feb 2014 18:31:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1FA7720013; Fri, 14 Feb 2014 18:31:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4547B2B4EDDF; Fri, 14 Feb 2014 18:31:18 +0100 (CET) Date: Fri, 14 Feb 2014 18:31:17 +0100 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140214173117.GA89592@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , Sharam Hakimi , "charles.cook2@centurylink.com" , "MORTON JR., AL" , "lmap@ietf.org" , "Bugenhagen, Michael K" , KEN KO , Brian Trammell References: <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/4uumRHbJE10vikyTwAYfXnaxp7I Cc: Sharam Hakimi , "charles.cook2@centurylink.com" , "MORTON JR., AL" , "lmap@ietf.org" , "Bugenhagen, Michael K" , KEN KO , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 17:31:32 -0000 On Fri, Feb 14, 2014 at 04:51:34PM +0000, STARK, BARBARA H wrote: > > MPs are effectively Measurement Responders. Two Measurement > > responders could not perform a test by the current definitions. This would > > mean that I could assign a test to two entities that I do not even control. > > I disagree with this definition of MP. I believe lmap is an operational framework and that its key functions need to be defined in operational terms, and not in terms of their roles in active measurement tasks. > > I find Juergen's proposed distinction between MA and MP (whether or not they have a Controller interface) to be very workable. But this means that an MA and an MP can potentially perform identical roles in an active Measurement Task. The set of Measurement Methods that can be implemented in an MA and MP are the same. The Information Model should take into account that not all Measurement Tasks are scheduled -- some may occur in reaction to external stimuli. It will need to be possible for the Controller to enable/disable these. You schedule a passive measurement task - I believe the information model is just fine with that. This is even better than enable/disable because I can control during which times it is enabled. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 14 09:33:35 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F95B1A034D for ; Fri, 14 Feb 2014 09:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-xQnPvyy-kb for ; Fri, 14 Feb 2014 09:33:32 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 90A6D1A0350 for ; Fri, 14 Feb 2014 09:33:31 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 12:33:30 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 12:33:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Feb 2014 12:34:07 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRkqyuqLftGYUCRyHP6AveWewABRf9wmrTseTCAAAp3UA== References: <52FC14BD.8040403@centurylink.com> <2845723087023D4CB5114223779FA9C8BC23F39C@njfpsrvexg8.research.att.com> <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> From: "Sharam Hakimi" To: "STARK, BARBARA H" , X-OriginalArrivalTime: 14 Feb 2014 17:33:30.0075 (UTC) FILETIME=[E043C2B0:01CF29AA] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/aqiORkDAsBHJCrYPw_U-N8_JMN4 Cc: "MORTON JR., AL" , lmap@ietf.org, Juergen Schoenwaelder , "Bugenhagen, Michael K" , KEN KO , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 17:33:34 -0000 MC controls MA MC does not control MP MA does not control MP MA sends Requests to MP MA cannot initiate task for MP <-> MP test MP cannot initiate task for MA <-> MA or MP test ( MP can originate a test after it is initiated by an MA) MA cannot initiate task for MA <-> MA test MA Can initiate task for MA <-> MP test This tells me that MP is a Responder. Thanks, Sharam =09 =20 -----Original Message----- From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Friday, February 14, 2014 11:52 AM To: Sharam Hakimi; charles.cook2@centurylink.com Cc: MORTON JR., AL; lmap@ietf.org; Juergen Schoenwaelder; Bugenhagen, Michael K; KEN KO; Brian Trammell Subject: RE: [lmap] MA vs MP > MPs are effectively Measurement Responders. Two Measurement > responders could not perform a test by the current definitions. This would > mean that I could assign a test to two entities that I do not even control. I disagree with this definition of MP. I believe lmap is an operational framework and that its key functions need to be defined in operational terms, and not in terms of their roles in active measurement tasks. I find Juergen's proposed distinction between MA and MP (whether or not they have a Controller interface) to be very workable. But this means that an MA and an MP can potentially perform identical roles in an active Measurement Task. The set of Measurement Methods that can be implemented in an MA and MP are the same. The Information Model should take into account that not all Measurement Tasks are scheduled -- some may occur in reaction to external stimuli. It will need to be possible for the Controller to enable/disable these. Barbara From nobody Fri Feb 14 11:50:54 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A37D1A03B6 for ; Fri, 14 Feb 2014 11:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72jHaWQh1g8K for ; Fri, 14 Feb 2014 11:50:43 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id A42761A0317 for ; Fri, 14 Feb 2014 11:49:15 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A5CAFF8A; Fri, 14 Feb 2014 20:49:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nuP8xtfMFSUp; Fri, 14 Feb 2014 20:49:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 14 Feb 2014 20:49:12 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6B7A20014; Fri, 14 Feb 2014 20:49:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id r-yF06dfRM8f; Fri, 14 Feb 2014 20:49:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86B8920026; Fri, 14 Feb 2014 20:49:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 17C5A2B4F5A8; Fri, 14 Feb 2014 20:49:05 +0100 (CET) Date: Fri, 14 Feb 2014 20:49:05 +0100 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20140214194905.GA89769@elstar.local> Mail-Followup-To: Sharam Hakimi , "STARK, BARBARA H" , charles.cook2@centurylink.com, "MORTON JR., AL" , lmap@ietf.org, "Bugenhagen, Michael K" , KEN KO , Brian Trammell References: <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/G4dlITgiQahlVIqrDih9jLkz7Ic Cc: charles.cook2@centurylink.com, "MORTON JR., AL" , lmap@ietf.org, "Bugenhagen, Michael K" , KEN KO , "STARK, BARBARA H" , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:50:48 -0000 On Fri, Feb 14, 2014 at 12:34:07PM -0500, Sharam Hakimi wrote: > > MC controls MA > > MC does not control MP > > MA does not control MP > > MA sends Requests to MP > > > MA cannot initiate task for MP <-> MP test > > MP cannot initiate task for MA <-> MA or MP test ( MP can > originate a test after it is initiated by an MA) > > MA cannot initiate task for MA <-> MA test > > MA Can initiate task for MA <-> MP test > > > > This tells me that MP is a Responder. I do not know the definition of initiate but I think some of the above statements are wrong and hence the conclusion does not hold. In particular, I believe an MA can initiate task for MA <-> MA test. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 14 12:13:03 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89061A03DB for ; Fri, 14 Feb 2014 12:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3hoI7rVzoRM for ; Fri, 14 Feb 2014 12:12:59 -0800 (PST) Received: from p02c12o147.mxlogic.net (p02c12o147.mxlogic.net [208.65.145.80]) by ietfa.amsl.com (Postfix) with ESMTP id F35D21A03DC for ; Fri, 14 Feb 2014 12:12:58 -0800 (PST) Received: from unknown [76.164.174.83] (EHLO p02c12o147.mxlogic.net) by p02c12o147.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 9c87ef25.2b3160e63940.24733.00-526.66541.p02c12o147.mxlogic.net (envelope-from ); Fri, 14 Feb 2014 13:12:57 -0700 (MST) X-MXL-Hash: 52fe78c95ebc500b-fa355d37c3a3fbeb626615ebb9ffa28bacf999d1 Received: from unknown [76.164.174.83] by p02c12o147.mxlogic.net(mxl_mta-7.2.4-1) with SMTP id 7e77ef25.0.21477.00-376.60447.p02c12o147.mxlogic.net (envelope-from ); Fri, 14 Feb 2014 13:09:18 -0700 (MST) X-MXL-Hash: 52fe77ee3469bb96-6771916ab61cf9ca27bd6c49f06701c9bd653652 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 14:08:57 -0600 From: KEN KO To: Juergen Schoenwaelder , "Sharam Hakimi" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRdZ+UYn/wQ5EuM8kKUQT8gigABRf9wmrTseTCAAAp3UIAAjm6A//+gv1A= Date: Fri, 14 Feb 2014 20:08:57 +0000 Message-ID: References: <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> <20140214194905.GA89769@elstar.local> In-Reply-To: <20140214194905.GA89769@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=fMuOK+me c=1 sm=1 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a] X-AnalysisOut: [=qZHQZMT3apYA:10 a=FBzmcnhlJawA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=_fbRkOfx] X-AnalysisOut: [OZYA:10 a=J_N6KFswAAAA:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8] X-AnalysisOut: [ a=p5P2in39hAArNhu8oiEA:9 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA] X-AnalysisOut: [:10 a=JrSEOxZJtCQA:10 a=4CLKj2Bp5_UA:10 a=Pwbduc0PQ3sA:10 ] X-AnalysisOut: [a=lZB815dzVvQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014021412); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/0WzuiKrImfcWPYf4qiii1pl7Ssg Cc: "charles.cook2@centurylink.com" , "MORTON JR., AL" , "lmap@ietf.org" , "Bugenhagen, Michael K" , "STARK, BARBARA H" , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:13:02 -0000 +1 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, February 14, 2014 2:49 PM > To: Sharam Hakimi > Cc: STARK, BARBARA H; charles.cook2@centurylink.com; MORTON JR., AL; > lmap@ietf.org; Bugenhagen, Michael K; KEN KO; Brian Trammell > Subject: Re: [lmap] MA vs MP >=20 > In particular, I > believe an MA can initiate task for MA <-> MA test. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From nobody Fri Feb 14 12:40:49 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EBB1A02F7 for ; Fri, 14 Feb 2014 12:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-3dECHwk19a for ; Fri, 14 Feb 2014 12:40:44 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 247C41A02AF for ; Fri, 14 Feb 2014 12:40:44 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 15:40:41 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 15:40:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Feb 2014 15:40:36 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B23817@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRdZ+UYn/wQ5EuM8kKUQT8gigABRf9wmrTseTCAAAp3UIAAjm6A//+gv1CAAAhbEA== References: <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> <20140214194905.GA89769@elstar.local> From: "Sharam Hakimi" To: "KEN KO" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 14 Feb 2014 20:40:41.0644 (UTC) FILETIME=[06CD2EC0:01CF29C5] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/iA7XTsLTFlYh5WLREJlk3pSt_4A Cc: charles.cook2@centurylink.com, "MORTON JR., AL" , lmap@ietf.org, "Bugenhagen, Michael K" , "STARK, BARBARA H" , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:40:47 -0000 That would mean that an MA has a silent responder built inside it, because without a responder function two senders cannot perform a test. Sharam -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com]=20 Sent: Friday, February 14, 2014 3:09 PM To: Juergen Schoenwaelder; Sharam Hakimi Cc: STARK, BARBARA H; charles.cook2@centurylink.com; MORTON JR., AL; lmap@ietf.org; Bugenhagen, Michael K; Brian Trammell Subject: RE: [lmap] MA vs MP +1 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, February 14, 2014 2:49 PM > To: Sharam Hakimi > Cc: STARK, BARBARA H; charles.cook2@centurylink.com; MORTON JR., AL; > lmap@ietf.org; Bugenhagen, Michael K; KEN KO; Brian Trammell > Subject: Re: [lmap] MA vs MP >=20 > In particular, I > believe an MA can initiate task for MA <-> MA test. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From nobody Fri Feb 14 12:51:02 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4EC1A03EA for ; Fri, 14 Feb 2014 12:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BSc8sAFTmh9 for ; Fri, 14 Feb 2014 12:50:52 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 991A01A03C9 for ; Fri, 14 Feb 2014 12:50:47 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D7241F82; Fri, 14 Feb 2014 21:50:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id O5M63COZcXTB; Fri, 14 Feb 2014 21:50:43 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 14 Feb 2014 21:50:43 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 626A320014; Fri, 14 Feb 2014 21:50:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ghPHU0J0o5FP; Fri, 14 Feb 2014 21:50:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64B5320013; Fri, 14 Feb 2014 21:50:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 156A22B4F8E4; Fri, 14 Feb 2014 21:50:38 +0100 (CET) Date: Fri, 14 Feb 2014 21:50:38 +0100 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20140214205038.GA90067@elstar.local> Mail-Followup-To: Sharam Hakimi , KEN KO , "STARK, BARBARA H" , charles.cook2@centurylink.com, "MORTON JR., AL" , lmap@ietf.org, "Bugenhagen, Michael K" , Brian Trammell References: <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> <20140214194905.GA89769@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B23817@spboexc01.exfo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02B23817@spboexc01.exfo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/VjTcWdnGn9xPKFjpXA2X1KLQCPk Cc: charles.cook2@centurylink.com, "MORTON JR., AL" , lmap@ietf.org, "Bugenhagen, Michael K" , KEN KO , "STARK, BARBARA H" , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:50:56 -0000 On Fri, Feb 14, 2014 at 03:40:36PM -0500, Sharam Hakimi wrote: > That would mean that an MA has a silent responder built inside it, > because without a responder function two senders cannot perform a test. You seem to assume that MA is a sender and an MP is a receiver, which is not what the text says. Hence you draw wrong conclusions. And a measurement between to MAs does not even require that there are any responses at all. It is perfectly fine that one MA generates a traffic train that is received by another MA. The LMAP framework tries to stay generic. It is the concrete measurement tests you run that make the difference. /js PS: If I do something as simple as sending ICMP echo requests, then pretty much every IP implementation has a built-in responder. Claiming this would not be the case would be kind of in conflict with how basic IP works. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 14 12:51:24 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E891A03C6 for ; Fri, 14 Feb 2014 12:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2ldA9yeNTB3 for ; Fri, 14 Feb 2014 12:51:16 -0800 (PST) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 724BF1A0045 for ; Fri, 14 Feb 2014 12:51:13 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-red.research.att.com (Postfix) with ESMTP id 96AA5554547; Fri, 14 Feb 2014 15:54:45 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-green.research.att.com (Postfix) with ESMTP id 32AFAE020C; Fri, 14 Feb 2014 15:50:19 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Fri, 14 Feb 2014 15:51:11 -0500 From: "MORTON, ALFRED C (AL)" To: Sharam Hakimi , KEN KO , Juergen Schoenwaelder Date: Fri, 14 Feb 2014 15:51:10 -0500 Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRdZ+UYn/wQ5EuM8kKUQT8gigABRf9wmrTseTCAAAp3UIAAjm6A//+gv1CAAAhbEIAAAidg Message-ID: <2845723087023D4CB5114223779FA9C8BC5B9B33@njfpsrvexg8.research.att.com> References: <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> <20140214194905.GA89769@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B23817@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02B23817@spboexc01.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9PexkFb7FTWuWmol-BuFO4rq0iE Cc: Brian Trammell , "charles.cook2@centurylink.com" , "STARK, BARBARA H" , "Bugenhagen, Michael K" , "lmap@ietf.org" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:51:20 -0000 No at all, you are assuming measurement functionality along with the LMAP system functions. There is nothing that prevents a device with an MA to also be equipped to act as either a TWAMP sender or reflector. Al > -----Original Message----- > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: Friday, February 14, 2014 3:41 PM > To: KEN KO; Juergen Schoenwaelder > Cc: STARK, BARBARA H; charles.cook2@centurylink.com; MORTON, ALFRED C > (AL); lmap@ietf.org; Bugenhagen, Michael K; Brian Trammell > Subject: RE: [lmap] MA vs MP >=20 > That would mean that an MA has a silent responder built inside it, > because without a responder function two senders cannot perform a test. >=20 > Sharam >=20 > -----Original Message----- > From: KEN KO [mailto:KEN.KO@adtran.com] > Sent: Friday, February 14, 2014 3:09 PM > To: Juergen Schoenwaelder; Sharam Hakimi > Cc: STARK, BARBARA H; charles.cook2@centurylink.com; MORTON JR., AL; > lmap@ietf.org; Bugenhagen, Michael K; Brian Trammell > Subject: RE: [lmap] MA vs MP >=20 > +1 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Friday, February 14, 2014 2:49 PM > > To: Sharam Hakimi > > Cc: STARK, BARBARA H; charles.cook2@centurylink.com; MORTON JR., AL; > > lmap@ietf.org; Bugenhagen, Michael K; KEN KO; Brian Trammell > > Subject: Re: [lmap] MA vs MP > > > > In particular, I > > believe an MA can initiate task for MA <-> MA test. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 From nobody Fri Feb 14 12:59:16 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8142B1A02C0 for ; Fri, 14 Feb 2014 12:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOiN6IYLvXSl for ; Fri, 14 Feb 2014 12:59:09 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 856C71A0394 for ; Fri, 14 Feb 2014 12:59:03 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 6938ef25.2ae3a763e940.358066.00-2408.1019823.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 14 Feb 2014 20:59:02 +0000 (UTC) X-MXL-Hash: 52fe839641fbd5b0-a596823f1c4fa2080c442faf0d75f24ac14082a6 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 2938ef25.0.358009.00-2227.1019649.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 14 Feb 2014 20:59:00 +0000 (UTC) X-MXL-Hash: 52fe8394498a8bf5-b56624db346be443235e651893daf6af31243736 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1EKwvT1010375; Fri, 14 Feb 2014 15:58:57 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1EKwleD010188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Feb 2014 15:58:49 -0500 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (GAALPA1MSGHUB9E.itservices.sbc.com [130.8.36.91]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 14 Feb 2014 20:58:30 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 15:58:30 -0500 From: "STARK, BARBARA H" To: KEN KO , Juergen Schoenwaelder , Sharam Hakimi Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRkqyuqLftGYUCRyHP6AveWewABRf9wmrTseTCAAAp3UIAAfauAgAAFjYD//7M5kA== Date: Fri, 14 Feb 2014 20:58:29 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303E86D2@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> <20140214194905.GA89769@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.108.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=EIuxJSlC c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=-6OodRfrcsQA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=_fbRkOfxO] X-AnalysisOut: [ZYA:10 a=eJNrpioGAAAA:8 a=J_N6KFswAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=j3Z76cjpAAAA:8 a=RNOe7UuodsovdNUfLe8A:9 a=CjuIK1q_8ugA:1] X-AnalysisOut: [0 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=4CLKj2Bp5_UA:10 a=] X-AnalysisOut: [DvnSUQUdWHYA:10 a=Pwbduc0PQ3sA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/RbYNWHf5QB_rTtQnj33MHH4W0MA Cc: Brian Trammell , "charles.cook2@centurylink.com" , "MORTON JR., AL" , "Bugenhagen, Michael K" , "lmap@ietf.org" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:59:13 -0000 +1 I also see nothing (other than the current terminology definitions of Activ= e Measurement Method (Task), MA, and MP -- which I believe all need to be c= hanged to reflect whatever we agree upon) that precludes: MA (either one) "initiates" MA <-> MA test MA2 "initiates" MA1 <-> MA2 test MA "initiates" MA <-> MP test MP "initiates" MA <-> MP test MP (either one) "initiates" MP <-> MP test (not that anyone cares) There needs to be nothing in the definitions of MA, MP, and Active Measurem= ent Method (Task) that limits, restricts, or proscribes the "role" an MA or= MP can play in Active Measurement Tasks an MA or MP participates in. Most importantly, none of the actual requirements of the framework are impa= cted by not restricting the "roles". Barbara > -----Original Message----- > From: KEN KO [mailto:KEN.KO@adtran.com] > Sent: Friday, February 14, 2014 3:09 PM > To: Juergen Schoenwaelder; Sharam Hakimi > Cc: STARK, BARBARA H; charles.cook2@centurylink.com; MORTON JR., AL; > lmap@ietf.org; Bugenhagen, Michael K; Brian Trammell > Subject: RE: [lmap] MA vs MP >=20 > +1 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Friday, February 14, 2014 2:49 PM > > To: Sharam Hakimi > > Cc: STARK, BARBARA H; charles.cook2@centurylink.com; MORTON JR., AL; > > lmap@ietf.org; Bugenhagen, Michael K; KEN KO; Brian Trammell > > Subject: Re: [lmap] MA vs MP > > > > In particular, I > > believe an MA can initiate task for MA <-> MA test. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 From nobody Fri Feb 14 13:24:45 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C241A0440 for ; Fri, 14 Feb 2014 13:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y52mtpr7rQ2r for ; Fri, 14 Feb 2014 13:24:32 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA0E1A041D for ; Fri, 14 Feb 2014 13:24:32 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1ELOPMZ010568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Feb 2014 14:24:26 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 92FE51E0067; Fri, 14 Feb 2014 14:24:20 -0700 (MST) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 7A7E21E0070; Fri, 14 Feb 2014 14:24:20 -0700 (MST) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1ELOKon020686; Fri, 14 Feb 2014 14:24:20 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1ELOJCv020676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 14:24:19 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 15:24:19 -0600 From: "Bugenhagen, Michael K" To: "MORTON, ALFRED C (AL)" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihkwABRf9wmrVI2gCAAAQcAP//7kPC Date: Fri, 14 Feb 2014 21:24:18 +0000 Message-ID: References: <20140213143012.GA85019@elstar.local> <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <20140214161306.GA89378@elstar.local>, <2845723087023D4CB5114223779FA9C8BC5B9A77@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC5B9A77@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/0D_q0Bf20oyPdvyyun239QqTGLY Cc: Sharam Hakimi , "Cook, Charles" , "lmap@ietf.org" , Juergen Schoenwaelder , KEN KO , "STARK, BARBARA H" , Brian Trammell Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:24:34 -0000 OWAMP is an Agent function .. It Just may not be a LMAP MA...=20 But if LMAP assumes to run agents under MA LMAP agents - ...=20 Tongue in cheek - confusing ? =20 Sent from my iPhone On Feb 14, 2014, at 11:27 AM, "MORTON, ALFRED C (AL)" wr= ote: >>> On Fri, Feb 14, 2014 at 10:57:33AM -0500, Sharam Hakimi wrote: >>> MPs are effectively Measurement Responders. Two Measurement responders >>> could not perform a test by the current definitions. This would mean >>> that I could assign a test to two entities that I do not even control. >>>=20 >>> Can we call a spade a spade. MP should really be called a measurement >>> Responder (MR) and I believe the term Responder is well understood ( it >>> does not initiate tests). >>=20 >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de= ] >>=20 >> This is not true or may be confusing. You can have an MA using a >> non-LMAP control protocol to trigger an MP sending traffic to an MA. >=20 > yes, said this just recently: "OWAMP can do it." > Al >=20 From nobody Fri Feb 14 13:48:57 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AEC1A0425 for ; Fri, 14 Feb 2014 13:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wgH-6KqUWtY for ; Fri, 14 Feb 2014 13:48:42 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 45B761A0411 for ; Fri, 14 Feb 2014 13:48:42 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 16:48:40 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Feb 2014 16:48:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Feb 2014 16:49:23 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B23841@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRdZ+UYn/wQ5EuM8kKUQT8gigABRf9wmrTseTCAAAp3UIAAjm6A//+gv1CAAAhbEIAAAidggAAQ82A= References: <20140213145255.GC85019@elstar.local> <20140213152252.GA85206@elstar.local> <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> <20140214194905.GA89769@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B23817@spboexc01.exfo.com> <2845723087023D4CB5114223779FA9C8BC5B9B33@njfpsrvexg8.research.att.com> From: "Sharam Hakimi" To: "MORTON, ALFRED C \(AL\)" , "KEN KO" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 14 Feb 2014 21:48:39.0824 (UTC) FILETIME=[85961100:01CF29CE] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/CZGPv0ghp1T-o7F3SsGXZRW0fCo Cc: Brian Trammell , charles.cook2@centurylink.com, "STARK, BARBARA H" , "Bugenhagen, Michael K" , lmap@ietf.org Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:48:47 -0000 Al, My assumption is that the device only has an MA function. I agree that it can have other functions, MP included, but if it only has an MA function then in order for it to be able to respond, it would have to have a silent responder built into its MA function. Sharam -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Friday, February 14, 2014 3:51 PM To: Sharam Hakimi; KEN KO; Juergen Schoenwaelder Cc: STARK, BARBARA H; charles.cook2@centurylink.com; lmap@ietf.org; Bugenhagen, Michael K; Brian Trammell Subject: RE: [lmap] MA vs MP No at all, you are assuming measurement functionality along with the LMAP system functions. There is nothing that prevents a device with an MA to also be equipped to act as either a TWAMP sender or reflector. Al > -----Original Message----- > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: Friday, February 14, 2014 3:41 PM > To: KEN KO; Juergen Schoenwaelder > Cc: STARK, BARBARA H; charles.cook2@centurylink.com; MORTON, ALFRED C > (AL); lmap@ietf.org; Bugenhagen, Michael K; Brian Trammell > Subject: RE: [lmap] MA vs MP >=20 > That would mean that an MA has a silent responder built inside it, > because without a responder function two senders cannot perform a test. >=20 > Sharam >=20 > -----Original Message----- > From: KEN KO [mailto:KEN.KO@adtran.com] > Sent: Friday, February 14, 2014 3:09 PM > To: Juergen Schoenwaelder; Sharam Hakimi > Cc: STARK, BARBARA H; charles.cook2@centurylink.com; MORTON JR., AL; > lmap@ietf.org; Bugenhagen, Michael K; Brian Trammell > Subject: RE: [lmap] MA vs MP >=20 > +1 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Friday, February 14, 2014 2:49 PM > > To: Sharam Hakimi > > Cc: STARK, BARBARA H; charles.cook2@centurylink.com; MORTON JR., AL; > > lmap@ietf.org; Bugenhagen, Michael K; KEN KO; Brian Trammell > > Subject: Re: [lmap] MA vs MP > > > > In particular, I > > believe an MA can initiate task for MA <-> MA test. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 From nobody Sun Feb 16 07:21:09 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34AE1A03EE; Sun, 16 Feb 2014 07:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWPABjWGbjed; Sun, 16 Feb 2014 07:20:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7021A0250; Sun, 16 Feb 2014 07:20:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140216152054.6394.98581.idtracker@ietfa.amsl.com> Date: Sun, 16 Feb 2014 07:20:54 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/CBHy3s-5t4RGrsfvQksdTTNl2-Y Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 15:21:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-00.txt Pages : 21 Date : 2014-02-14 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the MA or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the MA that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-information-model-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 17 03:49:16 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371051A048C for ; Mon, 17 Feb 2014 03:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkhe4qYcIBER for ; Mon, 17 Feb 2014 03:49:10 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 47D971A047A for ; Mon, 17 Feb 2014 03:49:08 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 17 Feb 2014 11:48:45 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 17 Feb 2014 11:48:31 +0000 From: To: Date: Mon, 17 Feb 2014 11:48:31 +0000 Thread-Topic: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8rzrCvkcTcIZKMQ229p7E8McN/qw== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEDF2EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Gq3bFWfKcQ3axzmuMMBkS7w8efw Subject: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 11:49:15 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEDF2EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There were a couple of comments about overlapping measurement tasks. draft-ietf-lmap-framework-03 says << {Comment: It is possible that the set of measurement schedules implies overlapping Measurement Tasks. It is not clear the best thing to do. Our current suggestion is to leave this to the protocol document.} >> I think we should say something in the framework doc - and not just punt th= is to the protocol doc (and in retrospect I'm not sure that's a good place)= . I still think it's not clear what the best thing to do is. As Charles says,= one approach is to run the first Task to start, then run the next. But one= can imagine tasks could get delayed - say a task was defined to "wait" if = it detected cross-user traffic, and try again a minute later. A task might = be written to re-try many times. Should you try and run the next task in th= e meantime? Should you allow multiple tasks to run at once? How many tasks = do you allow all to be waiting for others to complete? Are the consideratio= ns different if the Task is defined so that Measurement Peer sends traffic = towards the MA? These sorts of things seem quite complex and need accurate = knowledge of the characteristics of the task. Here's a proposal to say something meaningful but simple about overlapping = measurement tasks. -- In principle there are several reasons why a MA might have two Tasks that i= t are supposed to run at the same time: * The operator of the measurement system has unintentionally crea= ted a set of Schedules with overlapping Tasks * The completion of one Task is delayed beyond when another Task = is due to start (for example the Task may be designed to wait for a lull in= end-user traffic, or the Task may be of uncertain duration) In the initial stage of LMAP, overlapping Tasks will not be considered due = to their complexity. The above issues are addressed as follows * The operator of the measurement system should design their set = of Schedules with sufficient gaps between Tasks, so that one Task will comf= ortably complete before another begins * It is suggested that Tasks are never delayed - they either run = at the scheduled time or they don't * In line with this, if a (second) Task is due to start when a (f= irst) Task is still on-going, then the (second) Task is never started * A Task may delay itself internally (within the definition of th= e Task); this is invisible to the Schedule. However, caution is advised as = this may prevent other Tasks from executing * Rather than running a Passive Measurement Task continuously in = the background, instead it is run when there are no other Tasks operating * Rather than testing for the impact of cross-traffic by having t= wo Tasks that run simultaneously, instead a single Task generates two types= of traffic. More complex possibilities could be explored in LMAP2.0. As a general principle, if Tasks (especially Active ones) do overlap, this = should be noted in the Report, so that the Result can be treated with cauti= on. --- what do you reckon? Thanks phil From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: 05 February 2014 17:41 To: Eardley,PL,Philip,TUB8 R Cc: lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framew= ork-03.txt Phil, I like the improvements over the previous version. I did not have many add= itional comments on this draft. Attached is my marked up review. The main comments I had are as follows In summary: * Conflict Resolution: If two or more Measurement Tasks overlap in the= ir schedule, how should the MA behave? If two or more Measurement Tasks ar= e scheduled to start at the same time, the first one listed in the set of M= easurement Schedules can be run first. When complete, the conflicting Meas= urement Task can be run. If the Measurement Schedules overlap, but are not= scheduled to start at the same time, run the one scheduled to start first = to completion, and then run the overlapping Measurement Schedule. The Resu= lts Report should contain a start and stop time stamp that can be used in p= ost processing. Note: Some Measurement Tasks may be able to run in parall= el without impacting the Results of other Measurement Tasks. In this case,= scheduling conflicts are not an issue. But these will need to be will def= ined ahead of time. * MA Performing Pre-processing: I don't think that the MA should perfor= m pre-processing unless specifically instructed to do so in a Measurement M= ethod. The MA should provide enough detail in the Measurement Result to en= able post processing. Any Measurement Methods with pre-processing will nee= d to be very carefully constructed to ensure that the results are repeatabl= e/comparable. * MP Registration and Suppression: MPs also need to Register with the C= ontroller so that the Controller knows they exist. The Controller will als= o need to know the capabilities of the MP, and also have the ability to Sup= press/Unsuppress the MP as needed. I didn't see this in the draft. We jus= t need to add it. * Underlying Transport Protocol: Push and/or Pull: The LMAP Framework = identifies Push and Pull as possible underlying transport protocols, but do= es not specify a requirement. A discussion is needed to determine if one o= r both of these are required for the Framework. It sounds like Push is pre= ferred in general, but Pull may be needed in order to perform a Measurement= Task when the MA or MP is behind a NAT. Additional details are needed. F= or example should a Controller, in addition to Pushing out Instructions, pr= ovide a mechanism for an MA to Pull an Instruction if the MA is behind a NA= T? If a MA or MP is behind a NAT, should it execute a keep-alive so that t= he Controller knows where it is at? Great work. Charles On 1/21/2014 8:00 AM, philip.eardley@bt.com w= rote: We submitted a new version of the framework document. http://tools.ietf.org/html/draft-ietf-lmap-framework Here's a summary of the changes: o alignment with the Information Model [I-D.burbridge-lmap-information-model] as this is agreed as a WG document o One-off and periodic Measurement Schedules are kept separate, so that they can be updated independently o Measurement Suppression in a separate sub-section. Can now optionally include particular Measurement Tasks &/or Schedules to suppress, and start/stop time o for clarity, concept of Channel split into Control, Report and MA- to-Controller Channels o numerous editorial changes, mainly arising from a very detailed review by Charles Cook best wishes, phil, al, marcelo, trevor, paul, aamer _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEDF2EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= There were a couple of comments about over= lapping measurement tasks.

 

draft-ietf-lmap-framework-03 says 

<<=
;   {Comment: It is possible that t=
he set of measurement schedules

   implies overlapping Measurement Tasks.  It is not cle= ar the best

   thing= to do.  Our current suggestion is to leave this to the protocol<= /o:p>

   document.}<= /span>

>> 

 

I think we should say something in the framework doc – and= not just punt this to the protocol doc (and in retrospect I’m not su= re that’s a good place).

 

I still think it’s not clear wh= at the best thing to do is. As Charles says, one approach is to run the fir= st Task to start, then run the next. But one can imagine tasks could get de= layed – say a task was defined to “wait” if it detected c= ross-user traffic, and try again a minute later. A task might be written to= re-try many times. Should you try and run the next task in the meantime? S= hould you allow multiple tasks to run at once? How many tasks do you allow = all to be waiting for others to complete? Are the considerations different = if the Task is defined so that Measurement Peer sends traffic towards the M= A? These sorts of things seem quite complex and need accurate knowledge of = the characteristics of the task.

=  

Here’s a proposal to say some= thing meaningful but simple about overlapping measurement tasks.=

 = ;

--<= o:p>

=  

In principle there are several reasons why a MA might have two Tasks= that it are supposed to run at the same time:

•   &nb= sp;       The operator of the measurement sys= tem has unintentionally created a set of Schedules with overlapping Tasks

&= #8226;           The comp= letion of one Task is delayed beyond when another Task is due to start (for= example the Task may be designed to wait for a lull in end-user traffic, o= r the Task may be of uncertain duration)

 

In the initial stage of LMA= P, overlapping Tasks will not be considered due to their complexity.

&= nbsp;

The above issues are addressed as follows

•    &= nbsp;      The operator of the measurement system = should design their set of Schedules with sufficient gaps between Tasks, so= that one Task will comfortably complete before another begins

• = ;          It is suggested tha= t Tasks are never delayed – they either run at the scheduled time or = they don’t

•        &nb= sp;  In line with this, if a (second) Task is due to start when a (fir= st) Task is still on-going, then the (second) Task is never started

•=            A Task may del= ay itself internally (within the definition of the Task); this is invisible= to the Schedule. However, caution is advised as this may prevent other Tas= ks from executing

•        &n= bsp;  Rather than running a Passive Measurement Task continuously in t= he background, instead it is run when there are no other Tasks operating

&#= 8226;           Rather th= an testing for the impact of cross-traffic by having two Tasks that run sim= ultaneously, instead a single Task generates two types of traffic.

&nb= sp;

M= ore complex possibilities could be explored in LMAP2.0.

 

As a general= principle, if Tasks (especially Active ones) do overlap, this should be no= ted in the Report, so that the Result can be treated with caution.

 

---

what do you reckon?

 <= /p>

Thanks<= /span>

phil

 

From: Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: 0= 5 February 2014 17:41
To: Eardley,PL,Philip,TUB8 R
Cc: = lmap@ietf.org
Subject: Re: [lmap] FW: New Version Notification fo= r draft-ietf-lmap-framework-03.txt

 

Phil,

I like= the improvements over the previous version.  I did not have many addi= tional comments on this draft.  Attached is my marked up review. =

The main comments I had are as follows In summary:

<= ul type=3Ddisc>
  • Conflict Resolution: =   If two or more Measurement Tasks overlap in their schedule, how shou= ld the MA behave?  If two or more Measurement Tasks are scheduled to s= tart at the same time, the first one listed in the set of Measurement Sched= ules can be run first.  When complete, the conflicting Measurement Tas= k can be run.  If the Measurement Schedules overlap, but are not sched= uled to start at the same time, run the one scheduled to start first to com= pletion, and then run the overlapping Measurement Schedule.  The Resul= ts Report should contain a start and stop time stamp that can be used in po= st processing.  Note:  Some Measurement Tasks may be able to run = in parallel without impacting the Results of other Measurement Tasks. = In this case, scheduling conflicts are not an issue.  But these will = need to be will defined ahead of time. 
  • MA Performing Pre-processing:  I don't think = that the MA should perform pre-processing unless specifically instructed to= do so in a Measurement Method.  The MA should provide enough detail i= n the Measurement Result to enable post processing.  Any Measurement M= ethods with pre-processing will need to be very carefully constructed to en= sure that the results are repeatable/comparable.
  • MP Registration and Suppression:  MPs al= so need to Register with the Controller so that the Controller knows they e= xist.  The Controller will also need to know the capabilities of the M= P, and also have the ability to Suppress/Unsuppress the MP as needed. = I didn't see this in the draft.  We just need to add it.
  • Underlying Transport Protocol:&nb= sp; Push and/or Pull:  The LMAP Framework identifies Push and Pull as = possible underlying transport protocols, but does not specify a requirement= .  A discussion is needed to determine if one or both of these are req= uired for the Framework.  It sounds like Push is preferred in general,= but Pull may be needed in order to perform a Measurement Task when the MA = or MP is behind a NAT.  Additional details are needed.  For examp= le should a Controller, in addition to Pushing out Instructions, provide a = mechanism for an MA to Pull an Instruction if the MA is behind a NAT? = If a MA or MP is behind a NAT, should it execute a keep-alive so that the = Controller knows where it is at?


    • Great work.

    Charles

    On 1/21/2014 8:00 AM, philip.eardley@bt.com wrote:

    = 
    We submitte=
d a new version of the framework document.
     =

    http://tools.ietf.org/html/draft-ietf-lmap-framework =

     
    Here's a summary of the changes:
       o  alignment with the Information Model=

          [I-D.burbridge-lmap-in=
formation-model] as this is agreed as a WG
      =
;    document
     
       o  One-off and periodic Measurement Schedules are kept= separate, so
          that they=
 can be updated independently
     
    <= pre>   o  Measurement Suppression in a separate sub-section.=   Can now
          optional=
ly include particular Measurement Tasks &/or Schedules to
          suppress, and start/stop time
     
       o  for clarity=
, concept of Channel split into Control, Report and MA-
          to-Controller Channels
     
       o  numerous editorial chang=
es, mainly arising from a very detailed
      &n=
bsp;   review by Charles Cook
     
    best wishes,
    phil, al, marcelo, trevor, =
paul, aamer
     
    ______________=
_________________________________
    lmap mailing list
    lmap@ietf.org<=
/o:p>
    http=
s://www.ietf.org/mailman/listinfo/lmap



    -- 
     
    Charles Cook 
    Principal Archit=
ect
    Network
    5325 Zuni Street; Sui=
te 224
    Denver, CO  80221
    Tel=
:  303.992.8952  Fax:  925.281.0662
    charles.cook2@centurylink.com=
    = --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEDF2EMV67UKRDdoma_-- From nobody Mon Feb 17 04:15:35 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66BB1A04BE for ; Mon, 17 Feb 2014 04:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsA-AHuhZtQG for ; Mon, 17 Feb 2014 04:15:31 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id D88DF1A04BD for ; Mon, 17 Feb 2014 04:15:30 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 17 Feb 2014 12:15:24 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Mon, 17 Feb 2014 12:15:11 +0000 From: To: Date: Mon, 17 Feb 2014 12:15:11 +0000 Thread-Topic: Definition of Instruction (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8r2DiULYaV8mSaRQOeFi2z+cmJ5g== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEE1FEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/7yhhZxeIYclOqVTsmo-rVcnOuno Subject: [lmap] Definition of Instruction (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 12:15:34 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEE1FEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some comments made me realise the definition of Instruction needed clarifyi= ng - in particular, Ken pointed out that sometimes Instruction refers to th= e information in the MA (and Controller) - and sometimes to the message bet= ween the Controller and MA. I've worked with Ken, Charles and others (thank-you!) - proposed definition= is as follows (hopeful this would be aligned with Broadband forum's defini= tion) - Instruction: The description of Measurement Tasks for a MA to perform and the details of= the Report(s) for it to send. It is the collective description of the set = of Measurement Schedules, the set of Measurement Task configurations, the c= onfiguration of the Report Channel(s) and details of Suppression (if any). = The Controller sends a message over the Control Channel to the MA, in order= to update the Instruction or elements of it (there was a comment about the term 'Control Channel' which I'll get to lat= er) One thing to notice about this definition is that Suppression is part of th= e Instruction. phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEE1FEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Some comments made me rea= lise the definition of Instruction needed clarifying – in particular,= Ken pointed out that sometimes Instruction refers to the information in th= e MA (and Controller) – and sometimes to the message between the Cont= roller and MA.

     

    I’ve worked with Ken, Charles and others (thank-you!) - = proposed definition is as follows (hopeful this would be aligned with Broad= band forum’s definition) -

    &nb= sp;

    Instruction:

    The d= escription of Measurement Tasks for a MA to perform and the details of the = Report(s) for it to send. It is the collective description of the set of Me= asurement Schedules, the set of Measurement Task configurations, the config= uration of the Report Channel(s) and details of Suppression (if any). The C= ontroller sends a message over the Control Channel to the MA, in order to u= pdate the Instruction or elements of it

    &= nbsp;

    (there was a comment about the term ‘Co= ntrol Channel’ which I’ll get to later)

     

    One thing to notice about this de= finition is that Suppression is part of the Instruction.<= /p>

     

    phil

     

    = --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEE1FEMV67UKRDdoma_-- From nobody Mon Feb 17 04:25:20 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE651A034B for ; Mon, 17 Feb 2014 04:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2Aco8sp3iA7 for ; Mon, 17 Feb 2014 04:25:16 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAD71A015E for ; Mon, 17 Feb 2014 04:25:15 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAGr+AVOHCzIm/2dsb2JhbABZgkIjIThXvzSBHhZ0giUBAQEBAxIbXAIBCA0EBAEBCx0HMhQJCAEBBAESCBqHYwGfS6wVF45QNwEGgx6BFASUQ4pYizSBb4E+gio X-IronPort-AV: E=Sophos; i="4.95,860,1384318800"; d="scan'208,217"; a="49716203" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Feb 2014 07:25:12 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 17 Feb 2014 07:12:16 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 13:25:07 +0100 From: "Romascanu, Dan (Dan)" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] Definition of Instruction (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8r2DiULYaV8mSaRQOeFi2z+cmJ5gAAtiNg Date: Mon, 17 Feb 2014 12:25:06 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E41BA42@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E41BA42AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/AFNJ_pQ5PlpLMn9eTSqC1dQt8xg Subject: Re: [lmap] Definition of Instruction (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 12:25:19 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E41BA42AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe we should talk explicitly (and define) not only Instruction (and I am= fine with the definition below) but also' Instruction message' or 'message= carrying Instruction'. Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, February 17, 2014 2:15 PM To: lmap@ietf.org Subject: [lmap] Definition of Instruction (WGLC comments on draft-ietf-lmap= -framework-03) Some comments made me realise the definition of Instruction needed clarifyi= ng - in particular, Ken pointed out that sometimes Instruction refers to th= e information in the MA (and Controller) - and sometimes to the message bet= ween the Controller and MA. I've worked with Ken, Charles and others (thank-you!) - proposed definition= is as follows (hopeful this would be aligned with Broadband forum's defini= tion) - Instruction: The description of Measurement Tasks for a MA to perform and the details of= the Report(s) for it to send. It is the collective description of the set = of Measurement Schedules, the set of Measurement Task configurations, the c= onfiguration of the Report Channel(s) and details of Suppression (if any). = The Controller sends a message over the Control Channel to the MA, in order= to update the Instruction or elements of it (there was a comment about the term 'Control Channel' which I'll get to lat= er) One thing to notice about this definition is that Suppression is part of th= e Instruction. phil --_000_9904FB1B0159DA42B0B887B7FA8119CA2E41BA42AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Maybe we should talk e= xplicitly (and define) not only Instruction (and I am fine with the definit= ion below) but also’ Instruction message’ or ‘message car= rying Instruction’.

     

    Dan<= /p>

     

     

    From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
    Sent: Monday, February 17, 2014 2:15 PM
    To: lmap@ietf.org
    Subject: [lmap] Definition of Instruction (WGLC comments on draft-ie= tf-lmap-framework-03)

     

    Some comments made me real= ise the definition of Instruction needed clarifying – in particular, = Ken pointed out that sometimes Instruction refers to the information in the MA (and Controller) – and sometimes to the message between th= e Controller and MA.

     

    I’ve worked with Ken= , Charles and others (thank-you!) - proposed definition is as follows (hope= ful this would be aligned with Broadband forum’s definition) -

     

    Instruction:

    The description of Measurement Tasks for a MA t= o perform and the details of the Report(s) for it to send. It is the collec= tive description of the set of Measurement Schedules, the set of Measurement Task configurations, the configuration of the Repor= t Channel(s) and details of Suppression (if any). The Controller sends a me= ssage over the Control Channel to the MA, in order to update the Instructio= n or elements of it

     

    (there was a comment about the term ‘Cont= rol Channel’ which I’ll get to later)

     

    One thing to notice about this definition is th= at Suppression is part of the Instruction.

     

    phil

     

    --_000_9904FB1B0159DA42B0B887B7FA8119CA2E41BA42AZFFEXMB04globa_-- From nobody Mon Feb 17 05:58:03 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E02A1A01F6 for ; Mon, 17 Feb 2014 05:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkW2IDSBVgrA for ; Mon, 17 Feb 2014 05:57:58 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAFF1A01F1 for ; Mon, 17 Feb 2014 05:57:58 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 46512035.2ac0f3a8b940.2773696.00-2477.7732423.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 13:57:56 +0000 (UTC) X-MXL-Hash: 53021564377a3f39-b352e3065a087399ee7a817efeca9a194c9f909f Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id e5512035.0.2773663.00-2306.7732308.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 13:57:53 +0000 (UTC) X-MXL-Hash: 530215613980cd7a-3df8ce8d28f2d5235c2239bb5af998f8022f6243 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HDvnQw013144; Mon, 17 Feb 2014 08:57:49 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HDvdxj013035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 08:57:43 -0500 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 17 Feb 2014 13:57:25 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 08:57:25 -0500 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8rzrCvkcTcIZKMQ229p7E8McN/qwAFeghA Date: Mon, 17 Feb 2014 13:57:25 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.45.146] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611303E9446GAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=cIUMTu1c1TMA:10 a=ofMgfj31e3cA:10 a=3gqbixA_TXoA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=uCRMkwNkO] X-AnalysisOut: [M4A:10 a=fgyadf2rNTvS5UhPdhIA:9 a=CjuIK1q_8ugA:10 a=yMhMjl] X-AnalysisOut: [ubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A] X-AnalysisOut: [:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=soqfo-m_msGZniPN] X-AnalysisOut: [:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Ta8hFcguwG0IE94-6VTGFc4AUuo Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 13:58:02 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611303E9446GAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable * Rather than running a Passive Measurement Task continuously in = the background, instead it is run when there are no other Tasks operating I think this one item in the proposal is problematic and I don't see = a need for it. Lots of devices are continually running passive measurements= , and I don't want them to have to turn these off to start an active measur= ement. I'm also completely at a loss as to what the harm is. For example, i= n an RG, ADSL line statistics are always being captured, as are Ethernet fr= ames in/out and IP packets in/out. The firewall is logging various messages= it sees (and I really don't want to turn that off in order to run an activ= e measurement). There has also been the suggestion that the "responding" en= d of an active measurement task can simultaneously do passive measurements = on the traffic of that active measurement task. IMO, these are 2 separate t= asks (though, given the next bullet, we may not have a common definition of= Measurement Task, either). Anyway, unless the device is so incredibly proc= essor- or memory-limited that it can't collect passive measurements while d= oing active measurements (a serious design flaw, IMO, which would make me q= uestion this device's ability to even accurately do a single active measure= ment task), I see no reason to disable any passive measurements while other= measurements are occurring. Multiple passive measurements can also run sim= ultaneously. Oh -- and measuring internal processor- and memory-utilization= during the running of measurement tasks is also a passive measurement task= that I wouldn't want to see disabled. * Rather than testing for the impact of cross-traffic by having t= wo Tasks that run simultaneously, instead a single Task generates two types= of traffic. This is the point that makes me wonder if we're using the same defini= tion of "Task". Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defi= ned in a way that allows it to generate all of the needed types of traffic.= But the Measurement Methods (and the Registry of Measurement Methods) are = being defined external to lmap. This assumption would have the lmap framewo= rk imposing requirements on Measurement Methods and the associated Registry= in order to run certain tests. That makes me very uneasy. I'm also not understanding the proposed cross-traffic test, but maybe that'= s beside the point. I thought cross-traffic was something where we wanted t= o know whether or not there was any cross traffic present prior to starting= certain Active Measurement Tasks, or during an Active Measurement Task (wh= ich BTW would require something to do some passive measuring while the Acti= ve Measurement Task was happening). Understanding what sort of impact one t= ype of traffic has on the simultaneous running of another type of traffic, = from the same MA, strikes me as a rather complex thing to measure, and I'm = not sure I want to do much design around that, right now. --_000_2D09D61DDFA73D4C884805CC7865E611303E9446GAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    R= 26;           Rather than= running a Passive Measurement Task continuously in the background, instead= it is run when there are no other Tasks operating

    <bhs> I think this= one item in the proposal is problematic and I don’t see a need for i= t. Lots of devices are continually running passive measurements, and I don’t want them to have to turn these off to start an active measure= ment. I’m also completely at a loss as to what the harm is. For examp= le, in an RG, ADSL line statistics are always being captured, as are Ethern= et frames in/out and IP packets in/out. The firewall is logging various messages it sees (and I really don’t wan= t to turn that off in order to run an active measurement). There has also b= een the suggestion that the “responding” end of an active measu= rement task can simultaneously do passive measurements on the traffic of that active measurement task. IMO, these are 2 separate = tasks (though, given the next bullet, we may not have a common definition o= f Measurement Task, either). Anyway, unless the device is so incredibly pro= cessor- or memory-limited that it can’t collect passive measurements while doing active measurements (= a serious design flaw, IMO, which would make me question this device’= s ability to even accurately do a single active measurement task), I see no= reason to disable any passive measurements while other measurements are occurring. Multiple passive measurements can = also run simultaneously. Oh -- and measuring internal processor- and memory= -utilization during the running of measurement tasks is also a passive meas= urement task that I wouldn’t want to see disabled.

     = ;

    R= 26;           Rather than= testing for the impact of cross-traffic by having two Tasks that run simul= taneously, instead a single Task generates two types of traffic.=

    <bhs> This is the = point that makes me wonder if we’re using the same definition of R= 20;Task”. Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defined in a= way that allows it to generate all of the needed types of traffic. But the= Measurement Methods (and the Registry of Measurement Methods) are being de= fined external to lmap. This assumption would have the lmap framework imposing requirements on Measurement Methods= and the associated Registry in order to run certain tests. That makes me v= ery uneasy.

    I’m also not under= standing the proposed cross-traffic test, but maybe that’s beside the= point. I thought cross-traffic was something where we wanted to know whether or not there was any cross traffic present prior to starting certa= in Active Measurement Tasks, or during an Active Measurement Task (which BT= W would require something to do some passive measuring while the Active Mea= surement Task was happening). Understanding what sort of impact one type of traffic has on the simultaneous running of= another type of traffic, from the same MA, strikes me as a rather complex = thing to measure, and I’m not sure I want to do much design around th= at, right now.

    --_000_2D09D61DDFA73D4C884805CC7865E611303E9446GAALPA1MSGUSR9L_-- From nobody Mon Feb 17 06:38:04 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A6E1A0211 for ; Mon, 17 Feb 2014 06:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1YGbeFEWgcP for ; Mon, 17 Feb 2014 06:37:58 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB0F1A0207 for ; Mon, 17 Feb 2014 06:37:57 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 17 Feb 2014 14:37:34 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 17 Feb 2014 14:37:02 +0000 From: To: , Date: Mon, 17 Feb 2014 14:37:01 +0000 Thread-Topic: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8rzrCvkcTcIZKMQ229p7E8McN/qwAFeghAAAGRLIA= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEC1EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/wHAOEAhxI6ZtZ6m2iQcea_8Tc9o Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:38:03 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEC1EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-line Thanks phil From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 February 2014 13:57 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) * Rather than running a Passive Measurement Task continuously in = the background, instead it is run when there are no other Tasks operating I think this one item in the proposal is problematic and I don't see = a need for it. Lots of devices are continually running passive measurements= , and I don't want them to have to turn these off to start an active measur= ement. I'm also completely at a loss as to what the harm is. For example, i= n an RG, ADSL line statistics are always being captured, as are Ethernet fr= ames in/out and IP packets in/out. The firewall is logging various messages= it sees (and I really don't want to turn that off in order to run an activ= e measurement). There has also been the suggestion that the "responding" en= d of an active measurement task can simultaneously do passive measurements = on the traffic of that active measurement task. IMO, these are 2 separate t= asks (though, given the next bullet, we may not have a common definition of= Measurement Task, either). Anyway, unless the device is so incredibly proc= essor- or memory-limited that it can't collect passive measurements while d= oing active measurements (a serious design flaw, IMO, which would make me q= uestion this device's ability to even accurately do a single active measure= ment task), I see no reason to disable any passive measurements while other= measurements are occurring. Multiple passive measurements can also run sim= ultaneously. Oh -- and measuring internal processor- and memory-utilization= during the running of measurement tasks is also a passive measurement task= that I wouldn't want to see disabled. [phil] should suppression by default impact all Tasks or just Active ones? = The argument for the former is that it's simpler - it avoids having to clas= sify Tasks as active or passive - and for the MA having to remember this in= fo. It avoids getting into discussion about whether the passive tasks are g= enerating a lot of Reports (should they be suppressed), what to do if an ac= tive task has been mis-classified as a passive task, what happens if the op= erator wants to suppress tasks for reasons other than a network overload (p= erhaps some privacy attack), can we treat an active task that only generate= s 1 or 2 packets as (almost) passive. I have sympathy with your viewpoint (in fact, it was my viewpoint earlier).= At the moment, given suppression is only a rare thing, I've been persuaded= it's better to go for simplicity and make suppression affect all Tasks by = default. (of course, one can use the suppression option to list specific Ta= sks that are suppressed.) * Rather than testing for the impact of cross-traffic by having t= wo Tasks that run simultaneously, instead a single Task generates two types= of traffic. This is the point that makes me wonder if we're using the same defini= tion of "Task". Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defi= ned in a way that allows it to generate all of the needed types of traffic.= But the Measurement Methods (and the Registry of Measurement Methods) are = being defined external to lmap. This assumption would have the lmap framewo= rk imposing requirements on Measurement Methods and the associated Registry= in order to run certain tests. That makes me very uneasy. I'm also not understanding the proposed cross-traffic test, but maybe that'= s beside the point. I thought cross-traffic was something where we wanted t= o know whether or not there was any cross traffic present prior to starting= certain Active Measurement Tasks, or during an Active Measurement Task (wh= ich BTW would require something to do some passive measuring while the Acti= ve Measurement Task was happening). Understanding what sort of impact one t= ype of traffic has on the simultaneous running of another type of traffic, = from the same MA, strikes me as a rather complex thing to measure, and I'm = not sure I want to do much design around that, right now. [phil] I meant something on the lines of your last sentence: understanding = the impact of one sort of traffic on another sort. I agree this is quite co= mplex - some people have mentioned a test on these lines - so I was just po= inting out an implication for the proposed way of handling overlapping Task= s. --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEC1EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    = In-line

    Thanks

    phil

     

    From: STARK= , BARBARA H [mailto:bs7652@att.com]
    Sent: 17 February 2014 13:57=
    To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
    Subject: R= E: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framewor= k-03)

     

    • &n= bsp;         Rather than running a = Passive Measurement Task continuously in the background, instead it is run = when there are no other Tasks operating

    = <bhs> I think this one item in the proposal is problematic and I don&= #8217;t see a need for it. Lots of devices are continually running passive = measurements, and I don’t want them to have to turn these off to star= t an active measurement. I’m also completely at a loss as to what the= harm is. For example, in an RG, ADSL line statistics are always being capt= ured, as are Ethernet frames in/out and IP packets in/out. The firewall is = logging various messages it sees (and I really don’t want to turn tha= t off in order to run an active measurement). There has also been the sugge= stion that the “responding” end of an active measurement task c= an simultaneously do passive measurements on the traffic of that active mea= surement task. IMO, these are 2 separate tasks (though, given the next bull= et, we may not have a common definition of Measurement Task, either). Anywa= y, unless the device is so incredibly processor- or memory-limited that it = can’t collect passive measurements while doing active measurements (a= serious design flaw, IMO, which would make me question this device’s= ability to even accurately do a single active measurement task), I see no = reason to disable any passive measurements while other measurements are occ= urring. Multiple passive measurements can also run simultaneously. Oh -- an= d measuring internal processor- and memory-utilization during the running o= f measurement tasks is also a passive measurement task that I wouldn’= t want to see disabled.

     =

    [phil] should suppression by default impact all Tasks or just Act= ive ones? The argument for the former is that it’s simpler – it= avoids having to classify Tasks as active or passive – and for the M= A having to remember this info. It avoids getting into discussion about whe= ther the passive tasks are generating a lot of Reports (should they be supp= ressed), what to do if an active task has been mis-classified as a passive = task, what happens if the operator wants to suppress tasks for reasons othe= r than a network overload (perhaps some privacy attack), can we treat an ac= tive task that only generates 1 or 2 packets as (almost) passive.

     

    I have sympathy with y= our viewpoint (in fact, it was my viewpoint earlier). At the moment, given = suppression is only a rare thing, I’ve been persuaded it’s bett= er to go for simplicity and make suppression affect all Tasks by default. (= of course, one can use the suppression option to list specific Tasks that a= re suppressed.)

    •&= nbsp;          Rather than tes= ting for the impact of cross-traffic by having two Tasks that run simultane= ously, instead a single Task generates two types of traffic.

    <bhs> This is the point that makes me wonder if = we’re using the same definition of “Task”. Since Measurem= ent Task is an instantiation of a Measurement Method, this would imply that= the Measurement Method would have to be defined in a way that allows it to= generate all of the needed types of traffic. But the Measurement Methods (= and the Registry of Measurement Methods) are being defined external to lmap= . This assumption would have the lmap framework imposing requirements on Me= asurement Methods and the associated Registry in order to run certain tests= . That makes me very uneasy.

    I’m a= lso not understanding the proposed cross-traffic test, but maybe that’= ;s beside the point. I thought cross-traffic was something where we wanted = to know whether or not there was any cross traffic present prior to startin= g certain Active Measurement Tasks, or during an Active Measurement Task (w= hich BTW would require something to do some passive measuring while the Act= ive Measurement Task was happening). Understanding what sort of impact one = type of traffic has on the simultaneous running of another type of traffic,= from the same MA, strikes me as a rather complex thing to measure, and I&#= 8217;m not sure I want to do much design around that, right now.=

     

    [phil] I meant something= on the lines of your last sentence: understanding the impact of one sort o= f traffic on another sort. I agree this is quite complex – some peopl= e have mentioned a test on these lines – so I was just pointing out a= n implication for the proposed way of handling overlapping Tasks.

    = --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEC1EMV67UKRDdoma_-- From nobody Mon Feb 17 06:41:13 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F1F1A04EF for ; Mon, 17 Feb 2014 06:41:11 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com>\n X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW8HvzM2dDSc for ; Mon, 17 Feb 2014 06:41:07 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3411A0207 for ; Mon, 17 Feb 2014 06:41:06 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 17 Feb 2014 14:40:46 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 17 Feb 2014 14:41:03 +0000 From: To: , Date: Mon, 17 Feb 2014 14:41:03 +0000 Thread-Topic: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8rzrCvkcTcIZKMQ229p7E8McN/qwAFeghAAAGRLIAAAM6vQA== Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEC6EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/qr6rv0Z7iou0tt5bkdR--YNuV7Y Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:41:11 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEC6EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry please ignore, I will re-write shortly without the confusing referenc= e to suppression! (am currently preparing an email about suppression - too many overlapping t= asks in my brain!!) From: Eardley,PL,Philip,TUB8 R Sent: 17 February 2014 14:37 To: 'STARK, BARBARA H'; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) In-line Thanks phil From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 February 2014 13:57 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) * Rather than running a Passive Measurement Task continuously in = the background, instead it is run when there are no other Tasks operating I think this one item in the proposal is problematic and I don't see = a need for it. Lots of devices are continually running passive measurements= , and I don't want them to have to turn these off to start an active measur= ement. I'm also completely at a loss as to what the harm is. For example, i= n an RG, ADSL line statistics are always being captured, as are Ethernet fr= ames in/out and IP packets in/out. The firewall is logging various messages= it sees (and I really don't want to turn that off in order to run an activ= e measurement). There has also been the suggestion that the "responding" en= d of an active measurement task can simultaneously do passive measurements = on the traffic of that active measurement task. IMO, these are 2 separate t= asks (though, given the next bullet, we may not have a common definition of= Measurement Task, either). Anyway, unless the device is so incredibly proc= essor- or memory-limited that it can't collect passive measurements while d= oing active measurements (a serious design flaw, IMO, which would make me q= uestion this device's ability to even accurately do a single active measure= ment task), I see no reason to disable any passive measurements while other= measurements are occurring. Multiple passive measurements can also run sim= ultaneously. Oh -- and measuring internal processor- and memory-utilization= during the running of measurement tasks is also a passive measurement task= that I wouldn't want to see disabled. [phil] should suppression by default impact all Tasks or just Active ones? = The argument for the former is that it's simpler - it avoids having to clas= sify Tasks as active or passive - and for the MA having to remember this in= fo. It avoids getting into discussion about whether the passive tasks are g= enerating a lot of Reports (should they be suppressed), what to do if an ac= tive task has been mis-classified as a passive task, what happens if the op= erator wants to suppress tasks for reasons other than a network overload (p= erhaps some privacy attack), can we treat an active task that only generate= s 1 or 2 packets as (almost) passive. I have sympathy with your viewpoint (in fact, it was my viewpoint earlier).= At the moment, given suppression is only a rare thing, I've been persuaded= it's better to go for simplicity and make suppression affect all Tasks by = default. (of course, one can use the suppression option to list specific Ta= sks that are suppressed.) * Rather than testing for the impact of cross-traffic by having t= wo Tasks that run simultaneously, instead a single Task generates two types= of traffic. This is the point that makes me wonder if we're using the same defini= tion of "Task". Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defi= ned in a way that allows it to generate all of the needed types of traffic.= But the Measurement Methods (and the Registry of Measurement Methods) are = being defined external to lmap. This assumption would have the lmap framewo= rk imposing requirements on Measurement Methods and the associated Registry= in order to run certain tests. That makes me very uneasy. I'm also not understanding the proposed cross-traffic test, but maybe that'= s beside the point. I thought cross-traffic was something where we wanted t= o know whether or not there was any cross traffic present prior to starting= certain Active Measurement Tasks, or during an Active Measurement Task (wh= ich BTW would require something to do some passive measuring while the Acti= ve Measurement Task was happening). Understanding what sort of impact one t= ype of traffic has on the simultaneous running of another type of traffic, = from the same MA, strikes me as a rather complex thing to measure, and I'm = not sure I want to do much design around that, right now. [phil] I meant something on the lines of your last sentence: understanding = the impact of one sort of traffic on another sort. I agree this is quite co= mplex - some people have mentioned a test on these lines - so I was just po= inting out an implication for the proposed way of handling overlapping Task= s. --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEC6EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    = Sorry please ig= nore, I will re-write shortly without the confusing reference to suppressio= n!

    (am currently preparing an email about suppre= ssion – too many overlapping tasks in my brain!!)

     

    From: Eardley,= PL,Philip,TUB8 R
    Sent: 17 February 2014 14:37
    To: 'STA= RK, BARBARA H'; lmap@ietf.org
    Subject: RE: Overlapping Measuremen= t Tasks (WGLC comments on draft-ietf-lmap-framework-03)

     

    In-line<= /o:p>

    Thanks

    phil

     

    From: S= TARK, BARBARA H [mailto:bs7652@att.com]
    Sent: 17 February 2014 13:57
    To: Eardley,PL,Philip,= TUB8 R;     lmap@ietf.org
    Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-fram= ework-03)

     =

    •&nbs= p;          Rather than runnin= g a Passive Measurement Task continuously in the background, instead it is = run when there are no other Tasks operating

    <bhs> I think this one item in the proposal is problematic and = I don’t see a need for it. Lots of devices are continually running pa= ssive measurements, and I don’t want them to have to turn these off t= o start an active measurement. I’m also completely at a loss as to wh= at the harm is. For example, in an RG, ADSL line statistics are always bein= g captured, as are Ethernet frames in/out and IP packets in/out. The firewa= ll is logging various messages it sees (and I really don’t want to tu= rn that off in order to run an active measurement). There has also been the= suggestion that the “responding” end of an active measurement = task can simultaneously do passive measurements on the traffic of that acti= ve measurement task. IMO, these are 2 separate tasks (though, given the nex= t bullet, we may not have a common definition of Measurement Task, either).= Anyway, unless the device is so incredibly processor- or memory-limited th= at it can’t collect passive measurements while doing active measureme= nts (a serious design flaw, IMO, which would make me question this device&#= 8217;s ability to even accurately do a single active measurement task), I s= ee no reason to disable any passive measurements while other measurements a= re occurring. Multiple passive measurements can also run simultaneously. Oh= -- and measuring internal processor- and memory-utilization during the run= ning of measurement tasks is also a passive measurement task that I wouldn&= #8217;t want to see disabled.

     <= /span>

    [phil] should suppression by default impact all Tasks or ju= st Active ones? The argument for the former is that it’s simpler R= 11; it avoids having to classify Tasks as active or passive – and for= the MA having to remember this info. It avoids getting into discussion abo= ut whether the passive tasks are generating a lot of Reports (should they b= e suppressed), what to do if an active task has been mis-classified as a pa= ssive task, what happens if the operator wants to suppress tasks for reason= s other than a network overload (perhaps some privacy attack), can we treat= an active task that only generates 1 or 2 packets as (almost) passive.

     

    <= span style=3D'font-family:"Arial","sans-serif";color:blue'>I have sympathy = with your viewpoint (in fact, it was my viewpoint earlier). At the moment, = given suppression is only a rare thing, I’ve been persuaded it’= s better to go for simplicity and make suppression affect all Tasks by defa= ult. (of course, one can use the suppression option to list specific Tasks = that are suppressed.)

     

    •           Rath= er than testing for the impact of cross-traffic by having two Tasks that ru= n simultaneously, instead a single Task generates two types of traffic.

    <bhs> This is the point that makes me= wonder if we’re using the same definition of “Task”. Sin= ce Measurement Task is an instantiation of a Measurement Method, this would= imply that the Measurement Method would have to be defined in a way that a= llows it to generate all of the needed types of traffic. But the Measuremen= t Methods (and the Registry of Measurement Methods) are being defined exter= nal to lmap. This assumption would have the lmap framework imposing require= ments on Measurement Methods and the associated Registry in order to run ce= rtain tests. That makes me very uneasy.

    = I’m also not understanding the proposed cross-traffic test, but maybe= that’s beside the point. I thought cross-traffic was something where= we wanted to know whether or not there was any cross traffic present prior= to starting certain Active Measurement Tasks, or during an Active Measurem= ent Task (which BTW would require something to do some passive measuring wh= ile the Active Measurement Task was happening). Understanding what sort of = impact one type of traffic has on the simultaneous running of another type = of traffic, from the same MA, strikes me as a rather complex thing to measu= re, and I’m not sure I want to do much design around that, right now.=

     

    [phil] I mean= t something on the lines of your last sentence: understanding the impact of= one sort of traffic on another sort. I agree this is quite complex –= some people have mentioned a test on these lines – so I was just poi= nting out an implication for the proposed way of handling overlapping Tasks= .

    = --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEC6EMV67UKRDdoma_-- From nobody Mon Feb 17 07:02:37 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6E41A0207 for ; Mon, 17 Feb 2014 07:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7y3WuHc2AEK for ; Mon, 17 Feb 2014 07:02:31 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id BC5A21A01CE for ; Mon, 17 Feb 2014 07:02:30 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 17 Feb 2014 15:02:09 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Mon, 17 Feb 2014 15:02:15 +0000 From: To: Date: Mon, 17 Feb 2014 15:02:13 +0000 Thread-Topic: Measurement Suppression (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8r17HZyK2bFe3kRj2TM/+o+WTEjA== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEE4EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/VCVWrDvEMgmaS9HEvrg0vzT3dgg Subject: [lmap] Measurement Suppression (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:02:35 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEE4EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There were a number of comments about Suppression. There was also some disc= ussion in WT-304 (Broadband forum) and it would be very nice to keep BBF & = LMAP in step. Here's a proposal how to handle the various comments: - A couple of people suggested that Suppression should also be able t= o affect the Measurement Peer. I'm proposing not to include this, because S= uppression is part of the Instruction and M Peers don't get instructions. - Suppression should affect all M Tasks, not just Active ones. Reason= : simplicity. Avoids having to classify tasks as active or passive. Also, y= ou may want to suppress passive tasks - perhaps they are generating a lot o= f Reports, or an active task has been mis-classified as a passive task, or = there is some privacy issue that means passive Tasks need to be suppressed. - There should be an option in Suppression to stop on-going Tasks (th= e current text stops any new Tasks and says the impact on on-going Tasks is= undefined). Reason: on-going Tasks may be long-running and generating a lo= t of traffic. Comment: I wrote "a request that the MA stops on-going Measur= ement Tasks" rather than "the MA stops on-going Measurement Tasks" - not su= re that the MA would be able to stop all Tasks So the suppression section would look like this:- 5.2.1. Measurement Suppression Measurement Suppression is used if the measurement system wants to eliminate inessential traffic, because there is some unexpected network issue for example. The Controller instructs the MA to temporarily not begin new Measurement Tasks. By default, suppression applies to all Measurement Tasks, starts immediately and continues until an un-suppress message is received. Optionally the suppress message may include: o a set of Active Measurement Tasks to suppress; the others are not suppressed. For example, a particular Measurement Task may be overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends. o a request that the MA stops on-going Measurement Tasks (by default, i= t is not defined what the impact of Suppression is on on-going Measurement = Tasks; see Section 5.3) Note that Suppression is not intended to permanently stop a Measurement Task (instead, the Controller should send a new Measurement Schedule), nor to permanently disable a MA (instead, some kind of management action is suggested). +-----------------+ +-------------+ | | | Measurement | | Controller |=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| Agent | +-----------------+ +-------------+ Suppress: [(Measurement Task), -> (Measurement Schedule), start time, end time, stop on-going Tasks?] <- ACK Un-suppress -> <- ACK -- Comments? Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEE4EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    There were a number = of comments about Suppression. There was also some discussion in WT-304 (Br= oadband forum) and it would be very nice to keep BBF & LMAP in step.

     

    Here’s a proposal how to handle the various comments:

    -       A couple of people suggested that Suppression should= also be able to affect the Measurement Peer. I’m proposing not to in= clude this, because Suppression is part of the Instruction and M Peers don&= #8217;t get instructions.

    = - =       Suppression sho= uld affect all M Tasks, not just Active ones. Reason: simplicity. Avoids ha= ving to classify tasks as active or passive. Also, you may want to suppress= passive tasks – perhaps they are generating a lot of Reports, or an = active task has been mis-classified as a passive task, or there is some pri= vacy issue that means passive Tasks need to be suppressed.

    -       There should be an option in Suppression to stop on-going = Tasks (the current text stops any new Tasks and says the impact on on-going= Tasks is undefined). Reason: on-going Tasks may be long-running and genera= ting a lot of traffic. Comment: I wrote “a request that = the MA stops on-going Measurement Tasks” rather than “the MA st= ops on-going Measurement Tasks” – not sure that the MA would be= able to stop all Tasks

     = ;

    So the suppression section would look li= ke this:-

     

     

    5.2.1.  Measurement Suppression

       Measurement Suppression is used if the measurement system= wants to
       eliminate inessential=
 traffic, because there is some unexpected
    &=
nbsp;  network issue for example.  The Controller instructs the M=
A to
       temporarily not begin new =
Measurement Tasks.  By default,
     &=
nbsp; suppression applies to all Measurement Tasks, starts
       immediately and continues until an un-suppress =
message is received.
       Optionally=
 the suppress message may include:
    &nbs=
p;
       o  a set of Active Measureme=
nt Tasks to suppress; the others are not
    &n=
bsp;     suppressed.  For example, a particular Me=
asurement Task may be
       &nbs=
p;  overloading a Measurement Peer.
     
       o  a set of Measureme=
nt Schedules to suppress; the others are not
          suppressed.  For example, suppose the =
measurement system has
        &n=
bsp; defined two Schedules, one with the most critical
          Measurement Tasks and the ot=
her with less critical ones that
      =
;    create a lot of traffic, then it may only want to suppr=
ess the
          secon=
d.
     
    &n=
bsp;  o  a start time, at which suppression begins
     
       o =
 an end time, at which suppression ends.
     
       o  a request that the=
 MA stops on-going Measurement Tasks (by default, it is not defined what th=
e impact of Suppression is on on-going Measurement Tasks; see Section =
5.3)
     
       Note that Suppression is not intended to permanently stop a=

       Measurement Task (instead, th=
e Controller should send a new
       =
Measurement Schedule), nor to permanently disable a MA (instead, some<=
/o:p>
       kind of management action is suggest=
ed).
     
    &=
nbsp;  +-----------------+       &n=
bsp;            =
;            &n=
bsp;  +-------------+
       |&nb=
sp;            =
    |         &=
nbsp;           &nbs=
p;             =
| Measurement |
       |  Control=
ler     |=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|  Agent&n=
bsp;     |
       =
+-----------------+         &n=
bsp;            =
;             +=
-------------+
     
       Suppress:
      =
 [(Measurement Task),         =
            ->
        (Measurement Schedule),
        start time, end time,
        stop on-going Tasks?]
             =
;            &n=
bsp;            =
;          <-  &n=
bsp;           ACK
     
      =
 Un-suppress          &nb=
sp;            =
       ->
    &=
nbsp;           &nbs=
p;             =
            &nb=
sp;     <-      &=
nbsp;       ACK
     
    --
    Comments?
    Thanks<=
/p>
    phil
    = --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABEEE4EMV67UKRDdoma_-- From nobody Mon Feb 17 07:06:24 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2235E1A0203 for ; Mon, 17 Feb 2014 07:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNBlSMsp_tNA for ; Mon, 17 Feb 2014 07:06:21 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF511A01CE for ; Mon, 17 Feb 2014 07:06:21 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1HF6Bg7022535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 09:06:11 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 454431E0089; Mon, 17 Feb 2014 08:06:06 -0700 (MST) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 1F0101E0092; Mon, 17 Feb 2014 08:06:06 -0700 (MST) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1HF65GH009767; Mon, 17 Feb 2014 08:06:05 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1HF65Lq009757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 08:06:05 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 09:06:04 -0600 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" , "'Sharam Hakimi'" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihkwABRf9wmrTseTCAAAp3UIAAjm6A//+gv1CAAAhbEIAAZ+0AgAPxBcA= Date: Mon, 17 Feb 2014 15:06:03 +0000 Message-ID: References: <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> <20140214194905.GA89769@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B23817@spboexc01.exfo.com> <20140214205038.GA90067@elstar.local> In-Reply-To: <20140214205038.GA90067@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/swa4yH6OhXR5yz6OzFGCZpiCVKo Cc: "Cook, Charles" , "'MORTON JR., AL'" , "'lmap@ietf.org'" , 'KEN KO' , "'STARK, BARBARA H'" , 'Brian Trammell' Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:06:23 -0000 Juergen -=20 Just to clarify- I don't the we've defined the actual scientific catoreg= izational differences Specifically - The BBF MA - Rests above all other MA levels on that device and all the t= est and probe functions are controlled by it (with the exception of normal = protocol interactions). It does this specifically so it knows how many tests are running at one= time. =09 I don't think the MA in LMAP assumes tracking all tests as stated above, = and unless I miss understand it - the LMAP MA would do some type of resourc= e check - but not track all tests.. Cheers, Mike -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, February 14, 2014 2:51 PM To: Sharam Hakimi Cc: KEN KO; STARK, BARBARA H; Cook, Charles; MORTON JR., AL; lmap@ietf.org;= Bugenhagen, Michael K; Brian Trammell Subject: Re: [lmap] MA vs MP On Fri, Feb 14, 2014 at 03:40:36PM -0500, Sharam Hakimi wrote: > That would mean that an MA has a silent responder built inside it,=20 > because without a responder function two senders cannot perform a test. You seem to assume that MA is a sender and an MP is a receiver, which is no= t what the text says. Hence you draw wrong conclusions. And a measurement b= etween to MAs does not even require that there are any responses at all. It= is perfectly fine that one MA generates a traffic train that is received b= y another MA. The LMAP framework tries to stay generic. It is the concrete = measurement tests you run that make the difference. /js PS: If I do something as simple as sending ICMP echo requests, then pretty much every IP implementation has a built-in responder. Claiming this would not be the case would be kind of in conflict with how basic IP works. --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Feb 17 07:09:49 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C4A1A01CE for ; Mon, 17 Feb 2014 07:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK53qUpW6mie for ; Mon, 17 Feb 2014 07:09:44 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id A6AA71A021B for ; Mon, 17 Feb 2014 07:09:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BBFEDFC3; Mon, 17 Feb 2014 16:09:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 51F3x-pUono1; Mon, 17 Feb 2014 16:09:39 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Mon, 17 Feb 2014 16:09:39 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D60D20015; Mon, 17 Feb 2014 16:09:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id htScNH7hrvCo; Mon, 17 Feb 2014 16:09:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39AC920013; Mon, 17 Feb 2014 16:09:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 233B32B55461; Mon, 17 Feb 2014 16:09:37 +0100 (CET) Date: Mon, 17 Feb 2014 16:09:37 +0100 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20140217150937.GB99261@elstar.local> Mail-Followup-To: philip.eardley@bt.com, lmap@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FcWeMsu5zjDZhwZeuWmd-Giy5cI Cc: lmap@ietf.org Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:09:48 -0000 On Mon, Feb 17, 2014 at 11:48:31AM +0000, philip.eardley@bt.com wrote: > There were a couple of comments about overlapping measurement tasks. > > draft-ietf-lmap-framework-03 says > > << {Comment: It is possible that the set of measurement schedules > implies overlapping Measurement Tasks. It is not clear the best > thing to do. Our current suggestion is to leave this to the protocol > document.} > >> > > I think we should say something in the framework doc - and not just punt this to the protocol doc (and in retrospect I'm not sure that's a good place). > > I still think it's not clear what the best thing to do is. As Charles says, one approach is to run the first Task to start, then run the next. But one can imagine tasks could get delayed - say a task was defined to "wait" if it detected cross-user traffic, and try again a minute later. A task might be written to re-try many times. Should you try and run the next task in the meantime? Should you allow multiple tasks to run at once? How many tasks do you allow all to be waiting for others to complete? Are the considerations different if the Task is defined so that Measurement Peer sends traffic towards the MA? These sorts of things seem quite complex and need accurate knowledge of the characteristics of the task. > I do not think that overlapping tasks are necessarily evil. It really depends on the nature of the measurement tasks whether this is a problem or not and it even depends on the purpose of the measurement (e.g., I might run a bulk download measurement just to generate lots of background traffic for something else I am interested to study under load). I think we should refrain from hardcoding assumptions about the nature of measurement tasks into the LMAP framework or information model or protocol. We should separate policy from the mechanism. If we want to tackle this problem, we should allow people to express which sets of tasks may not overlap and the action to take if this constrained is violated (delay starting, do not start at all, kill the running task and start, start anyway but report the issue, ...). I actually think it is not too hard to provide the mechanisms such that suitable policies can be configured. But all this comes with a cost of course (but the added robustness may be worth it - I have my own set of experience of cron jobs going wild in certain situations). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Feb 17 07:10:26 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE501A0207 for ; Mon, 17 Feb 2014 07:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-TSmX4Uk9w8 for ; Mon, 17 Feb 2014 07:10:20 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id B1B4C1A0222 for ; Mon, 17 Feb 2014 07:10:19 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 95622035.2ac0a8a13940.2817221.00-2477.7858267.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 15:10:17 +0000 (UTC) X-MXL-Hash: 5302265944657906-db2b54907035f8cc603144b6cf81aaf5458ed192 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 35622035.0.2817170.00-2270.7858109.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 15:10:12 +0000 (UTC) X-MXL-Hash: 530226542be4d207-c531ccebccf69a9323e3db5529d04a6f2de286c9 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HFA9Va001435; Mon, 17 Feb 2014 10:10:10 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HF9xhF001200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 10:10:02 -0500 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 17 Feb 2014 15:09:42 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 10:09:42 -0500 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Is suppression just for Active Measurement Tasks Thread-Index: Ac8r8kSovBNM0GKVQzG03CdAC7BkTQ== Date: Mon, 17 Feb 2014 15:09:40 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303E953A@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.45.146] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611303E953AGAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=8iRfzFZV_vEA:10 a=ofMgfj31e3cA:10 a=3gqbixA_TXoA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=IZZzUd2rG] X-AnalysisOut: [m4A:10 a=z2xXK00m6Bxap6ft4q0A:9 a=CjuIK1q_8ugA:10 a=yMhMjl] X-AnalysisOut: [ubAAAA:8 a=SSmOFEACAAAA:8 a=THOmu_m3vy2JioyfA1UA:9 a=gKO2H] X-AnalysisOut: [q4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-] X-AnalysisOut: [hUA:10 a=yBITQOuji0Yo-uBY:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/80Ay7F_g0cmkTOKP6G9lzsxZUGg Subject: [lmap] Is suppression just for Active Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:10:23 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611303E953AGAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil, Sorry, I just can't ignore. :) But I did change the subject line of the ema= il thread. [phil] should suppression by default impact all Tasks or just Active ones? = The argument for the former is that it's simpler - it avoids having to clas= sify Tasks as active or passive - and for the MA having to remember this in= fo. It avoids getting into discussion about whether the passive tasks are g= enerating a lot of Reports (should they be suppressed), what to do if an ac= tive task has been mis-classified as a passive task, what happens if the op= erator wants to suppress tasks for reasons other than a network overload (p= erhaps some privacy attack), can we treat an active task that only generate= s 1 or 2 packets as (almost) passive. I have sympathy with your viewpoint (in fact, it was my viewpoint earlier).= At the moment, given suppression is only a rare thing, I've been persuaded= it's better to go for simplicity and make suppression affect all Tasks by = default. (of course, one can use the suppression option to list specific Ta= sks that are suppressed.) I'm currently working on formulating a coherent argument as to why I = think suppression should only apply to active measurements. I'm not done th= inking this through, but I'll pass along some of where I'm at with this thi= nking. 1. We've talked about the possibility of MAs being in home routers, s= et-top-boxes, and various network elements (DSLAM, BNG, etc) and such. In o= ther words, as a function inside a device/element with a whole lot of other= functions and not dedicated to measurements. I'm not sure if people sugges= ting suppression apply to passive measurements are fully aware of the exten= t of passive measurement that goes on in these device/elements today. It's = huge. And, yes, the firewall log is generated through passive measurement. = Firewall logging is the main required element of any ICSA-compliant firewal= l. Shutting all of this down is not a good idea, and is completely unnecess= ary. 2. The idea for suppression was initially put forward as a means to p= rotect the network during times of congestion, or to protect certain "MPs" = or "MAs that can 'respond' to measurement tasks" when those MPs and MAs are= having issues. Passive measurements have no impact on these. 3. If suppression is seen as "don't generate IP packets / Ethernet fr= ames related to any Measurement Task (or related to just this specific list= of Tasks/Methods/Schedules)", then there is no need for classification of = passive vs. active and passive measurements are automatically exempt. This = is pretty simple -- even I could figure out how to code this. BTW, I don't see reports as being a component of suppression either. Suppre= ssion shouldn't brick a device/element or shut down all its functions. Just= don't generate any traffic associated with performing measurement tasks. --_000_2D09D61DDFA73D4C884805CC7865E611303E953AGAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Phil,

    Sorry, I just can’t= ignore. J But I did change the subject line of t= he email thread.

     <= /p>

    [phil] should suppression = by default impact all Tasks or just Active ones? The argument for the forme= r is that it’s simpler – it avoids having to classify Tasks as active or passive – and for the MA having to remember this info. = It avoids getting into discussion about whether the passive tasks are gener= ating a lot of Reports (should they be suppressed), what to do if an active= task has been mis-classified as a passive task, what happens if the operator wants to suppress tasks for reasons oth= er than a network overload (perhaps some privacy attack), can we treat an a= ctive task that only generates 1 or 2 packets as (almost) passive.

     

    I have sympathy with your viewpo= int (in fact, it was my viewpoint earlier). At the moment, given suppressio= n is only a rare thing, I’ve been persuaded it’s better to go for simplicity and make suppression affect all Tasks by default. (of co= urse, one can use the suppression option to list specific Tasks that are su= ppressed.)

     = ;

    <bhs= > I’m currently working on formulating a coherent argument as to w= hy I think suppression should only apply to active measurements. I’m = not done thinking this through, but I’ll pass along some of where I̵= 7;m at with this thinking.

    1.  = ;     We’ve talked abou= t the possibility of MAs being in home routers, set-top-boxes, and various = network elements (DSLAM, BNG, etc) and such. In other words, as a function = inside a device/element with a whole lot of other functions and not dedicated to measurements. I’m not sure i= f people suggesting suppression apply to passive measurements are fully awa= re of the extent of passive measurement that goes on in these device/elemen= ts today. It’s huge. And, yes, the firewall log is generated through passive measurement. Firewall logging is the main= required element of any ICSA-compliant firewall. Shutting all of this down= is not a good idea, and is completely unnecessary.

    2.  = ;     The idea for suppressio= n was initially put forward as a means to protect the network during times = of congestion, or to protect certain “MPs” or “MAs that c= an ‘respond’ to measurement tasks” when those MPs and MAs are having issues. Passive measurements have no impact on these.<= /o:p>

    3.  = ;     If suppression is seen = as “don’t generate IP packets / Ethernet frames related to any = Measurement Task (or related to just this specific list of Tasks/Methods/Sc= hedules)”, then there is no need for classification of passive vs. active and passive measurements are automatically exempt. T= his is pretty simple -- even I could figure out how to code this.

     =

    BTW, I don’t see r= eports as being a component of suppression either. Suppression shouldn̵= 7;t brick a device/element or shut down all its functions. Just don’t generate any traffic associated with performing measurement tasks.

    --_000_2D09D61DDFA73D4C884805CC7865E611303E953AGAALPA1MSGUSR9L_-- From nobody Mon Feb 17 07:20:05 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BEF1A0207 for ; Mon, 17 Feb 2014 07:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sYEQMvRcdcW for ; Mon, 17 Feb 2014 07:20:00 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 61F721A0211 for ; Mon, 17 Feb 2014 07:20:00 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7273FFEA; Mon, 17 Feb 2014 16:19:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XsyjKZ1bSxQZ; Mon, 17 Feb 2014 16:19:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Mon, 17 Feb 2014 16:19:56 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 538DC20028; Mon, 17 Feb 2014 16:19:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id E4D16Idp2EKt; Mon, 17 Feb 2014 16:19:56 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E82020013; Mon, 17 Feb 2014 16:19:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3C0322B55638; Mon, 17 Feb 2014 16:19:54 +0100 (CET) Date: Mon, 17 Feb 2014 16:19:54 +0100 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140217151954.GD99261@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E611303E953A@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303E953A@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/DpmMKHwYWr1YZb8HPpTRS440MF4 Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Is suppression just for Active Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:20:03 -0000 On Mon, Feb 17, 2014 at 03:09:40PM +0000, STARK, BARBARA H wrote: > Hi Phil, > Sorry, I just can't ignore. :) But I did change the subject line of the email thread. > > [phil] should suppression by default impact all Tasks or just Active ones? The argument for the former is that it's simpler - it avoids having to classify Tasks as active or passive - and for the MA having to remember this info. It avoids getting into discussion about whether the passive tasks are generating a lot of Reports (should they be suppressed), what to do if an active task has been mis-classified as a passive task, what happens if the operator wants to suppress tasks for reasons other than a network overload (perhaps some privacy attack), can we treat an active task that only generates 1 or 2 packets as (almost) passive. > > I have sympathy with your viewpoint (in fact, it was my viewpoint earlier). At the moment, given suppression is only a rare thing, I've been persuaded it's better to go for simplicity and make suppression affect all Tasks by default. (of course, one can use the suppression option to list specific Tasks that are suppressed.) > > I'm currently working on formulating a coherent argument as to why I think suppression should only apply to active measurements. I'm not done thinking this through, but I'll pass along some of where I'm at with this thinking. > > 1. We've talked about the possibility of MAs being in home routers, set-top-boxes, and various network elements (DSLAM, BNG, etc) and such. In other words, as a function inside a device/element with a whole lot of other functions and not dedicated to measurements. I'm not sure if people suggesting suppression apply to passive measurements are fully aware of the extent of passive measurement that goes on in these device/elements today. It's huge. And, yes, the firewall log is generated through passive measurement. Firewall logging is the main required element of any ICSA-compliant firewall. Shutting all of this down is not a good idea, and is completely unnecessary. > As long as your firewall is not a measurement task (which I think it isn't because it is a system function), LMAP will not affect it all. I think we should not confuse system functions with measurement tasks. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Feb 17 07:20:20 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD701A04B8 for ; Mon, 17 Feb 2014 07:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk0EUxZtCnnh for ; Mon, 17 Feb 2014 07:20:09 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBBE1A04DD for ; Mon, 17 Feb 2014 07:20:09 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 7a822035.2ac10029f940.2824453.00-2497.7878996.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 15:20:07 +0000 (UTC) X-MXL-Hash: 530228a757fee5b2-0109ce603a19fd485eb8315d06448e9fdd30af8c Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 45822035.0.2823500.00-2203.7876284.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 15:18:45 +0000 (UTC) X-MXL-Hash: 530228555c5cf8c8-0894aaea1709bfa0edf09ac43e14e92c7af8ea28 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HFIg8Y010374; Mon, 17 Feb 2014 10:18:43 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HFIXYs010247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 10:18:37 -0500 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi132.aldc.att.com (RSA Interceptor); Mon, 17 Feb 2014 15:18:19 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 10:18:19 -0500 From: "STARK, BARBARA H" To: "Bugenhagen, Michael K" , "'Juergen Schoenwaelder'" , "'Sharam Hakimi'" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRkqyuqLftGYUCRyHP6AveWewABRf9wmrTseTCAAAp3UIAAjm6A//+gv1CAAAhbEIAAV1UAgARWuID//62vEA== Date: Mon, 17 Feb 2014 15:18:19 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303E958A@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> <20140214194905.GA89769@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B23817@spboexc01.exfo.com> <20140214205038.GA90067@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.45.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=3gqbixA_TXoA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=_fbRkOfxO] X-AnalysisOut: [ZYA:10 a=E8ERxZvXQ55qxo8BNDAA:9 a=CjuIK1q_8ugA:10 a=--Ix1B] X-AnalysisOut: [Xj95EA:10 a=CMnSaJzitnsA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Nvf353wj_3kk90JhN6fyGAkbaa4 Cc: 'Brian Trammell' , "Cook, Charles" , "MORTON JR., AL" , 'KEN KO' , "'lmap@ietf.org'" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:20:14 -0000 > The BBF MA - Rests above all other MA levels on that device and all the= test > and probe functions are controlled by it (with the exception of normal > protocol interactions). > It does this specifically so it knows how many tests are running at o= ne time. I disagree with this characterization of the BBF MA. There is no such assum= ption in BBF. then =20 Barbara From nobody Mon Feb 17 07:42:58 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C44B1A04DE for ; Mon, 17 Feb 2014 07:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKsfoSCHCM2i for ; Mon, 17 Feb 2014 07:42:53 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9401A0249 for ; Mon, 17 Feb 2014 07:42:53 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1HFgi7w019937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 08:42:45 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id B80D31E0062; Mon, 17 Feb 2014 08:42:39 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 8AA3F1E005F; Mon, 17 Feb 2014 08:42:39 -0700 (MST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1HFgcbJ011809; Mon, 17 Feb 2014 09:42:38 -0600 (CST) Received: from [10.183.197.95] (X1069818.dhcp.intranet [10.183.197.95]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1HFgbGp011769; Mon, 17 Feb 2014 09:42:37 -0600 (CST) Message-ID: <53022DEC.6040600@centurylink.com> Date: Mon, 17 Feb 2014 08:42:36 -0700 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: philip.eardley@bt.com References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------070409040600050905040306" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ZcgisPOkAaloTNYvjgbyeszhbxg Cc: lmap@ietf.org Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: charles.cook2@centurylink.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:42:57 -0000 This is a multi-part message in MIME format. --------------070409040600050905040306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phil, See inline Charles On 2/17/2014 4:48 AM, philip.eardley@bt.com wrote: > > There were a couple of comments about overlapping measurement tasks. > > > > draft-ietf-lmap-framework-03 says > > << {Comment: It is possible that the set of measurement schedules > > implies overlapping Measurement Tasks. It is not clear the best > > thing to do. Our current suggestion is to leave this to the protocol > > document.} > > >> > > > > I think we should say something in the framework doc -- and not just > punt this to the protocol doc (and in retrospect I'm not sure that's a > good place). > > > > I still think it's not clear what the best thing to do is. As Charles > says, one approach is to run the first Task to start, then run the > next. But one can imagine tasks could get delayed -- say a task was > defined to "wait" if it detected cross-user traffic, and try again a > minute later. A task might be written to re-try many times. Should you > try and run the next task in the meantime? Should you allow multiple > tasks to run at once? How many tasks do you allow all to be waiting > for others to complete? Are the considerations different if the Task > is defined so that Measurement Peer sends traffic towards the MA? > These sorts of things seem quite complex and need accurate knowledge > of the characteristics of the task. > > > > Here's a proposal to say something meaningful but simple about > overlapping measurement tasks. > > > > -- > > > > In principle there are several reasons why a MA might have two Tasks > that it are supposed to run at the same time: > > . The operator of the measurement system has unintentionally > created a set of Schedules with overlapping Tasks > > . The completion of one Task is delayed beyond when another > Task is due to start (for example the Task may be designed to wait for > a lull in end-user traffic, or the Task may be of uncertain duration) > > > > In the initial stage of LMAP, overlapping Tasks will not be considered > due to their complexity. > > > > The above issues are addressed as follows > > . The operator of the measurement system should design their > set of Schedules with sufficient gaps between Tasks, so that one Task > will comfortably complete before another begins > > . It is suggested that Tasks are never delayed -- they > either run at the scheduled time or they don't > > . In line with this, if a (second) Task is due to start when > a (first) Task is still on-going, then the (second) Task is never started > > . A Task may delay itself internally (within the definition > of the Task); this is invisible to the Schedule. However, caution is > advised as this may prevent other Tasks from executing > > . Rather than running a Passive Measurement Task > continuously in the background, instead it is run when there are no > other Tasks operating > I am comfortable with no overlapping active Measurement Tasks, and if two active Measurement Tasks overlap, the second Measurement Task is not performed. I need to think more about whether active Measurement Tasks should be handled differently from passive Measurement Tasks. > > . Rather than testing for the impact of cross-traffic by > having two Tasks that run simultaneously, instead a single Task > generates two types of traffic. > Maybe this needs to be discussed separately. It appears to impact what the general format of what a Measurement Method will look like. Perhaps this should be deferred to a later version of the LMAP Framework. > > > > More complex possibilities could be explored in LMAP2.0. > > > > As a general principle, if Tasks (especially Active ones) do overlap, > this should be noted in the Report, so that the Result can be treated > with caution. > Agree. > > > > --- > > what do you reckon? > > > > Thanks > > phil > > > > *From:*Charles Cook [mailto:charles.cook2@centurylink.com] > *Sent:* 05 February 2014 17:41 > *To:* Eardley,PL,Philip,TUB8 R > *Cc:* lmap@ietf.org > *Subject:* Re: [lmap] FW: New Version Notification for > draft-ietf-lmap-framework-03.txt > > > > Phil, > > I like the improvements over the previous version. I did not have > many additional comments on this draft. Attached is my marked up > review. > > The main comments I had are as follows In summary: > > * *Conflict Resolution: * If two or more Measurement Tasks overlap > in their schedule, how should the MA behave? If two or more > Measurement Tasks are scheduled to start at the same time, the > first one listed in the set of Measurement Schedules can be run > first. When complete, the conflicting Measurement Task can be > run. If the Measurement Schedules overlap, but are not scheduled > to start at the same time, run the one scheduled to start first to > completion, and then run the overlapping Measurement Schedule. > The Results Report should contain a start and stop time stamp that > can be used in post processing. Note: Some Measurement Tasks may > be able to run in parallel without impacting the Results of other > Measurement Tasks. In this case, scheduling conflicts are not an > issue. But these will need to be will defined ahead of time. > * *MA Performing Pre-processing:* I don't think that the MA should > perform pre-processing unless specifically instructed to do so in > a Measurement Method. The MA should provide enough detail in the > Measurement Result to enable post processing. Any Measurement > Methods with pre-processing will need to be very carefully > constructed to ensure that the results are repeatable/comparable. > * *MP Registration and Suppression:* MPs also need to Register with > the Controller so that the Controller knows they exist. The > Controller will also need to know the capabilities of the MP, and > also have the ability to Suppress/Unsuppress the MP as needed. I > didn't see this in the draft. We just need to add it. > * *Underlying Transport Protocol:* Push and/or Pull: The LMAP > Framework identifies Push and Pull as possible underlying > transport protocols, but does not specify a requirement. A > discussion is needed to determine if one or both of these are > required for the Framework. It sounds like Push is preferred in > general, but Pull may be needed in order to perform a Measurement > Task when the MA or MP is behind a NAT. Additional details are > needed. For example should a Controller, in addition to Pushing > out Instructions, provide a mechanism for an MA to Pull an > Instruction if the MA is behind a NAT? If a MA or MP is behind a > NAT, should it execute a keep-alive so that the Controller knows > where it is at? > > > Great work. > > Charles > > On 1/21/2014 8:00 AM, philip.eardley@bt.com > wrote: > > We submitted a new version of the framework document. > > > > http://tools.ietf.org/html/draft-ietf-lmap-framework > > > > Here's a summary of the changes: > > o alignment with the Information Model > > [I-D.burbridge-lmap-information-model] as this is agreed as a WG > > document > > > > o One-off and periodic Measurement Schedules are kept separate, so > > that they can be updated independently > > > > o Measurement Suppression in a separate sub-section. Can now > > optionally include particular Measurement Tasks &/or Schedules to > > suppress, and start/stop time > > > > o for clarity, concept of Channel split into Control, Report and MA- > > to-Controller Channels > > > > o numerous editorial changes, mainly arising from a very detailed > > review by Charles Cook > > > > best wishes, > > phil, al, marcelo, trevor, paul, aamer > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > > > -- > > Charles Cook > Principal Architect > Network > 5325 Zuni Street; Suite 224 > Denver, CO 80221 > Tel: 303.992.8952 Fax: 925.281.0662 > charles.cook2@centurylink.com > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com --------------070409040600050905040306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phil,

    See inline <cc>

    Charles

    On 2/17/2014 4:48 AM, philip.eardley@bt.com wrote:

    There were a couple of comments about overlapping measurement tasks.

     

    draft-ietf-lmap-framework-03 says 

    <<   {Comment: It is possible that the set of measurement schedules

       implies overlapping Measurement Tasks.  It is not clear the best

       thing to do.  Our current suggestion is to leave this to the protocol

       document.}

    >> 

     

    I think we should say something in the framework doc – and not just punt this to the protocol doc (and in retrospect I’m not sure that’s a good place).

     

    I still think it’s not clear what the best thing to do is. As Charles says, one approach is to run the first Task to start, then run the next. But one can imagine tasks could get delayed – say a task was defined to “wait” if it detected cross-user traffic, and try again a minute later. A task might be written to re-try many times. Should you try and run the next task in the meantime? Should you allow multiple tasks to run at once? How many tasks do you allow all to be waiting for others to complete? Are the considerations different if the Task is defined so that Measurement Peer sends traffic towards the MA? These sorts of things seem quite complex and need accurate knowledge of the characteristics of the task.

     

    Here’s a proposal to say something meaningful but simple about overlapping measurement tasks.

     

    --

     

    In principle there are several reasons why a MA might have two Tasks that it are supposed to run at the same time:

    •           The operator of the measurement system has unintentionally created a set of Schedules with overlapping Tasks

    •           The completion of one Task is delayed beyond when another Task is due to start (for example the Task may be designed to wait for a lull in end-user traffic, or the Task may be of uncertain duration)

     

    In the initial stage of LMAP, overlapping Tasks will not be considered due to their complexity.

     

    The above issues are addressed as follows

    •           The operator of the measurement system should design their set of Schedules with sufficient gaps between Tasks, so that one Task will comfortably complete before another begins

    •           It is suggested that Tasks are never delayed – they either run at the scheduled time or they don’t

    •           In line with this, if a (second) Task is due to start when a (first) Task is still on-going, then the (second) Task is never started

    •           A Task may delay itself internally (within the definition of the Task); this is invisible to the Schedule. However, caution is advised as this may prevent other Tasks from executing

    •           Rather than running a Passive Measurement Task continuously in the background, instead it is run when there are no other Tasks operating

    <cc> I am comfortable with no overlapping active Measurement Tasks, and if two active Measurement Tasks overlap, the second Measurement Task is not performed.  I need to think more about whether active Measurement Tasks should be handled differently from passive Measurement Tasks. 

    •           Rather than testing for the impact of cross-traffic by having two Tasks that run simultaneously, instead a single Task generates two types of traffic.

    <cc>  Maybe this needs to be discussed separately.  It appears to impact what the general format of what a Measurement Method will look like.  Perhaps this should be deferred to a later version of the LMAP Framework.

     

    More complex possibilities could be explored in LMAP2.0.

     

    As a general principle, if Tasks (especially Active ones) do overlap, this should be noted in the Report, so that the Result can be treated with caution.

    <cc> Agree.

     

    ---

    what do you reckon?

     

    Thanks

    phil

     

    From: Charles Cook [mailto:charles.cook2@centurylink.com]
    Sent: 05 February 2014 17:41
    To: Eardley,PL,Philip,TUB8 R
    Cc: lmap@ietf.org
    Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-03.txt

     

    Phil,

    I like the improvements over the previous version.  I did not have many additional comments on this draft.  Attached is my marked up review. 

    The main comments I had are as follows In summary:

    • Conflict Resolution:   If two or more Measurement Tasks overlap in their schedule, how should the MA behave?  If two or more Measurement Tasks are scheduled to start at the same time, the first one listed in the set of Measurement Schedules can be run first.  When complete, the conflicting Measurement Task can be run.  If the Measurement Schedules overlap, but are not scheduled to start at the same time, run the one scheduled to start first to completion, and then run the overlapping Measurement Schedule.  The Results Report should contain a start and stop time stamp that can be used in post processing.  Note:  Some Measurement Tasks may be able to run in parallel without impacting the Results of other Measurement Tasks.  In this case, scheduling conflicts are not an issue.  But these will need to be will defined ahead of time. 
    • MA Performing Pre-processing:  I don't think that the MA should perform pre-processing unless specifically instructed to do so in a Measurement Method.  The MA should provide enough detail in the Measurement Result to enable post processing.  Any Measurement Methods with pre-processing will need to be very carefully constructed to ensure that the results are repeatable/comparable.
    • MP Registration and Suppression:  MPs also need to Register with the Controller so that the Controller knows they exist.  The Controller will also need to know the capabilities of the MP, and also have the ability to Suppress/Unsuppress the MP as needed.  I didn't see this in the draft.  We just need to add it.
    • Underlying Transport Protocol:  Push and/or Pull:  The LMAP Framework identifies Push and Pull as possible underlying transport protocols, but does not specify a requirement.  A discussion is needed to determine if one or both of these are required for the Framework.  It sounds like Push is preferred in general, but Pull may be needed in order to perform a Measurement Task when the MA or MP is behind a NAT.  Additional details are needed.  For example should a Controller, in addition to Pushing out Instructions, provide a mechanism for an MA to Pull an Instruction if the MA is behind a NAT?  If a MA or MP is behind a NAT, should it execute a keep-alive so that the Controller knows where it is at?


    Great work.

    Charles

    On 1/21/2014 8:00 AM, philip.eardley@bt.com wrote:

    We submitted a new version of the framework document.
     
    http://tools.ietf.org/html/draft-ietf-lmap-framework 
     
    Here's a summary of the changes:
       o  alignment with the Information Model
          [I-D.burbridge-lmap-information-model] as this is agreed as a WG
          document
     
       o  One-off and periodic Measurement Schedules are kept separate, so
          that they can be updated independently
     
       o  Measurement Suppression in a separate sub-section.  Can now
          optionally include particular Measurement Tasks &/or Schedules to
          suppress, and start/stop time
     
       o  for clarity, concept of Channel split into Control, Report and MA-
          to-Controller Channels
     
       o  numerous editorial changes, mainly arising from a very detailed
          review by Charles Cook
     
    best wishes,
    phil, al, marcelo, trevor, paul, aamer
     
    _______________________________________________
    lmap mailing list
    lmap@ietf.org
    https://www.ietf.org/mailman/listinfo/lmap



    -- 
     
    Charles Cook 
    Principal Architect
    Network
    5325 Zuni Street; Suite 224
    Denver, CO  80221
    Tel:  303.992.8952  Fax:  925.281.0662
    charles.cook2@centurylink.com


    _______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap


    -- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
charles.cook2@centurylink.com
    --------------070409040600050905040306-- From nobody Mon Feb 17 07:50:48 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639DE1A024B for ; Mon, 17 Feb 2014 07:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGO-8ugUUJXM for ; Mon, 17 Feb 2014 07:50:44 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 05C471A020C for ; Mon, 17 Feb 2014 07:50:44 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 9987412026F; Mon, 17 Feb 2014 10:54:12 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id BC765F0372; Mon, 17 Feb 2014 10:50:39 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Mon, 17 Feb 2014 10:50:39 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "STARK, BARBARA H" Date: Mon, 17 Feb 2014 10:50:39 -0500 Thread-Topic: [lmap] Is suppression just for Active Measurement Tasks Thread-Index: Ac8r88ns/S+0qR2FTgy46xgOVAxdfwAAusud Message-ID: <2845723087023D4CB5114223779FA9C8BC2BCF1B@njfpsrvexg8.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E611303E953A@GAALPA1MSGUSR9L.ITServices.sbc.com>, <20140217151954.GD99261@elstar.local> In-Reply-To: <20140217151954.GD99261@elstar.local> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2ewsHZagX0WtvapdZizOsSbvO-w Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Is suppression just for Active Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:50:46 -0000 ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder [j.sc= hoenwaelder@jacobs-university.de] Sent: Monday, February 17, 2014 10:19 AM To: STARK, BARBARA H Cc: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Is suppression just for Active Measurement Tasks On Mon, Feb 17, 2014 at 03:09:40PM +0000, STARK, BARBARA H wrote: > Hi Phil, > Sorry, I just can't ignore. :) But I did change the subject line of the e= mail thread. > > [phil] should suppression by default impact all Tasks or just Active ones= ? The argument for the former is that it's simpler - it avoids having to cl= assify Tasks as active or passive - and for the MA having to remember this = info. It avoids getting into discussion about whether the passive tasks are= generating a lot of Reports (should they be suppressed), what to do if an = active task has been mis-classified as a passive task, what happens if the = operator wants to suppress tasks for reasons other than a network overload = (perhaps some privacy attack), can we treat an active task that only genera= tes 1 or 2 packets as (almost) passive. > > I have sympathy with your viewpoint (in fact, it was my viewpoint earlier= ). At the moment, given suppression is only a rare thing, I've been persuad= ed it's better to go for simplicity and make suppression affect all Tasks b= y default. (of course, one can use the suppression option to list specific = Tasks that are suppressed.) > > I'm currently working on formulating a coherent argument as to why = I think suppression should only apply to active measurements. I'm not done = thinking this through, but I'll pass along some of where I'm at with this t= hinking. > > 1. We've talked about the possibility of MAs being in home routers,= set-top-boxes, and various network elements (DSLAM, BNG, etc) and such. In= other words, as a function inside a device/element with a whole lot of oth= er functions and not dedicated to measurements. I'm not sure if people sugg= esting suppression apply to passive measurements are fully aware of the ext= ent of passive measurement that goes on in these device/elements today. It'= s huge. And, yes, the firewall log is generated through passive measurement= . Firewall logging is the main required element of any ICSA-compliant firew= all. Shutting all of this down is not a good idea, and is completely unnece= ssary. > As long as your firewall is not a measurement task (which I think it isn't because it is a system function), LMAP will not affect it all. I think we should not confuse system functions with measurement tasks. /js [Al adds] +1, Suppress can only affect LMAP tasks. Also, when reporting is considered it may be more important to stop passive reporting when the task involves=20 measurements on all user flows, or worse, on all packets (could easily prod= uce more network load than many active tests used today). Al From nobody Mon Feb 17 07:54:07 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FC91A050A for ; Mon, 17 Feb 2014 07:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRmiuw7KK746 for ; Mon, 17 Feb 2014 07:54:03 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3F41A0509 for ; Mon, 17 Feb 2014 07:54:03 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1HFrte6026424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 09:53:55 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 7D8D41E0049; Mon, 17 Feb 2014 09:53:50 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 5E7CF1E005B; Mon, 17 Feb 2014 09:53:50 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s1HFro2I029433; Mon, 17 Feb 2014 09:53:50 -0600 (CST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s1HFrmmW029410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 09:53:49 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 09:53:49 -0600 From: "Bugenhagen, Michael K" To: "'STARK, BARBARA H'" , "'Juergen Schoenwaelder'" , "'Sharam Hakimi'" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihkwABRf9wmrTseTCAAAp3UIAAjm6A//+gv1CAAAhbEIAAZ+0AgAPxBcCAAGkggP//o5Gg Date: Mon, 17 Feb 2014 15:53:48 +0000 Message-ID: References: <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> <20140214194905.GA89769@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B23817@spboexc01.exfo.com> <20140214205038.GA90067@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E958A@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303E958A@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FsflFr3RsFVy19s7YsUxvTLwiDw Cc: 'Brian Trammell' , "Cook, Charles" , "'MORTON JR., AL'" , 'KEN KO' , "'lmap@ietf.org'" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:54:06 -0000 It's part of the "test admission schema" - Operationally multiple probes that don't know about each other and can us= e resources don't work. So if we want to put multiple probes (which would also require multiple man= agement ports) on a single device both projects will have to add a "CPU / R= esource" utilization cross hold monitoring during testing... At the moment both documents suggestion a "pre-test" resource Check - if yo= u have a collision space that two probes can test, and then collide we have= another problem. So I would say again - the 304 approach has one resource check without othe= r probes using resources as peer who can break that schema. So I'll have to go back and check our text, but I think the statement is tr= ue. =20 I definitely believe this "one probe" view is definitely an ISP op's requir= ement - they've been fighting the Video probe, VoIP probe, Broadband Probe = thing for multiple years...=20 So I'm going to stick with one probe view is a delta...=20 -----Original Message----- From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Monday, February 17, 2014 9:18 AM To: Bugenhagen, Michael K; 'Juergen Schoenwaelder'; 'Sharam Hakimi' Cc: 'KEN KO'; Cook, Charles; MORTON JR., AL; 'lmap@ietf.org'; 'Brian Tramme= ll' Subject: RE: [lmap] MA vs MP > The BBF MA - Rests above all other MA levels on that device and all=20 > the test and probe functions are controlled by it (with the exception=20 > of normal protocol interactions). > It does this specifically so it knows how many tests are running at o= ne time. I disagree with this characterization of the BBF MA. There is no such assum= ption in BBF. then Barbara From nobody Mon Feb 17 07:58:42 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878B41A03D2 for ; Mon, 17 Feb 2014 07:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j5ufnEdVYPC for ; Mon, 17 Feb 2014 07:58:38 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0C01E1A022E for ; Mon, 17 Feb 2014 07:58:37 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1HFwVTB000222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 09:58:31 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 52AC01E0071; Mon, 17 Feb 2014 09:58:26 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 13CDF1E0073; Mon, 17 Feb 2014 09:58:26 -0600 (CST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1HFwPUu008230; Mon, 17 Feb 2014 08:58:25 -0700 (MST) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1HFwNBm008146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 08:58:25 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 09:58:24 -0600 From: "Bugenhagen, Michael K" To: "Bugenhagen, Michael K" , "'STARK, BARBARA H'" , "'Juergen Schoenwaelder'" , "'Sharam Hakimi'" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKGoUT/Hp0ufxTE6K3jw+b/ihkwABRf9wmrTseTCAAAp3UIAAjm6A//+gv1CAAAhbEIAAZ+0AgAPxBcCAAGkggP//o5GggAAC1TA= Date: Mon, 17 Feb 2014 15:58:23 +0000 Message-ID: References: <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> <20140214194905.GA89769@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B23817@spboexc01.exfo.com> <20140214205038.GA90067@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E958A@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/LUFQLJOb46wOeORIDbzG2ulCqXI Cc: "'lmap@ietf.org'" , "Cook, Charles" , "'MORTON JR., AL'" , 'KEN KO' , 'Brian Trammell' Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:58:40 -0000 Do you guys think there is any chance of having a Joint meeting with whiteb= oards to knock these out ??? BBF is in Denver in June / July I think ... Mike -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael = K Sent: Monday, February 17, 2014 9:54 AM To: 'STARK, BARBARA H'; 'Juergen Schoenwaelder'; 'Sharam Hakimi' Cc: 'Brian Trammell'; Cook, Charles; 'MORTON JR., AL'; 'KEN KO'; 'lmap@ietf= .org' Subject: Re: [lmap] MA vs MP It's part of the "test admission schema" - Operationally multiple probes that don't know about each other and can us= e resources don't work. So if we want to put multiple probes (which would also require multiple man= agement ports) on a single device both projects will have to add a "CPU / R= esource" utilization cross hold monitoring during testing... At the moment both documents suggestion a "pre-test" resource Check - if yo= u have a collision space that two probes can test, and then collide we have= another problem. So I would say again - the 304 approach has one resource check without othe= r probes using resources as peer who can break that schema. So I'll have to go back and check our text, but I think the statement is tr= ue. =20 I definitely believe this "one probe" view is definitely an ISP op's requir= ement - they've been fighting the Video probe, VoIP probe, Broadband Probe = thing for multiple years...=20 So I'm going to stick with one probe view is a delta...=20 -----Original Message----- From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Monday, February 17, 2014 9:18 AM To: Bugenhagen, Michael K; 'Juergen Schoenwaelder'; 'Sharam Hakimi' Cc: 'KEN KO'; Cook, Charles; MORTON JR., AL; 'lmap@ietf.org'; 'Brian Tramme= ll' Subject: RE: [lmap] MA vs MP > The BBF MA - Rests above all other MA levels on that device and all=20 > the test and probe functions are controlled by it (with the exception=20 > of normal protocol interactions). > It does this specifically so it knows how many tests are running at o= ne time. I disagree with this characterization of the BBF MA. There is no such assum= ption in BBF. then Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Feb 17 08:30:26 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88D31A03FF for ; Mon, 17 Feb 2014 08:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svagtHYSybDT for ; Mon, 17 Feb 2014 08:30:21 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 03C6E1A03FC for ; Mon, 17 Feb 2014 08:30:20 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id a1932035.2ac0e8679940.2874011.00-2495.8020997.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 16:30:18 +0000 (UTC) X-MXL-Hash: 5302391a04a8cf92-5ceadbd142104e773e14341854c7eeb46ecd88f8 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 60932035.0.2873855.00-2234.8020550.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 16:30:00 +0000 (UTC) X-MXL-Hash: 5302390804efd3ff-1ba6a1e7bede26878dd5b189793d54f104574343 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HGTwfr030709; Mon, 17 Feb 2014 11:29:58 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HGTp1O030637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 11:29:56 -0500 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 17 Feb 2014 16:29:32 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 11:29:32 -0500 From: "STARK, BARBARA H" To: "MORTON JR., AL" , Juergen Schoenwaelder Thread-Topic: [lmap] Is suppression just for Active Measurement Tasks Thread-Index: Ac8r8kSovBNM0GKVQzG03CdAC7BkTQAK1m4AAAES7YAACk41wA== Date: Mon, 17 Feb 2014 16:29:31 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303E9663@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611303E953A@GAALPA1MSGUSR9L.ITServices.sbc.com>, <20140217151954.GD99261@elstar.local> <2845723087023D4CB5114223779FA9C8BC2BCF1B@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC2BCF1B@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.45.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=3QwjvjL7IrkA:10 a=ofMgfj31e3cA:10 a=3gqbixA_TXoA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=k9KLwFGVL8QA:10 a=ddcI5Fc0t0aKjCq-0lkA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/E2VLTrY7NGpZ3whX3BBjd3oVVu8 Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Is suppression just for Active Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 16:30:25 -0000 > As long as your firewall is not a measurement task (which I think it isn'= t > because it is a system function), LMAP will not affect it all. I think we= should > not confuse system functions with measurement tasks. >=20 > /js >=20 > [Al adds] > +1, Suppress can only affect LMAP tasks. Also, when reporting is > +considered > it may be more important to stop passive reporting when the task involves > measurements on all user flows, or worse, on all packets (could easily > produce more network load than many active tests used today). I believe that reports should be disabled (when necessary) by disabling a r= eport channel. If reports of passive measurements are the problem, and acti= ve measurements are not, then sending a suppression message targeted at the= measurements that can be reported via a particular report channel is more = complicated than just disabling the report channel. Also, if the same passi= ve measurement is reported out 2 different channels and only one of those c= hannels is distressed, then killing the passive measurement is not the righ= t approach.=20 I also consider it conceivable that having mass reporting of firewall logs = (not as part of a regulatory use case, but perhaps as part of a service pro= vider use case to determine how well the firewalls are working) could occur= . So maybe now the firewall log is both an MA and system function and the w= ay things are coded causes all firewall logging to stop when the suppressio= n happens. What I'm trying to do is avoid the Law of Unintended Consequences that gene= rally takes hold when functions like this are too broadly defined. There is= no need to define Suppression this broadly. It's just not that hard to hav= e it apply only to active measurement traffic. If a passive measurement is = causing internal-to-the-device issues, then stop that specific passive meas= urement. If a report channel has issues, disable the report channel. Don't = try to use this suppression kill switch as a means of targeted disabling of= specific activities. If there are specific activities you want to disable,= then disable them via "regular" commands. Barbara From nobody Mon Feb 17 09:04:34 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7401A0522 for ; Mon, 17 Feb 2014 09:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVF24he3wEb3 for ; Mon, 17 Feb 2014 09:04:30 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 172D31A050C for ; Mon, 17 Feb 2014 09:04:30 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1HH4Kbp024635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 10:04:21 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 629AA1E0089; Mon, 17 Feb 2014 10:04:10 -0700 (MST) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id D4B291E005F; Mon, 17 Feb 2014 10:04:09 -0700 (MST) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1HH40nJ018662; Mon, 17 Feb 2014 10:04:01 -0700 (MST) Received: from [10.183.197.95] (X1069818.dhcp.intranet [10.183.197.95]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1HH3xu4018645; Mon, 17 Feb 2014 10:04:00 -0700 (MST) Message-ID: <530240FF.6010002@centurylink.com> Date: Mon, 17 Feb 2014 10:03:59 -0700 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E611303E953A@GAALPA1MSGUSR9L.ITServices.sbc.com>, <20140217151954.GD99261@elstar.local> <2845723087023D4CB5114223779FA9C8BC2BCF1B@njfpsrvexg8.research.att.com> <2D09D61DDFA73D4C884805CC7865E611303E9663@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303E9663@GAALPA1MSGUSR9L.ITServices.sbc.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/RXG8-h7GsXzmLM7oAyvCRv1LP3s Cc: "philip.eardley@bt.com" , Juergen Schoenwaelder , "MORTON JR., AL" , "lmap@ietf.org" Subject: Re: [lmap] Is suppression just for Active Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: charles.cook2@centurylink.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:04:32 -0000 Suppression of the Report Channel should be able to address concerns of Passive Measurement Tasks creating a negative impact on the network. Charles On 2/17/2014 9:29 AM, STARK, BARBARA H wrote: >> As long as your firewall is not a measurement task (which I think it isn't >> because it is a system function), LMAP will not affect it all. I think we should >> not confuse system functions with measurement tasks. >> >> /js >> >> [Al adds] >> +1, Suppress can only affect LMAP tasks. Also, when reporting is >> +considered >> it may be more important to stop passive reporting when the task involves >> measurements on all user flows, or worse, on all packets (could easily >> produce more network load than many active tests used today). > I believe that reports should be disabled (when necessary) by disabling a report channel. If reports of passive measurements are the problem, and active measurements are not, then sending a suppression message targeted at the measurements that can be reported via a particular report channel is more complicated than just disabling the report channel. Also, if the same passive measurement is reported out 2 different channels and only one of those channels is distressed, then killing the passive measurement is not the right approach. > > I also consider it conceivable that having mass reporting of firewall logs (not as part of a regulatory use case, but perhaps as part of a service provider use case to determine how well the firewalls are working) could occur. So maybe now the firewall log is both an MA and system function and the way things are coded causes all firewall logging to stop when the suppression happens. > > What I'm trying to do is avoid the Law of Unintended Consequences that generally takes hold when functions like this are too broadly defined. There is no need to define Suppression this broadly. It's just not that hard to have it apply only to active measurement traffic. If a passive measurement is causing internal-to-the-device issues, then stop that specific passive measurement. If a report channel has issues, disable the report channel. Don't try to use this suppression kill switch as a means of targeted disabling of specific activities. If there are specific activities you want to disable, then disable them via "regular" commands. > Barbara > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com From nobody Mon Feb 17 09:51:56 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45001A051A for ; Mon, 17 Feb 2014 09:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7JxxRawOKfw for ; Mon, 17 Feb 2014 09:51:50 -0800 (PST) Received: from p02c11o144.mxlogic.net (p02c11o144.mxlogic.net [208.65.144.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0437E1A050E for ; Mon, 17 Feb 2014 09:51:49 -0800 (PST) Received: from unknown [76.164.174.82] (EHLO p02c11o144.mxlogic.net) by p02c11o144.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 33c42035.2ae8f7017940.34620.00-559.85132.p02c11o144.mxlogic.net (envelope-from ); Mon, 17 Feb 2014 10:51:47 -0700 (MST) X-MXL-Hash: 53024c331ff5c84e-d3008fc7181c1d51e5fc21f81ce1557817a256fb Received: from unknown [76.164.174.82] by p02c11o144.mxlogic.net(mxl_mta-7.2.4-1) with SMTP id 90c42035.0.34091.00-326.84362.p02c11o144.mxlogic.net (envelope-from ); Mon, 17 Feb 2014 10:51:09 -0700 (MST) X-MXL-Hash: 53024c0d2a91a9f2-1da8799cb1b04e150da25e689f4c7c887b63945d Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 11:50:30 -0600 From: KEN KO To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] Measurement Suppression (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8r17HZyK2bFe3kRj2TM/+o+WTEjAAMOQIw Date: Mon, 17 Feb 2014 17:50:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.197] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77751A16Fexmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=T847uY2Q c=1 sm=1 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a] X-AnalysisOut: [=yNyjBr5hEpkA:10 a=qZHQZMT3apYA:10 a=FBzmcnhlJawA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=NraYV488] X-AnalysisOut: [NNYA:10 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8 a=K8PqX9kDrD4ZfV] X-AnalysisOut: [i8g3kA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=W1qU_X6G3J8] X-AnalysisOut: [A:10 a=UBEM1fv-BfZmgDNN:21 a=6IOAXJh0gdUHPKXz:21 a=yMhMjlu] X-AnalysisOut: [bAAAA:8 a=SSmOFEACAAAA:8 a=sjUDXQDbwOLjrLqOsAIA:9 a=gKO2Hq] X-AnalysisOut: [4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-h] X-AnalysisOut: [UA:10 a=hMGJ-Wx7gcjJ2yyb:21 a=L_jv34qJlqO_WX3G:21 a=LzZOrL] X-AnalysisOut: [aY6NbgXIl2:21] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014021709); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/eKxZl7_vYK_TF4NXQjw2NNoZ1BM Subject: Re: [lmap] Measurement Suppression (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:51:54 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77751A16Fexmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, Looks good to me with one minor edit. There is still one instance of "Activ= e Measurement" (in the first bullet) where I think you just mean "Measureme= nt." Ken From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, February 17, 2014 10:02 AM To: lmap@ietf.org Subject: [lmap] Measurement Suppression (WGLC comments on draft-ietf-lmap-f= ramework-03) There were a number of comments about Suppression. There was also some disc= ussion in WT-304 (Broadband forum) and it would be very nice to keep BBF & = LMAP in step. Here's a proposal how to handle the various comments: - A couple of people suggested that Suppression should also be able t= o affect the Measurement Peer. I'm proposing not to include this, because S= uppression is part of the Instruction and M Peers don't get instructions. - Suppression should affect all M Tasks, not just Active ones. Reason= : simplicity. Avoids having to classify tasks as active or passive. Also, y= ou may want to suppress passive tasks - perhaps they are generating a lot o= f Reports, or an active task has been mis-classified as a passive task, or = there is some privacy issue that means passive Tasks need to be suppressed. - There should be an option in Suppression to stop on-going Tasks (th= e current text stops any new Tasks and says the impact on on-going Tasks is= undefined). Reason: on-going Tasks may be long-running and generating a lo= t of traffic. Comment: I wrote "a request that the MA stops on-going Measur= ement Tasks" rather than "the MA stops on-going Measurement Tasks" - not su= re that the MA would be able to stop all Tasks So the suppression section would look like this:- 5.2.1. Measurement Suppression Measurement Suppression is used if the measurement system wants to eliminate inessential traffic, because there is some unexpected network issue for example. The Controller instructs the MA to temporarily not begin new Measurement Tasks. By default, suppression applies to all Measurement Tasks, starts immediately and continues until an un-suppress message is received. Optionally the suppress message may include: o a set of Active Measurement Tasks to suppress; the others are not suppressed. For example, a particular Measurement Task may be overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends. o a request that the MA stops on-going Measurement Tasks (by default, i= t is not defined what the impact of Suppression is on on-going Measurement = Tasks; see Section 5.3) Note that Suppression is not intended to permanently stop a Measurement Task (instead, the Controller should send a new Measurement Schedule), nor to permanently disable a MA (instead, some kind of management action is suggested). +-----------------+ +-------------+ | | | Measurement | | Controller |=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| Agent | +-----------------+ +-------------+ Suppress: [(Measurement Task), -> (Measurement Schedule), start time, end time, stop on-going Tasks?] <- ACK Un-suppress -> <- ACK -- Comments? Thanks phil --_000_D14B7E40AEBFD54EA3AD964902DD7CB77751A16Fexmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Phil,

     

    Looks good to me with = one minor edit. There is still one instance of “Active Measurement= 221; (in the first bullet) where I think you just mean “Measurement.&= #8221;

     

    Ken<= /p>

     

    From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
    Sent: Monday, February 17, 2014 10:02 AM
    To: lmap@ietf.org
    Subject: [lmap] Measurement Suppression (WGLC comments on draft-ietf= -lmap-framework-03)

     

    There were a number o= f comments about Suppression. There was also some discussion in WT-304 (Bro= adband forum) and it would be very nice to keep BBF & LMAP in step.

     

    Here’s a propos= al how to handle the various comments:

    -    &nb= sp;  A couple of people suggested that Sup= pression should also be able to affect the Measurement Peer. I’m prop= osing not to include this, because Suppression is part of the Instruction and M Peers don’t get instructions.

    -    &nb= sp;  Suppression should affect all M Tasks= , not just Active ones. Reason: simplicity. Avoids having to classify tasks= as active or passive. Also, you may want to suppress passive tasks – perhaps they are generating a lot of Reports, or an active t= ask has been mis-classified as a passive task, or there is some privacy iss= ue that means passive Tasks need to be suppressed.

    -    &nb= sp;  There should be an option in Suppress= ion to stop on-going Tasks (the current text stops any new Tasks and says t= he impact on on-going Tasks is undefined). Reason: on-going Tasks may be long-running and generating a lot of traffic. Comment: I wrot= e “a request that the MA stops on-= going Measurement Tasks” rather than “the MA stops on-going Mea= surement Tasks” – not sure that the MA would be able to stop all Tasks<= /span>

     

    So the suppression se= ction would look like this:-

      

     

    5.2.1.  Measurement Suppression

       Measurement Suppression is used if the measurement s=
ystem wants to
       eliminate inessential traffic, because there is some=
 unexpected
       network issue for example.  The Controller inst=
ructs the MA to
       temporarily not begin new Measurement Tasks.  B=
y default,
       suppression applies to all Measurement Tasks, starts=

       immediately and continues until an un-suppress messa=
ge is received.
       Optionally the suppress message may include:
     
       o  a set of Active Measurement Tasks to suppres=
s; the others are not
          suppressed.  For example, a p=
articular Measurement Task may be
          overloading a Measurement Peer.
     
       o  a set of Measurement Schedules to suppress; =
the others are not
          suppressed.  For example, sup=
pose the measurement system has
          defined two Schedules, one with th=
e most critical
          Measurement Tasks and the other wi=
th less critical ones that
          create a lot of traffic, then it m=
ay only want to suppress the
          second.
     
       o  a start time, at which suppression begins
     
       o  an end time, at which suppression ends.=

     
       o  a request that the MA stops on-going Measure=
ment Tasks (by default, it is not defined what the impact of Suppression is=
 on on-going Measurement Tasks; see Section 5.3)=

     
       Note that Suppression is not intended to permanently=
 stop a
       Measurement Task (instead, the Controller should sen=
d a new
       Measurement Schedule), nor to permanently disable a =
MA (instead, some
       kind of management action is suggested).<=
/span>
     
       +-----------------+    &=
nbsp;           &nbs=
p;            &=
nbsp;     +-------------+

       |        &nb=
sp;        |    &nbs=
p;            &=
nbsp;           &nbs=
p;     | Measurement |
    

       |  Controller     |=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|  Agent      |<=
/o:p>
    

       +-----------------+    &=
nbsp;           &nbs=
p;            &=
nbsp;     +-------------+

     
    

       Suppress:
    

       [(Measurement Task),     &n=
bsp;            =
;   ->
    

        (Measurement Schedule),

        start time, end time,
    

        stop on-going Tasks?]
    

               =
;            &n=
bsp;            =
;        <-    &n=
bsp;         ACK<=
/pre>

     
    

       Un-suppress       =
;            &n=
bsp;          ->=

    

               =
;             &=
nbsp;           &nbs=
p;       <-    &n=
bsp;         ACK<=
/pre>

     

    --
    

    Comments?
    

    Thanks

    phil
    --_000_D14B7E40AEBFD54EA3AD964902DD7CB77751A16Fexmb1corpadtran_-- From nobody Mon Feb 17 10:20:44 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D091A0103 for ; Mon, 17 Feb 2014 10:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzvBrS7B0e0a for ; Mon, 17 Feb 2014 10:20:40 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 2838A1A022E for ; Mon, 17 Feb 2014 10:20:40 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Feb 2014 13:20:37 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Feb 2014 13:20:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Feb 2014 13:21:22 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B238EA@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] Is suppression just for Active Measurement Tasks Thread-Index: Ac8r876i8oIC7pNDRg2bZYx58LO2ZgAGIK+Q References: <2D09D61DDFA73D4C884805CC7865E611303E953A@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140217151954.GD99261@elstar.local> From: "Sharam Hakimi" To: "Juergen Schoenwaelder" , "STARK, BARBARA H" X-OriginalArrivalTime: 17 Feb 2014 18:20:36.0481 (UTC) FILETIME=[F42C5710:01CF2C0C] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_hQItkThqWcyegz5uFy4atiZcz8 Cc: philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] Is suppression just for Active Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 18:20:43 -0000 I think it is fairly easy to have two TASK instructions for the MA, one is the Active tests and the other is the Passive test. This is managed by the user at the MC. Once a Suppression is issued, it would be followed by the Passive TASK Instruction. This would keep the passive tasks running after a suppression command. It is not perfect, but stripping every test in a task is a much more difficult endeavor in my opinion. Sharam=20 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Monday, February 17, 2014 10:20 AM To: STARK, BARBARA H Cc: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Is suppression just for Active Measurement Tasks On Mon, Feb 17, 2014 at 03:09:40PM +0000, STARK, BARBARA H wrote: > Hi Phil, > Sorry, I just can't ignore. :) But I did change the subject line of the email thread. >=20 > [phil] should suppression by default impact all Tasks or just Active ones? The argument for the former is that it's simpler - it avoids having to classify Tasks as active or passive - and for the MA having to remember this info. It avoids getting into discussion about whether the passive tasks are generating a lot of Reports (should they be suppressed), what to do if an active task has been mis-classified as a passive task, what happens if the operator wants to suppress tasks for reasons other than a network overload (perhaps some privacy attack), can we treat an active task that only generates 1 or 2 packets as (almost) passive. >=20 > I have sympathy with your viewpoint (in fact, it was my viewpoint earlier). At the moment, given suppression is only a rare thing, I've been persuaded it's better to go for simplicity and make suppression affect all Tasks by default. (of course, one can use the suppression option to list specific Tasks that are suppressed.) >=20 > I'm currently working on formulating a coherent argument as to why I think suppression should only apply to active measurements. I'm not done thinking this through, but I'll pass along some of where I'm at with this thinking. >=20 > 1. We've talked about the possibility of MAs being in home routers, set-top-boxes, and various network elements (DSLAM, BNG, etc) and such. In other words, as a function inside a device/element with a whole lot of other functions and not dedicated to measurements. I'm not sure if people suggesting suppression apply to passive measurements are fully aware of the extent of passive measurement that goes on in these device/elements today. It's huge. And, yes, the firewall log is generated through passive measurement. Firewall logging is the main required element of any ICSA-compliant firewall. Shutting all of this down is not a good idea, and is completely unnecessary. >=20 As long as your firewall is not a measurement task (which I think it isn't because it is a system function), LMAP will not affect it all. I think we should not confuse system functions with measurement tasks. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Feb 17 10:32:15 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C15C1A053A for ; Mon, 17 Feb 2014 10:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plw2NGmOtedZ for ; Mon, 17 Feb 2014 10:32:11 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id CCBC11A052B for ; Mon, 17 Feb 2014 10:32:10 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Feb 2014 13:32:08 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Feb 2014 13:32:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Feb 2014 13:32:57 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B238ED@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] Is suppression just for Active Measurement Tasks Thread-Index: Ac8r876i8oIC7pNDRg2bZYx58LO2ZgAGIK+QAACMpyA= References: <2D09D61DDFA73D4C884805CC7865E611303E953A@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140217151954.GD99261@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B238EA@spboexc01.exfo.com> From: "Sharam Hakimi" To: "Sharam Hakimi" , "Juergen Schoenwaelder" , "STARK, BARBARA H" X-OriginalArrivalTime: 17 Feb 2014 18:32:07.0490 (UTC) FILETIME=[900BF220:01CF2C0E] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/YGJi83aZ8I0_TqHQkGP-xVDwyKw Cc: philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] Is suppression just for Active Measurement Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 18:32:13 -0000 Sorry, That was supposed to be STRIPING every test. Auto correct did me an unwanted favor. Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi Sent: Monday, February 17, 2014 1:21 PM To: Juergen Schoenwaelder; STARK, BARBARA H Cc: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Is suppression just for Active Measurement Tasks I think it is fairly easy to have two TASK instructions for the MA, one is the Active tests and the other is the Passive test. This is managed by the user at the MC. Once a Suppression is issued, it would be followed by the Passive TASK Instruction. This would keep the passive tasks running after a suppression command. It is not perfect, but stripping every test in a task is a much more difficult endeavor in my opinion. Sharam=20 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Monday, February 17, 2014 10:20 AM To: STARK, BARBARA H Cc: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Is suppression just for Active Measurement Tasks On Mon, Feb 17, 2014 at 03:09:40PM +0000, STARK, BARBARA H wrote: > Hi Phil, > Sorry, I just can't ignore. :) But I did change the subject line of the email thread. >=20 > [phil] should suppression by default impact all Tasks or just Active ones? The argument for the former is that it's simpler - it avoids having to classify Tasks as active or passive - and for the MA having to remember this info. It avoids getting into discussion about whether the passive tasks are generating a lot of Reports (should they be suppressed), what to do if an active task has been mis-classified as a passive task, what happens if the operator wants to suppress tasks for reasons other than a network overload (perhaps some privacy attack), can we treat an active task that only generates 1 or 2 packets as (almost) passive. >=20 > I have sympathy with your viewpoint (in fact, it was my viewpoint earlier). At the moment, given suppression is only a rare thing, I've been persuaded it's better to go for simplicity and make suppression affect all Tasks by default. (of course, one can use the suppression option to list specific Tasks that are suppressed.) >=20 > I'm currently working on formulating a coherent argument as to why I think suppression should only apply to active measurements. I'm not done thinking this through, but I'll pass along some of where I'm at with this thinking. >=20 > 1. We've talked about the possibility of MAs being in home routers, set-top-boxes, and various network elements (DSLAM, BNG, etc) and such. In other words, as a function inside a device/element with a whole lot of other functions and not dedicated to measurements. I'm not sure if people suggesting suppression apply to passive measurements are fully aware of the extent of passive measurement that goes on in these device/elements today. It's huge. And, yes, the firewall log is generated through passive measurement. Firewall logging is the main required element of any ICSA-compliant firewall. Shutting all of this down is not a good idea, and is completely unnecessary. >=20 As long as your firewall is not a measurement task (which I think it isn't because it is a system function), LMAP will not affect it all. I think we should not confuse system functions with measurement tasks. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 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 nobody Mon Feb 17 11:46:37 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175D31A0215 for ; Mon, 17 Feb 2014 11:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKWLQGBBUxuZ for ; Mon, 17 Feb 2014 11:46:32 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 667D41A0177 for ; Mon, 17 Feb 2014 11:46:32 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 61762035.2abd3a00f940.4830660.00-2477.12504414.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 17 Feb 2014 19:46:30 +0000 (UTC) X-MXL-Hash: 530267167ae1f69b-e185baace0025e88a9010732a4b858f89c707b5c Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id e0762035.0.4830589.00-2397.12504211.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 17 Feb 2014 19:46:25 +0000 (UTC) X-MXL-Hash: 53026711340c01cd-42aa51212e72bf3d68af3101c0508caaa72dd03b Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HJkLd5006494; Mon, 17 Feb 2014 14:46:22 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HJkCvJ006334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 14:46:13 -0500 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 17 Feb 2014 19:46:08 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 14:46:08 -0500 From: "STARK, BARBARA H" To: "Bugenhagen, Michael K" , "'Juergen Schoenwaelder'" , "'Sharam Hakimi'" Thread-Topic: [lmap] MA vs MP Thread-Index: AQHPKFRkqyuqLftGYUCRyHP6AveWewABRf9wmrTseTCAAAp3UIAAjm6A//+gv1CAAAhbEIAAV1UAgARWuID//62vEIAAX6gA///MqCA= Date: Mon, 17 Feb 2014 19:46:07 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303E98FD@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20140214070448.GA87161@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E82F5@GAALPA1MSGUSR9L.ITServices.sbc.com> <52FE30C5.8020005@centurylink.com> <084CDC75FEC1E640B60338273BEACDFA02B23758@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303E84E3@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23778@spboexc01.exfo.com> <20140214194905.GA89769@elstar.local> <084CDC75FEC1E640B60338273BEACDFA02B23817@spboexc01.exfo.com> <20140214205038.GA90067@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303E958A@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.45.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=N9We4RBB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=3gqbixA_TXoA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=_fbRkOfxO] X-AnalysisOut: [ZYA:10 a=-zb7BOiQW0Td11qlV5EA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_bByjrarmMqmZJqmsJ9DfmxPofI Cc: 'Brian Trammell' , "Cook, Charles" , "MORTON JR., AL" , 'KEN KO' , "'lmap@ietf.org'" Subject: Re: [lmap] MA vs MP X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 19:46:35 -0000 > Operationally multiple probes that don't know about each other and can = use > resources don't work. >=20 > So if we want to put multiple probes (which would also require multiple > management ports) on a single device both projects will have to add a "CP= U / > Resource" utilization cross hold monitoring during testing... Assuming that by Probe you mean MA or MP (I would prefer to use "official" = terminology)... An MA (under BBF or LMAP) cannot be assumed to have knowledge of any other = functionality that may reside on a physical device. For an MA to know what'= s going on before and during a Measurement Task, it would need to access th= e underlying OS to determine network interface, memory, and processor utili= zation. In general, OSs provide APIs that give access to this info. How an MA is designed to react in the event of certain network interface, m= emory, and processor utilization will be something I would not expect BBF o= r LMAP to try to mandate. It will vary based on the measurement method, the= percentage of utilization, the purpose of the measurement (regulatory, jus= t for the service provider, just for the end user, etc.), and other factors= . For example, if the task is to do a ping and the utilization of all 3 (ne= twork interface, memory, processor) is around 10%, then there's no need to = stop the ping test. If the task is a bandwidth test of some sort, and memor= y/processor is relatively low and network interface utilization is < 1% (as= a percentage of measured bandwidth, perhaps), then this may be good enough= for an end user to be satisfied with the result, but maybe it's not good e= nough for a regulator. Maybe for a regulator you'd want < 0.1% network inte= rface utilization. I suspect 0% would be unrealistic. On the other hand, pe= rhaps > 1% network interface utilization indicates the user is doing someth= ing and bandwidth measuring should be immediately halted. Less intensive me= asurement tasks may proceed. VoIP tests that only require around 100kbps co= uld easily proceed on a 10Mbps down / 1Mbps up connection with 10% utilizat= ion. But not on a 256 kbps down / 128 kbps up connection with 10% utilizati= on. Note that whether the cause of this "other" utilization is another MA or so= me other function is completely irrelevant. An MA does not need to know the= cause of utilization or be able to interact with or control that cause in = order to know about and react appropriately (per whatever design) to utiliz= ation. > So I would say again - the 304 approach has one resource check without > other probes using resources as peer who can break that schema. [For IETFers, 304 =3D BBF WT-304 draft on performance measurements.] Huh? > I definitely believe this "one probe" view is definitely an ISP op's > requirement - they've been fighting the Video probe, VoIP probe, > Broadband Probe thing for multiple years... >=20 > So I'm going to stick with one probe view is a delta... If you are in control of the device as a whole (e.g., it's your network ele= ment or your STB or your RG or your whitebox or dedicated measurement box),= and you are able to design the MA within it, then do so. Design it the way= you want. I completely agree that putting multiple MAs on a device under y= our control that you can design is a really inefficient and complex thing t= o make work well. If bashing your head against the wall hurts, don't do it. If you are a 3rd party designing an MA to run on a PC or smartphone (as an = app), then you need to accept that you have no control over whatever else i= s running on that platform. Design the MA appropriately.=20 LMAP and BBF allow for both of these models. Because neither tries to dicta= te the underlying platform. There is no difference between the 2 views of M= A in this regard. What BBF does have in its draft are requirements for service parameters and= test environment parameters that get reported with various test result dat= a. It *may* also have guidance (suggestions) regarding when not to do certa= in tests, and how to interpret results together with the service and test e= nvironment parameters (if someone decides to write such guidance). The exis= tence of such requirements or guidance does not make a BBF MA some sort of = super MA that rules over all other MAs. =20 Barbara From nobody Tue Feb 18 00:48:43 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBC71A0454 for ; Tue, 18 Feb 2014 00:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axpkcUH6YeBC for ; Tue, 18 Feb 2014 00:48:38 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 604951A0388 for ; Tue, 18 Feb 2014 00:48:37 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 18 Feb 2014 08:48:16 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Tue, 18 Feb 2014 08:48:02 +0000 From: To: , Date: Tue, 18 Feb 2014 08:48:01 +0000 Thread-Topic: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8rzrCvkcTcIZKMQ229p7E8McN/qwAFeghAACgGvJA= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABF01AEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/DN_Awqui2-RjTYMoGOSYP71LzwA Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 08:48:42 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABF01AEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Barbara, Thanks for the comments. With these two bullets I was pointing out the implications of the proposed = way of not allowing overlapping Tasks (don't start, and never start, a (sec= ond) Task if a (first) Task is still on-going). On your second comment below, I meant something on the lines of your last s= entence: understanding the impact of one sort of traffic on another sort. I= was just saying that such a test could still be achieved, but would have t= o be defined as a single test rather than two. I agree this is quite comple= x - but some people have mentioned a test on these lines On your first bullet, I have some sympathy with this. It is a technical imp= act. Counter arguments are that it's not necessarily clear cut what's a passive = and what's an active Task, and that it adds some complexity to have to clas= sify all tasks as active or passive and to tell the MA this. An active task= misconfigured as passive is nasty. Possible approaches are: - Leave as original proposal. No overlapping Tasks, therefore passive= have to be run at a separate time to active tasks - Modify original proposal, so the MA has a list of Tasks and runs th= rough them one a time. Doesn't affect the 2 bullets you mention - Allow MA to do what it wants, ie start overlapping Tasks (but recor= d this in the Results). Solves your 2 bullets, but also can have multiple o= verlapping active tasks - Distinguish active and passive tasks. Keep original proposal for ac= tive tasks; passive tasks can be run simultaneously. phil From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 February 2014 13:57 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) * Rather than running a Passive Measurement Task continuously in = the background, instead it is run when there are no other Tasks operating I think this one item in the proposal is problematic and I don't see = a need for it. Lots of devices are continually running passive measurements= , and I don't want them to have to turn these off to start an active measur= ement. I'm also completely at a loss as to what the harm is. For example, i= n an RG, ADSL line statistics are always being captured, as are Ethernet fr= ames in/out and IP packets in/out. The firewall is logging various messages= it sees (and I really don't want to turn that off in order to run an activ= e measurement). There has also been the suggestion that the "responding" en= d of an active measurement task can simultaneously do passive measurements = on the traffic of that active measurement task. IMO, these are 2 separate t= asks (though, given the next bullet, we may not have a common definition of= Measurement Task, either). Anyway, unless the device is so incredibly proc= essor- or memory-limited that it can't collect passive measurements while d= oing active measurements (a serious design flaw, IMO, which would make me q= uestion this device's ability to even accurately do a single active measure= ment task), I see no reason to disable any passive measurements while other= measurements are occurring. Multiple passive measurements can also run sim= ultaneously. Oh -- and measuring internal processor- and memory-utilization= during the running of measurement tasks is also a passive measurement task= that I wouldn't want to see disabled. * Rather than testing for the impact of cross-traffic by having t= wo Tasks that run simultaneously, instead a single Task generates two types= of traffic. This is the point that makes me wonder if we're using the same defini= tion of "Task". Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defi= ned in a way that allows it to generate all of the needed types of traffic.= But the Measurement Methods (and the Registry of Measurement Methods) are = being defined external to lmap. This assumption would have the lmap framewo= rk imposing requirements on Measurement Methods and the associated Registry= in order to run certain tests. That makes me very uneasy. I'm also not understanding the proposed cross-traffic test, but maybe that'= s beside the point. I thought cross-traffic was something where we wanted t= o know whether or not there was any cross traffic present prior to starting= certain Active Measurement Tasks, or during an Active Measurement Task (wh= ich BTW would require something to do some passive measuring while the Acti= ve Measurement Task was happening). Understanding what sort of impact one t= ype of traffic has on the simultaneous running of another type of traffic, = from the same MA, strikes me as a rather complex thing to measure, and I'm = not sure I want to do much design around that, right now. --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABF01AEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    = Barbara,

    Thanks for the comments.

     

    With these two bullets I was pointing out t= he implications of the proposed way of not allowing overlapping Tasks (don&= #8217;t start, and never start, a (second) Task if a (first) Task is still = on-going).

     

    On= your second comment below, I meant something on the lines of your last sen= tence: understanding the impact of one sort of traffic on another sort. I w= as just saying that such a test could still be achieved, but would have to = be defined as a single test rather than two. I agree this is quite complex = – but some people have mentioned a test on these lines

     

    On your first bullet, I ha= ve some sympathy with this. It is a technical impact.

    =

    Counter arguments are that it’s not necessarily clear cut what&= #8217;s a passive and what’s an active Task, and that it adds some co= mplexity to have to classify all tasks as active or passive and to tell the= MA this. An active task misconfigured as passive is nasty.

     

    Possible approaches are:=

    -       Leave as original proposal. No overlapping Tasks, therefore pas= sive have to be run at a separate time to active tasks

    -       = Modif= y original proposal, so the MA has a list of Tasks and runs through them on= e a time. Doesn’t affect the 2 bullets you mention<= /p>

    -       All= ow MA to do what it wants, ie start overlapping Tasks (but record this in t= he Results). Solves your 2 bullets, but also can have multiple overlapping = active tasks

    -    = ;   Distinguish active and passive tasks. Keep or= iginal proposal for active tasks; passive tasks can be run simultaneously.<= o:p>

     

    phil

     

    From: STARK, BARBARA H [mailto:bs7652@att.com]
    Sent:     17 February 2014 13:57
    To: Eardley,PL,Philip,TUB8 R; l= map@ietf.org
    Subject: RE: Overlapping Measurement Tasks (WGLC com= ments on draft-ietf-lmap-framework-03)

     

    •        &n= bsp;  Rather than running a Passive Measurement Task continuously in t= he background, instead it is run when there are no other Tasks operating

    <bhs> I think this one item in the p= roposal is problematic and I don’t see a need for it. Lots of devices= are continually running passive measurements, and I don’t want them = to have to turn these off to start an active measurement. I’m also co= mpletely at a loss as to what the harm is. For example, in an RG, ADSL line= statistics are always being captured, as are Ethernet frames in/out and IP= packets in/out. The firewall is logging various messages it sees (and I re= ally don’t want to turn that off in order to run an active measuremen= t). There has also been the suggestion that the “responding” en= d of an active measurement task can simultaneously do passive measurements = on the traffic of that active measurement task. IMO, these are 2 separate t= asks (though, given the next bullet, we may not have a common definition of= Measurement Task, either). Anyway, unless the device is so incredibly proc= essor- or memory-limited that it can’t collect passive measurements w= hile doing active measurements (a serious design flaw, IMO, which would mak= e me question this device’s ability to even accurately do a single ac= tive measurement task), I see no reason to disable any passive measurements= while other measurements are occurring. Multiple passive measurements can = also run simultaneously. Oh -- and measuring internal processor- and memory= -utilization during the running of measurement tasks is also a passive meas= urement task that I wouldn’t want to see disabled.<= /p>

     

    •     =       Rather than testing for the impact of cross-= traffic by having two Tasks that run simultaneously, instead a single Task = generates two types of traffic.

    <= span style=3D'font-family:"Calibri","sans-serif";color:windowtext'><bhs&= gt; This is the point that makes me wonder if we’re using the same de= finition of “Task”. Since Measurement Task is an instantiation = of a Measurement Method, this would imply that the Measurement Method would= have to be defined in a way that allows it to generate all of the needed t= ypes of traffic. But the Measurement Methods (and the Registry of Measureme= nt Methods) are being defined external to lmap. This assumption would have = the lmap framework imposing requirements on Measurement Methods and the ass= ociated Registry in order to run certain tests. That makes me very uneasy.<= o:p>

    I’m also not understanding the pro= posed cross-traffic test, but maybe that’s beside the point. I though= t cross-traffic was something where we wanted to know whether or not there = was any cross traffic present prior to starting certain Active Measurement = Tasks, or during an Active Measurement Task (which BTW would require someth= ing to do some passive measuring while the Active Measurement Task was happ= ening). Understanding what sort of impact one type of traffic has on the si= multaneous running of another type of traffic, from the same MA, strikes me= as a rather complex thing to measure, and I’m not sure I want to do = much design around that, right now.

    = --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABF01AEMV67UKRDdoma_-- From nobody Tue Feb 18 05:44:23 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5B41A04CC for ; Tue, 18 Feb 2014 05:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7Jd9LHyYLho for ; Tue, 18 Feb 2014 05:44:16 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 129971A01D4 for ; Tue, 18 Feb 2014 05:44:15 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Feb 2014 08:44:13 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Feb 2014 08:44:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF2CAF.818411ED" Date: Tue, 18 Feb 2014 08:45:04 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B23959@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8rzrCvkcTcIZKMQ229p7E8McN/qwAFeghAACgGvJAACnB0gA== References: <2D09D61DDFA73D4C884805CC7865E611303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com> From: "Sharam Hakimi" To: , , X-OriginalArrivalTime: 18 Feb 2014 13:44:12.0195 (UTC) FILETIME=[8194DF30:01CF2CAF] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/7lSlNVtuVWIvzMEGyQdigqXm7a8 Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 13:44:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF2CAF.818411ED Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Phil, One thing that is missing is whether "suppress" is stateful. I believe that it should be. One would not want to power cycle a device (intentional or power outage) and have the device return to executing measurement tasks. =20 I suggest adding another bullet that : * A device in suppression must enter suppression mode after a power cycle. =20 =20 Cheers, Sharam =20 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Tuesday, February 18, 2014 3:48 AM To: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) =20 Barbara, Thanks for the comments. =20 With these two bullets I was pointing out the implications of the proposed way of not allowing overlapping Tasks (don't start, and never start, a (second) Task if a (first) Task is still on-going).=20 =20 On your second comment below, I meant something on the lines of your last sentence: understanding the impact of one sort of traffic on another sort. I was just saying that such a test could still be achieved, but would have to be defined as a single test rather than two. I agree this is quite complex - but some people have mentioned a test on these lines=20 =20 On your first bullet, I have some sympathy with this. It is a technical impact. Counter arguments are that it's not necessarily clear cut what's a passive and what's an active Task, and that it adds some complexity to have to classify all tasks as active or passive and to tell the MA this. An active task misconfigured as passive is nasty. =20 Possible approaches are: - Leave as original proposal. No overlapping Tasks, therefore passive have to be run at a separate time to active tasks - Modify original proposal, so the MA has a list of Tasks and runs through them one a time. Doesn't affect the 2 bullets you mention - Allow MA to do what it wants, ie start overlapping Tasks (but record this in the Results). Solves your 2 bullets, but also can have multiple overlapping active tasks - Distinguish active and passive tasks. Keep original proposal for active tasks; passive tasks can be run simultaneously. =20 phil =20 From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: 17 February 2014 13:57 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) =20 * Rather than running a Passive Measurement Task continuously in the background, instead it is run when there are no other Tasks operating I think this one item in the proposal is problematic and I don't see a need for it. Lots of devices are continually running passive measurements, and I don't want them to have to turn these off to start an active measurement. I'm also completely at a loss as to what the harm is. For example, in an RG, ADSL line statistics are always being captured, as are Ethernet frames in/out and IP packets in/out. The firewall is logging various messages it sees (and I really don't want to turn that off in order to run an active measurement). There has also been the suggestion that the "responding" end of an active measurement task can simultaneously do passive measurements on the traffic of that active measurement task. IMO, these are 2 separate tasks (though, given the next bullet, we may not have a common definition of Measurement Task, either). Anyway, unless the device is so incredibly processor- or memory-limited that it can't collect passive measurements while doing active measurements (a serious design flaw, IMO, which would make me question this device's ability to even accurately do a single active measurement task), I see no reason to disable any passive measurements while other measurements are occurring. Multiple passive measurements can also run simultaneously. Oh -- and measuring internal processor- and memory-utilization during the running of measurement tasks is also a passive measurement task that I wouldn't want to see disabled. =20 * Rather than testing for the impact of cross-traffic by having two Tasks that run simultaneously, instead a single Task generates two types of traffic. This is the point that makes me wonder if we're using the same definition of "Task". Since Measurement Task is an instantiation of a Measurement Method, this would imply that the Measurement Method would have to be defined in a way that allows it to generate all of the needed types of traffic. But the Measurement Methods (and the Registry of Measurement Methods) are being defined external to lmap. This assumption would have the lmap framework imposing requirements on Measurement Methods and the associated Registry in order to run certain tests. That makes me very uneasy. I'm also not understanding the proposed cross-traffic test, but maybe that's beside the point. I thought cross-traffic was something where we wanted to know whether or not there was any cross traffic present prior to starting certain Active Measurement Tasks, or during an Active Measurement Task (which BTW would require something to do some passive measuring while the Active Measurement Task was happening). Understanding what sort of impact one type of traffic has on the simultaneous running of another type of traffic, from the same MA, strikes me as a rather complex thing to measure, and I'm not sure I want to do much design around that, right now. ------_=_NextPart_001_01CF2CAF.818411ED Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    Phil,

    One thing that is missing is whether = “suppress” is stateful. I believe that it should be. One would not want to power cycle a device = (intentional or power outage) and have the device return to executing measurement = tasks.

     

    I suggest adding another bullet that = :

    ·         A device in suppression must enter suppression mode after a power cycle. =  

     

    Cheers,

    Sharam

     

    From: lmap = [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
    Sent: Tuesday, February 18, 2014 3:48 AM
    To: bs7652@att.com; lmap@ietf.org
    Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments = on draft-ietf-lmap-framework-03)

     

    Barbara,

    Thanks for the comments.

     

    With these two bullets I was pointing out the implications = of the proposed way of not allowing overlapping Tasks (don’t start, and = never start, a (second) Task if a (first) Task is still on-going). =

     

    On your second comment below, I meant something on the lines = of your last sentence: understanding the impact of one sort of traffic on = another sort. I was just saying that such a test could still be achieved, but = would have to be defined as a single test rather than two. I agree this is = quite complex – but some people have mentioned a test on these lines =

     

    On your first bullet, I have some sympathy with this. It is = a technical impact.

    Counter arguments are that it’s not necessarily clear = cut what’s a passive and what’s an active Task, and that it adds = some complexity to have to classify all tasks as active or passive and to = tell the MA this. An active task misconfigured as passive is = nasty.

     

    Possible approaches are:

    -       Leave as original proposal. No overlapping Tasks, therefore = passive have to be run at a separate time to active tasks

    -       Modify original proposal, so the MA has a list of Tasks and = runs through them one a time. Doesn’t affect the 2 bullets you = mention

    -       Allow MA to do what it wants, ie start overlapping Tasks = (but record this in the Results). Solves your 2 bullets, but also can have = multiple overlapping active tasks

    -       Distinguish active and passive tasks. Keep original proposal = for active tasks; passive tasks can be run = simultaneously.

     

    phil

     

    From: STARK, BARBARA H [mailto:bs7652@att.com]
    Sent: 17 February 2014 13:57
    To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
    Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03)

     

    •      &nb= sp;    Rather than running a Passive Measurement Task continuously in the = background, instead it is run when there are no other Tasks = operating

    <bhs> I think this one item in the proposal is problematic and I don’t see a need for it. Lots of devices are continually running passive measurements, and I don’t want them to = have to turn these off to start an active measurement. I’m also = completely at a loss as to what the harm is. For example, in an RG, ADSL line = statistics are always being captured, as are Ethernet frames in/out and IP packets = in/out. The firewall is logging various messages it sees (and I really don’t = want to turn that off in order to run an active measurement). There has also = been the suggestion that the “responding” end of an active = measurement task can simultaneously do passive measurements on the traffic of that active measurement task. IMO, these are 2 separate tasks (though, given the = next bullet, we may not have a common definition of Measurement Task, = either). Anyway, unless the device is so incredibly processor- or memory-limited = that it can’t collect passive measurements while doing active measurements = (a serious design flaw, IMO, which would make me question this = device’s ability to even accurately do a single active measurement task), I see = no reason to disable any passive measurements while other measurements are occurring. Multiple passive measurements can also run simultaneously. Oh = -- and measuring internal processor- and memory-utilization during the running = of measurement tasks is also a passive measurement task that I = wouldn’t want to see disabled.

     

    •      &nb= sp;    Rather than testing for the impact of cross-traffic by having two Tasks = that run simultaneously, instead a single Task generates two types of = traffic.

    <bhs> This is the point that makes me wonder if we’re using the same definition of “Task”. Since = Measurement Task is an instantiation of a Measurement Method, this would imply that = the Measurement Method would have to be defined in a way that allows it to = generate all of the needed types of traffic. But the Measurement Methods (and the Registry of Measurement Methods) are being defined external to lmap. = This assumption would have the lmap framework imposing requirements on = Measurement Methods and the associated Registry in order to run certain tests. That = makes me very uneasy.

    I’m also not understanding the proposed = cross-traffic test, but maybe that’s beside the point. I thought cross-traffic = was something where we wanted to know whether or not there was any cross = traffic present prior to starting certain Active Measurement Tasks, or during an = Active Measurement Task (which BTW would require something to do some passive measuring while the Active Measurement Task was happening). = Understanding what sort of impact one type of traffic has on the simultaneous running of = another type of traffic, from the same MA, strikes me as a rather complex thing to = measure, and I’m not sure I want to do much design around that, right = now.

    ------_=_NextPart_001_01CF2CAF.818411ED-- From nobody Tue Feb 18 06:03:49 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FF11A0673 for ; Tue, 18 Feb 2014 06:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.147 X-Spam-Level: X-Spam-Status: No, score=-4.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9EfEzv8CKgG for ; Tue, 18 Feb 2014 06:03:43 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id DFF811A0491 for ; Tue, 18 Feb 2014 06:03:42 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id c3863035.2b86f7017940.578864.00-2470.1616664.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 18 Feb 2014 14:03:40 +0000 (UTC) X-MXL-Hash: 5303683c6d272258-f3e873c7eeb252ff28d2da5fc83444b4f7b30aae Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 43863035.0.578793.00-2263.1616469.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 18 Feb 2014 14:03:35 +0000 (UTC) X-MXL-Hash: 530368370b76dded-7c28c12bf8eff87c0f23798485190c5f5dd43991 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IE3VmL032692; Tue, 18 Feb 2014 09:03:32 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IE3PL7032621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 09:03:28 -0500 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 18 Feb 2014 14:03:11 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 09:03:11 -0500 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8rzrCvkcTcIZKMQ229p7E8McN/qwAFeghAACgGvJAACuTM0A== Date: Tue, 18 Feb 2014 14:03:10 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303E9FCB@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.101.144] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611303E9FCBGAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OL2QK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=cIUMTu1c1TMA:10 a=ofMgfj31e3cA:10 a=3HMTSpwm3aUA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=uCRMkwNkO] X-AnalysisOut: [M4A:10 a=e9qsufxtAAAA:8 a=48vgC7mUAAAA:8 a=m3ZTRq9_FzRlJDK] X-AnalysisOut: [9tDwA:9 a=CjuIK1q_8ugA:10 a=W1qU_X6G3J8A:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=] X-AnalysisOut: [gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4] X-AnalysisOut: [AuCg-hUA:10 a=0pP9XuRH1PzptLj4:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/nwV_ybXcw6qoJZm2KyXcq-B_jZw Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 14:03:48 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611303E9FCBGAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Phil. Personally, I prefer Option 3 (3rd dashed item) in your list: " - Allow MA to do what it wants, ie start overlapping Tasks (but= record this in the Results). Solves your 2 bullets, but also can have mult= iple overlapping active tasks" Not all MAs are for regulatory use cases, and different use cases may have = different tolerances regarding accuracy and precision. And as I mentioned i= n a previous email, tasks that use minimal resources and are not attempting= to actively measure total resource availability can provide reasonably acc= urate results during times when the device is not resource-constrained -- i= ndependent of what other tasks (or non-measurement related functions) may b= e using those same resources. It also makes no sense to restrict what a sin= gle MA can do simultaneously when other functions inside the device can be = doing all sorts of things at the same time. Including utilization measures = of various device resources with Results is to me far preferable. We need to remember that this framework is not supposed to cost an arm and = a leg to implement. It is not intended to provide perfect measurements. It = is intended to provide "good enough" measurements. What is "good enough" wi= ll vary per use case, country/jurisdiction, entity procuring/designing the = MAs, etc. Barbara From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Tuesday, February 18, 2014 3:48 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) Barbara, Thanks for the comments. With these two bullets I was pointing out the implications of the proposed = way of not allowing overlapping Tasks (don't start, and never start, a (sec= ond) Task if a (first) Task is still on-going). On your second comment below, I meant something on the lines of your last s= entence: understanding the impact of one sort of traffic on another sort. I= was just saying that such a test could still be achieved, but would have t= o be defined as a single test rather than two. I agree this is quite comple= x - but some people have mentioned a test on these lines On your first bullet, I have some sympathy with this. It is a technical imp= act. Counter arguments are that it's not necessarily clear cut what's a passive = and what's an active Task, and that it adds some complexity to have to clas= sify all tasks as active or passive and to tell the MA this. An active task= misconfigured as passive is nasty. Possible approaches are: - Leave as original proposal. No overlapping Tasks, therefore passive= have to be run at a separate time to active tasks - Modify original proposal, so the MA has a list of Tasks and runs th= rough them one a time. Doesn't affect the 2 bullets you mention - Allow MA to do what it wants, ie start overlapping Tasks (but recor= d this in the Results). Solves your 2 bullets, but also can have multiple o= verlapping active tasks - Distinguish active and passive tasks. Keep original proposal for ac= tive tasks; passive tasks can be run simultaneously. phil From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 February 2014 13:57 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) * Rather than running a Passive Measurement Task continuously in = the background, instead it is run when there are no other Tasks operating I think this one item in the proposal is problematic and I don't see = a need for it. Lots of devices are continually running passive measurements= , and I don't want them to have to turn these off to start an active measur= ement. I'm also completely at a loss as to what the harm is. For example, i= n an RG, ADSL line statistics are always being captured, as are Ethernet fr= ames in/out and IP packets in/out. The firewall is logging various messages= it sees (and I really don't want to turn that off in order to run an activ= e measurement). There has also been the suggestion that the "responding" en= d of an active measurement task can simultaneously do passive measurements = on the traffic of that active measurement task. IMO, these are 2 separate t= asks (though, given the next bullet, we may not have a common definition of= Measurement Task, either). Anyway, unless the device is so incredibly proc= essor- or memory-limited that it can't collect passive measurements while d= oing active measurements (a serious design flaw, IMO, which would make me q= uestion this device's ability to even accurately do a single active measure= ment task), I see no reason to disable any passive measurements while other= measurements are occurring. Multiple passive measurements can also run sim= ultaneously. Oh -- and measuring internal processor- and memory-utilization= during the running of measurement tasks is also a passive measurement task= that I wouldn't want to see disabled. * Rather than testing for the impact of cross-traffic by having t= wo Tasks that run simultaneously, instead a single Task generates two types= of traffic. This is the point that makes me wonder if we're using the same defini= tion of "Task". Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defi= ned in a way that allows it to generate all of the needed types of traffic.= But the Measurement Methods (and the Registry of Measurement Methods) are = being defined external to lmap. This assumption would have the lmap framewo= rk imposing requirements on Measurement Methods and the associated Registry= in order to run certain tests. That makes me very uneasy. I'm also not understanding the proposed cross-traffic test, but maybe that'= s beside the point. I thought cross-traffic was something where we wanted t= o know whether or not there was any cross traffic present prior to starting= certain Active Measurement Tasks, or during an Active Measurement Task (wh= ich BTW would require something to do some passive measuring while the Acti= ve Measurement Task was happening). Understanding what sort of impact one t= ype of traffic has on the simultaneous running of another type of traffic, = from the same MA, strikes me as a rather complex thing to measure, and I'm = not sure I want to do much design around that, right now. --_000_2D09D61DDFA73D4C884805CC7865E611303E9FCBGAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Thanks Phil.

    Personally, I prefer O= ption 3 (3rd dashed item) in your list:

    “ -  &= nbsp;        Allow MA to do what it want= s, ie start overlapping Tasks (but record this in the Results). Solves your= 2 bullets, but also can have multiple overlapping active tasks”

     

    Not all MAs are for re= gulatory use cases, and different use cases may have different tolerances r= egarding accuracy and precision. And as I mentioned in a previous email, tasks that use minimal resources and are not attempting to= actively measure total resource availability can provide reasonably accura= te results during times when the device is not resource-constrained -- inde= pendent of what other tasks (or non-measurement related functions) may be using those same resources. It a= lso makes no sense to restrict what a single MA can do simultaneously when = other functions inside the device can be doing all sorts of things at the s= ame time. Including utilization measures of various device resources with Results is to me far preferable.=

     

    We need to remember th= at this framework is not supposed to cost an arm and a leg to implement. It= is not intended to provide perfect measurements. It is intended to provide “good enough” measurements. What is “= ;good enough” will vary per use case, country/jurisdiction, entity pr= ocuring/designing the MAs, etc.

    Barbara

     <= /p>

    From: philip.eardley@bt.com [mailto:philip.eardley@bt.c= om]
    Sent: Tuesday, February 18, 2014 3:48 AM
    To: STARK, BARBARA H; lmap@ietf.org
    Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-i= etf-lmap-framework-03)

     

    Barbara,

    Thanks for the comments.

     

    With these two bullets I was poi= nting out the implications of the proposed way of not allowing overlapping = Tasks (don’t start, and never start, a (second) Task if a (first) Task is still on-going).

     

    On your second comment below, I = meant something on the lines of your last sentence: understanding the impac= t of one sort of traffic on another sort. I was just saying that such a test could still be achieved, but would have to be defined as = a single test rather than two. I agree this is quite complex – but so= me people have mentioned a test on these lines

     

    On your first bullet, I have som= e sympathy with this. It is a technical impact.

    Counter arguments are that it= 217;s not necessarily clear cut what’s a passive and what’s an = active Task, and that it adds some complexity to have to classify all tasks as active or passive and to tell the MA this. An active task misconfigured= as passive is nasty.

     

    Possible approaches are:

    -  &= nbsp;    Leave as original propos= al. No overlapping Tasks, therefore passive have to be run at a separate ti= me to active tasks

    -  &= nbsp;    Modify original proposal= , so the MA has a list of Tasks and runs through them one a time. DoesnR= 17;t affect the 2 bullets you mention

    -  &= nbsp;    Allow MA to do what it w= ants, ie start overlapping Tasks (but record this in the Results). Solves y= our 2 bullets, but also can have multiple overlapping active tasks

    -  &= nbsp;    Distinguish active and p= assive tasks. Keep original proposal for active tasks; passive tasks can be= run simultaneously.

     

    phil

     

    From: STARK, BARBARA H [mailto:bs7652@att.com]
    Sent: 17 February 2014 13:57
    To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
    Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-i= etf-lmap-framework-03)

     

    R= 26;           Rather than= running a Passive Measurement Task continuously in the background, instead= it is run when there are no other Tasks operating

    <bhs> I think this= one item in the proposal is problematic and I don’t see a need for i= t. Lots of devices are continually running passive measurements, and I don’t want them to have to turn these off to start an active measure= ment. I’m also completely at a loss as to what the harm is. For examp= le, in an RG, ADSL line statistics are always being captured, as are Ethern= et frames in/out and IP packets in/out. The firewall is logging various messages it sees (and I really don’t wan= t to turn that off in order to run an active measurement). There has also b= een the suggestion that the “responding” end of an active measu= rement task can simultaneously do passive measurements on the traffic of that active measurement task. IMO, these are 2 separate = tasks (though, given the next bullet, we may not have a common definition o= f Measurement Task, either). Anyway, unless the device is so incredibly pro= cessor- or memory-limited that it can’t collect passive measurements while doing active measurements (= a serious design flaw, IMO, which would make me question this device’= s ability to even accurately do a single active measurement task), I see no= reason to disable any passive measurements while other measurements are occurring. Multiple passive measurements can = also run simultaneously. Oh -- and measuring internal processor- and memory= -utilization during the running of measurement tasks is also a passive meas= urement task that I wouldn’t want to see disabled.

     = ;

    R= 26;           Rather than= testing for the impact of cross-traffic by having two Tasks that run simul= taneously, instead a single Task generates two types of traffic.=

    <bhs> This is the = point that makes me wonder if we’re using the same definition of R= 20;Task”. Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defined in a= way that allows it to generate all of the needed types of traffic. But the= Measurement Methods (and the Registry of Measurement Methods) are being de= fined external to lmap. This assumption would have the lmap framework imposing requirements on Measurement Methods= and the associated Registry in order to run certain tests. That makes me v= ery uneasy.

    I’m also not under= standing the proposed cross-traffic test, but maybe that’s beside the= point. I thought cross-traffic was something where we wanted to know whether or not there was any cross traffic present prior to starting certa= in Active Measurement Tasks, or during an Active Measurement Task (which BT= W would require something to do some passive measuring while the Active Mea= surement Task was happening). Understanding what sort of impact one type of traffic has on the simultaneous running of= another type of traffic, from the same MA, strikes me as a rather complex = thing to measure, and I’m not sure I want to do much design around th= at, right now.

    --_000_2D09D61DDFA73D4C884805CC7865E611303E9FCBGAALPA1MSGUSR9L_-- From nobody Tue Feb 18 07:13:56 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57801A01E2 for ; Tue, 18 Feb 2014 07:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.147 X-Spam-Level: X-Spam-Status: No, score=-4.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ruJUzhbhRh3 for ; Tue, 18 Feb 2014 07:13:49 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id BF3EF1A0699 for ; Tue, 18 Feb 2014 07:13:35 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id d9873035.2b872185b940.623477.00-2449.1744146.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 18 Feb 2014 15:13:33 +0000 (UTC) X-MXL-Hash: 5303789d4e364373-046173e8ec4d32acb13965d6e78538823e058dcb Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id f8873035.0.623305.00-2282.1743649.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 18 Feb 2014 15:13:21 +0000 (UTC) X-MXL-Hash: 530378910aa2c1a2-b7f9445c2cc7878a792f7430fcb85f30d1c00755 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IFDIaQ015466; Tue, 18 Feb 2014 10:13:18 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IFD50s015255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 10:13:12 -0500 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 18 Feb 2014 15:12:42 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 10:12:42 -0500 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: determining passive vs. active nature of measurement task Thread-Index: Ac8su9uG/Z96xXmsRyqSwIjA7oRtQg== Date: Tue, 18 Feb 2014 15:12:41 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303EA07C@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.112.67] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611303EA07CGAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OL2QK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=He7eqCg0_OgA:10 a=ofMgfj31e3cA:10 a=iEfvJiHnMjQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=xiONRnEJR] X-AnalysisOut: [RYA:10 a=e9qsufxtAAAA:8 a=48vgC7mUAAAA:8 a=LQqy4XP7xtDDVVB] X-AnalysisOut: [3CLAA:9 a=CjuIK1q_8ugA:10 a=W1qU_X6G3J8A:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=] X-AnalysisOut: [T52-BqWkz7G0ATByNT8A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10] X-AnalysisOut: [ a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=yY-NMte6esG1bQom:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/NGJlH3pInpxXl7wzxo5cK_P7dYM Subject: [lmap] determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 15:13:54 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611303EA07CGAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil, In the email below (I'm replying using a different subject line for this), = you made the following statement Counter arguments are that it's not necessarily clear cut what's a passive = and what's an active Task, and that it adds some complexity to have to clas= sify all tasks as active or passive and to tell the MA this. An active task= misconfigured as passive is nasty. I've been trying to get my head around this statement and have to say that = I really don't understand it. Is there really an intention for "passive" vs. "active" to be a configurabl= e parameter of a Measurement Method or Measurement Task? If so, how would t= hat work? And is there really a set of Measurement Methods whose active/pas= sive nature is ambiguous, unknown, or configurable (per the specification t= hat defines the Measurement Method)? If so, I'd like concrete examples of s= uch Measurement Methods so I can better understand. For example, let's look at a simple "ping" (I'm using "ping" here to mean a= client capability that initiates IPv4 ICMP echo). If a MA tells its Contro= ller that it supports ping (I'm hoping we consider this a possible Measurem= ent Method capability), and the Controller wants to configure this, I would= n't expect the Controller to be able to configure ping to run in passive mo= de. It is illogical for ping configuration parameters to include such a con= figuration option (and I've never seen an implementation that includes such= a configuration option). Furthermore, every ping implementation that I've = ever seen knows which of its configuration options are mandatory and which = are optional, and the correct syntax, in order for it to actually run. For = example, it has to have a target IP address or URL. If it is incorrectly co= nfigured, this generates an error condition. An implementation of a Measurement Method in a MA needs to be compliant wit= h whatever spec defines that Measurement Method, and needs to expose config= uration parameters consistent with its spec (and perhaps the Registry). If = we can't assume compliant Measurement Methods in a MA, then I think the sco= pe of the problem we're trying to solve becomes too huge to solve in the ti= meframe we've given ourselves. So hopefully we aren't trying to include non= -compliant or ill-defined Measurement Method implementations in lmap scope. Anyway, I look forward to learning about Measurement Methods that allow for= active/passive configuration and understanding why they are not resilient = when this parameter is configured in a manner inconsistent with the Method'= s other configuration parameters (i.e., why the Measurement Method is not d= esigned with internal configuration consistency checks). Barbara From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Tuesday, February 18, 2014 3:48 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) Barbara, Thanks for the comments. With these two bullets I was pointing out the implications of the proposed = way of not allowing overlapping Tasks (don't start, and never start, a (sec= ond) Task if a (first) Task is still on-going). On your second comment below, I meant something on the lines of your last s= entence: understanding the impact of one sort of traffic on another sort. I= was just saying that such a test could still be achieved, but would have t= o be defined as a single test rather than two. I agree this is quite comple= x - but some people have mentioned a test on these lines On your first bullet, I have some sympathy with this. It is a technical imp= act. Counter arguments are that it's not necessarily clear cut what's a passive = and what's an active Task, and that it adds some complexity to have to clas= sify all tasks as active or passive and to tell the MA this. An active task= misconfigured as passive is nasty. Possible approaches are: - Leave as original proposal. No overlapping Tasks, therefore passive= have to be run at a separate time to active tasks - Modify original proposal, so the MA has a list of Tasks and runs th= rough them one a time. Doesn't affect the 2 bullets you mention - Allow MA to do what it wants, ie start overlapping Tasks (but recor= d this in the Results). Solves your 2 bullets, but also can have multiple o= verlapping active tasks - Distinguish active and passive tasks. Keep original proposal for ac= tive tasks; passive tasks can be run simultaneously. phil From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 February 2014 13:57 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) * Rather than running a Passive Measurement Task continuously in = the background, instead it is run when there are no other Tasks operating I think this one item in the proposal is problematic and I don't see = a need for it. Lots of devices are continually running passive measurements= , and I don't want them to have to turn these off to start an active measur= ement. I'm also completely at a loss as to what the harm is. For example, i= n an RG, ADSL line statistics are always being captured, as are Ethernet fr= ames in/out and IP packets in/out. The firewall is logging various messages= it sees (and I really don't want to turn that off in order to run an activ= e measurement). There has also been the suggestion that the "responding" en= d of an active measurement task can simultaneously do passive measurements = on the traffic of that active measurement task. IMO, these are 2 separate t= asks (though, given the next bullet, we may not have a common definition of= Measurement Task, either). Anyway, unless the device is so incredibly proc= essor- or memory-limited that it can't collect passive measurements while d= oing active measurements (a serious design flaw, IMO, which would make me q= uestion this device's ability to even accurately do a single active measure= ment task), I see no reason to disable any passive measurements while other= measurements are occurring. Multiple passive measurements can also run sim= ultaneously. Oh -- and measuring internal processor- and memory-utilization= during the running of measurement tasks is also a passive measurement task= that I wouldn't want to see disabled. * Rather than testing for the impact of cross-traffic by having t= wo Tasks that run simultaneously, instead a single Task generates two types= of traffic. This is the point that makes me wonder if we're using the same defini= tion of "Task". Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defi= ned in a way that allows it to generate all of the needed types of traffic.= But the Measurement Methods (and the Registry of Measurement Methods) are = being defined external to lmap. This assumption would have the lmap framewo= rk imposing requirements on Measurement Methods and the associated Registry= in order to run certain tests. That makes me very uneasy. I'm also not understanding the proposed cross-traffic test, but maybe that'= s beside the point. I thought cross-traffic was something where we wanted t= o know whether or not there was any cross traffic present prior to starting= certain Active Measurement Tasks, or during an Active Measurement Task (wh= ich BTW would require something to do some passive measuring while the Acti= ve Measurement Task was happening). Understanding what sort of impact one t= ype of traffic has on the simultaneous running of another type of traffic, = from the same MA, strikes me as a rather complex thing to measure, and I'm = not sure I want to do much design around that, right now. --_000_2D09D61DDFA73D4C884805CC7865E611303EA07CGAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Phil,

    In the email below (IR= 17;m replying using a different subject line for this), you made the follow= ing statement

    Counter arguments are that it= 217;s not necessarily clear cut what’s a passive and what’s an = active Task, and that it adds some complexity to have to classify all tasks as active or passive and to tell the MA this. An active task misconfigured= as passive is nasty.

    I’ve been trying to= get my head around this statement and have to say that I really don’= t understand it.

    Is there really an intent= ion for “passive” vs. “active” to be a configurable= parameter of a Measurement Method or Measurement Task? If so, how would th= at work? And is there really a set of Measurement Methods whose active/passive natu= re is ambiguous, unknown, or configurable (per the specification that defin= es the Measurement Method)? If so, I’d like concrete examples of such= Measurement Methods so I can better understand.

     <= /p>

    For example, let’s = look at a simple “ping” (I’m using “ping” her= e to mean a client capability that initiates IPv4 ICMP echo). If a MA tells= its Controller that it supports ping (I’m hoping we consider this a possible Measurement= Method capability), and the Controller wants to configure this, I wouldn&#= 8217;t expect the Controller to be able to configure ping to run in passive= mode. It is illogical for ping configuration parameters to include such a configuration option (and I’ve never se= en an implementation that includes such a configuration option). Furthermor= e, every ping implementation that I’ve ever seen knows which of its c= onfiguration options are mandatory and which are optional, and the correct syntax, in order for it to actually run. For= example, it has to have a target IP address or URL. If it is incorrectly c= onfigured, this generates an error condition.

     <= /p>

    An implementation of a Me= asurement Method in a MA needs to be compliant with whatever spec defines t= hat Measurement Method, and needs to expose configuration parameters consistent with its spec (and perhaps the Registry). If we can&= #8217;t assume compliant Measurement Methods in a MA, then I think the scop= e of the problem we’re trying to solve becomes too huge to solve in t= he timeframe we’ve given ourselves. So hopefully we aren’t trying to include non-compliant or ill-defined Measurement= Method implementations in lmap scope.

     <= /p>

    Anyway, I look forward to= learning about Measurement Methods that allow for active/passive configura= tion and understanding why they are not resilient when this parameter is configured in a manner inconsistent with the Method’s o= ther configuration parameters (i.e., why the Measurement Method is not desi= gned with internal configuration consistency checks).

    Barbara=

     <= /p>

     <= /p>

    From: philip.eardley@bt.com [mailto:philip.eardley@bt.c= om]
    Sent: Tuesday, February 18, 2014 3:48 AM
    To: STARK, BARBARA H; lmap@ietf.org
    Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-i= etf-lmap-framework-03)

     

    Barbara,

    Thanks for the comments.

     

    With these two bullets I was poi= nting out the implications of the proposed way of not allowing overlapping = Tasks (don’t start, and never start, a (second) Task if a (first) Task is still on-going).

     

    On your second comment below, I = meant something on the lines of your last sentence: understanding the impac= t of one sort of traffic on another sort. I was just saying that such a test could still be achieved, but would have to be defined as = a single test rather than two. I agree this is quite complex – but so= me people have mentioned a test on these lines

     

    On your first bullet, I have som= e sympathy with this. It is a technical impact.

    Counter arguments are that it= 217;s not necessarily clear cut what’s a passive and what’s an = active Task, and that it adds some complexity to have to classify all tasks as active or passive and to tell the MA this. An active task misconfigured= as passive is nasty.

     

    Possible approaches are:

    -  &= nbsp;    Leave as original propos= al. No overlapping Tasks, therefore passive have to be run at a separate ti= me to active tasks

    -  &= nbsp;    Modify original proposal= , so the MA has a list of Tasks and runs through them one a time. DoesnR= 17;t affect the 2 bullets you mention

    -  &= nbsp;    Allow MA to do what it w= ants, ie start overlapping Tasks (but record this in the Results). Solves y= our 2 bullets, but also can have multiple overlapping active tasks

    -  &= nbsp;    Distinguish active and p= assive tasks. Keep original proposal for active tasks; passive tasks can be= run simultaneously.

     

    phil

     

    From: STARK, BARBARA H [mailto:bs7652@att.com]
    Sent: 17 February 2014 13:57
    To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
    Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-i= etf-lmap-framework-03)

     

    R= 26;           Rather than= running a Passive Measurement Task continuously in the background, instead= it is run when there are no other Tasks operating

    <bhs> I think this= one item in the proposal is problematic and I don’t see a need for i= t. Lots of devices are continually running passive measurements, and I don’t want them to have to turn these off to start an active measure= ment. I’m also completely at a loss as to what the harm is. For examp= le, in an RG, ADSL line statistics are always being captured, as are Ethern= et frames in/out and IP packets in/out. The firewall is logging various messages it sees (and I really don’t wan= t to turn that off in order to run an active measurement). There has also b= een the suggestion that the “responding” end of an active measu= rement task can simultaneously do passive measurements on the traffic of that active measurement task. IMO, these are 2 separate = tasks (though, given the next bullet, we may not have a common definition o= f Measurement Task, either). Anyway, unless the device is so incredibly pro= cessor- or memory-limited that it can’t collect passive measurements while doing active measurements (= a serious design flaw, IMO, which would make me question this device’= s ability to even accurately do a single active measurement task), I see no= reason to disable any passive measurements while other measurements are occurring. Multiple passive measurements can = also run simultaneously. Oh -- and measuring internal processor- and memory= -utilization during the running of measurement tasks is also a passive meas= urement task that I wouldn’t want to see disabled.

     = ;

    R= 26;           Rather than= testing for the impact of cross-traffic by having two Tasks that run simul= taneously, instead a single Task generates two types of traffic.=

    <bhs> This is the = point that makes me wonder if we’re using the same definition of R= 20;Task”. Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defined in a= way that allows it to generate all of the needed types of traffic. But the= Measurement Methods (and the Registry of Measurement Methods) are being de= fined external to lmap. This assumption would have the lmap framework imposing requirements on Measurement Methods= and the associated Registry in order to run certain tests. That makes me v= ery uneasy.

    I’m also not under= standing the proposed cross-traffic test, but maybe that’s beside the= point. I thought cross-traffic was something where we wanted to know whether or not there was any cross traffic present prior to starting certa= in Active Measurement Tasks, or during an Active Measurement Task (which BT= W would require something to do some passive measuring while the Active Mea= surement Task was happening). Understanding what sort of impact one type of traffic has on the simultaneous running of= another type of traffic, from the same MA, strikes me as a rather complex = thing to measure, and I’m not sure I want to do much design around th= at, right now.

    --_000_2D09D61DDFA73D4C884805CC7865E611303EA07CGAALPA1MSGUSR9L_-- From nobody Tue Feb 18 07:45:34 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A9A1A01E2 for ; Tue, 18 Feb 2014 07:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.147 X-Spam-Level: X-Spam-Status: No, score=-4.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gucnyz0AV4Kx for ; Tue, 18 Feb 2014 07:45:27 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id B65721A01CE for ; Tue, 18 Feb 2014 07:45:26 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 41083035.2b8744893940.645780.00-2428.1807458.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 18 Feb 2014 15:45:24 +0000 (UTC) X-MXL-Hash: 530380146f571066-7e7f025a0fb3fdee27b38efbe025398b2c0197c2 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id d0083035.0.645702.00-2303.1807233.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 18 Feb 2014 15:45:19 +0000 (UTC) X-MXL-Hash: 5303800f18c54fb7-d3af165d572060454ef9ff7a10e358510ac2c467 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IFjFns020824; Tue, 18 Feb 2014 10:45:17 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IFjB2t020740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 10:45:13 -0500 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (GAALPA1MSGHUB9E.itservices.sbc.com [130.8.36.91]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 18 Feb 2014 15:44:50 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 10:44:50 -0500 From: "STARK, BARBARA H" To: Sharam Hakimi , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8rzrCvkcTcIZKMQ229p7E8McN/qwAFeghAACgGvJAACnB0gAADfbZA Date: Tue, 18 Feb 2014 15:44:49 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303EA0CA@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23959@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA02B23959@spboexc01.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.112.67] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611303EA0CAGAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OL2QK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=bmWGoxaDoNYA:10 a=ofMgfj31e3cA:10 a=iEfvJiHnMjQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=5s58gDRpS] X-AnalysisOut: [GQA:10 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8 a=ufha4ocntvXcbXL] X-AnalysisOut: [aGcEA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=W1qU_X6G3J8A] X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=qPh6ih1IOtisiuou:21 a=QCvDgHtB6zHW] X-AnalysisOut: [puqd:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:1] X-AnalysisOut: [0 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=] X-AnalysisOut: [9hysWW1L-BLVv25C:21 a=JJT5CHojJUAX77_8:21 a=YKkombAM5UbcIA] X-AnalysisOut: [6F:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/f0PirnDE_DN5PjLwFYuNXXP7HiE Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 15:45:32 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611303EA0CAGAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This suggestion is attempting to impose requirements on the device where th= e MA is. I think that's problematic. But perhaps you meant MA instead of de= vice? If survivability of suppression is so important, I'm not sure this is the b= est way to ensure it. I could envision a MA that is factory-configured to r= un a set of basic measurement tasks. If reset to factory configuration, it = will go back to doing those (and suppression will be lost) in the absence o= f updated configuration (Instructions) from the Controller. I could also en= vision a case where the suppression message was sent while a MA was powered= down. On the other hand, I would expect that one of the very first things a MA do= es on boot is contact its Controller. The MA should never assume that its c= onfiguration is current after a power cycle. We've said (I think) that if a= MA can't talk to its Controller, it shouldn't run measurements. So the MA = shouldn't be starting up measurement tasks before that's been successful. I= would suggest that rather than rely on an MA's ability to remember suppres= sion, a Controller would be expected to transmit any currently active suppr= ession whenever an MA contacts it. If a Controller doesn't indicate active = suppression to a MA at any time when it is communicating with the MA, the M= A can assume it is not suppressed. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi Sent: Tuesday, February 18, 2014 8:45 AM To: philip.eardley@bt.com; STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-i= etf-lmap-framework-03) Phil, One thing that is missing is whether "suppress" is stateful. I believe that= it should be. One would not want to power cycle a device (intentional or p= ower outage) and have the device return to executing measurement tasks. I suggest adding another bullet that : * A device in suppression must enter suppression mode after a power= cycle. Cheers, Sharam From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Tuesday, February 18, 2014 3:48 AM To: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-i= etf-lmap-framework-03) Barbara, Thanks for the comments. With these two bullets I was pointing out the implications of the proposed = way of not allowing overlapping Tasks (don't start, and never start, a (sec= ond) Task if a (first) Task is still on-going). On your second comment below, I meant something on the lines of your last s= entence: understanding the impact of one sort of traffic on another sort. I= was just saying that such a test could still be achieved, but would have t= o be defined as a single test rather than two. I agree this is quite comple= x - but some people have mentioned a test on these lines On your first bullet, I have some sympathy with this. It is a technical imp= act. Counter arguments are that it's not necessarily clear cut what's a passive = and what's an active Task, and that it adds some complexity to have to clas= sify all tasks as active or passive and to tell the MA this. An active task= misconfigured as passive is nasty. Possible approaches are: - Leave as original proposal. No overlapping Tasks, therefore passive= have to be run at a separate time to active tasks - Modify original proposal, so the MA has a list of Tasks and runs th= rough them one a time. Doesn't affect the 2 bullets you mention - Allow MA to do what it wants, ie start overlapping Tasks (but recor= d this in the Results). Solves your 2 bullets, but also can have multiple o= verlapping active tasks - Distinguish active and passive tasks. Keep original proposal for ac= tive tasks; passive tasks can be run simultaneously. phil From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 February 2014 13:57 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) * Rather than running a Passive Measurement Task continuously in = the background, instead it is run when there are no other Tasks operating I think this one item in the proposal is problematic and I don't see = a need for it. Lots of devices are continually running passive measurements= , and I don't want them to have to turn these off to start an active measur= ement. I'm also completely at a loss as to what the harm is. For example, i= n an RG, ADSL line statistics are always being captured, as are Ethernet fr= ames in/out and IP packets in/out. The firewall is logging various messages= it sees (and I really don't want to turn that off in order to run an activ= e measurement). There has also been the suggestion that the "responding" en= d of an active measurement task can simultaneously do passive measurements = on the traffic of that active measurement task. IMO, these are 2 separate t= asks (though, given the next bullet, we may not have a common definition of= Measurement Task, either). Anyway, unless the device is so incredibly proc= essor- or memory-limited that it can't collect passive measurements while d= oing active measurements (a serious design flaw, IMO, which would make me q= uestion this device's ability to even accurately do a single active measure= ment task), I see no reason to disable any passive measurements while other= measurements are occurring. Multiple passive measurements can also run sim= ultaneously. Oh -- and measuring internal processor- and memory-utilization= during the running of measurement tasks is also a passive measurement task= that I wouldn't want to see disabled. * Rather than testing for the impact of cross-traffic by having t= wo Tasks that run simultaneously, instead a single Task generates two types= of traffic. This is the point that makes me wonder if we're using the same defini= tion of "Task". Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defi= ned in a way that allows it to generate all of the needed types of traffic.= But the Measurement Methods (and the Registry of Measurement Methods) are = being defined external to lmap. This assumption would have the lmap framewo= rk imposing requirements on Measurement Methods and the associated Registry= in order to run certain tests. That makes me very uneasy. I'm also not understanding the proposed cross-traffic test, but maybe that'= s beside the point. I thought cross-traffic was something where we wanted t= o know whether or not there was any cross traffic present prior to starting= certain Active Measurement Tasks, or during an Active Measurement Task (wh= ich BTW would require something to do some passive measuring while the Acti= ve Measurement Task was happening). Understanding what sort of impact one t= ype of traffic has on the simultaneous running of another type of traffic, = from the same MA, strikes me as a rather complex thing to measure, and I'm = not sure I want to do much design around that, right now. --_000_2D09D61DDFA73D4C884805CC7865E611303EA0CAGAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    This suggestion is attemp= ting to impose requirements on the device where the MA is. I think thatR= 17;s problematic. But perhaps you meant MA instead of device?

     <= /p>

    If survivability of suppr= ession is so important, I’m not sure this is the best way to ensure i= t. I could envision a MA that is factory-configured to run a set of basic measurement tasks. If reset to factory configuration, it will go = back to doing those (and suppression will be lost) in the absence of update= d configuration (Instructions) from the Controller. I could also envision a= case where the suppression message was sent while a MA was powered down.

     <= /p>

    On the other hand, I woul= d expect that one of the very first things a MA does on boot is contact its= Controller. The MA should never assume that its configuration is current after a power cycle. We’ve said (I think) that if a MA ca= n’t talk to its Controller, it shouldn’t run measurements. So t= he MA shouldn’t be starting up measurement tasks before that’s = been successful. I would suggest that rather than rely on an MA’s ability to remember suppression, a Controller would be expected to transmi= t any currently active suppression whenever an MA contacts it. If a Control= ler doesn’t indicate active suppression to a MA at any time when it i= s communicating with the MA, the MA can assume it is not suppressed.

    Barbara=

     <= /p>

    From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi
    Sent: Tuesday, February 18, 2014 8:45 AM
    To: philip.eardley@bt.com; STARK, BARBARA H; lmap@ietf.org
    Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on = draft-ietf-lmap-framework-03)

     

    Phil,

    One thing that is missing= is whether “suppress” is stateful. I believe that it should be= . One would not want to power cycle a device (intentional or power outage) and have the device return to executing measurement tasks.

     <= /p>

    I suggest adding another = bullet that :

    ·         A device in su= ppression must enter suppression mode after a power cycle.  

     

    Cheers,

    Sharam

     <= /p>

    From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
    Sent: Tuesday, February 18, 2014 3:48 AM
    To: bs7652@att.com; lmap@ietf.org
    Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on = draft-ietf-lmap-framework-03)

     

    Barbara,

    Thanks for the comments.

     

    With these two bullets I was poi= nting out the implications of the proposed way of not allowing overlapping = Tasks (don’t start, and never start, a (second) Task if a (first) Task is still on-going).

     

    On your second comment below, I = meant something on the lines of your last sentence: understanding the impac= t of one sort of traffic on another sort. I was just saying that such a test could still be achieved, but would have to be defined as = a single test rather than two. I agree this is quite complex – but so= me people have mentioned a test on these lines

     

    On your first bullet, I have som= e sympathy with this. It is a technical impact.

    Counter arguments are that it= 217;s not necessarily clear cut what’s a passive and what’s an = active Task, and that it adds some complexity to have to classify all tasks as active or passive and to tell the MA this. An active task misconfigured= as passive is nasty.

     

    Possible approaches are:

    -  &= nbsp;    Leave as original propos= al. No overlapping Tasks, therefore passive have to be run at a separate ti= me to active tasks

    -  &= nbsp;    Modify original proposal= , so the MA has a list of Tasks and runs through them one a time. DoesnR= 17;t affect the 2 bullets you mention

    -  &= nbsp;    Allow MA to do what it w= ants, ie start overlapping Tasks (but record this in the Results). Solves y= our 2 bullets, but also can have multiple overlapping active tasks

    -  &= nbsp;    Distinguish active and p= assive tasks. Keep original proposal for active tasks; passive tasks can be= run simultaneously.

     

    phil

     

    From: STARK, BARBARA H [mailto:bs7652@att.com]
    Sent: 17 February 2014 13:57
    To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
    Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-i= etf-lmap-framework-03)

     

    R= 26;           Rather than= running a Passive Measurement Task continuously in the background, instead= it is run when there are no other Tasks operating

    <bhs> I think this= one item in the proposal is problematic and I don’t see a need for i= t. Lots of devices are continually running passive measurements, and I don’t want them to have to turn these off to start an active measure= ment. I’m also completely at a loss as to what the harm is. For examp= le, in an RG, ADSL line statistics are always being captured, as are Ethern= et frames in/out and IP packets in/out. The firewall is logging various messages it sees (and I really don’t wan= t to turn that off in order to run an active measurement). There has also b= een the suggestion that the “responding” end of an active measu= rement task can simultaneously do passive measurements on the traffic of that active measurement task. IMO, these are 2 separate = tasks (though, given the next bullet, we may not have a common definition o= f Measurement Task, either). Anyway, unless the device is so incredibly pro= cessor- or memory-limited that it can’t collect passive measurements while doing active measurements (= a serious design flaw, IMO, which would make me question this device’= s ability to even accurately do a single active measurement task), I see no= reason to disable any passive measurements while other measurements are occurring. Multiple passive measurements can = also run simultaneously. Oh -- and measuring internal processor- and memory= -utilization during the running of measurement tasks is also a passive meas= urement task that I wouldn’t want to see disabled.

     = ;

    R= 26;           Rather than= testing for the impact of cross-traffic by having two Tasks that run simul= taneously, instead a single Task generates two types of traffic.=

    <bhs> This is the = point that makes me wonder if we’re using the same definition of R= 20;Task”. Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defined in a= way that allows it to generate all of the needed types of traffic. But the= Measurement Methods (and the Registry of Measurement Methods) are being de= fined external to lmap. This assumption would have the lmap framework imposing requirements on Measurement Methods= and the associated Registry in order to run certain tests. That makes me v= ery uneasy.

    I’m also not under= standing the proposed cross-traffic test, but maybe that’s beside the= point. I thought cross-traffic was something where we wanted to know whether or not there was any cross traffic present prior to starting certa= in Active Measurement Tasks, or during an Active Measurement Task (which BT= W would require something to do some passive measuring while the Active Mea= surement Task was happening). Understanding what sort of impact one type of traffic has on the simultaneous running of= another type of traffic, from the same MA, strikes me as a rather complex = thing to measure, and I’m not sure I want to do much design around th= at, right now.

    --_000_2D09D61DDFA73D4C884805CC7865E611303EA0CAGAALPA1MSGUSR9L_-- From nobody Tue Feb 18 08:40:52 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9AB1A0504 for ; Tue, 18 Feb 2014 08:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEPt-MMeRpIB for ; Tue, 18 Feb 2014 08:40:45 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id A4BBA1A06C5 for ; Tue, 18 Feb 2014 08:40:45 -0800 (PST) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 819971203CF; Tue, 18 Feb 2014 11:44:18 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-azure.research.att.com (Postfix) with ESMTP id A20F3E0277; Tue, 18 Feb 2014 11:40:42 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Tue, 18 Feb 2014 11:40:42 -0500 From: "MORTON, ALFRED C (AL)" To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" Date: Tue, 18 Feb 2014 11:40:41 -0500 Thread-Topic: determining passive vs. active nature of measurement task Thread-Index: Ac8su9uG/Z96xXmsRyqSwIjA7oRtQgAC0KHC Message-ID: <2845723087023D4CB5114223779FA9C8BC2BCF26@njfpsrvexg8.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E611303EA07C@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303EA07C@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/uCz7lScS_ix_LrK6oKTyBVYDWY0 Subject: Re: [lmap] determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:40:51 -0000 Hi Barbara, Briefly, there are Hybrid methods of measurement that combine techniques fr= om the purely active and passive ends of the continuum. One such method proposed is to tag user traffic with the usual info found i= n active measurement packets, like sequence numbers and/or timestamps. IPPM has seen proposals in the Hybrid class, and will like discuss one in L= ondon. hope this helps, Al=20 ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Tuesday, February 18, 2014 10:12 AM To: philip.eardley@bt.com; lmap@ietf.org Subject: [lmap] determining passive vs. active nature of measurement task ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Hi Phil, In the email below (I=92m replying using a different subject line for this)= , you made the following statement Counter arguments are that it=92s not necessarily clear cut what=92s a pass= ive and what=92s an active Task, and that it adds some complexity to have t= o classify all tasks as active or passive and to tell the MA this. An activ= e task misconfigured as passive is nasty. I=92ve been trying to get my head around this statement and have to say tha= t I really don=92t understand it. Is there really an intention for =93passive=94 vs. =93active=94 to be a con= figurable parameter of a Measurement Method or Measurement Task? If so, how= would that work? And is there really a set of Measurement Methods whose ac= tive/passive nature is ambiguous, unknown, or configurable (per the specifi= cation that defines the Measurement Method)? If so, I=92d like concrete exa= mples of such Measurement Methods so I can better understand. For example, let=92s look at a simple =93ping=94 (I=92m using =93ping=94 he= re to mean a client capability that initiates IPv4 ICMP echo). If a MA tell= s its Controller that it supports ping (I=92m hoping we consider this a pos= sible Measurement Method capability), and the Controller wants to configure= this, I wouldn=92t expect the Controller to be able to configure ping to r= un in passive mode. It is illogical for ping configuration parameters to in= clude such a configuration option (and I=92ve never seen an implementation = that includes such a configuration option). Furthermore, every ping impleme= ntation that I=92ve ever seen knows which of its configuration options are = mandatory and which are optional, and the correct syntax, in order for it t= o actually run. For example, it has to have a target IP address or URL. If = it is incorrectly configured, this generates an error condition. An implementation of a Measurement Method in a MA needs to be compliant wit= h whatever spec defines that Measurement Method, and needs to expose config= uration parameters consistent with its spec (and perhaps the Registry). If = we can=92t assume compliant Measurement Methods in a MA, then I think the s= cope of the problem we=92re trying to solve becomes too huge to solve in th= e timeframe we=92ve given ourselves. So hopefully we aren=92t trying to inc= lude non-compliant or ill-defined Measurement Method implementations in lma= p scope. Anyway, I look forward to learning about Measurement Methods that allow for= active/passive configuration and understanding why they are not resilient = when this parameter is configured in a manner inconsistent with the Method= =92s other configuration parameters (i.e., why the Measurement Method is no= t designed with internal configuration consistency checks). Barbara From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Tuesday, February 18, 2014 3:48 AM To: STARK, BARBARA H; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) Barbara, Thanks for the comments. With these two bullets I was pointing out the implications of the proposed = way of not allowing overlapping Tasks (don=92t start, and never start, a (s= econd) Task if a (first) Task is still on-going). On your second comment below, I meant something on the lines of your last s= entence: understanding the impact of one sort of traffic on another sort. I= was just saying that such a test could still be achieved, but would have t= o be defined as a single test rather than two. I agree this is quite comple= x =96 but some people have mentioned a test on these lines On your first bullet, I have some sympathy with this. It is a technical imp= act. Counter arguments are that it=92s not necessarily clear cut what=92s a pass= ive and what=92s an active Task, and that it adds some complexity to have t= o classify all tasks as active or passive and to tell the MA this. An activ= e task misconfigured as passive is nasty. Possible approaches are: - Leave as original proposal. No overlapping Tasks, therefore passive= have to be run at a separate time to active tasks - Modify original proposal, so the MA has a list of Tasks and runs th= rough them one a time. Doesn=92t affect the 2 bullets you mention - Allow MA to do what it wants, ie start overlapping Tasks (but recor= d this in the Results). Solves your 2 bullets, but also can have multiple o= verlapping active tasks - Distinguish active and passive tasks. Keep original proposal for ac= tive tasks; passive tasks can be run simultaneously. phil From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 February 2014 13:57 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) =95 Rather than running a Passive Measurement Task continuously i= n the background, instead it is run when there are no other Tasks operating I think this one item in the proposal is problematic and I don=92t se= e a need for it. Lots of devices are continually running passive measuremen= ts, and I don=92t want them to have to turn these off to start an active me= asurement. I=92m also completely at a loss as to what the harm is. For exam= ple, in an RG, ADSL line statistics are always being captured, as are Ether= net frames in/out and IP packets in/out. The firewall is logging various me= ssages it sees (and I really don=92t want to turn that off in order to run = an active measurement). There has also been the suggestion that the =93resp= onding=94 end of an active measurement task can simultaneously do passive m= easurements on the traffic of that active measurement task. IMO, these are = 2 separate tasks (though, given the next bullet, we may not have a common d= efinition of Measurement Task, either). Anyway, unless the device is so inc= redibly processor- or memory-limited that it can=92t collect passive measur= ements while doing active measurements (a serious design flaw, IMO, which w= ould make me question this device=92s ability to even accurately do a singl= e active measurement task), I see no reason to disable any passive measurem= ents while other measurements are occurring. Multiple passive measurements = can also run simultaneously. Oh -- and measuring internal processor- and me= mory-utilization during the running of measurement tasks is also a passive = measurement task that I wouldn=92t want to see disabled. =95 Rather than testing for the impact of cross-traffic by having= two Tasks that run simultaneously, instead a single Task generates two typ= es of traffic. This is the point that makes me wonder if we=92re using the same defi= nition of =93Task=94. Since Measurement Task is an instantiation of a Measu= rement Method, this would imply that the Measurement Method would have to b= e defined in a way that allows it to generate all of the needed types of tr= affic. But the Measurement Methods (and the Registry of Measurement Methods= ) are being defined external to lmap. This assumption would have the lmap f= ramework imposing requirements on Measurement Methods and the associated Re= gistry in order to run certain tests. That makes me very uneasy. I=92m also not understanding the proposed cross-traffic test, but maybe tha= t=92s beside the point. I thought cross-traffic was something where we want= ed to know whether or not there was any cross traffic present prior to star= ting certain Active Measurement Tasks, or during an Active Measurement Task= (which BTW would require something to do some passive measuring while the = Active Measurement Task was happening). Understanding what sort of impact o= ne type of traffic has on the simultaneous running of another type of traff= ic, from the same MA, strikes me as a rather complex thing to measure, and = I=92m not sure I want to do much design around that, right now. From nobody Tue Feb 18 08:57:22 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F0B1A04FF for ; Tue, 18 Feb 2014 08:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IedLdzJR1031 for ; Tue, 18 Feb 2014 08:57:11 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id CE5931A0228 for ; Tue, 18 Feb 2014 08:57:10 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 4e093035.2ac1020a2940.3511879.00-2455.9818286.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 18 Feb 2014 16:57:08 +0000 (UTC) X-MXL-Hash: 530390e4315d53c3-b3562c23b50fa98f41386321be267bfc66f3282e Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 9c093035.0.3511577.00-2379.9817421.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 18 Feb 2014 16:56:42 +0000 (UTC) X-MXL-Hash: 530390ca44d00382-8c8846543578dcf1fbdb24c8350dee9bd3e8b601 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IGudPJ015858; Tue, 18 Feb 2014 11:56:40 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IGuXQY015733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 11:56:38 -0500 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 18 Feb 2014 16:56:24 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 11:56:24 -0500 From: "STARK, BARBARA H" To: "MORTON JR., AL" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: determining passive vs. active nature of measurement task Thread-Index: Ac8su9uG/Z96xXmsRyqSwIjA7oRtQgAC0KHCAABOh8A= Date: Tue, 18 Feb 2014 16:56:23 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303EA227@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611303EA07C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC2BCF26@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC2BCF26@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.112.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=2VakHkCbVv0A:10 a=ofMgfj31e3cA:10 a=iEfvJiHnMjQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=3MO6qHia6N4A:10 a=re4_dVJID9Aj1hU95fIA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/fJdcYyBv0Eo7KiKvGHrt48HT54g Subject: Re: [lmap] determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:57:14 -0000 > Briefly, there are Hybrid methods of measurement that combine techniques > from the purely active and passive ends of the continuum. >=20 > One such method proposed is to tag user traffic with the usual info found= in > active measurement packets, like sequence numbers and/or timestamps. >=20 > IPPM has seen proposals in the Hybrid class, and will like discuss one in > London. >=20 > hope this helps, > Al But do implementations of these methods or the specifications describing th= ese methods allow for specific configuration of "active" and "passive", and= do they allow for active/passive to be configured in such a way that the m= ethod (or a specific task instance of the method) is misconfigured but some= how valid? Do we need to consider a configuration server that configures pa= rameters for one of these methods but doesn't understand the method suffici= ently to be able to configure those parameters correctly, as being a good a= nd compliant lmap Controller? Or are the specifications for these methods w= ritten in such a way that it is unclear how to configure them correctly, to= make them do what is desired of them? I'm not understanding the use case of a Controller that doesn't know what t= he Method it is configuring *is*, and how to configure it correctly. Barbara From nobody Tue Feb 18 09:23:46 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75621A06CF for ; Tue, 18 Feb 2014 09:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSsY2dDVZeOM for ; Tue, 18 Feb 2014 09:23:42 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id DAC131A06CD for ; Tue, 18 Feb 2014 09:23:41 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id EBD381201ED; Tue, 18 Feb 2014 12:27:14 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id 050FBEF691; Tue, 18 Feb 2014 12:23:39 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Tue, 18 Feb 2014 12:23:35 -0500 From: "MORTON, ALFRED C (AL)" To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" Date: Tue, 18 Feb 2014 12:23:28 -0500 Thread-Topic: determining passive vs. active nature of measurement task Thread-Index: Ac8su9uG/Z96xXmsRyqSwIjA7oRtQgAC0KHCAABOh8AAAM3Z4A== Message-ID: <2845723087023D4CB5114223779FA9C8BC2BCF27@njfpsrvexg8.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E611303EA07C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC2BCF26@njfpsrvexg8.research.att.com>, <2D09D61DDFA73D4C884805CC7865E611303EA227@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303EA227@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/DiQ-7UpkDdRKeWlbvIvWXWTIZ3g Subject: Re: [lmap] determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:23:44 -0000 It's fair to say that the Controller will know if the requested metric/meth= od is active or passive, IF we continue with a naming convention that includes th= is distinction in the name prefix . (In fact, this raises a possible issue in my mind with registry index numbe= rs. It's just something to check later, if may affect the Information model ins= tead.) But the future metrics/methods are not decided, and Hybrid metrics/methods could end-up in their own sub-registry, with a different name prefix, or no= t. So the problem is less about distinguishing active from passive, but that t= here=20 are more possibilities than these two and whether all Hybrid should be trea= ted as active when it comes to "Suppress", and what the Framework draft should= =20 say now when there are details like this to-be-decided. Al ________________________________________ From: STARK, BARBARA H Sent: Tuesday, February 18, 2014 11:56 AM To: MORTON, ALFRED C (AL); philip.eardley@bt.com; lmap@ietf.org Subject: RE: determining passive vs. active nature of measurement task > Briefly, there are Hybrid methods of measurement that combine techniques > from the purely active and passive ends of the continuum. > > One such method proposed is to tag user traffic with the usual info found= in > active measurement packets, like sequence numbers and/or timestamps. > > IPPM has seen proposals in the Hybrid class, and will like discuss one in > London. > > hope this helps, > Al But do implementations of these methods or the specifications describing th= ese methods allow for specific configuration of "active" and "passive", and= do they allow for active/passive to be configured in such a way that the m= ethod (or a specific task instance of the method) is misconfigured but some= how valid? Do we need to consider a configuration server that configures pa= rameters for one of these methods but doesn't understand the method suffici= ently to be able to configure those parameters correctly, as being a good a= nd compliant lmap Controller? Or are the specifications for these methods w= ritten in such a way that it is unclear how to configure them correctly, to= make them do what is desired of them? I'm not understanding the use case of a Controller that doesn't know what t= he Method it is configuring *is*, and how to configure it correctly. Barbara From nobody Tue Feb 18 10:09:01 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADA61A06D6 for ; Tue, 18 Feb 2014 10:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NttC07a2HvqT for ; Tue, 18 Feb 2014 10:08:52 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 357571A06E6 for ; Tue, 18 Feb 2014 10:08:49 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Feb 2014 13:08:46 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Feb 2014 13:08:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF2CD4.76243C09" Date: Tue, 18 Feb 2014 13:09:35 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B239F7@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8rzrCvkcTcIZKMQ229p7E8McN/qwAFeghAACgGvJAACnB0gAADfbZAAAWy+rA= References: <2D09D61DDFA73D4C884805CC7865E611303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23959@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303EA0CA@GAALPA1MSGUSR9L.ITServices.sbc.com> From: "Sharam Hakimi" To: "STARK, BARBARA H" , , X-OriginalArrivalTime: 18 Feb 2014 18:08:45.0133 (UTC) FILETIME=[7696FFD0:01CF2CD4] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/K-EPKwzYeYGqJyP5v60Sbl78Icc Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:08:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF2CD4.76243C09 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable My intention was the MA inside a device, but a device is reset not he MA so it is a catch 22. The reason I am suggesting to have suppression to be stateful is for the that you mentioned. If a MA in a device is pre configured and will power-up and starts running tests without having to check with the MC, that would be a problem. If a device, pre configured or not, must check with the MC before it starts running tests, then the MC could either send a 'no task' to the MA or send a suppression message to the MA during a suppression period. =20 Sharam=20 =20 From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Tuesday, February 18, 2014 10:45 AM To: Sharam Hakimi; philip.eardley@bt.com; lmap@ietf.org Subject: RE: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) =20 This suggestion is attempting to impose requirements on the device where the MA is. I think that's problematic. But perhaps you meant MA instead of device? =20 If survivability of suppression is so important, I'm not sure this is the best way to ensure it. I could envision a MA that is factory-configured to run a set of basic measurement tasks. If reset to factory configuration, it will go back to doing those (and suppression will be lost) in the absence of updated configuration (Instructions) from the Controller. I could also envision a case where the suppression message was sent while a MA was powered down. =20 On the other hand, I would expect that one of the very first things a MA does on boot is contact its Controller. The MA should never assume that its configuration is current after a power cycle. We've said (I think) that if a MA can't talk to its Controller, it shouldn't run measurements. So the MA shouldn't be starting up measurement tasks before that's been successful. I would suggest that rather than rely on an MA's ability to remember suppression, a Controller would be expected to transmit any currently active suppression whenever an MA contacts it. If a Controller doesn't indicate active suppression to a MA at any time when it is communicating with the MA, the MA can assume it is not suppressed.=20 Barbara =20 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi Sent: Tuesday, February 18, 2014 8:45 AM To: philip.eardley@bt.com; STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) =20 Phil, One thing that is missing is whether "suppress" is stateful. I believe that it should be. One would not want to power cycle a device (intentional or power outage) and have the device return to executing measurement tasks. =20 I suggest adding another bullet that : * A device in suppression must enter suppression mode after a power cycle. =20 =20 Cheers, Sharam =20 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Tuesday, February 18, 2014 3:48 AM To: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) =20 Barbara, Thanks for the comments. =20 With these two bullets I was pointing out the implications of the proposed way of not allowing overlapping Tasks (don't start, and never start, a (second) Task if a (first) Task is still on-going).=20 =20 On your second comment below, I meant something on the lines of your last sentence: understanding the impact of one sort of traffic on another sort. I was just saying that such a test could still be achieved, but would have to be defined as a single test rather than two. I agree this is quite complex - but some people have mentioned a test on these lines=20 =20 On your first bullet, I have some sympathy with this. It is a technical impact. Counter arguments are that it's not necessarily clear cut what's a passive and what's an active Task, and that it adds some complexity to have to classify all tasks as active or passive and to tell the MA this. An active task misconfigured as passive is nasty. =20 Possible approaches are: - Leave as original proposal. No overlapping Tasks, therefore passive have to be run at a separate time to active tasks - Modify original proposal, so the MA has a list of Tasks and runs through them one a time. Doesn't affect the 2 bullets you mention - Allow MA to do what it wants, ie start overlapping Tasks (but record this in the Results). Solves your 2 bullets, but also can have multiple overlapping active tasks - Distinguish active and passive tasks. Keep original proposal for active tasks; passive tasks can be run simultaneously. =20 phil =20 From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: 17 February 2014 13:57 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) =20 * Rather than running a Passive Measurement Task continuously in the background, instead it is run when there are no other Tasks operating I think this one item in the proposal is problematic and I don't see a need for it. Lots of devices are continually running passive measurements, and I don't want them to have to turn these off to start an active measurement. I'm also completely at a loss as to what the harm is. For example, in an RG, ADSL line statistics are always being captured, as are Ethernet frames in/out and IP packets in/out. The firewall is logging various messages it sees (and I really don't want to turn that off in order to run an active measurement). There has also been the suggestion that the "responding" end of an active measurement task can simultaneously do passive measurements on the traffic of that active measurement task. IMO, these are 2 separate tasks (though, given the next bullet, we may not have a common definition of Measurement Task, either). Anyway, unless the device is so incredibly processor- or memory-limited that it can't collect passive measurements while doing active measurements (a serious design flaw, IMO, which would make me question this device's ability to even accurately do a single active measurement task), I see no reason to disable any passive measurements while other measurements are occurring. Multiple passive measurements can also run simultaneously. Oh -- and measuring internal processor- and memory-utilization during the running of measurement tasks is also a passive measurement task that I wouldn't want to see disabled. =20 * Rather than testing for the impact of cross-traffic by having two Tasks that run simultaneously, instead a single Task generates two types of traffic. This is the point that makes me wonder if we're using the same definition of "Task". Since Measurement Task is an instantiation of a Measurement Method, this would imply that the Measurement Method would have to be defined in a way that allows it to generate all of the needed types of traffic. But the Measurement Methods (and the Registry of Measurement Methods) are being defined external to lmap. This assumption would have the lmap framework imposing requirements on Measurement Methods and the associated Registry in order to run certain tests. That makes me very uneasy. I'm also not understanding the proposed cross-traffic test, but maybe that's beside the point. I thought cross-traffic was something where we wanted to know whether or not there was any cross traffic present prior to starting certain Active Measurement Tasks, or during an Active Measurement Task (which BTW would require something to do some passive measuring while the Active Measurement Task was happening). Understanding what sort of impact one type of traffic has on the simultaneous running of another type of traffic, from the same MA, strikes me as a rather complex thing to measure, and I'm not sure I want to do much design around that, right now. ------_=_NextPart_001_01CF2CD4.76243C09 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    My intention was the MA inside a device, but a device is = reset not he MA so it is a catch 22. The reason I am suggesting to have = suppression to be stateful is for the that you mentioned. If a MA in a device is pre configured and will power-up and starts running tests without having to = check with the MC, that would be a problem. If a device, pre configured or = not, must check with the MC before it starts running tests, then the MC could = either send a ‘no task’ to the MA or send a suppression message to the = MA during a suppression period.

     

    Sharam

     

    From: STARK, BARBARA H [mailto:bs7652@att.com]
    Sent: Tuesday, February 18, 2014 10:45 AM
    To: Sharam Hakimi; philip.eardley@bt.com; lmap@ietf.org
    Subject: RE: [lmap] Overlapping Measurement Tasks (WGLC comments = on draft-ietf-lmap-framework-03)

     

    This suggestion is attempting to impose requirements on = the device where the MA is. I think that’s problematic. But perhaps = you meant MA instead of device?

     

    If survivability of suppression is so important, = I’m not sure this is the best way to ensure it. I could envision a MA that is factory-configured to run a set of basic measurement tasks. If reset to = factory configuration, it will go back to doing those (and suppression will be = lost) in the absence of updated configuration (Instructions) from the Controller. = I could also envision a case where the suppression message was sent while = a MA was powered down.

     

    On the other hand, I would expect that one of the very = first things a MA does on boot is contact its Controller. The MA should never = assume that its configuration is current after a power cycle. We’ve said = (I think) that if a MA can’t talk to its Controller, it = shouldn’t run measurements. So the MA shouldn’t be starting up measurement tasks = before that’s been successful. I would suggest that rather than rely on = an MA’s ability to remember suppression, a Controller would be = expected to transmit any currently active suppression whenever an MA contacts it. If = a Controller doesn’t indicate active suppression to a MA at any time = when it is communicating with the MA, the MA can assume it is not suppressed. =

    Barbara

     

    From: lmap = [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi
    Sent: Tuesday, February 18, 2014 8:45 AM
    To: philip.eardley@bt.com; STARK, BARBARA H; lmap@ietf.org
    Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments = on draft-ietf-lmap-framework-03)

     

    Phil,

    One thing that is missing is whether = “suppress” is stateful. I believe that it should be. One would not want to power cycle = a device (intentional or power outage) and have the device return to = executing measurement tasks.

     

    I suggest adding another bullet that = :

    ·         A device in = suppression must enter suppression mode after a power cycle. =  

     

    Cheers,

    Sharam

     

    From: lmap [mailto:lmap-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com
    Sent: Tuesday, February 18, 2014 3:48 AM
    To: bs7652@att.com; lmap@ietf.org
    Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments = on draft-ietf-lmap-framework-03)

     

    Barbara,

    Thanks for the comments.

     

    With these two bullets I was pointing out the implications = of the proposed way of not allowing overlapping Tasks (don’t start, and = never start, a (second) Task if a (first) Task is still on-going). =

     

    On your second comment below, I meant something on the lines = of your last sentence: understanding the impact of one sort of traffic on = another sort. I was just saying that such a test could still be achieved, but = would have to be defined as a single test rather than two. I agree this is = quite complex – but some people have mentioned a test on these lines =

     

    On your first bullet, I have some sympathy with this. It is = a technical impact.

    Counter arguments are that it’s not necessarily clear = cut what’s a passive and what’s an active Task, and that it adds = some complexity to have to classify all tasks as active or passive and to = tell the MA this. An active task misconfigured as passive is = nasty.

     

    Possible approaches are:

    -       Leave as original proposal. No overlapping Tasks, therefore = passive have to be run at a separate time to active tasks

    -       Modify original proposal, so the MA has a list of Tasks and = runs through them one a time. Doesn’t affect the 2 bullets you = mention

    -       Allow MA to do what it wants, ie start overlapping Tasks = (but record this in the Results). Solves your 2 bullets, but also can have = multiple overlapping active tasks

    -       Distinguish active and passive tasks. Keep original proposal = for active tasks; passive tasks can be run = simultaneously.

     

    phil

     

    From: STARK, BARBARA H [mailto:bs7652@att.com]
    Sent: 17 February 2014 13:57
    To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
    Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03)

     

    •      &nb= sp;    Rather than running a Passive Measurement Task continuously in the = background, instead it is run when there are no other Tasks = operating

    <bhs> I think this one item in the proposal is problematic and I don’t see a need for it. Lots of devices are continually running passive measurements, and I don’t want them to = have to turn these off to start an active measurement. I’m also = completely at a loss as to what the harm is. For example, in an RG, ADSL line = statistics are always being captured, as are Ethernet frames in/out and IP packets = in/out. The firewall is logging various messages it sees (and I really don’t = want to turn that off in order to run an active measurement). There has also = been the suggestion that the “responding” end of an active = measurement task can simultaneously do passive measurements on the traffic of that active measurement task. IMO, these are 2 separate tasks (though, given the = next bullet, we may not have a common definition of Measurement Task, = either). Anyway, unless the device is so incredibly processor- or memory-limited = that it can’t collect passive measurements while doing active measurements = (a serious design flaw, IMO, which would make me question this = device’s ability to even accurately do a single active measurement task), I see = no reason to disable any passive measurements while other measurements are occurring. Multiple passive measurements can also run simultaneously. Oh = -- and measuring internal processor- and memory-utilization during the running = of measurement tasks is also a passive measurement task that I wouldn’t want to = see disabled.

     

    •      &nb= sp;    Rather than testing for the impact of cross-traffic by having two Tasks = that run simultaneously, instead a single Task generates two types of = traffic.

    <bhs> This is the point that makes me wonder if we’re using the same definition of “Task”. Since = Measurement Task is an instantiation of a Measurement Method, this would imply that = the Measurement Method would have to be defined in a way that allows it to = generate all of the needed types of traffic. But the Measurement Methods (and the Registry of Measurement Methods) are being defined external to lmap. = This assumption would have the lmap framework imposing requirements on = Measurement Methods and the associated Registry in order to run certain tests. That = makes me very uneasy.

    I’m also not understanding the proposed = cross-traffic test, but maybe that’s beside the point. I thought cross-traffic = was something where we wanted to know whether or not there was any cross = traffic present prior to starting certain Active Measurement Tasks, or during an = Active Measurement Task (which BTW would require something to do some passive measuring while the Active Measurement Task was happening). = Understanding what sort of impact one type of traffic has on the simultaneous running of = another type of traffic, from the same MA, strikes me as a rather complex thing = to measure, and I’m not sure I want to do much design around that, = right now.

    ------_=_NextPart_001_01CF2CD4.76243C09-- From nobody Tue Feb 18 10:22:38 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4233A1A04FC for ; Tue, 18 Feb 2014 10:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4V5zDEag_xe for ; Tue, 18 Feb 2014 10:22:28 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1911A0408 for ; Tue, 18 Feb 2014 10:22:26 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 18 Feb 2014 18:22:06 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Tue, 18 Feb 2014 18:22:22 +0000 From: To: , , Date: Tue, 18 Feb 2014 18:22:20 +0000 Thread-Topic: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8rzrCvkcTcIZKMQ229p7E8McN/qwAFeghAACgGvJAACnB0gAADfbZAAAZsdxA= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303E9446@GAALPA1MSGUSR9L.ITServices.sbc.com> <084CDC75FEC1E640B60338273BEACDFA02B23959@spboexc01.exfo.com> <2D09D61DDFA73D4C884805CC7865E611303EA0CA@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303EA0CA@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABF2A4EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/L_9vaf9tQpqMIfYuobIe53fo7ng Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:22:37 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABF2A4EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This sounds sensible to me ie after a re-boot ask Controller to re-send Ins= truction. I know there's a bit about re-boot in the framework, will check w= hat it says and update Thanks phil From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 18 February 2014 15:45 To: Sharam Hakimi; Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-i= etf-lmap-framework-03) This suggestion is attempting to impose requirements on the device where th= e MA is. I think that's problematic. But perhaps you meant MA instead of de= vice? If survivability of suppression is so important, I'm not sure this is the b= est way to ensure it. I could envision a MA that is factory-configured to r= un a set of basic measurement tasks. If reset to factory configuration, it = will go back to doing those (and suppression will be lost) in the absence o= f updated configuration (Instructions) from the Controller. I could also en= vision a case where the suppression message was sent while a MA was powered= down. On the other hand, I would expect that one of the very first things a MA do= es on boot is contact its Controller. The MA should never assume that its c= onfiguration is current after a power cycle. We've said (I think) that if a= MA can't talk to its Controller, it shouldn't run measurements. So the MA = shouldn't be starting up measurement tasks before that's been successful. I= would suggest that rather than rely on an MA's ability to remember suppres= sion, a Controller would be expected to transmit any currently active suppr= ession whenever an MA contacts it. If a Controller doesn't indicate active = suppression to a MA at any time when it is communicating with the MA, the M= A can assume it is not suppressed. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi Sent: Tuesday, February 18, 2014 8:45 AM To: philip.eardley@bt.com; STARK, BARBARA H; = lmap@ietf.org Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-i= etf-lmap-framework-03) Phil, One thing that is missing is whether "suppress" is stateful. I believe that= it should be. One would not want to power cycle a device (intentional or p= ower outage) and have the device return to executing measurement tasks. I suggest adding another bullet that : * A device in suppression must enter suppression mode after a power= cycle. Cheers, Sharam From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Tuesday, February 18, 2014 3:48 AM To: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] Overlapping Measurement Tasks (WGLC comments on draft-i= etf-lmap-framework-03) Barbara, Thanks for the comments. With these two bullets I was pointing out the implications of the proposed = way of not allowing overlapping Tasks (don't start, and never start, a (sec= ond) Task if a (first) Task is still on-going). On your second comment below, I meant something on the lines of your last s= entence: understanding the impact of one sort of traffic on another sort. I= was just saying that such a test could still be achieved, but would have t= o be defined as a single test rather than two. I agree this is quite comple= x - but some people have mentioned a test on these lines On your first bullet, I have some sympathy with this. It is a technical imp= act. Counter arguments are that it's not necessarily clear cut what's a passive = and what's an active Task, and that it adds some complexity to have to clas= sify all tasks as active or passive and to tell the MA this. An active task= misconfigured as passive is nasty. Possible approaches are: - Leave as original proposal. No overlapping Tasks, therefore passive= have to be run at a separate time to active tasks - Modify original proposal, so the MA has a list of Tasks and runs th= rough them one a time. Doesn't affect the 2 bullets you mention - Allow MA to do what it wants, ie start overlapping Tasks (but recor= d this in the Results). Solves your 2 bullets, but also can have multiple o= verlapping active tasks - Distinguish active and passive tasks. Keep original proposal for ac= tive tasks; passive tasks can be run simultaneously. phil From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 17 February 2014 13:57 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-ietf-lma= p-framework-03) * Rather than running a Passive Measurement Task continuously in = the background, instead it is run when there are no other Tasks operating I think this one item in the proposal is problematic and I don't see = a need for it. Lots of devices are continually running passive measurements= , and I don't want them to have to turn these off to start an active measur= ement. I'm also completely at a loss as to what the harm is. For example, i= n an RG, ADSL line statistics are always being captured, as are Ethernet fr= ames in/out and IP packets in/out. The firewall is logging various messages= it sees (and I really don't want to turn that off in order to run an activ= e measurement). There has also been the suggestion that the "responding" en= d of an active measurement task can simultaneously do passive measurements = on the traffic of that active measurement task. IMO, these are 2 separate t= asks (though, given the next bullet, we may not have a common definition of= Measurement Task, either). Anyway, unless the device is so incredibly proc= essor- or memory-limited that it can't collect passive measurements while d= oing active measurements (a serious design flaw, IMO, which would make me q= uestion this device's ability to even accurately do a single active measure= ment task), I see no reason to disable any passive measurements while other= measurements are occurring. Multiple passive measurements can also run sim= ultaneously. Oh -- and measuring internal processor- and memory-utilization= during the running of measurement tasks is also a passive measurement task= that I wouldn't want to see disabled. * Rather than testing for the impact of cross-traffic by having t= wo Tasks that run simultaneously, instead a single Task generates two types= of traffic. This is the point that makes me wonder if we're using the same defini= tion of "Task". Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defi= ned in a way that allows it to generate all of the needed types of traffic.= But the Measurement Methods (and the Registry of Measurement Methods) are = being defined external to lmap. This assumption would have the lmap framewo= rk imposing requirements on Measurement Methods and the associated Registry= in order to run certain tests. That makes me very uneasy. I'm also not understanding the proposed cross-traffic test, but maybe that'= s beside the point. I thought cross-traffic was something where we wanted t= o know whether or not there was any cross traffic present prior to starting= certain Active Measurement Tasks, or during an Active Measurement Task (wh= ich BTW would require something to do some passive measuring while the Acti= ve Measurement Task was happening). Understanding what sort of impact one t= ype of traffic has on the simultaneous running of another type of traffic, = from the same MA, strikes me as a rather complex thing to measure, and I'm = not sure I want to do much design around that, right now. --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABF2A4EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    = This sounds sen= sible to me ie after a re-boot ask Controller to re-send Instruction. I kno= w there’s a bit about re-boot in the framework, will check what it sa= ys and update

     

    = Thanks

    phil

    &nbs= p;

    From: STARK, BARBARA H [mailto= :bs7652@att.com]
    Sent: 18 February 2014 15:45
    To: Shar= am Hakimi; Eardley,PL,Philip,TUB8 R; lmap@ietf.org
    Subject: RE: [= lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-frame= work-03)

     <= /o:p>

    This suggestion is attemp= ting to impose requirements on the device where the MA is. I think thatR= 17;s problematic. But perhaps you meant MA instead of device?

     

    If survivability of suppression = is so important, I’m not sure this is the best way to ensure it. I co= uld envision a MA that is factory-configured to run a set of basic measurem= ent tasks. If reset to factory configuration, it will go back to doing thos= e (and suppression will be lost) in the absence of updated configuration (I= nstructions) from the Controller. I could also envision a case where the su= ppression message was sent while a MA was powered down.

     

    On the other hand, I would expect that= one of the very first things a MA does on boot is contact its Controller. = The MA should never assume that its configuration is current after a power = cycle. We’ve said (I think) that if a MA can’t talk to its Cont= roller, it shouldn’t run measurements. So the MA shouldn’t be s= tarting up measurement tasks before that’s been successful. I would s= uggest that rather than rely on an MA’s ability to remember suppressi= on, a Controller would be expected to transmit any currently active suppres= sion whenever an MA contacts it. If a Controller doesn’t indicate act= ive suppression to a MA at any time when it is communicating with the MA, t= he MA can assume it is not suppressed.

    Barbara

     

    From: lmap [mailto:lmap-bounces@ie= tf.org] On Behalf Of Sharam Hakimi
    Sent: Tuesday, Febr= uary 18, 2014 8:45 AM
    To: philip.eardley@bt.com; STARK, BARBARA H; lmap@ietf.org
    Subject: Re: [lmap] Overlapping Measuremen= t Tasks (WGLC comments on draft-ietf-lmap-framework-03)

     

    Phil,

    =

    One thing that is missing is wheth= er “suppress” is stateful. I believe that it should be. One wou= ld not want to power cycle a device (intentional or power outage) and have = the device return to executing measurement tasks.

     

    I suggest adding another bullet that :

    ·  =        A device in suppression must enter supp= ression mode after a power cycle.  

     

    Cheers,=

    Sharam

     

    From: lmap [mailto:lmap-bou= nces@ietf.org] On Behalf Of philip.eardley@bt.com
    Sent: Tuesday, February 18, 2014 3= :48 AM
    To: bs7652@att.com; = lmap@ietf.org
    Subject: Re: [= lmap] Overlapping Measurement Tasks (WGLC comments on draft-ietf-lmap-frame= work-03)

     

    Barbara,

    Thanks for the comments.

     

    With these two bullets I was pointing out the implications o= f the proposed way of not allowing overlapping Tasks (don’t start, an= d never start, a (second) Task if a (first) Task is still on-going). <= /o:p>

     

    On your second comm= ent below, I meant something on the lines of your last sentence: understand= ing the impact of one sort of traffic on another sort. I was just saying th= at such a test could still be achieved, but would have to be defined as a s= ingle test rather than two. I agree this is quite complex – but some = people have mentioned a test on these lines

     

    On your first bullet, I have some sympathy = with this. It is a technical impact.

    Counter arg= uments are that it’s not necessarily clear cut what’s a passive= and what’s an active Task, and that it adds some complexity to have = to classify all tasks as active or passive and to tell the MA this. An acti= ve task misconfigured as passive is nasty.

    =  

    Possible approaches are:

    =

    -       <= ![endif]>Leave = as original proposal. No overlapping Tasks, therefore passive have to be ru= n at a separate time to active tasks

    -&= nbsp;      Modify original proposa= l, so the MA has a list of Tasks and runs through them one a time. Doesn= 217;t affect the 2 bullets you mention

    -       Allow MA to do what i= t wants, ie start overlapping Tasks (but record this in the Results). Solve= s your 2 bullets, but also can have multiple overlapping active tasks<= /o:p>

    -       Distinguish active and passive tasks. Keep original proposal fo= r active tasks; passive tasks can be run simultaneously.<= /p>

     

    = phil

     

    =

    From: STARK, BARBARA H [mailto:bs7652= @att.com]
    Sent: 17 February 2014 13:57
    To: Eardley= ,PL,Philip,TUB8 R; lmap@ietf.org
    Subject: RE: Overlapping Measurement Tasks (WGLC comments on draft-iet= f-lmap-framework-03)

    =  

    = •           Rather = than running a Passive Measurement Task continuously in the background, ins= tead it is run when there are no other Tasks operating

    <bhs> I think this one item in the proposal is problem= atic and I don’t see a need for it. Lots of devices are continually r= unning passive measurements, and I don’t want them to have to turn th= ese off to start an active measurement. I’m also completely at a loss= as to what the harm is. For example, in an RG, ADSL line statistics are al= ways being captured, as are Ethernet frames in/out and IP packets in/out. T= he firewall is logging various messages it sees (and I really don’t w= ant to turn that off in order to run an active measurement). There has also= been the suggestion that the “responding” end of an active mea= surement task can simultaneously do passive measurements on the traffic of = that active measurement task. IMO, these are 2 separate tasks (though, give= n the next bullet, we may not have a common definition of Measurement Task,= either). Anyway, unless the device is so incredibly processor- or memory-l= imited that it can’t collect passive measurements while doing active = measurements (a serious design flaw, IMO, which would make me question this= device’s ability to even accurately do a single active measurement t= ask), I see no reason to disable any passive measurements while other measu= rements are occurring. Multiple passive measurements can also run simultane= ously. Oh -- and measuring internal processor- and memory-utilization durin= g the running of measurement tasks is also a passive measurement task that = I wouldn’t want to see disabled.

     

    •       &nbs= p;   Rather than testing for the impact of cross-traffic by havin= g two Tasks that run simultaneously, instead a single Task generates two ty= pes of traffic.

    <bhs> This is the = point that makes me wonder if we’re using the same definition of R= 20;Task”. Since Measurement Task is an instantiation of a Measurement= Method, this would imply that the Measurement Method would have to be defi= ned in a way that allows it to generate all of the needed types of traffic.= But the Measurement Methods (and the Registry of Measurement Methods) are = being defined external to lmap. This assumption would have the lmap framewo= rk imposing requirements on Measurement Methods and the associated Registry= in order to run certain tests. That makes me very uneasy.

    I’m also not understanding the proposed cross-traf= fic test, but maybe that’s beside the point. I thought cross-traffic = was something where we wanted to know whether or not there was any cross tr= affic present prior to starting certain Active Measurement Tasks, or during= an Active Measurement Task (which BTW would require something to do some p= assive measuring while the Active Measurement Task was happening). Understa= nding what sort of impact one type of traffic has on the simultaneous runni= ng of another type of traffic, from the same MA, strikes me as a rather com= plex thing to measure, and I’m not sure I want to do much design arou= nd that, right now.

    = --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABF2A4EMV67UKRDdoma_-- From nobody Tue Feb 18 11:17:56 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0407C1A03ED for ; Tue, 18 Feb 2014 11:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A2MzHWB5cqx for ; Tue, 18 Feb 2014 11:17:52 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 19DCF1A0150 for ; Tue, 18 Feb 2014 11:17:51 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id dd1b3035.2ac0aee1d940.3609595.00-2471.10098723.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 18 Feb 2014 19:17:49 +0000 (UTC) X-MXL-Hash: 5303b1dd0c5349f8-12f68ca2d1d7fbff5241e63661c1561f73a0719b Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 7c1b3035.0.3609323.00-2392.10097894.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 18 Feb 2014 19:17:28 +0000 (UTC) X-MXL-Hash: 5303b1c805ed3b62-b23e53a36e8d3d319d9362299de2683d1b97196f Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IJHQot019668; Tue, 18 Feb 2014 14:17:27 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IJHLE5019583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 14:17:22 -0500 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 18 Feb 2014 19:17:08 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 14:17:08 -0500 From: "STARK, BARBARA H" To: "MORTON JR., AL" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: determining passive vs. active nature of measurement task Thread-Index: Ac8su9uG/Z96xXmsRyqSwIjA7oRtQgAC0KHCAABOh8AAAM3Z4AADExGg Date: Tue, 18 Feb 2014 19:17:08 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303EA663@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611303EA07C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC2BCF26@njfpsrvexg8.research.att.com>, <2D09D61DDFA73D4C884805CC7865E611303EA227@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC2BCF27@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC2BCF27@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.112.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=2VakHkCbVv0A:10 a=ofMgfj31e3cA:10 a=iEfvJiHnMjQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=3MO6qHia6N4A:10 a=9FXybcTdQxs87k3_LMIA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=inhitZloKXCA1vai:21 a=6qv7tPbLY_4fN6W_:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/l_94RLXrC-yi6M7PJqYFIAnra7A Subject: Re: [lmap] determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:17:54 -0000 So here is a suggestion regarding whether or not suppression applies to pas= sive measurements, that I think would provide flexibility. Suppression ensures no IP packets related to Measurement Tasks are sent out= any IP interface. Suppression MAY impact the operation of internal MA proc= esses as well (e.g., passive Measurement Tasks). This implies it cannot be assumed whether or not passive measurements (or s= ubset of passive measurements) will or won't be impacted by suppression. If the Controller's entity happens to know (a priori, and not per the Infor= mation Model -- e.g., this entity developed, specified, or is otherwise ful= ly familiar with the design of the specific MA) that the MA will or won't i= mpact passive measurements (or certain passive measurements), then this ent= ity can have its Controller issue suppression commands with this knowledge = in mind. If an MA's behavior is unknown, and it's desired to ensure passive measurem= ents are untouched, then the entity's Controller will need to provide a spe= cific list of Measurement Tasks/Schedules/Methods for suppression to apply = to. If an MA's behavior is unknown, and it's desired to ensure passive measurem= ents are stopped or reports do not get generated, then the entity's Control= ler will need to explicitly stop those passive measurements or disable repo= rt channels. This allows flexibility in MA design (e.g., if a service provider in the UK= wants MAs to disable all measurements in reaction to suppression, they can= specify their MAs to do that; and if a service provider in the US wants th= eir MAs not to disable passive measurements in reaction to suppression, the= y can specify their MAs to do that), while ensuring the stated suppression = goal of stopping Measurement Task traffic in the network is accomplished. Barbara From nobody Tue Feb 18 11:49:42 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6AA1A04F2 for ; Tue, 18 Feb 2014 11:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIj5dfjAQQOi for ; Tue, 18 Feb 2014 11:49:38 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id BB4941A0221 for ; Tue, 18 Feb 2014 11:49:37 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6EDBCFC3; Tue, 18 Feb 2014 20:49:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kW4U4R22bBon; Tue, 18 Feb 2014 20:49:32 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Tue, 18 Feb 2014 20:49:32 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A038620026; Tue, 18 Feb 2014 20:49:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lv5U_jWDGp7x; Tue, 18 Feb 2014 20:49:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2037920015; Tue, 18 Feb 2014 20:49:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D7D0B2B58557; Tue, 18 Feb 2014 20:49:30 +0100 (CET) Date: Tue, 18 Feb 2014 20:49:30 +0100 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20140218194930.GA2976@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E611303EA07C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC2BCF26@njfpsrvexg8.research.att.com> <2D09D61DDFA73D4C884805CC7865E611303EA227@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC2BCF27@njfpsrvexg8.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2845723087023D4CB5114223779FA9C8BC2BCF27@njfpsrvexg8.research.att.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/5yuVv8n9CQQsXwXlXRdPWUjETc8 Cc: "philip.eardley@bt.com" , "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:49:40 -0000 On Tue, Feb 18, 2014 at 12:23:28PM -0500, MORTON, ALFRED C (AL) wrote: > > But the future metrics/methods are not decided, and Hybrid metrics/methods > could end-up in their own sub-registry, with a different name prefix, or not. > > So the problem is less about distinguishing active from passive, but that there > are more possibilities than these two and whether all Hybrid should be treated > as active when it comes to "Suppress", and what the Framework draft should > say now when there are details like this to-be-decided. > I vote for thinking about any mechanisms needed to deal with overlapping measurement tasks and to stay away from hard coding any policy. There may be valid reasons for overlapping active measurements, there may be valid reasons for enforcing non-overlapping passive measurements. Lets focus on the mechanism and leave it to deployments to configure a policy that makes sense. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Feb 19 09:36:08 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688BE1A0510 for ; Wed, 19 Feb 2014 09:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZcSAENRJMgY for ; Wed, 19 Feb 2014 09:36:03 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id D17C81A01CE for ; Wed, 19 Feb 2014 09:36:02 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 19 Feb 2014 17:34:43 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Wed, 19 Feb 2014 17:35:15 +0000 From: To: Date: Wed, 19 Feb 2014 17:35:14 +0000 Thread-Topic: Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8tlhV3TNdpUpq+Qpm+Dna82yWzGQ== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAB3FA79EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/nSYezWMcPOxgXWEg14dZFFTYdoA Subject: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:36:07 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAB3FA79EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One issue that was raised by Jason is that it may be good to include 'servi= ce parameters' in the Report - I presume this is things like the subscribed= rate and type of access). Currently we say in S5.4 <> I propose we add another bullet o the MA also includes the Subscribed service parameters, such as the s= ubscribed rate and type of access, if inclusion of such information has bee= n configured for the Report Channel and is known by the MA this would imply that we should include something in the Instruction - I th= ink as part of the configuration of each Report Channel: * a configuration option that the MA includes information about any = Subscribed service parameters that it knows (by default, not included) I'm assuming that this will just be a free list of service parameters, ie t= he information model doesn't have to worry about defining the details (perh= aps the information model should say something about it being a list of nam= e-value pairs? For instance "subscribed rate: 80 Mbs up 20 Mbs down ; acce= ss type : FTTC") What do you reckon? thanks phil -- Original comment from Jason: << 2) Reporting of Service Parameters by MA if available The Charter includes this sentence on the topic of Service Parameters: "How= ever, if the service parameters are available to the MAs, they could be rep= orted with the measurement results in the Report Protocol" Discovery of Service Parameters is out of scope per the Charter, but I beli= eve there has been some discussion on the list that if the MA has the infor= mation it may be included in the Reporting Protocol. It is stated as a 'cou= ld' but I think it would be useful to state this somewhere in the discussio= n of the Report Protocol. There currently is this bullet which seems to imp= ly that only the Results are to be delivered to the collector and not the S= ervice Parameters but I may be reading too much into this bullet: o a Report Protocol, which delivers a Report from the MA to a Collector. The Report contains the Measurement Results. >> --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAB3FA79EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    One issue that was r= aised by Jason is that it may be good to include ‘service parameters&= #8217; in the Report – I presume this is things like the subscribed r= ate and type of access).

     =

    Currently we say in S5.4

    <<The primary purpose of the Report Protocol is= to allow a Measurement

       = Agent to report its Measurement Results to a Collector, and the<= /span>

       context in which they were obtained= .

    …

       The Report contains:

     

       o  = the MA-ID or a Group-ID (to anonymise results)

     

       o = the actual Measurement Results, including the time they were

          measured=

     

    &n= bsp;  o  the details of the Measurement Task (to avoid the Collec= tor having

        &n= bsp; to ask the Controller for this information later)

    >> 

    = I pr= opose we add another bullet

     &nb= sp; o  the MA also includes the Subscribed service parameters, such as= the subscribed rate and type of access, if inclusion of such information h= as been configured for the Report Channel and is known by the MA=

     

    th= is would imply that we should include something in the Instruction – = I think as part of the configuration of each Report Channel:

          *  a configuration option th= at the MA includes information about any Subscribed service parameters that= it knows (by default, not included)

     

    I’m assuming that this = will just be a free list of service parameters, ie the information model do= esn’t have to worry about defining the details (perhaps the informati= on model should say something about it being a list of name-value pairs? Fo= r instance  “subscribed rate: 80 Mbs up 20 Mbs down ; access typ= e : FTTC”)

     

    What do you reckon?

     

    thanks

    phil

    --<= /o:p>

     

    =  

    << 

    2) Reporting of Service Parameters by MA if available

    The Charter includes this sentence on t= he topic of Service Parameters: "However, if the service parameters ar= e available to the MAs, they could be reported

    with the measurement results in the Report Protocol"

     

     

         = ; Collector.  The Report contains the Measurement Results.<= /span>

    >> 

    = --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAB3FA79EMV67UKRDdoma_-- From nobody Wed Feb 19 14:26:20 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C0C1A02C1 for ; Wed, 19 Feb 2014 14:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S3jjjdxZwub for ; Wed, 19 Feb 2014 14:26:14 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2151A0226 for ; Wed, 19 Feb 2014 14:26:14 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0BE55F79; Wed, 19 Feb 2014 23:26:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id N5mIKGuqSEds; Wed, 19 Feb 2014 23:26:09 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Wed, 19 Feb 2014 23:26:09 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18D8C20026; Wed, 19 Feb 2014 23:26:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 81j6rRM_Z2-t; Wed, 19 Feb 2014 23:26:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4F6F20015; Wed, 19 Feb 2014 23:26:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 97B022B5B7B3; Wed, 19 Feb 2014 23:26:06 +0100 (CET) Date: Wed, 19 Feb 2014 23:26:06 +0100 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20140219222605.GA5993@elstar.local> Mail-Followup-To: philip.eardley@bt.com, lmap@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_M-kQhrc4TI9JqUDUYsUC5W4RQY Cc: lmap@ietf.org Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:26:18 -0000 On Wed, Feb 19, 2014 at 05:35:14PM +0000, philip.eardley@bt.com wrote: > One issue that was raised by Jason is that it may be good to include > 'service parameters' in the Report - I presume this is things like > the subscribed rate and type of access). While it might be convenient for processing results to have service parameters available, it feels wrong to decorate every Report with service parameters. > I'm assuming that this will just be a free list of service > parameters, ie the information model doesn't have to worry about > defining the details (perhaps the information model should say > something about it being a list of name-value pairs? For instance > "subscribed rate: 80 Mbs up 20 Mbs down ; access type : FTTC") This makes it kind of non-interoperable by definition. So why define it then? Another way of dealing with this is to define a measurement task that simply reports the service parameters. This way, you can schedule how frequently service parameters are shipped to collectors. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Feb 19 15:09:33 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B79E1A0535 for ; Wed, 19 Feb 2014 15:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-_cR43wcPxp for ; Wed, 19 Feb 2014 15:09:27 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id ED72F1A052E for ; Wed, 19 Feb 2014 15:09:26 -0800 (PST) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 0D06712038A; Wed, 19 Feb 2014 18:13:03 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-azure.research.att.com (Postfix) with ESMTP id 7FB3FE0277; Wed, 19 Feb 2014 18:09:23 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Wed, 19 Feb 2014 18:09:23 -0500 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "philip.eardley@bt.com" Date: Wed, 19 Feb 2014 18:09:23 -0500 Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8twaMIDJ7vu+qHTP+S6uAq8MxhFAABKsbp Message-ID: <2845723087023D4CB5114223779FA9C8BC2BCF3A@njfpsrvexg8.research.att.com> References: , <20140219222605.GA5993@elstar.local> In-Reply-To: <20140219222605.GA5993@elstar.local> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/j00mgcT6Yi9Lf1DputfDFHyCMxs Cc: "lmap@ietf.org" Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 23:09:29 -0000 Although it is permitted in the LMAP charter, there's no need to include th= e=20 service parameters in the ISP use case. A third party could get the servic= e info per participating subscriber from the service provider separately, pro= bably more efficient than having the MA do it.=20 Al ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder [j.sc= hoenwaelder@jacobs-university.de] Sent: Wednesday, February 19, 2014 5:26 PM To: philip.eardley@bt.com Cc: lmap@ietf.org Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft= -ietf-lmap-framework-03) On Wed, Feb 19, 2014 at 05:35:14PM +0000, philip.eardley@bt.com wrote: > One issue that was raised by Jason is that it may be good to include > 'service parameters' in the Report - I presume this is things like > the subscribed rate and type of access). While it might be convenient for processing results to have service parameters available, it feels wrong to decorate every Report with service parameters. > I'm assuming that this will just be a free list of service > parameters, ie the information model doesn't have to worry about > defining the details (perhaps the information model should say > something about it being a list of name-value pairs? For instance > "subscribed rate: 80 Mbs up 20 Mbs down ; access type : FTTC") This makes it kind of non-interoperable by definition. So why define it then? Another way of dealing with this is to define a measurement task that simply reports the service parameters. This way, you can schedule how frequently service parameters are shipped to collectors. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Feb 19 18:42:21 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CE31A01FC for ; Wed, 19 Feb 2014 18:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DPQcfI9Z4Oy for ; Wed, 19 Feb 2014 18:42:17 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 30CA31A00D5 for ; Wed, 19 Feb 2014 18:42:16 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,509,1389762000"; d="scan'208";a="194979286" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 19 Feb 2014 21:41:47 -0500 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.33]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 19 Feb 2014 21:42:12 -0500 From: "Weil, Jason" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder , "philip.eardley@bt.com" Date: Wed, 19 Feb 2014 21:42:12 -0500 Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8t5VuJ5koxRD5bSdWm9va7GO13wQ== Message-ID: In-Reply-To: <2845723087023D4CB5114223779FA9C8BC2BCF3A@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/8wkI0TR4dT2GYL9ezGoRXFKVeBQ Cc: "lmap@ietf.org" Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 02:42:19 -0000 I was thinking more of a may operation. If the data is available you may want to send it up with the measurement info in the Report Protocol. The way it reads now this is not supported at all. If this is the case we should explicitly state that as well. Jason On 2/19/14 6:09 PM, "MORTON, ALFRED C (AL)" wrote: >Although it is permitted in the LMAP charter, there's no need to include >the >service parameters in the ISP use case. A third party could get the >service >info per participating subscriber from the service provider separately, >probably more >efficient than having the MA do it. > >Al >________________________________________ >From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder >[j.schoenwaelder@jacobs-university.de] >Sent: Wednesday, February 19, 2014 5:26 PM >To: philip.eardley@bt.com >Cc: lmap@ietf.org >Subject: Re: [lmap] Reporting of service parameters (WGLC comments on >draft-ietf-lmap-framework-03) > >On Wed, Feb 19, 2014 at 05:35:14PM +0000, philip.eardley@bt.com wrote: > >> One issue that was raised by Jason is that it may be good to include >> 'service parameters' in the Report - I presume this is things like >> the subscribed rate and type of access). > >While it might be convenient for processing results to have service >parameters available, it feels wrong to decorate every Report with >service parameters. > >> I'm assuming that this will just be a free list of service >> parameters, ie the information model doesn't have to worry about >> defining the details (perhaps the information model should say >> something about it being a list of name-value pairs? For instance >> "subscribed rate: 80 Mbs up 20 Mbs down ; access type : FTTC") > >This makes it kind of non-interoperable by definition. So why define >it then? > >Another way of dealing with this is to define a measurement task that >simply reports the service parameters. This way, you can schedule how >frequently service parameters are shipped to collectors. > >/js > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > >_______________________________________________ >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 nobody Wed Feb 19 21:22:27 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07E71A05F2 for ; Wed, 19 Feb 2014 21:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrYRbr0CnzVI for ; Wed, 19 Feb 2014 21:22:23 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 21C131A02D8 for ; Wed, 19 Feb 2014 21:22:23 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id c0195035.2b873587b940.1694486.00-2460.4783617.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 20 Feb 2014 05:22:20 +0000 (UTC) X-MXL-Hash: 5305910c4ebe3eed-da2f93bb1250d434ec28420959be6cdff7e314d3 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 70195035.0.1694474.00-2318.4783589.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 20 Feb 2014 05:22:17 +0000 (UTC) X-MXL-Hash: 53059109231d816b-a3e69140bcb59450bd62a9dcfcaa6535bffc29c8 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1K5MEMK032299; Thu, 20 Feb 2014 00:22:14 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1K5M6V7032241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Feb 2014 00:22:10 -0500 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 20 Feb 2014 05:21:53 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0174.001; Thu, 20 Feb 2014 00:21:53 -0500 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , "MORTON JR., AL" Thread-Topic: [lmap] determining passive vs. active nature of measurement task Thread-Index: Ac8su9uG/Z96xXmsRyqSwIjA7oRtQgAC0KHCAABOh8AAAM3Z4AAQOLoAACpspNA= Date: Thu, 20 Feb 2014 05:21:52 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303EB2CD@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611303EA07C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC2BCF26@njfpsrvexg8.research.att.com> <2D09D61DDFA73D4C884805CC7865E611303EA227@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC2BCF27@njfpsrvexg8.research.att.com> <20140218194930.GA2976@elstar.local> In-Reply-To: <20140218194930.GA2976@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.46.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OL2QK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=5Eeuc2IJcf4A:10 a=ofMgfj31e3cA:10 a=38b0v79eTMQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=Pga3Syy5cmoA:10 a=EkGmAt_4vbxm57WXBowA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=4CLKj2Bp5_UA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/-lenjyqBbGSzpo8gdqgcNejSKVw Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 05:22:26 -0000 +1 Barbara > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] >=20 > I vote for thinking about any mechanisms needed to deal with overlapping > measurement tasks and to stay away from hard coding any policy. >=20 > There may be valid reasons for overlapping active measurements, there may > be valid reasons for enforcing non-overlapping passive measurements. >=20 > Lets focus on the mechanism and leave it to deployments to configure a > policy that makes sense. >=20 > /js From nobody Wed Feb 19 22:24:58 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16301A02A3 for ; Wed, 19 Feb 2014 22:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4txzMz2hgjua for ; Wed, 19 Feb 2014 22:24:54 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 815AB1A0263 for ; Wed, 19 Feb 2014 22:24:54 -0800 (PST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id EF39E1A0025 for ; Thu, 20 Feb 2014 07:24:19 +0100 (CET) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_8BC42246-A592-4FF4-BF65-BFC16E4E06F4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 20 Feb 2014 07:24:19 +0100 References: To: lmap@ietf.org Message-Id: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Sw88wISUAIZnQ9WiB9An3Cl04J4 Subject: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 06:24:57 -0000 --Apple-Mail=_8BC42246-A592-4FF4-BF65-BFC16E4E06F4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii +1 as well. cheers, Brian On 20 Feb 2014, at 06:21, STARK, BARBARA H wrote: > +1 > Barbara > >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- >> university.de] >> >> I vote for thinking about any mechanisms needed to deal with overlapping >> measurement tasks and to stay away from hard coding any policy. >> >> There may be valid reasons for overlapping active measurements, there may >> be valid reasons for enforcing non-overlapping passive measurements. >> >> Lets focus on the mechanism and leave it to deployments to configure a >> policy that makes sense. >> >> /js > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --Apple-Mail=_8BC42246-A592-4FF4-BF65-BFC16E4E06F4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTBZ+TAAoJENt3nsOmbNJcIlsH/3jqQRIMG62zijE6kSpr9EJ/ 6i5WpNhR2e/WCVaxIcSr9OPcxF/cvcw1dK+YPbuwlR6yRm077Wte7hbCpzhvvOz5 BGrsILmHjhIEqGwsDtFZu50fFS87pq+S2ZciA//XLhtfSplQeT6IYHgeC8Qlk+4x AIxNQ9pHiaMPTQs5tJxgMv9vGwFfqqjhnhdaT7E8QN3zQN8U798kxRok2/pT13Pi JKm1J77TQvYAGVAeoVEy0EKj00sT1/VX0SN9FgzT9N/8CreYsuFmwWiqqFyqv5Hw ykVp5TPLyXaIGoZmfEXDxhAJwiIYw6cyx6k6t48YlFFNBGrb93+yIcwtBmHPiiU= =SIsC -----END PGP SIGNATURE----- --Apple-Mail=_8BC42246-A592-4FF4-BF65-BFC16E4E06F4-- From nobody Thu Feb 20 00:30:38 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790881A02A3 for ; Wed, 19 Feb 2014 22:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGznjDApymVi for ; Wed, 19 Feb 2014 22:22:44 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C82391A0263 for ; Wed, 19 Feb 2014 22:22:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 39AE3D946D; Thu, 20 Feb 2014 07:22:39 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xA1jutKMkAfo; Thu, 20 Feb 2014 07:22:39 +0100 (MET) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 57747D9468; Thu, 20 Feb 2014 07:22:38 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_F80A475D-7463-402E-ADB4-C0760738BE31"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303EB2CD@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Thu, 20 Feb 2014 07:22:37 +0100 Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611303EA07C@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC2BCF26@njfpsrvexg8.research.att.com> <2D09D61DDFA73D4C884805CC7865E611303EA227@GAALPA1MSGUSR9L.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C8BC2BCF27@njfpsrvexg8.research.att.com> <20140218194930.GA2976@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303EB2CD@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/uSDRBdIZSj9wRUx5xW0CTFyeWDE X-Mailman-Approved-At: Thu, 20 Feb 2014 00:30:36 -0800 Cc: "philip.eardley@bt.com" , Juergen Schoenwaelder , Al Morton , "lmap@ietf.org" Subject: Re: [lmap] determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 06:22:46 -0000 --Apple-Mail=_F80A475D-7463-402E-ADB4-C0760738BE31 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii +1 as well. cheers, Brian On 20 Feb 2014, at 06:21, STARK, BARBARA H wrote: > +1 > Barbara > >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- >> university.de] >> >> I vote for thinking about any mechanisms needed to deal with overlapping >> measurement tasks and to stay away from hard coding any policy. >> >> There may be valid reasons for overlapping active measurements, there may >> be valid reasons for enforcing non-overlapping passive measurements. >> >> Lets focus on the mechanism and leave it to deployments to configure a >> policy that makes sense. >> >> /js > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --Apple-Mail=_F80A475D-7463-402E-ADB4-C0760738BE31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTBZ8tAAoJENt3nsOmbNJcSd4H/3mFcGkue8UAUtAoFRUCBx4w 7/ror1OTIBWnC5SkR9pFuwwGNx04PL+aEc+5PvQdLu4Qh4Sblw14D8jI7jJ8JRlg G6Kd3hEZKrf3TIcUm0Iwv/k6VSk1rDZ1jCOh1U/pgRJnN5KhBh5zVDPvavOqn0L2 WdSgr9bTCEG7QZ52XW0C/tJ6qb1Ti31xI7kbvyY24xP5YdQpJMVDMqp3HdqbotFq lGS7EMepLhkZ2q0rUxgddmV8SPJq21eauhosa7I9ekdDCTjtOhR3ZYp4RhOUOtBJ mCulCgg9nNBD0IZk6ybuvgeGuBH6ZBlF5AFCEx4VXPmT9PNQG4UexqKrxiNsbBQ= =kB3v -----END PGP SIGNATURE----- --Apple-Mail=_F80A475D-7463-402E-ADB4-C0760738BE31-- From nobody Thu Feb 20 01:12:03 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F421A0053 for ; Thu, 20 Feb 2014 01:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVef3N1FdSdc for ; Thu, 20 Feb 2014 01:11:59 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 708741A004E for ; Thu, 20 Feb 2014 01:11:59 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1K9Bn1P002418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Feb 2014 02:11:49 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 563F11E0062; Thu, 20 Feb 2014 02:11:44 -0700 (MST) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 1A34A1E0035; Thu, 20 Feb 2014 02:11:44 -0700 (MST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s1K9BhEN020416; Thu, 20 Feb 2014 03:11:43 -0600 (CST) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s1K9BhF6020411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 03:11:43 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 03:11:42 -0600 From: "Bugenhagen, Michael K" To: "'Weil, Jason'" , "'MORTON, ALFRED C (AL)'" , "'Juergen Schoenwaelder'" , "'philip.eardley@bt.com'" Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8tlhV3TNdpUpq+Qpm+Dna82yWzGQAXcmcAAAGC/IAAB266AAAA3fjA Date: Thu, 20 Feb 2014 09:11:41 +0000 Message-ID: References: <2845723087023D4CB5114223779FA9C8BC2BCF3A@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Hhkunu3E7Mj23hV4rbkvDNcjLMg Cc: "'lmap@ietf.org'" Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 09:12:01 -0000 I concur - If they are available and defined and contextually relevant to t= he test (in fact saying % of Terms of Service throughput) then they are req= uired. We have found that some terms of service literally change over time of day,= =20 Others change based on "state of the service" passed a cap and get throttle= - more of a wireless thing today but growing on the other technologies Walled gardens from people getting hacked and not understanding it.. The bigger issues here- If you have 2 people out of 10 in a service tier with a "mis understood = service state" - publishing results that don't accurate reflect facts would= be highly problematic to say the least. So a small bit of work here goes a long way. Regards, Mike -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason Sent: Wednesday, February 19, 2014 8:42 PM To: MORTON, ALFRED C (AL); Juergen Schoenwaelder; philip.eardley@bt.com Cc: lmap@ietf.org Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft= -ietf-lmap-framework-03) I was thinking more of a may operation. If the data is available you may wa= nt to send it up with the measurement info in the Report Protocol. The way = it reads now this is not supported at all. If this is the case we should ex= plicitly state that as well. Jason On 2/19/14 6:09 PM, "MORTON, ALFRED C (AL)" wrote: >Although it is permitted in the LMAP charter, there's no need to=20 >include the service parameters in the ISP use case. A third party=20 >could get the service info per participating subscriber from the=20 >service provider separately, probably more efficient than having the MA=20 >do it. > >Al >________________________________________ >From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder=20 >[j.schoenwaelder@jacobs-university.de] >Sent: Wednesday, February 19, 2014 5:26 PM >To: philip.eardley@bt.com >Cc: lmap@ietf.org >Subject: Re: [lmap] Reporting of service parameters (WGLC comments on >draft-ietf-lmap-framework-03) > >On Wed, Feb 19, 2014 at 05:35:14PM +0000, philip.eardley@bt.com wrote: > >> One issue that was raised by Jason is that it may be good to include=20 >> 'service parameters' in the Report - I presume this is things like=20 >> the subscribed rate and type of access). > >While it might be convenient for processing results to have service=20 >parameters available, it feels wrong to decorate every Report with=20 >service parameters. > >> I'm assuming that this will just be a free list of service=20 >> parameters, ie the information model doesn't have to worry about=20 >> defining the details (perhaps the information model should say=20 >> something about it being a list of name-value pairs? For instance=20 >> "subscribed rate: 80 Mbs up 20 Mbs down ; access type : FTTC") > >This makes it kind of non-interoperable by definition. So why define it=20 >then? > >Another way of dealing with this is to define a measurement task that=20 >simply reports the service parameters. This way, you can schedule how=20 >frequently service parameters are shipped to collectors. > >/js > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > >_______________________________________________ >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. _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Feb 20 01:22:00 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1363B1A0057 for ; Thu, 20 Feb 2014 01:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvRWW3avNZ3z for ; Thu, 20 Feb 2014 01:21:54 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7080F1A004C for ; Thu, 20 Feb 2014 01:21:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 408D4AE0; Thu, 20 Feb 2014 10:21:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uwoflAhQiXYS; Thu, 20 Feb 2014 10:21:48 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 20 Feb 2014 10:21:48 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A54CE20026; Thu, 20 Feb 2014 10:21:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FnaNX05eJgN5; Thu, 20 Feb 2014 10:21:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99A5420015; Thu, 20 Feb 2014 10:21:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 268492B5F101; Thu, 20 Feb 2014 10:21:44 +0100 (CET) Date: Thu, 20 Feb 2014 10:21:44 +0100 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20140220092144.GA18837@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , "'Weil, Jason'" , "'MORTON, ALFRED C (AL)'" , "'philip.eardley@bt.com'" , "'lmap@ietf.org'" References: <2845723087023D4CB5114223779FA9C8BC2BCF3A@njfpsrvexg8.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/kulRAFKDJ5RRyucNyXWjQaoxZOI Cc: "'philip.eardley@bt.com'" , "'lmap@ietf.org'" , "'MORTON, ALFRED C \(AL\)'" , "'Weil, Jason'" Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 09:21:58 -0000 Sure, but for me this is just another 'measurement task' reporting service parameters. You want the flexibility to control and schedule this like any other measurement task. The current LMAP framework and information model provide you the means to do this and hence I believe there is nothing technical to be done to address this requirement. I do not mind if text gets added to the framework document pointing out that service parameters can be reported by a special 'service parameters measurement task' if that adds clarity how one can address the "However, if the service parameters are available to the MAs, they could be reported with the measurement results in the Report Protocol." phrase of the charter. /js On Thu, Feb 20, 2014 at 09:11:41AM +0000, Bugenhagen, Michael K wrote: > I concur - If they are available and defined and contextually relevant to the test (in fact saying % of Terms of Service throughput) then they are required. > > We have found that some terms of service literally change over time of day, > Others change based on "state of the service" passed a cap and get throttle - more of a wireless thing today but growing on the other technologies > Walled gardens from people getting hacked and not understanding it.. > > The bigger issues here- > If you have 2 people out of 10 in a service tier with a "mis understood service state" - publishing results that don't accurate reflect facts would be highly problematic to say the least. > > So a small bit of work here goes a long way. > > Regards, > Mike > > > > > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason > Sent: Wednesday, February 19, 2014 8:42 PM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder; philip.eardley@bt.com > Cc: lmap@ietf.org > Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) > > I was thinking more of a may operation. If the data is available you may want to send it up with the measurement info in the Report Protocol. The way it reads now this is not supported at all. If this is the case we should explicitly state that as well. > > Jason > > On 2/19/14 6:09 PM, "MORTON, ALFRED C (AL)" wrote: > > >Although it is permitted in the LMAP charter, there's no need to > >include the service parameters in the ISP use case. A third party > >could get the service info per participating subscriber from the > >service provider separately, probably more efficient than having the MA > >do it. > > > >Al > >________________________________________ > >From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > >[j.schoenwaelder@jacobs-university.de] > >Sent: Wednesday, February 19, 2014 5:26 PM > >To: philip.eardley@bt.com > >Cc: lmap@ietf.org > >Subject: Re: [lmap] Reporting of service parameters (WGLC comments on > >draft-ietf-lmap-framework-03) > > > >On Wed, Feb 19, 2014 at 05:35:14PM +0000, philip.eardley@bt.com wrote: > > > >> One issue that was raised by Jason is that it may be good to include > >> 'service parameters' in the Report - I presume this is things like > >> the subscribed rate and type of access). > > > >While it might be convenient for processing results to have service > >parameters available, it feels wrong to decorate every Report with > >service parameters. > > > >> I'm assuming that this will just be a free list of service > >> parameters, ie the information model doesn't have to worry about > >> defining the details (perhaps the information model should say > >> something about it being a list of name-value pairs? For instance > >> "subscribed rate: 80 Mbs up 20 Mbs down ; access type : FTTC") > > > >This makes it kind of non-interoperable by definition. So why define it > >then? > > > >Another way of dealing with this is to define a measurement task that > >simply reports the service parameters. This way, you can schedule how > >frequently service parameters are shipped to collectors. > > > >/js > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > >Fax: +49 421 200 3103 > > > >_______________________________________________ > >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 that 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Feb 20 02:25:03 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4971A0069 for ; Thu, 20 Feb 2014 02:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjEaHAH4uuB8 for ; Thu, 20 Feb 2014 02:24:58 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id C0F951A0092 for ; Thu, 20 Feb 2014 02:24:58 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1KAOhta005024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Feb 2014 03:24:43 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 1D5F61E005D; Thu, 20 Feb 2014 04:24:38 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id E0ACC1E005F; Thu, 20 Feb 2014 04:24:37 -0600 (CST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1KAObAe007398; Thu, 20 Feb 2014 03:24:37 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1KAOa1g007362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 03:24:37 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 04:24:36 -0600 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8tlhV3TNdpUpq+Qpm+Dna82yWzGQAXcmcAAAGC/IAAB266AAAA3fjAAA0WIwAACpATsA== Date: Thu, 20 Feb 2014 10:24:35 +0000 Message-ID: References: <2845723087023D4CB5114223779FA9C8BC2BCF3A@njfpsrvexg8.research.att.com> <20140220092144.GA18837@elstar.local> In-Reply-To: <20140220092144.GA18837@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/6b9Y3sCFUv756oxHUKa7XdpyfIs Cc: "'philip.eardley@bt.com'" , "'lmap@ietf.org'" , "'MORTON, ALFRED C \(AL\)'" , "'Weil, Jason'" Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 10:25:02 -0000 Great! - So I think we have agreement that we can add a "test" step that in= cludes hitting the ISP interface for Service Attributes. So a "service attributes" "dip" should be included if the MA was configured= or discovered an ISP Service interface... COOL! We still have to resolve the "detecting" transit traffic - the interface to= grab utilization information... Could be the same interface, or different one... Any druthers ??? Mike -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, February 20, 2014 3:22 AM To: Bugenhagen, Michael K Cc: 'Weil, Jason'; 'MORTON, ALFRED C (AL)'; 'philip.eardley@bt.com'; 'lmap@= ietf.org' Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft= -ietf-lmap-framework-03) Sure, but for me this is just another 'measurement task' reporting service = parameters. You want the flexibility to control and schedule this like any = other measurement task. The current LMAP framework and information model pr= ovide you the means to do this and hence I believe there is nothing technic= al to be done to address this requirement. I do not mind if text gets added to the framework document pointing out tha= t service parameters can be reported by a special 'service parameters measu= rement task' if that adds clarity how one can address the "However, if the = service parameters are available to the MAs, they could be reported with th= e measurement results in the Report Protocol." phrase of the charter. /js On Thu, Feb 20, 2014 at 09:11:41AM +0000, Bugenhagen, Michael K wrote: > I concur - If they are available and defined and contextually relevant to= the test (in fact saying % of Terms of Service throughput) then they are r= equired. >=20 > We have found that some terms of service literally change over time of=20 > day, Others change based on "state of the service" passed a cap and=20 > get throttle - more of a wireless thing today but growing on the other t= echnologies Walled gardens from people getting hacked and not understanding= it.. >=20 > The bigger issues here- > If you have 2 people out of 10 in a service tier with a "mis understoo= d service state" - publishing results that don't accurate reflect facts wou= ld be highly problematic to say the least. >=20 > So a small bit of work here goes a long way. >=20 > Regards, > Mike >=20 >=20 >=20 >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason > Sent: Wednesday, February 19, 2014 8:42 PM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder;=20 > philip.eardley@bt.com > Cc: lmap@ietf.org > Subject: Re: [lmap] Reporting of service parameters (WGLC comments on=20 > draft-ietf-lmap-framework-03) >=20 > I was thinking more of a may operation. If the data is available you may = want to send it up with the measurement info in the Report Protocol. The wa= y it reads now this is not supported at all. If this is the case we should = explicitly state that as well. >=20 > Jason >=20 > On 2/19/14 6:09 PM, "MORTON, ALFRED C (AL)" wrote: >=20 > >Although it is permitted in the LMAP charter, there's no need to=20 > >include the service parameters in the ISP use case. A third party=20 > >could get the service info per participating subscriber from the=20 > >service provider separately, probably more efficient than having the=20 > >MA do it. > > > >Al > >________________________________________ > >From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder=20 > >[j.schoenwaelder@jacobs-university.de] > >Sent: Wednesday, February 19, 2014 5:26 PM > >To: philip.eardley@bt.com > >Cc: lmap@ietf.org > >Subject: Re: [lmap] Reporting of service parameters (WGLC comments on > >draft-ietf-lmap-framework-03) > > > >On Wed, Feb 19, 2014 at 05:35:14PM +0000, philip.eardley@bt.com wrote: > > > >> One issue that was raised by Jason is that it may be good to=20 > >> include 'service parameters' in the Report - I presume this is=20 > >> things like the subscribed rate and type of access). > > > >While it might be convenient for processing results to have service=20 > >parameters available, it feels wrong to decorate every Report with=20 > >service parameters. > > > >> I'm assuming that this will just be a free list of service=20 > >> parameters, ie the information model doesn't have to worry about=20 > >> defining the details (perhaps the information model should say=20 > >> something about it being a list of name-value pairs? For instance=20 > >> "subscribed rate: 80 Mbs up 20 Mbs down ; access type : FTTC") > > > >This makes it kind of non-interoperable by definition. So why define=20 > >it then? > > > >Another way of dealing with this is to define a measurement task that=20 > >simply reports the service parameters. This way, you can schedule how=20 > >frequently service parameters are shipped to collectors. > > > >/js > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > >Fax: +49 421 200 3103 > > > >_______________________________________________ > >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 >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight 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 t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Feb 20 02:43:46 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55931A00A3 for ; Thu, 20 Feb 2014 02:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S3c6XQ1Bhfi for ; Thu, 20 Feb 2014 02:43:43 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id ACCC01A0097 for ; Thu, 20 Feb 2014 02:43:43 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1KAhdG3017215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Feb 2014 03:43:39 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 5B9BC1E0073; Thu, 20 Feb 2014 04:43:34 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 41FAA1E006F; Thu, 20 Feb 2014 04:43:34 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1KAhI2v003594; Thu, 20 Feb 2014 04:43:18 -0600 (CST) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1KAhIwl003587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 04:43:18 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 04:43:17 -0600 From: "Bugenhagen, Michael K" To: "'Brian Trammell'" , "'lmap@ietf.org'" Thread-Topic: [lmap] Fwd: determining passive vs. active nature of measurement task Thread-Index: AQHPLgR6hOq8I0MfRk6I+PLAUhiqRZq99Fgw Date: Thu, 20 Feb 2014 10:43:17 +0000 Message-ID: References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> In-Reply-To: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/7USZRGwDTyRL3GvGW9GNEkJRfWU Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 10:43:46 -0000 Also there is the "multi-MA" overlapping test issue that I mentioned earlie= r. One way to handle this is "only one MA" per element -=20 Another would be (more complicated) something inter-probe but then we'd hav= e to boil the ocean with all the different existing probe server functions. My preference is overlapping test avoidance is the Assumption of one MA per= device. -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell Sent: Thursday, February 20, 2014 12:24 AM To: lmap@ietf.org Subject: [lmap] Fwd: determining passive vs. active nature of measurement t= ask +1 as well. cheers, Brian On 20 Feb 2014, at 06:21, STARK, BARBARA H wrote: > +1 > Barbara >=20 >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 >> university.de] >>=20 >> I vote for thinking about any mechanisms needed to deal with=20 >> overlapping measurement tasks and to stay away from hard coding any poli= cy. >>=20 >> There may be valid reasons for overlapping active measurements, there=20 >> may be valid reasons for enforcing non-overlapping passive measurements. >>=20 >> Lets focus on the mechanism and leave it to deployments to configure=20 >> a policy that makes sense. >>=20 >> /js >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Feb 20 02:49:36 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3F81A0061 for ; Thu, 20 Feb 2014 02:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rAq-bgaTKNq for ; Thu, 20 Feb 2014 02:49:32 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC951A0072 for ; Thu, 20 Feb 2014 02:49:32 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B7969F6B; Thu, 20 Feb 2014 11:49:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ikHj00QfTF6f; Thu, 20 Feb 2014 11:49:27 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 20 Feb 2014 11:49:27 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3A9020015; Thu, 20 Feb 2014 11:49:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JENWBeZsGHmk; Thu, 20 Feb 2014 11:49:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C084E20026; Thu, 20 Feb 2014 11:49:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 628A72B5F50A; Thu, 20 Feb 2014 11:49:25 +0100 (CET) Date: Thu, 20 Feb 2014 11:49:25 +0100 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20140220104925.GC18837@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , 'Brian Trammell' , "'lmap@ietf.org'" References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/8OdMbwhTcsL4z_4jJ4JkNSJFgxo Cc: 'Brian Trammell' , "'lmap@ietf.org'" Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 10:49:34 -0000 On Thu, Feb 20, 2014 at 10:43:17AM +0000, Bugenhagen, Michael K wrote: > Also there is the "multi-MA" overlapping test issue that I mentioned earlier. > > One way to handle this is "only one MA" per element - > Another would be (more complicated) something inter-probe but then we'd have to boil the ocean with all the different existing probe server functions. > > My preference is overlapping test avoidance is the Assumption of one MA per device. > This is an implementation issue and the framework should stay silent about the packaging. I believe it is possible to build 'elements' or 'devices' (all not well defined terms anyway) that can host multiple MAs without causing resource contention as much as I believe it is possible that build 'elements' or 'devices' that host only a single MA that suffers from resource shortage. The market will sort this out. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Feb 20 03:21:40 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA011A00B3 for ; Thu, 20 Feb 2014 03:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD4JYPUwW-3P for ; Thu, 20 Feb 2014 03:21:36 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 09C2F1A00B0 for ; Thu, 20 Feb 2014 03:21:35 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1KBLVXf006737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Feb 2014 04:21:32 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A35761E005B; Thu, 20 Feb 2014 05:21:26 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 8879B1E0059; Thu, 20 Feb 2014 05:21:26 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1KBLQA3003644; Thu, 20 Feb 2014 05:21:26 -0600 (CST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1KBLPIp003637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 05:21:25 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 05:21:25 -0600 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" Thread-Topic: [lmap] Fwd: determining passive vs. active nature of measurement task Thread-Index: AQHPLilvcN7+fXJbI0muejudQTDFmZq9+s2Q Date: Thu, 20 Feb 2014 11:21:24 +0000 Message-ID: References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> <20140220104925.GC18837@elstar.local> In-Reply-To: <20140220104925.GC18837@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/4fmAai1BCgeRxh0eewuss2tEnmo Cc: 'Brian Trammell' , "'lmap@ietf.org'" Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 11:21:38 -0000 The MA / Probe vendors, and even existing testing standards vendors haven't= fixed it by working together or making a overlapping test schema. We could very easily slightly modify the MA resource check in both the IETF= & BBF to look for resource use collision. The "watch for transit traffic" in-fact suggests avoiding overlapping test = collisions. If we apply the same "collision domain" avoidance principle to the CPU & Me= mory use we would then create a MA framework that all independent MA's coul= d avoid collisions, much like the same way MAC ports us Collision detection= . Agreeable ? -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, February 20, 2014 4:49 AM To: Bugenhagen, Michael K Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: Re: [lmap] Fwd: determining passive vs. active nature of measureme= nt task On Thu, Feb 20, 2014 at 10:43:17AM +0000, Bugenhagen, Michael K wrote: > Also there is the "multi-MA" overlapping test issue that I mentioned earl= ier. >=20 > One way to handle this is "only one MA" per element - Another would=20 > be (more complicated) something inter-probe but then we'd have to boil th= e ocean with all the different existing probe server functions. >=20 > My preference is overlapping test avoidance is the Assumption of one MA p= er device. >=20 This is an implementation issue and the framework should stay silent about = the packaging. I believe it is possible to build 'elements' or 'devices' (all not well def= ined terms anyway) that can host multiple MAs without causing resource cont= ention as much as I believe it is possible that build 'elements' or 'device= s' that host only a single MA that suffers from resource shortage. The mark= et will sort this out. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Feb 20 04:28:57 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE591A012D for ; Thu, 20 Feb 2014 04:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FndjH-wTMHSH for ; Thu, 20 Feb 2014 04:28:54 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 827301A0087 for ; Thu, 20 Feb 2014 04:28:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A5A74F5B; Thu, 20 Feb 2014 13:28:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tMo8h-PdRzPv; Thu, 20 Feb 2014 13:28:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 20 Feb 2014 13:28:49 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A008420026; Thu, 20 Feb 2014 13:28:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WRxH_as6NQ1x; Thu, 20 Feb 2014 13:28:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3CF820015; Thu, 20 Feb 2014 13:28:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A169E2B5F914; Thu, 20 Feb 2014 13:28:45 +0100 (CET) Date: Thu, 20 Feb 2014 13:28:45 +0100 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20140220122845.GC19222@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , 'Brian Trammell' , "'lmap@ietf.org'" References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> <20140220104925.GC18837@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FgEY03zW-dlAoxKt8J4vcqi3Q4w Cc: 'Brian Trammell' , "'lmap@ietf.org'" Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 12:28:57 -0000 On Thu, Feb 20, 2014 at 11:21:24AM +0000, Bugenhagen, Michael K wrote: > > If we apply the same "collision domain" avoidance principle to the CPU & Memory use we would then create a MA framework that all independent MA's could avoid collisions, much like the same way MAC ports us Collision detection. > I can't parse this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Feb 20 05:01:55 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE491A0144 for ; Thu, 20 Feb 2014 05:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj-x4j4AYgbv for ; Thu, 20 Feb 2014 05:01:51 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 131AD1A0140 for ; Thu, 20 Feb 2014 05:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2995; q=dns/txt; s=iport; t=1392901308; x=1394110908; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y0vYQZPeh33/rugEgoYCEwatQwp3gH7FgvS2YJpOJg4=; b=kvssFoHlCu2AsDWAC6rTbtcVfnulDDNNE04vQjkQUkQbGRCW5WakxQDp tc/tf7YArQNTut4Fze+UeSz7qM9VlQurl/RWtW5jbcwh6jJe5XvBbgQGE lBReI2+05hrsHlfq/gA30FUFHXq/t+MiOGsa+oR2dLm5LQAfioVTTQ3FY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGv7BVOtJXG8/2dsb2JhbABWA4MGOFfACoEMFnSCJQEBAQQBAQE3NAsMAgICAQgQAQQBAQEKFAkHGwwLFAkIAgQBDQUIh30NzjwXBI4vIRACBQYLgxOBFASqVIMtgio X-IronPort-AV: E=Sophos;i="4.97,512,1389744000"; d="scan'208";a="305355738" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 20 Feb 2014 13:01:45 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1KD1iMS021803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 13:01:44 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.9]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 07:01:44 -0600 From: "Aamer Akhter (aakhter)" To: "Bugenhagen, Michael K" , "'Juergen Schoenwaelder'" Thread-Topic: [lmap] Fwd: determining passive vs. active nature of measurement task Thread-Index: AQHPLilzvacLa29z6USbrG4pdK91VZq+ZAkA//+2rLA= Date: Thu, 20 Feb 2014 13:01:44 +0000 Message-ID: <75C0E47A1889264493A2DCB2869AC09633BDAB7E@xmb-rcd-x15.cisco.com> References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> <20140220104925.GC18837@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.25.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/gz_zXqeC1mgRSfshE45nZzAd4vs Cc: 'Brian Trammell' , "'lmap@ietf.org'" Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:01:53 -0000 Hi Michael, There are multiple approaches to the problem. In fact this reminds me of th= e IPSLA group scheduling feature, which is used for more dispersed scheduli= ng to relieve (among other things) local CPU contention. http://www.cisco.com/c/en/us/td/docs/ios/ipsla/configuration/guide/15_s/sla= _15_0s_book/sla_multi_scheduler.html That said, there may be constraints in the test request itself such that a = delayed/early test is just not acceptable either. aa -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael = K Sent: Thursday, February 20, 2014 6:21 AM To: 'Juergen Schoenwaelder' Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: Re: [lmap] Fwd: determining passive vs. active nature of measureme= nt task The MA / Probe vendors, and even existing testing standards vendors haven't= fixed it by working together or making a overlapping test schema. We could very easily slightly modify the MA resource check in both the IETF= & BBF to look for resource use collision. The "watch for transit traffic" in-fact suggests avoiding overlapping test = collisions. If we apply the same "collision domain" avoidance principle to the CPU & Me= mory use we would then create a MA framework that all independent MA's coul= d avoid collisions, much like the same way MAC ports us Collision detection= . Agreeable ? -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, February 20, 2014 4:49 AM To: Bugenhagen, Michael K Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: Re: [lmap] Fwd: determining passive vs. active nature of measureme= nt task On Thu, Feb 20, 2014 at 10:43:17AM +0000, Bugenhagen, Michael K wrote: > Also there is the "multi-MA" overlapping test issue that I mentioned earl= ier. >=20 > One way to handle this is "only one MA" per element - Another would=20 > be (more complicated) something inter-probe but then we'd have to boil th= e ocean with all the different existing probe server functions. >=20 > My preference is overlapping test avoidance is the Assumption of one MA p= er device. >=20 This is an implementation issue and the framework should stay silent about = the packaging. I believe it is possible to build 'elements' or 'devices' (all not well def= ined terms anyway) that can host multiple MAs without causing resource cont= ention as much as I believe it is possible that build 'elements' or 'device= s' that host only a single MA that suffers from resource shortage. The mark= et will sort this out. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Feb 20 06:15:03 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360A31A01B2 for ; Thu, 20 Feb 2014 06:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DaaFDnDjIFc for ; Thu, 20 Feb 2014 06:14:59 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 84E471A0173 for ; Thu, 20 Feb 2014 06:14:59 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1KEEtWF020489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Feb 2014 07:14:55 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 250151E0062; Thu, 20 Feb 2014 07:14:50 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id EA5F31E005F; Thu, 20 Feb 2014 07:14:49 -0700 (MST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1KEEnZI029034; Thu, 20 Feb 2014 08:14:49 -0600 (CST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1KEEmlJ029007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 08:14:48 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 08:14:48 -0600 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" Thread-Topic: [lmap] Fwd: determining passive vs. active nature of measurement task Thread-Index: AQHPLilvcN7+fXJbI0muejudQTDFmZq9+s2QgAB8DYD//6+s4A== Date: Thu, 20 Feb 2014 14:14:47 +0000 Message-ID: References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> <20140220104925.GC18837@elstar.local> <20140220122845.GC19222@elstar.local> In-Reply-To: <20140220122845.GC19222@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/rpBxEfVR3LzG5_ZtbK6CRuD4VDo Cc: 'Brian Trammell' , "'lmap@ietf.org'" Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:15:01 -0000 Ok.... I'll try to clarify. A CPU and Memory can both be utilized by different MA's on the same element= (so say the vendors I've worked with). The MA's when running therefore dip from the same resource well, so if eith= er the CPU or the Memory utilization gets to high it the entire system slow= s down. So as an abstract concept level - that is a resource pool collision domain. If there is a "MIB" that indicates Memory Use, and CPU use... (assumption) We can create monitoring logic that watches CPU & Memory utilization before= a test is conduct (at initiation) And then perform (during the test) continuous monitoring of CPU / MEM utili= zation with Threshold crossing event logic =09 i.e. - ping the CPU / Mem. Utilization every second watching for a Thresho= ld crossing event - which triggers the test to stop and mark test results a= s invalid. In a pyshical appliance this is easy, it's harder in a virtualized probe = it's tougher because CPU utilization doesn't reflect congestion directly. Thanks, Mike -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, February 20, 2014 6:29 AM To: Bugenhagen, Michael K Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: Re: [lmap] Fwd: determining passive vs. active nature of measureme= nt task On Thu, Feb 20, 2014 at 11:21:24AM +0000, Bugenhagen, Michael K wrote: >=20 > If we apply the same "collision domain" avoidance principle to the CPU & = Memory use we would then create a MA framework that all independent MA's co= uld avoid collisions, much like the same way MAC ports us Collision detecti= on. >=20 I can't parse this. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Feb 20 06:27:12 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A3D1A019D for ; Thu, 20 Feb 2014 06:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub3f7KNqHt4G for ; Thu, 20 Feb 2014 06:27:06 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 65F411A0061 for ; Thu, 20 Feb 2014 06:27:05 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7D024F7F; Thu, 20 Feb 2014 15:27:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9lgGkR_nJ-xZ; Thu, 20 Feb 2014 15:27:00 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 20 Feb 2014 15:27:00 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7401A20027; Thu, 20 Feb 2014 15:27:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id x1BMwnjOUQ4L; Thu, 20 Feb 2014 15:27:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED25C20015; Thu, 20 Feb 2014 15:26:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 67F3E2B6C9B7; Thu, 20 Feb 2014 15:26:58 +0100 (CET) Date: Thu, 20 Feb 2014 15:26:57 +0100 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20140220142657.GA86658@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , 'Brian Trammell' , "'lmap@ietf.org'" References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> <20140220104925.GC18837@elstar.local> <20140220122845.GC19222@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/XPUv0QClGrUg4a-0K41bw3vKpRE Cc: 'Brian Trammell' , "'lmap@ietf.org'" Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:27:11 -0000 On Thu, Feb 20, 2014 at 02:14:47PM +0000, Bugenhagen, Michael K wrote: > Ok.... I'll try to clarify. > > A CPU and Memory can both be utilized by different MA's on the same element (so say the vendors I've worked with). > The MA's when running therefore dip from the same resource well, so if either the CPU or the Memory utilization gets to high it the entire system slows down. > So as an abstract concept level - that is a resource pool collision domain. > > If there is a "MIB" that indicates Memory Use, and CPU use... (assumption) > > We can create monitoring logic that watches CPU & Memory utilization before a test is conduct (at initiation) > And then perform (during the test) continuous monitoring of CPU / MEM utilization with Threshold crossing event logic > > i.e. - ping the CPU / Mem. Utilization every second watching for a Threshold crossing event - which triggers the test to stop and mark test results as invalid. > In a pyshical appliance this is easy, it's harder in a virtualized probe it's tougher because CPU utilization doesn't reflect congestion directly. > So how do I translate all that back into the framework / information model documents we have? What exact change or addition do you suggest? Can't this be left to the definition of measurement tasks where this is relevant? (A traceroute likely is not CPU or memory bound, for example.) I like to understand what in concrete terms is missing or unclear in the WG documents. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Feb 20 06:38:17 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420BF1A016F for ; Thu, 20 Feb 2014 06:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDZl7-0z45BA for ; Thu, 20 Feb 2014 06:38:14 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id F0EE61A019E for ; Thu, 20 Feb 2014 06:38:12 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1KEc8pK000130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Feb 2014 08:38:08 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2318D1E0067; Thu, 20 Feb 2014 07:38:03 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id E57121E0035; Thu, 20 Feb 2014 07:38:02 -0700 (MST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1KEc1WH001780; Thu, 20 Feb 2014 08:38:01 -0600 (CST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1KEc0kH001769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 08:38:01 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 08:38:00 -0600 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" Thread-Topic: [lmap] Fwd: determining passive vs. active nature of measurement task Thread-Index: AQHPLilvcN7+fXJbI0muejudQTDFmZq9+s2QgAB8DYD//6+s4IAAcVqA//+eYQA= Date: Thu, 20 Feb 2014 14:37:59 +0000 Message-ID: References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> <20140220104925.GC18837@elstar.local> <20140220122845.GC19222@elstar.local> <20140220142657.GA86658@elstar.local> In-Reply-To: <20140220142657.GA86658@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/zAezoVJINXCr6laatQDsmDG9HmM Cc: 'Brian Trammell' , "'lmap@ietf.org'" Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:38:16 -0000 I would suggest we add that to the "resource check" functional area for the= MA. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, February 20, 2014 8:27 AM To: Bugenhagen, Michael K Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: Re: [lmap] Fwd: determining passive vs. active nature of measureme= nt task On Thu, Feb 20, 2014 at 02:14:47PM +0000, Bugenhagen, Michael K wrote: > Ok.... I'll try to clarify. >=20 > A CPU and Memory can both be utilized by different MA's on the same eleme= nt (so say the vendors I've worked with). > The MA's when running therefore dip from the same resource well, so if ei= ther the CPU or the Memory utilization gets to high it the entire system sl= ows down. > So as an abstract concept level - that is a resource pool collision domai= n. >=20 > If there is a "MIB" that indicates Memory Use, and CPU use...=20 > (assumption) >=20 > We can create monitoring logic that watches CPU & Memory utilization=20 > before a test is conduct (at initiation) And then perform (during the=20 > test) continuous monitoring of CPU / MEM utilization with Threshold=20 > crossing event logic > =09 > i.e. - ping the CPU / Mem. Utilization every second watching for a Thres= hold crossing event - which triggers the test to stop and mark test results= as invalid. > In a pyshical appliance this is easy, it's harder in a virtualized prob= e it's tougher because CPU utilization doesn't reflect congestion directly. >=20 So how do I translate all that back into the framework / information model = documents we have? What exact change or addition do you suggest? Can't this be left to the definition of measurement tasks where this is rel= evant? (A traceroute likely is not CPU or memory bound, for example.) I like to understand what in concrete terms is missing or unclear= in the WG documents. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Feb 20 06:44:20 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDCC1A0170 for ; Thu, 20 Feb 2014 06:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2cLRDh4Fs9i for ; Thu, 20 Feb 2014 06:44:14 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id C53031A0195 for ; Thu, 20 Feb 2014 06:44:14 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1KEi9uD004908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Feb 2014 08:44:10 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id CA1E11E0049; Thu, 20 Feb 2014 07:44:04 -0700 (MST) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id ADA121E0035; Thu, 20 Feb 2014 07:44:04 -0700 (MST) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1KEi4hH007608; Thu, 20 Feb 2014 07:44:04 -0700 (MST) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1KEi3fB007593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 07:44:04 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 08:44:03 -0600 From: "Bugenhagen, Michael K" To: "'Aamer Akhter (aakhter)'" , "'Juergen Schoenwaelder'" Thread-Topic: [lmap] Fwd: determining passive vs. active nature of measurement task Thread-Index: AQHPLilvcN7+fXJbI0muejudQTDFmZq9+s2QgACFRAD//7dUsA== Date: Thu, 20 Feb 2014 14:44:02 +0000 Message-ID: References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> <20140220104925.GC18837@elstar.local> <75C0E47A1889264493A2DCB2869AC09633BDAB7E@xmb-rcd-x15.cisco.com> In-Reply-To: <75C0E47A1889264493A2DCB2869AC09633BDAB7E@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/RjXre1DgXYnFvBO66ynbV-5PRCs Cc: 'Brian Trammell' , "'lmap@ietf.org'" Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:44:18 -0000 Aamer, That's pretty cool, I hadn't seen that document approach. I don't think all the vendors would want to match any specific test lifecyc= le management schema, originally I hoped that we'd provide them a list of t= ests with attributes that they could run and the scheduling would be left u= p to them. But what I've proposed is for test overlap avoidance between two different = schedulers on the same box so although this is a good way to schedule, unle= ss all tests are run under a single MA that won't help. But this is a nice= framework. Thanks, Mike -----Original Message----- From: Aamer Akhter (aakhter) [mailto:aakhter@cisco.com]=20 Sent: Thursday, February 20, 2014 7:02 AM To: Bugenhagen, Michael K; 'Juergen Schoenwaelder' Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: RE: [lmap] Fwd: determining passive vs. active nature of measureme= nt task Hi Michael, There are multiple approaches to the problem. In fact this reminds me of th= e IPSLA group scheduling feature, which is used for more dispersed scheduli= ng to relieve (among other things) local CPU contention. http://www.cisco.com/c/en/us/td/docs/ios/ipsla/configuration/guide/15_s/sla= _15_0s_book/sla_multi_scheduler.html That said, there may be constraints in the test request itself such that a = delayed/early test is just not acceptable either. aa -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael = K Sent: Thursday, February 20, 2014 6:21 AM To: 'Juergen Schoenwaelder' Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: Re: [lmap] Fwd: determining passive vs. active nature of measureme= nt task The MA / Probe vendors, and even existing testing standards vendors haven't= fixed it by working together or making a overlapping test schema. We could very easily slightly modify the MA resource check in both the IETF= & BBF to look for resource use collision. The "watch for transit traffic" in-fact suggests avoiding overlapping test = collisions. If we apply the same "collision domain" avoidance principle to the CPU & Me= mory use we would then create a MA framework that all independent MA's coul= d avoid collisions, much like the same way MAC ports us Collision detection= . Agreeable ? -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, February 20, 2014 4:49 AM To: Bugenhagen, Michael K Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: Re: [lmap] Fwd: determining passive vs. active nature of measureme= nt task On Thu, Feb 20, 2014 at 10:43:17AM +0000, Bugenhagen, Michael K wrote: > Also there is the "multi-MA" overlapping test issue that I mentioned earl= ier. >=20 > One way to handle this is "only one MA" per element - Another would=20 > be (more complicated) something inter-probe but then we'd have to boil th= e ocean with all the different existing probe server functions. >=20 > My preference is overlapping test avoidance is the Assumption of one MA p= er device. >=20 This is an implementation issue and the framework should stay silent about = the packaging. I believe it is possible to build 'elements' or 'devices' (all not well def= ined terms anyway) that can host multiple MAs without causing resource cont= ention as much as I believe it is possible that build 'elements' or 'device= s' that host only a single MA that suffers from resource shortage. The mark= et will sort this out. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Feb 20 06:48:29 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6171A01B3 for ; Thu, 20 Feb 2014 06:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZBeOO-RVtI7 for ; Thu, 20 Feb 2014 06:48:25 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 62B321A0195 for ; Thu, 20 Feb 2014 06:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4297; q=dns/txt; s=iport; t=1392907702; x=1394117302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5+SoVUEtjtD0vUHJq2QtC2BS9cBCLox9pxNyOPCXPYE=; b=Sa+20Sn1xUS6kDzzBI2PbOUqpH4aSajnzXVW/msviaLWTiRKjial7uvo t/pW2Z/p9y0yNw9GlZfstfapXUQxefJmXV333Tf1NdZySdzrB4p6qs6Oz BffFMfwN4Z2AWIDaCnUzeNcrgsEQji2fQJ7Fs7Bni1/TNUD898jKbP2EX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALwUBlOtJV2c/2dsb2JhbABWA4MGOFfAC4EOFnSCJQEBAQQBAQE3NAsMAgICAQgQAQQBAQEKFAkHGwwLFAkIAgQBDQUIh30Nzi8XBI4vIRACBQYLgxOBFASqVIMtgio X-IronPort-AV: E=Sophos;i="4.97,512,1389744000"; d="scan'208";a="21897855" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 20 Feb 2014 14:48:21 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1KEmLLL015265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 14:48:21 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.9]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 08:48:21 -0600 From: "Aamer Akhter (aakhter)" To: "Bugenhagen, Michael K" , "'Juergen Schoenwaelder'" Thread-Topic: [lmap] Fwd: determining passive vs. active nature of measurement task Thread-Index: AQHPLilzvacLa29z6USbrG4pdK91VZq+ZAkA//+2rLCAAIHxAP//nEpQ Date: Thu, 20 Feb 2014 14:48:21 +0000 Message-ID: <75C0E47A1889264493A2DCB2869AC09633BDB81C@xmb-rcd-x15.cisco.com> References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> <20140220104925.GC18837@elstar.local> <75C0E47A1889264493A2DCB2869AC09633BDAB7E@xmb-rcd-x15.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.25.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/yqEN-zgNlqP83vViR_8SfmbtY6k Cc: 'Brian Trammell' , "'lmap@ietf.org'" Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:48:29 -0000 Indeed- the group scheduling approach does needs common scheduler :-)=20 -----Original Message----- From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com]=20 Sent: Thursday, February 20, 2014 9:44 AM To: Aamer Akhter (aakhter); 'Juergen Schoenwaelder' Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: RE: [lmap] Fwd: determining passive vs. active nature of measureme= nt task Aamer, That's pretty cool, I hadn't seen that document approach. I don't think all the vendors would want to match any specific test lifecyc= le management schema, originally I hoped that we'd provide them a list of t= ests with attributes that they could run and the scheduling would be left u= p to them. But what I've proposed is for test overlap avoidance between two different = schedulers on the same box so although this is a good way to schedule, unle= ss all tests are run under a single MA that won't help. But this is a nice= framework. Thanks, Mike -----Original Message----- From: Aamer Akhter (aakhter) [mailto:aakhter@cisco.com] Sent: Thursday, February 20, 2014 7:02 AM To: Bugenhagen, Michael K; 'Juergen Schoenwaelder' Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: RE: [lmap] Fwd: determining passive vs. active nature of measureme= nt task Hi Michael, There are multiple approaches to the problem. In fact this reminds me of th= e IPSLA group scheduling feature, which is used for more dispersed scheduli= ng to relieve (among other things) local CPU contention. http://www.cisco.com/c/en/us/td/docs/ios/ipsla/configuration/guide/15_s/sla= _15_0s_book/sla_multi_scheduler.html That said, there may be constraints in the test request itself such that a = delayed/early test is just not acceptable either. aa -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael = K Sent: Thursday, February 20, 2014 6:21 AM To: 'Juergen Schoenwaelder' Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: Re: [lmap] Fwd: determining passive vs. active nature of measureme= nt task The MA / Probe vendors, and even existing testing standards vendors haven't= fixed it by working together or making a overlapping test schema. We could very easily slightly modify the MA resource check in both the IETF= & BBF to look for resource use collision. The "watch for transit traffic" in-fact suggests avoiding overlapping test = collisions. If we apply the same "collision domain" avoidance principle to the CPU & Me= mory use we would then create a MA framework that all independent MA's coul= d avoid collisions, much like the same way MAC ports us Collision detection= . Agreeable ? -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, February 20, 2014 4:49 AM To: Bugenhagen, Michael K Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: Re: [lmap] Fwd: determining passive vs. active nature of measureme= nt task On Thu, Feb 20, 2014 at 10:43:17AM +0000, Bugenhagen, Michael K wrote: > Also there is the "multi-MA" overlapping test issue that I mentioned earl= ier. >=20 > One way to handle this is "only one MA" per element - Another would=20 > be (more complicated) something inter-probe but then we'd have to boil th= e ocean with all the different existing probe server functions. >=20 > My preference is overlapping test avoidance is the Assumption of one MA p= er device. >=20 This is an implementation issue and the framework should stay silent about = the packaging. I believe it is possible to build 'elements' or 'devices' (all not well def= ined terms anyway) that can host multiple MAs without causing resource cont= ention as much as I believe it is possible that build 'elements' or 'device= s' that host only a single MA that suffers from resource shortage. The mark= et will sort this out. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Feb 20 06:48:47 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF8D1A0170 for ; Thu, 20 Feb 2014 06:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk9uVk4KL8rO for ; Thu, 20 Feb 2014 06:48:42 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 53C091A01A6 for ; Thu, 20 Feb 2014 06:48:42 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 879A1E84; Thu, 20 Feb 2014 15:48:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2Wxe0NKDx_VV; Thu, 20 Feb 2014 15:48:36 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 20 Feb 2014 15:48:36 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8E8120026; Thu, 20 Feb 2014 15:48:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mzjHxmsc4rti; Thu, 20 Feb 2014 15:48:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4034F20015; Thu, 20 Feb 2014 15:48:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B649A2B6CAF0; Thu, 20 Feb 2014 15:48:32 +0100 (CET) Date: Thu, 20 Feb 2014 15:48:31 +0100 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20140220144829.GB86658@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , 'Brian Trammell' , "'lmap@ietf.org'" References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> <20140220104925.GC18837@elstar.local> <20140220122845.GC19222@elstar.local> <20140220142657.GA86658@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/vTep_WLcNKUwloRe0SZVUg7CkPk Cc: 'Brian Trammell' , "'lmap@ietf.org'" Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:48:45 -0000 Michael, what is 'that' and what is the resource check" functional area? Can you make a concrete text proposal? It helps tremendously in WG processes if discussions lead at some time to concrete actionable proposals. /js On Thu, Feb 20, 2014 at 02:37:59PM +0000, Bugenhagen, Michael K wrote: > I would suggest we add that to the "resource check" functional area for the MA. > > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, February 20, 2014 8:27 AM > To: Bugenhagen, Michael K > Cc: 'Brian Trammell'; 'lmap@ietf.org' > Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task > > On Thu, Feb 20, 2014 at 02:14:47PM +0000, Bugenhagen, Michael K wrote: > > Ok.... I'll try to clarify. > > > > A CPU and Memory can both be utilized by different MA's on the same element (so say the vendors I've worked with). > > The MA's when running therefore dip from the same resource well, so if either the CPU or the Memory utilization gets to high it the entire system slows down. > > So as an abstract concept level - that is a resource pool collision domain. > > > > If there is a "MIB" that indicates Memory Use, and CPU use... > > (assumption) > > > > We can create monitoring logic that watches CPU & Memory utilization > > before a test is conduct (at initiation) And then perform (during the > > test) continuous monitoring of CPU / MEM utilization with Threshold > > crossing event logic > > > > i.e. - ping the CPU / Mem. Utilization every second watching for a Threshold crossing event - which triggers the test to stop and mark test results as invalid. > > In a pyshical appliance this is easy, it's harder in a virtualized probe it's tougher because CPU utilization doesn't reflect congestion directly. > > > > So how do I translate all that back into the framework / information model documents we have? What exact change or addition do you suggest? > Can't this be left to the definition of measurement tasks where this is relevant? (A traceroute likely is not CPU or memory bound, for > example.) I like to understand what in concrete terms is missing or unclear in the WG documents. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Feb 20 08:12:18 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBE31A01D4 for ; Thu, 20 Feb 2014 08:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXrhS3vDCuDv for ; Thu, 20 Feb 2014 08:12:15 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 78D9A1A01D1 for ; Thu, 20 Feb 2014 08:12:15 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1KGCB8k021105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Feb 2014 10:12:11 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 01D3B1E005B; Thu, 20 Feb 2014 10:12:06 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id D9BFF1E0078; Thu, 20 Feb 2014 10:12:05 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1KGC4rj023619; Thu, 20 Feb 2014 10:12:04 -0600 (CST) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1KGC3mg023586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 10:12:04 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 10:12:03 -0600 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" Thread-Topic: [lmap] Fwd: determining passive vs. active nature of measurement task Thread-Index: AQHPLilvcN7+fXJbI0muejudQTDFmZq9+s2QgAB8DYD//6+s4IAAcVqA//+eYQCAAGemgP//sqaQ Date: Thu, 20 Feb 2014 16:12:03 +0000 Message-ID: References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> <20140220104925.GC18837@elstar.local> <20140220122845.GC19222@elstar.local> <20140220142657.GA86658@elstar.local> <20140220144829.GB86658@elstar.local> In-Reply-To: <20140220144829.GB86658@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/sA2NrrgWw00LdCllTLmdCA0j5UE Cc: 'Brian Trammell' , "'lmap@ietf.org'" Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 16:12:17 -0000 I will but I'm at a meeting this week so it will be next week some time - Thanks, Mike -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, February 20, 2014 8:49 AM To: Bugenhagen, Michael K Cc: 'Brian Trammell'; 'lmap@ietf.org' Subject: Re: [lmap] Fwd: determining passive vs. active nature of measureme= nt task Michael, what is 'that' and what is the resource check" functional area? Can you mak= e a concrete text proposal? It helps tremendously in WG processes if discus= sions lead at some time to concrete actionable proposals. /js On Thu, Feb 20, 2014 at 02:37:59PM +0000, Bugenhagen, Michael K wrote: > I would suggest we add that to the "resource check" functional area for t= he MA. >=20 >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, February 20, 2014 8:27 AM > To: Bugenhagen, Michael K > Cc: 'Brian Trammell'; 'lmap@ietf.org' > Subject: Re: [lmap] Fwd: determining passive vs. active nature of=20 > measurement task >=20 > On Thu, Feb 20, 2014 at 02:14:47PM +0000, Bugenhagen, Michael K wrote: > > Ok.... I'll try to clarify. > >=20 > > A CPU and Memory can both be utilized by different MA's on the same ele= ment (so say the vendors I've worked with). > > The MA's when running therefore dip from the same resource well, so if = either the CPU or the Memory utilization gets to high it the entire system = slows down. > > So as an abstract concept level - that is a resource pool collision dom= ain. > >=20 > > If there is a "MIB" that indicates Memory Use, and CPU use...=20 > > (assumption) > >=20 > > We can create monitoring logic that watches CPU & Memory utilization=20 > > before a test is conduct (at initiation) And then perform (during=20 > > the > > test) continuous monitoring of CPU / MEM utilization with Threshold=20 > > crossing event logic > > =09 > > i.e. - ping the CPU / Mem. Utilization every second watching for a Thr= eshold crossing event - which triggers the test to stop and mark test resul= ts as invalid. > > In a pyshical appliance this is easy, it's harder in a virtualized pr= obe it's tougher because CPU utilization doesn't reflect congestion directl= y. > >=20 >=20 > So how do I translate all that back into the framework / information mode= l documents we have? What exact change or addition do you suggest? > Can't this be left to the definition of measurement tasks where this=20 > is relevant? (A traceroute likely is not CPU or memory bound, for > example.) I like to understand what in concrete terms is missing or uncle= ar in the WG documents. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 21 03:51:55 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E2B1A0528 for ; Fri, 21 Feb 2014 03:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy7gz22i1z9N for ; Fri, 21 Feb 2014 03:51:50 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 34DC41A0524 for ; Fri, 21 Feb 2014 03:51:50 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 21 Feb 2014 11:50:31 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 21 Feb 2014 11:51:28 +0000 From: To: , Date: Fri, 21 Feb 2014 11:51:28 +0000 Thread-Topic: [lmap] Fwd: determining passive vs. active nature of measurement task Thread-Index: AQHPLilvcN7+fXJbI0muejudQTDFmZq9+s2QgAB8DYD//6+s4IAAcVqA//+eYQCAAGemgP//sqaQACjJsxA= Message-ID: References: <4F4FB431-DFA3-46DE-9A52-AE082804A751@trammell.ch> <20140220104925.GC18837@elstar.local> <20140220122845.GC19222@elstar.local> <20140220142657.GA86658@elstar.local> <20140220144829.GB86658@elstar.local> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/d7212pM462RJP76-Lzlr6zuszVQ Cc: ietf@trammell.ch, lmap@ietf.org Subject: Re: [lmap] Fwd: determining passive vs. active nature of measurement task X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 11:51:53 -0000 The current text on "Starting and stopping Measurement Tasks" is in S5.3. The start of this section says: The LMAP WG is neutral to what the actual Measurement Task is. The WG does not define a generic start and stop process, since the correct approach depend on the particular Measurement Task; the details are defined as part of each Measurement Method, and hence potentially by the IPPM WG. I'm sceptical that a memory & cpu check would be needed in practice before = every time the MA runs a test. After all, the operator of the measurement s= ystem knows the capability of the devices on which it deploys an MA, can do= checks in the labs before deployment, and can be cautious about not hittin= g the device hard. for me, if the resources like cpu and memory run short, = then that's a failure condition and not a temporary 'do not run this test a= t the moment' Indeed, as S4.2 says This simplifies the design of MAs (critical for a large-scale infrastructure) and allows a Measurement Schedule to be tested on specific types of MA before deployment to ensure that the end user experience is not impacted (due to CPU, memory or broadband-product constraints). And S5.2.0 (near end) says The MA can inform the Controller about a Failure. There are two broad categories of failure: ... (2) the MA cannot execute the Measurement Task or deliver the Report (for example, the MA unexpectedly has no spare CPU cycles; or the Collector is not responding). Note that it is not considered a failure if a Measurement Task (correctly) doesn't start; for example if the MA detects cross-traffic, this is reported to the Collector in the normal manner. Best wishes, phil=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, > Michael K > Sent: 20 February 2014 16:12 > To: 'Juergen Schoenwaelder' > Cc: 'Brian Trammell'; 'lmap@ietf.org' > Subject: Re: [lmap] Fwd: determining passive vs. active nature of > measurement task >=20 > I will but I'm at a meeting this week so it will be next week some time > - >=20 > Thanks, > Mike >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, February 20, 2014 8:49 AM > To: Bugenhagen, Michael K > Cc: 'Brian Trammell'; 'lmap@ietf.org' > Subject: Re: [lmap] Fwd: determining passive vs. active nature of > measurement task >=20 > Michael, >=20 > what is 'that' and what is the resource check" functional area? Can you > make a concrete text proposal? It helps tremendously in WG processes if > discussions lead at some time to concrete actionable proposals. >=20 > /js >=20 > On Thu, Feb 20, 2014 at 02:37:59PM +0000, Bugenhagen, Michael K wrote: > > I would suggest we add that to the "resource check" functional area > for the MA. > > > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, February 20, 2014 8:27 AM > > To: Bugenhagen, Michael K > > Cc: 'Brian Trammell'; 'lmap@ietf.org' > > Subject: Re: [lmap] Fwd: determining passive vs. active nature of > > measurement task > > > > On Thu, Feb 20, 2014 at 02:14:47PM +0000, Bugenhagen, Michael K > wrote: > > > Ok.... I'll try to clarify. > > > > > > A CPU and Memory can both be utilized by different MA's on the same > element (so say the vendors I've worked with). > > > The MA's when running therefore dip from the same resource well, so > if either the CPU or the Memory utilization gets to high it the entire > system slows down. > > > So as an abstract concept level - that is a resource pool collision > domain. > > > > > > If there is a "MIB" that indicates Memory Use, and CPU use... > > > (assumption) > > > > > > We can create monitoring logic that watches CPU & Memory > utilization > > > before a test is conduct (at initiation) And then perform (during > > > the > > > test) continuous monitoring of CPU / MEM utilization with Threshold > > > crossing event logic > > > > > > i.e. - ping the CPU / Mem. Utilization every second watching for a > Threshold crossing event - which triggers the test to stop and mark > test results as invalid. > > > In a pyshical appliance this is easy, it's harder in a > virtualized probe it's tougher because CPU utilization doesn't reflect > congestion directly. > > > > > > > So how do I translate all that back into the framework / information > model documents we have? What exact change or addition do you suggest? > > Can't this be left to the definition of measurement tasks where this > > is relevant? (A traceroute likely is not CPU or memory bound, for > > example.) I like to understand what in concrete terms is missing or > unclear in the WG documents. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Feb 21 06:04:33 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346771A01C4 for ; Fri, 21 Feb 2014 06:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Md31Nh_9sZcD for ; Fri, 21 Feb 2014 06:04:30 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3B69F1A030C for ; Fri, 21 Feb 2014 06:04:30 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id aec57035.2ac0dc866940.5272290.00-2431.14794036.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 21 Feb 2014 14:04:26 +0000 (UTC) X-MXL-Hash: 53075cea78a0907a-d20aa4323332b47159e21b77083de82f25364570 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 7ec57035.0.5272269.00-2189.14793959.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 21 Feb 2014 14:04:25 +0000 (UTC) X-MXL-Hash: 53075ce905fd0228-39285b838d6c18624b374342262c06efca1bc692 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LE4Mem012477; Fri, 21 Feb 2014 09:04:23 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LE4JnC012441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 09:04:20 -0500 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 21 Feb 2014 14:03:57 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 09:03:54 -0500 From: "STARK, BARBARA H" To: "Weil, Jason" , "MORTON JR., AL" , Juergen Schoenwaelder , "philip.eardley@bt.com" Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8tlhV3TNdpUpq+Qpm+Dna82yWzGQAVWfYAAAGC+4AAB267AAA+u1HQ Date: Fri, 21 Feb 2014 14:03:54 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303EC06E@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2845723087023D4CB5114223779FA9C8BC2BCF3A@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.121.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=cecMfMTh3BkA:10 a=ofMgfj31e3cA:10 a=HyTqpmEkfWEA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=rrdmgw4RE7AA:10 a=EDQGsj66vZJtp381yDMA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2O7ZEO8L9nYpi50Gipb3679J1dk Cc: "lmap@ietf.org" Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:04:32 -0000 > I was thinking more of a may operation. If the data is available you may = want > to send it up with the measurement info in the Report Protocol. The way i= t > reads now this is not supported at all. If this is the case we should exp= licitly > state that as well. >=20 > Jason Going back to what Jason said... The framework already says: "5.4. Report Protocol The primary purpose of the Report Protocol is to allow a Measurement Agent to report its Measurement Results to a Collector, and the context in which they were obtained." It then has a bulleted list about what the Report contains. I think if we a= dded another bullet that said something like: - the context in which the Measurement Results were obtained, where the de= tails of which (if any) context to include are dependent on implementation = and Measurement Method/Task And then later in the same section (maybe at the end) if we added a paragra= ph that said something like: The context in which Measurement Results are obtained may include attribute= s related to an end user's service (e.g., subscribed data rate) as well as = information related to the conditions that existed when the Measurement Tas= k took place (e.g., resource utilization on the physical device where the M= A resides). How such information may be obtained is outside the scope of th= e LMAP WG. Which contextual information to include in a Report is specific = to the MA implementation and the Measurement Methods / Tasks. -------------- Information Model I think there still needs to be a discussion regarding what to include in t= he Information Model related to this contextual information. But I don't fe= el ready to have that conversation here now. I think I'll be ready in about= a month. Barbara From nobody Fri Feb 21 06:45:41 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D77E1A032C for ; Fri, 21 Feb 2014 06:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGi571Mv6SNt for ; Fri, 21 Feb 2014 06:45:36 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 012211A035E for ; Fri, 21 Feb 2014 06:45:35 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 21 Feb 2014 14:45:45 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 21 Feb 2014 14:45:23 +0000 From: To: , , , Date: Fri, 21 Feb 2014 14:45:22 +0000 Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8tlhV3TNdpUpq+Qpm+Dna82yWzGQAVWfYAAAGC+4AAB267AAA+u1HQAAITgRA= Message-ID: References: <2845723087023D4CB5114223779FA9C8BC2BCF3A@njfpsrvexg8.research.att.com> <2D09D61DDFA73D4C884805CC7865E611303EC06E@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303EC06E@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/GPc5xIC675FzGRxDddM261T5T5o Cc: lmap@ietf.org Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:45:39 -0000 Now I engage my brain, I remember (I think) that a while back we agreed tha= t enhancing measurement data with subscriber info was a post collector acti= vity.=20 However, Barbara's text works for me. I think it's also worth adding a note= that subscriber /line information can be enhanced post collection - in the= Repository or Data collection tools (in Figure 1 of the framework). Framework-03 almost says this already: =20 A results repository records all Measurement Results in an equivalent form, for example an SQL database, so that they can easily be accessed by the data analysis tools. The data analysis tools also need to understand the Subscriber's service information, for example the broadband contract. phil > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: 21 February 2014 14:04 > To: Weil, Jason; MORTON JR., AL; Juergen Schoenwaelder; > Eardley,PL,Philip,TUB8 R > Cc: lmap@ietf.org > Subject: RE: [lmap] Reporting of service parameters (WGLC comments on > draft-ietf-lmap-framework-03) >=20 > > I was thinking more of a may operation. If the data is available you > > may want to send it up with the measurement info in the Report > > Protocol. The way it reads now this is not supported at all. If this > > is the case we should explicitly state that as well. > > > > Jason >=20 > Going back to what Jason said... > The framework already says: >=20 > "5.4. Report Protocol >=20 > The primary purpose of the Report Protocol is to allow a Measurement > Agent to report its Measurement Results to a Collector, and the > context in which they were obtained." >=20 > It then has a bulleted list about what the Report contains. I think if > we added another bullet that said something like: > - the context in which the Measurement Results were obtained, where > the details of which (if any) context to include are dependent on > implementation and Measurement Method/Task >=20 > And then later in the same section (maybe at the end) if we added a > paragraph that said something like: > The context in which Measurement Results are obtained may include > attributes related to an end user's service (e.g., subscribed data > rate) as well as information related to the conditions that existed > when the Measurement Task took place (e.g., resource utilization on the > physical device where the MA resides). How such information may be > obtained is outside the scope of the LMAP WG. Which contextual > information to include in a Report is specific to the MA implementation > and the Measurement Methods / Tasks. >=20 > -------------- > Information Model > I think there still needs to be a discussion regarding what to include > in the Information Model related to this contextual information. But I > don't feel ready to have that conversation here now. I think I'll be > ready in about a month. >=20 > Barbara From nobody Fri Feb 21 06:57:47 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC621A0198 for ; Fri, 21 Feb 2014 06:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdhAMZ3gc7Hs for ; Fri, 21 Feb 2014 06:57:45 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 51DF11A0179 for ; Fri, 21 Feb 2014 06:57:45 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 56967035.2b8700626940.2497179.00-2456.7042826.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 21 Feb 2014 14:57:41 +0000 (UTC) X-MXL-Hash: 530769651d41c7ef-de686d93b02fb4f5249abefaa45e252e7d551123 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id b2967035.0.2496670.00-2275.7041351.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 21 Feb 2014 14:56:44 +0000 (UTC) X-MXL-Hash: 5307692c281ebead-c00b74a5ca862941e5cc02e436a8e13792d65dab Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LEuc5p003952; Fri, 21 Feb 2014 09:56:43 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LEuYLc003878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 09:56:35 -0500 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 21 Feb 2014 14:56:20 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 09:56:20 -0500 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "jason.weil@twcable.com" , "MORTON JR., AL" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8tlhV3TNdpUpq+Qpm+Dna82yWzGQAVWfYAAAGC+4AAB267AAA+u1HQAAITgRAAAFLUMA== Date: Fri, 21 Feb 2014 14:56:19 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303EC0CF@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2845723087023D4CB5114223779FA9C8BC2BCF3A@njfpsrvexg8.research.att.com> <2D09D61DDFA73D4C884805CC7865E611303EC06E@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.121.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OL2QK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=cecMfMTh3BkA:10 a=ofMgfj31e3cA:10 a=HyTqpmEkfWEA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=rrdmgw4RE7AA:10 a=PVIQ5__wEiG6NjIiz5kA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/KW4DGhAt613o3A_X_sIif2EeG_Q Cc: "lmap@ietf.org" Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:57:47 -0000 > Now I engage my brain, I remember (I think) that a while back we agreed > that enhancing measurement data with subscriber info was a post collector > activity. Minor nit to this remembrance... My remembrance was that we agreed that this *could* be a post collector act= ivity, or it *could* be done by the MA and attached to reported results. An= d that lmap would not try to preclude or mandate how this would be accompli= shed, or define any method for acquiring the subscriber info. But I think t= hat the Report does need to *allow* for inclusion of such information, or e= lse it would effectively be precluding the MA-attachment model. Since you said you were ok with my suggested text, and my suggestion was to= allow for this inclusion, I'm hoping we're ok. Barbara From nobody Fri Feb 21 07:07:23 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BE51A02DF for ; Fri, 21 Feb 2014 07:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyMHuSUKvFYC for ; Fri, 21 Feb 2014 07:07:20 -0800 (PST) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 552FF1A02CC for ; Fri, 21 Feb 2014 07:07:20 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,519,1389762000"; d="scan'208";a="62967461" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Feb 2014 10:06:38 -0500 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.33]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 21 Feb 2014 10:06:56 -0500 From: "Weil, Jason" To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "MORTON JR., AL" , "j.schoenwaelder@jacobs-university.de" Date: Fri, 21 Feb 2014 10:06:55 -0500 Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8vFo+lp3JKfBO0TlOQm2o5fmoVPw== Message-ID: In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303EC0CF@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/fKjpq1d0gb2qFaSg26__tBTO6nQ Cc: "lmap@ietf.org" Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:07:22 -0000 I am inline with Barbara's thinking on this point so if the current text works then I am ok on this point as well. Jason On 2/21/14 9:56 AM, "STARK, BARBARA H" wrote: >> Now I engage my brain, I remember (I think) that a while back we agreed >> that enhancing measurement data with subscriber info was a post >>collector >> activity. > >Minor nit to this remembrance... >My remembrance was that we agreed that this *could* be a post collector >activity, or it *could* be done by the MA and attached to reported >results. And that lmap would not try to preclude or mandate how this >would be accomplished, or define any method for acquiring the subscriber >info. But I think that the Report does need to *allow* for inclusion of >such information, or else it would effectively be precluding the >MA-attachment model. > >Since you said you were ok with my suggested text, and my suggestion was >to allow for this inclusion, I'm hoping we're ok. >Barbara > >_______________________________________________ >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 nobody Fri Feb 21 07:15:29 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874211A01AB for ; Fri, 21 Feb 2014 07:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRNIVO1Ya8Qm for ; Fri, 21 Feb 2014 07:15:17 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7186D1A0316 for ; Fri, 21 Feb 2014 07:15:16 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DD4B8FA3; Fri, 21 Feb 2014 16:15:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id H8YghvZ3sKIw; Fri, 21 Feb 2014 16:15:10 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 21 Feb 2014 16:15:10 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C503A20015; Fri, 21 Feb 2014 16:15:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WV6nOImBx_8O; Fri, 21 Feb 2014 16:15:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81A1020027; Fri, 21 Feb 2014 16:15:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3A27C2B7029D; Fri, 21 Feb 2014 16:15:06 +0100 (CET) Date: Fri, 21 Feb 2014 16:15:06 +0100 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140221151506.GA92858@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "jason.weil@twcable.com" , "MORTON JR., AL" , "lmap@ietf.org" References: <2845723087023D4CB5114223779FA9C8BC2BCF3A@njfpsrvexg8.research.att.com> <2D09D61DDFA73D4C884805CC7865E611303EC06E@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611303EC0CF@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303EC0CF@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/21pUHuqrHFsqKODIe8ZMWP6HW2A Cc: "philip.eardley@bt.com" , "lmap@ietf.org" , "MORTON JR., AL" , "jason.weil@twcable.com" Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:15:23 -0000 On Fri, Feb 21, 2014 at 02:56:19PM +0000, STARK, BARBARA H wrote: > > Now I engage my brain, I remember (I think) that a while back we agreed > > that enhancing measurement data with subscriber info was a post collector > > activity. > > Minor nit to this remembrance... > My remembrance was that we agreed that this *could* be a post collector activity, or it *could* be done by the MA and attached to reported results. And that lmap would not try to preclude or mandate how this would be accomplished, or define any method for acquiring the subscriber info. But I think that the Report does need to *allow* for inclusion of such information, or else it would effectively be precluding the MA-attachment model. > I am worried about the word 'attached' or 'attachment'. I would see this as separate result records generated by a subscriber info measurement task. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 21 08:48:15 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5281A04D5 for ; Fri, 21 Feb 2014 08:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqF7TgrFHe_9 for ; Fri, 21 Feb 2014 08:48:09 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 41B1B1A01F3 for ; Fri, 21 Feb 2014 08:48:09 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 21 Feb 2014 16:46:50 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Fri, 21 Feb 2014 16:47:28 +0000 From: To: , Date: Fri, 21 Feb 2014 16:47:26 +0000 Thread-Topic: Working Group Last Call for http://www.ietf.org/id/draft-ietf-lmap-use-cases-02.txt Thread-Index: Ac8o2AJS6aCwsIm0Qm+Xzcg0odywXwGRyZvw Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA2E40ADF3@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E40ADF3@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AC2996E0EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/uOe5mt0k8DlCa2bnjmLSXBxctq8 Subject: Re: [lmap] Working Group Last Call for http://www.ietf.org/id/draft-ietf-lmap-use-cases-02.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 16:48:14 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AC2996E0EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks good to me, I think it's ready to submit to iesg Couple of minor comments 1.1 Key words - don't think this section is needed 2 Use cases The first para read a little awkwardly to me. Suggested re-phrasing: 2 Use C= ases From the LMAP perspective, there is no difference between fixed service and mobile (cellular) service used for Internet access. Hence, like measurements will take place on both fixed and mobile networks. Fixed services, commonly known as "Last Mile" include technologies like DSL, Cable, and Carrier Ethernet. Mobile services include all those advertised as 2G, 3G, 4G, and LTE. A metric defined to measure end-to-end services will execute similarly on all access technologies. Other metrics may be acces= s technology specific. The LMAP architecture also covers both IPv4 and IPv6 networks. 2.1 first para Delete In addition they may also desire visibility of their competitor's networks and services in order to be able to benchmark and improve their own offerings. This is a niche possibility. I think it is misleading to include this, espe= cially in the overview of the use case in Section 2. Benchmarking is discus= sed extensively in the Regulators section, which I think is the right place 2.2 penultimate para Regulators role in the development and enforcement of broadband Internet access service policies also require To A regulator's role in the development and enforcement of broadband Internet access service policies also requires Thanks phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 13 February 2014 16:24 To: lmap@ietf.org Subject: [lmap] Working Group Last Call for http://www.ietf.org/id/draft-ie= tf-lmap-use-cases-02.txt This is a Working Group Last Call for the Internet-Draft 'Large-Scale Broad= band Measurement Use Cases' which can be found at http://www.ietf.org/id/draft-ietf-lmap-use-cases-02.txt. Please send your c= omments about this I-D to the WG mail list until 2/27/13. If you have no c= omments but you believe that the document is ready to be submitted to the I= ESG for consideration as Informational RFC a short mail stating this is als= o welcome. Thanks and Regards, Dan --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AC2996E0EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Looks good to me, I think it’s = ready to submit to iesg

     

    Co= uple of minor comments

     

    1.1   Key words – don= 217;t think this section is needed

     

    2 Use cases

    The first para read a little awk= wardly to me. Suggested re-phrasing:

     =

     

    2  Use Cases

       From the LMAP persp= ective, there is no

       difference between fixed service and mobile (cellul= ar) service used

       for Internet access.  Hence, like measurements wi= ll take place on

       both fixed and mobile networks.  Fixed services, = commonly known as

       "Last Mile" include technologies like DSL, = Cable, and Carrier

       Ethernet.  Mobile services include all those ad= vertised as 2G, 3G,

       4G, and LTE.  A metric defined to measure end-= to-end services will

       execute similarly on all access technologies. Othe= r metrics may be access technology specific. The LMAP architecture

       also= covers both IPv4 and IPv6 networks.

     

     

    2.1 first para

    Delete

    In addition they may also desire visibilit= y of their

       competitor's networks and services in order to be able = to benchmark

       and improve their own offerings.

    = This is a niche possibility. I think it is misleading to include this, espe= cially in the overview of the use case in Section 2. Benchmarking is discus= sed extensively in the Regulators section, which I think is the right place=

    <= span lang=3DEN style=3D'font-family:"Times New Roman","serif"'> <= /o:p>

    2.2 penultimat= e para

    Re= gulators role in the development and enforcement of broadband

       Internet= access service policies also require

    To

    A regulator’s role in the development and enfo= rcement of broadband

       Internet access service policies also requires

    <= span lang=3DEN style=3D'font-family:"Times New Roman","serif"'> <= /o:p>

    Thanks

    phil<= /span>

     

     

     

    From: lmap [mailto:lmap-bounces@ietf.org] On B= ehalf Of Romascanu, Dan (Dan)
    Sent: 13 February 2014 16:24To: lmap@ietf.org
    Subject: [lmap] Working Group Last Call= for http://www.ietf.org/id/draft-ietf-lmap-use-cases-02.txt

     

    This is a Working Group Last Call for the Internet-Draft ‘L=
arge-Scale Broadband Measurement Use Cases’ which can be found at

    http://www.ietf.org/i= d/draft-ietf-lmap-use-cases-02.txt. Please send your comments about thi= s I-D to the WG mail list until 2/27/13.  If you have no comments but = you believe that the document is ready to be submitted to the IESG for cons= ideration as Informational RFC a short mail stating this is also welcome. <= o:p>

     

    Thanks and Regards,

     

    Dan<= /p>

     

    = --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AC2996E0EMV67UKRDdoma_-- From nobody Fri Feb 21 09:04:38 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6791A0443 for ; Fri, 21 Feb 2014 09:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PyfQ-CXfErZ for ; Fri, 21 Feb 2014 09:04:30 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9068E1A0208 for ; Fri, 21 Feb 2014 09:04:29 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 21 Feb 2014 17:03:11 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 21 Feb 2014 17:04:24 +0000 From: To: Date: Fri, 21 Feb 2014 17:04:22 +0000 Thread-Topic: Channels (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8sj7u09pKTiHtDRoCijNvN4PBsBgCleWxg Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/hDGPlPtV1grCnDzuzEFegauEBh8 Subject: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:04:33 -0000 Thanks Juergen and others for the comments on Channels. I agree the terms aren't good and like your suggestions. So we have Instruction Channel, Capabilities and Failure Information Channe= l, and Report Channel. Also been a suggestion of 'Logging' rather than 'Failure' (I prefer the lat= ter; Juergen prefers the former. I don't think this matters much - will jus= t do a straw poll in London, hope this is ok.) A Channel is one-way, hence the difference between the Instruction Channel = (Controller to MA) and Capabilities and Failure Information Channel (MA to = Controller). As to the question of splitting the latter into two: a Capabilities Channel= and a Failure Information Channel. I think a Channel is basically conceptu= al at this stage, so it doesn't matter. At the current level of analysis, i= t's from MA to Controller and both have info sent asynchronously (Capabilit= ies info could also be sent in response to a request by the controller), so= I don't see any point splitting it in two. Maybe when we design the protoc= ol, it turns out that two different protocols are needed. Of course, people= may be several steps ahead of me and know that it _will_ need two protocol= s (this would be interesting to learn about!) The mention of 'suppression channel' is indeed a remnant - will delete. Thanks phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: 07 February 2014 16:26 > To: lmap@ietf.org > Subject: [lmap] review of draft-ietf-lmap-framework-03 >=20 > Hi, >=20 > I think the document is generally in a good shape. I do only have a=20 > few technical comments: >=20 > a] I do not like the term MA-to-Controller channel. The situation is a > bit complicated to explain. So let me go through a couple of > definitions in order to explain why I think the terms we have are > confusing: >=20 > A Control Protocol "delivering Instruction(s) from a Controller > to a Measurement Agent" and it "delivers Failure Information and > Capabilities Information from the Measurement Agent to the > Controller." >=20 > A Control Channel is a channel "over which Instructions are > sent." So this is really an instruction channel somewhat > mis-labelled as an Control Channel. >=20 > A MA-to-Controller Channel is a channel over which Capabilities > and Failure Information is sent. I think it would be more > consistent to call it a Capabilities and Failure Information > Channel. >=20 > So if we keep the separation of the channels as they are defined, I > would suggest to rename Control Channel to Instruction Channel and > MA-to-Controller Channel to Capabilities and Failure Information > Channel. >=20 > That said, one can ask what the value is of defining two channels > for the Control Protocol. Since the Control Protocol carries three > different things, why are two of them in one channel and the third > in a separate channel? Would it not make sense to either have three > separate channels (Instruction Channel, Capabilities Channel, > Failure Information Channel) or, alternatively, to have just one > Control Channel? What is in the document right now does not seem to > be very consistent. >=20 > > If I were to use lets say NETCONF, then Instruction and=20 > Capabilities > would likely be carried over one "channel" while Failure=20 > Information > would likely be carried over a separate notification "channel". I=20 > am > mentioning this just as an example to demonstrate why the current > distinction seems somewhat arbitrary. > >=20 > As far as I am concerned, my preference is that the terminology has > a since conceptual Control Channel that carries Instructions, > Capabilities, and Failure Information. I can also live with having > three distinct conceptual channels (Instruction Channel, > Capabilities Channel, Failure Information Channel) between the MA > and the Controller. >=20 > b] The figure on page 14 mentions a "Suppression Channel" which I > think is a leftover and should be removed. There is also text > talking about a different channel for Suppressions on page 14. >=20 > c] The definition of Capabilities mentions "interface type and speed > and its IP address" as examples. The text on page 16 says "Note > that Capabilities do not include dynamic information like the MA's > currently unused CPU, memory or battery life." For many devices, > the set of IP addresses assigned to an interface is pretty much > dynamic information, consider for example temporary IPv6 addresses > with Randomized Interface Identifiers. My proposal is to (a) add > text to the definition of Capabilities clarifying that Capabilities > do not include dynamic information and (b) to remove IP address > from the examples mentioned in the Capabilities definition. >=20 > d] I do not understand the {Comment} on page 20. Overlapping > measurement tasks may be fine, it really depends on what the tasks > actually do. I do not think a protocol document can resolve this. > I sugges to simply remove the {Comment}. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Feb 21 10:25:33 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED031A022B for ; Fri, 21 Feb 2014 10:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqiBcL9YPMER for ; Fri, 21 Feb 2014 10:25:30 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5997D1A0245 for ; Fri, 21 Feb 2014 10:25:30 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 61a97035.2ac0a9e15940.5448813.00-2458.15300222.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 21 Feb 2014 18:25:26 +0000 (UTC) X-MXL-Hash: 53079a166faacaf9-b4a4d389c3b90342d07b0c8cda3643501dea4ac9 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 01a97035.0.5448721.00-2368.15299973.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 21 Feb 2014 18:25:21 +0000 (UTC) X-MXL-Hash: 53079a1147fb3a45-2bcea964de1559cafbf3fdf3245023d7ea2b4813 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LIPJoc007930; Fri, 21 Feb 2014 13:25:19 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LIPFh9007900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 13:25:16 -0500 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 21 Feb 2014 18:25:00 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 13:25:00 -0500 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Channels (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8sj7u09pKTiHtDRoCijNvN4PBsBgCleWxgAAJn/dA= Date: Fri, 21 Feb 2014 18:25:00 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303EC384@GAALPA1MSGUSR9L.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.121.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=uqi3naUUzQUA:10 a=ofMgfj31e3cA:10 a=HyTqpmEkfWEA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=gWR9lkOfTb4A:10 a=E097MgXK9YGB-4SOCCYA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/92j70r0T2MEJ5e1oQ1xwtVHyUFQ Subject: Re: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:25:32 -0000 > I agree the terms aren't good and like your suggestions. > So we have Instruction Channel, Capabilities and Failure Information > Channel, and Report Channel. I prefer Juergen's other suggestion of a single Control Channel. [See text = snipped below.] > A Channel is one-way, hence the difference between the Instruction > Channel (Controller to MA) and Capabilities and Failure Information Chann= el > (MA to Controller). I find this confusing. If the Controller wants to ask the MA to tell the Co= ntroller the MA's current Measurement Task Configurations and Measurement S= chedules (for example, when a MA first communicates with a new Controller, = the Controller may want to know about the existing Instructions so it can j= ust send updates and not have to send the entire set of Instructions),=20 1) Is it envisioned that this is possible? (I would actually consider it re= quired of a Control Protocol.) 2) Since the set of current Instructions would go from the MA to the Contro= ller, and the proposed "Instruction Channel" is only Controller to MA, does= this mean that the existing set of Instructions get sent to the Controller= via the Capabilities Channel? I'm having real trouble getting my head arou= nd this unidirectional concept. Client/server architecture I would understa= nd. Grasping the applicability of separate "channels" based on the directio= n information is sent is causing my head to hurt. >From Juergen's email: > > That said, one can ask what the value is of defining two channels > > for the Control Protocol. Since the Control Protocol carries three > > different things, why are two of them in one channel and the third > > in a separate channel? Would it not make sense to either have three > > separate channels (Instruction Channel, Capabilities Channel, > > Failure Information Channel) or, alternatively, to have just one > > Control Channel? What is in the document right now does not seem to > > be very consistent. > > As far as I am concerned, my preference is that the terminology has > > a since conceptual Control Channel that carries Instructions, > > Capabilities, and Failure Information. I can also live with having > > three distinct conceptual channels (Instruction Channel, > > Capabilities Channel, Failure Information Channel) between the MA > > and the Controller. From nobody Fri Feb 21 11:07:48 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CC11A01ED for ; Fri, 21 Feb 2014 11:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikTtqqrhIvLy for ; Fri, 21 Feb 2014 11:07:41 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3A11A0443 for ; Fri, 21 Feb 2014 11:07:40 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 21 Feb 2014 19:07:50 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Fri, 21 Feb 2014 19:07:35 +0000 From: To: , Date: Fri, 21 Feb 2014 19:07:34 +0000 Thread-Topic: Channels (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8sj7u09pKTiHtDRoCijNvN4PBsBgCleWxgAAJn/dAAAgTjIA== Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303EC384@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303EC384@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2882wkTzQ23bj8wDWCrrrXZwuCI Subject: Re: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:07:44 -0000 Yes, Capabilities includes the measurement methods that the MA can do. the Instruction replaces (rather than adds to) the elements that it contain= s (the 5 elements are: configuration of measurement tasks, report channels, p= eriodic schedules, one-off schedules and suppression information.)=20 So if an instruction contains config of measurement tasks, it replaces what= ever measurement task config is in the MA. This was felt to be simpler. Will leave others to comment on the 1 vs 2 vs 3 channels issue. Happy to go= with the consensus. > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: 21 February 2014 18:25 > To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org > Subject: RE: Channels (WGLC comments on draft-ietf-lmap-framework-03) >=20 > > I agree the terms aren't good and like your suggestions. > > So we have Instruction Channel, Capabilities and Failure Information > > Channel, and Report Channel. >=20 > I prefer Juergen's other suggestion of a single Control Channel. [See > text snipped below.] >=20 > > A Channel is one-way, hence the difference between the Instruction > > Channel (Controller to MA) and Capabilities and Failure Information > > Channel (MA to Controller). >=20 > I find this confusing. If the Controller wants to ask the MA to tell > the Controller the MA's current Measurement Task Configurations and > Measurement Schedules (for example, when a MA first communicates with a > new Controller, the Controller may want to know about the existing > Instructions so it can just send updates and not have to send the > entire set of Instructions), > 1) Is it envisioned that this is possible? (I would actually consider > it required of a Control Protocol.) > 2) Since the set of current Instructions would go from the MA to the > Controller, and the proposed "Instruction Channel" is only Controller > to MA, does this mean that the existing set of Instructions get sent to > the Controller via the Capabilities Channel? I'm having real trouble > getting my head around this unidirectional concept. Client/server > architecture I would understand. Grasping the applicability of separate > "channels" based on the direction information is sent is causing my > head to hurt. >=20 > From Juergen's email: > > > That said, one can ask what the value is of defining two > channels > > > for the Control Protocol. Since the Control Protocol carries > three > > > different things, why are two of them in one channel and the > third > > > in a separate channel? Would it not make sense to either have > three > > > separate channels (Instruction Channel, Capabilities Channel, > > > Failure Information Channel) or, alternatively, to have just one > > > Control Channel? What is in the document right now does not seem > to > > > be very consistent. > > > > As far as I am concerned, my preference is that the terminology > has > > > a since conceptual Control Channel that carries Instructions, > > > Capabilities, and Failure Information. I can also live with > having > > > three distinct conceptual channels (Instruction Channel, > > > Capabilities Channel, Failure Information Channel) between the > MA > > > and the Controller. From nobody Fri Feb 21 11:48:56 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0894A1A03EE for ; Fri, 21 Feb 2014 11:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds6ecAWRLK-r for ; Fri, 21 Feb 2014 11:48:52 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id CABC91A021B for ; Fri, 21 Feb 2014 11:48:51 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 73896F84; Fri, 21 Feb 2014 20:48:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id atD5ZQHQLjtx; Fri, 21 Feb 2014 20:48:46 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 21 Feb 2014 20:48:46 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED91520026; Fri, 21 Feb 2014 20:48:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SUAdMfrLxzPe; Fri, 21 Feb 2014 20:48:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FFB120015; Fri, 21 Feb 2014 20:48:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 318282B71127; Fri, 21 Feb 2014 20:48:42 +0100 (CET) Date: Fri, 21 Feb 2014 20:48:42 +0100 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20140221194842.GA94097@elstar.local> Mail-Followup-To: philip.eardley@bt.com, lmap@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9eBhKjzWeP9eN-5WKcDRMtMiS8Q Cc: lmap@ietf.org Subject: Re: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:48:55 -0000 On Fri, Feb 21, 2014 at 05:04:22PM +0000, philip.eardley@bt.com wrote: > Thanks Juergen and others for the comments on Channels. > > I agree the terms aren't good and like your suggestions. > So we have Instruction Channel, Capabilities and Failure Information Channel, and Report Channel. > > Also been a suggestion of 'Logging' rather than 'Failure' (I prefer the latter; Juergen prefers the former. I don't think this matters much - will just do a straw poll in London, hope this is ok.) It is 'Logging' vs 'Failure Information'. First, 'Logging' is shorter and second I assume that say a failure to parse an instruction will not be reported over this channel but lead to an error indication on the Instruction Channel. But yes, I am guessing here, I do not think this is really spelled out. If I am correct, then I would find the name 'Failure Information" potentially misleading. > A Channel is one-way, hence the difference between the Instruction Channel (Controller to MA) and Capabilities and Failure Information Channel (MA to Controller). Is it stated anywhere that a channel is one-way? If that is the assumption behind a channel, this needs to be made explicit. And I assume 'one-way' as far as the information flowing over the channel is concerned. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 21 11:54:29 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB3B1A021B for ; Fri, 21 Feb 2014 11:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSdXAH_adfzn for ; Fri, 21 Feb 2014 11:54:24 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id B64A81A014C for ; Fri, 21 Feb 2014 11:54:24 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Feb 2014 14:54:20 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Feb 2014 14:54:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Feb 2014 14:45:48 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA02B73847@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8sj7u09pKTiHtDRoCijNvN4PBsBgCleWxgAAJn/dAAAgTjIAABRdkQ References: <2D09D61DDFA73D4C884805CC7865E611303EC384@GAALPA1MSGUSR9L.ITServices.sbc.com> From: "Sharam Hakimi" To: , , X-OriginalArrivalTime: 21 Feb 2014 19:54:20.0213 (UTC) FILETIME=[B5D4BE50:01CF2F3E] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/LwDePoqCr1OFUMp40sNaVDf3pIw Subject: Re: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:54:27 -0000 My two cents on this, I am not sure why reports have channels in the 5 elements Phil listed below. I believe it should be report destinations and not channels. I think we need to have two Channels: Control Data Then Instructions, and any control information (Bi-directional) will use the control channel and reports will use the Data channel, Bi-directional. I also agree that defining directional paths/channels is very confusing. Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Friday, February 21, 2014 2:08 PM To: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03) Yes, Capabilities includes the measurement methods that the MA can do. the Instruction replaces (rather than adds to) the elements that it contains (the 5 elements are: configuration of measurement tasks, report channels, periodic schedules, one-off schedules and suppression information.)=20 So if an instruction contains config of measurement tasks, it replaces whatever measurement task config is in the MA. This was felt to be simpler. Will leave others to comment on the 1 vs 2 vs 3 channels issue. Happy to go with the consensus. > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: 21 February 2014 18:25 > To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org > Subject: RE: Channels (WGLC comments on draft-ietf-lmap-framework-03) >=20 > > I agree the terms aren't good and like your suggestions. > > So we have Instruction Channel, Capabilities and Failure Information > > Channel, and Report Channel. >=20 > I prefer Juergen's other suggestion of a single Control Channel. [See > text snipped below.] >=20 > > A Channel is one-way, hence the difference between the Instruction > > Channel (Controller to MA) and Capabilities and Failure Information > > Channel (MA to Controller). >=20 > I find this confusing. If the Controller wants to ask the MA to tell > the Controller the MA's current Measurement Task Configurations and > Measurement Schedules (for example, when a MA first communicates with a > new Controller, the Controller may want to know about the existing > Instructions so it can just send updates and not have to send the > entire set of Instructions), > 1) Is it envisioned that this is possible? (I would actually consider > it required of a Control Protocol.) > 2) Since the set of current Instructions would go from the MA to the > Controller, and the proposed "Instruction Channel" is only Controller > to MA, does this mean that the existing set of Instructions get sent to > the Controller via the Capabilities Channel? I'm having real trouble > getting my head around this unidirectional concept. Client/server > architecture I would understand. Grasping the applicability of separate > "channels" based on the direction information is sent is causing my > head to hurt. >=20 > From Juergen's email: > > > That said, one can ask what the value is of defining two > channels > > > for the Control Protocol. Since the Control Protocol carries > three > > > different things, why are two of them in one channel and the > third > > > in a separate channel? Would it not make sense to either have > three > > > separate channels (Instruction Channel, Capabilities Channel, > > > Failure Information Channel) or, alternatively, to have just one > > > Control Channel? What is in the document right now does not seem > to > > > be very consistent. > > > > As far as I am concerned, my preference is that the terminology > has > > > a since conceptual Control Channel that carries Instructions, > > > Capabilities, and Failure Information. I can also live with > having > > > three distinct conceptual channels (Instruction Channel, > > > Capabilities Channel, Failure Information Channel) between the > MA > > > and the Controller. _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Feb 21 13:21:28 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE05A1A028E for ; Fri, 21 Feb 2014 13:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pli0wYjnqQFj for ; Fri, 21 Feb 2014 13:21:24 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 95F571A027E for ; Fri, 21 Feb 2014 13:21:24 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 053c7035.2ac0cba4b940.5571900.00-2444.15650408.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 21 Feb 2014 21:21:20 +0000 (UTC) X-MXL-Hash: 5307c350143b5466-f74a98b54d902f8137299f46041dd6b54c65c6c6 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 913c7035.0.5571387.00-2107.15648923.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 21 Feb 2014 21:20:27 +0000 (UTC) X-MXL-Hash: 5307c31b0d704efa-0c81524322b9609ed809a51ff34e19d10a1d44ff Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LLKN2S007953; Fri, 21 Feb 2014 16:20:24 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1LLKDEj007789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 16:20:20 -0500 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 21 Feb 2014 21:20:04 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 16:20:04 -0500 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Channels (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8sj7u09pKTiHtDRoCijNvN4PBsBgCleWxgAAJn/dAAAgTjIAADkp2Q Date: Fri, 21 Feb 2014 21:20:04 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303EC536@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611303EC384@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.121.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=uqi3naUUzQUA:10 a=ofMgfj31e3cA:10 a=HyTqpmEkfWEA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=gWR9lkOfTb4A:10 a=EKAMqNt9TqohN9f3LEIA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/eL-NReB09y-JOjB8uZadCvHA7OE Subject: Re: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 21:21:27 -0000 > the Instruction replaces (rather than adds to) the elements that it conta= ins > (the 5 elements are: configuration of measurement tasks, report channels, > periodic schedules, one-off schedules and suppression information.) So if= an > instruction contains config of measurement tasks, it replaces whatever > measurement task config is in the MA. > This was felt to be simpler. I do not understand this assumptive leap, and disagree with it. I went back and re-read the emails discussing Instruction definition. I saw the proposal that Instruction be defined as: Instruction: The description of Measurement Tasks for a MA to perform and the details of= the Report(s) for it to send. It is the collective description of the set = of Measurement Schedules, the set of Measurement Task configurations, the c= onfiguration of the Report Channel(s) and details of Suppression (if any). = The Controller sends a message over the Control Channel to the MA, in order= to update the Instruction or elements of it. I'm ok with this definition. This indicates to me that "Instruction" is all of these data sets, as they = reside in the MA, and that it is possible to update specific "elements" wit= hout updating everything. Note that "elements" is not defined, and I did no= t see "elements" as necessarily being used to mean "the 4 elements of the I= nstruction are the set of Measurement Schedules, the set of Measurement Tas= k configurations, the configuration of the Report Channel(s) and details of= Suppression (if any)". My interpretation of "element" was that it referred= to any subset of the Instruction. There is nothing in the definition that suggests the set of Measurement Tas= ks cannot be updated, but must be replaced in its entirety when changing th= e slightest thing. I have no problem with the Control Protocol being able t= o behave in this manner, for those who wish to use it in this manner. But I= do not believe that such inefficient behavior should be imposed on those w= ho wish to be more efficient. Admittedly, it is simple, but deployers of MA= s should be allowed to choose to use more intelligent Controllers that main= tain knowledge of MA configurations and are capable of sending updates and = not just replacement configurations. There is no need to require wholesale = replacement, as the only permitted manner in which a Control Protocol can f= unction. I believe that most of the protocols we are considering are perfec= tly capable of doing updates. What you propose is an unnecessary constraint= . Barbara From nobody Sun Feb 23 04:54:50 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BF41A00DE for ; Sun, 23 Feb 2014 04:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dexouXdeNItN for ; Sun, 23 Feb 2014 04:54:46 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEEA1A00CD for ; Sun, 23 Feb 2014 04:54:45 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFACfvCVPGmAcV/2dsb2JhbABZgkIjITtXwF2BBhZ0gicBAQMSG14BDAkVViYBBBsah2MBDJc/hFKrTBMEjhAjLYMvgRQEnySDcIdHgy2CKg X-IronPort-AV: E=Sophos; i="4.97,529,1389762000"; d="scan'208,217"; a="43972342" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Feb 2014 07:54:43 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 23 Feb 2014 07:42:43 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Sun, 23 Feb 2014 13:54:41 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: important information for the lmap meeting in London Thread-Index: Ac8wlmq+OF0hrg9HTVW2E4lINsbW6A== Date: Sun, 23 Feb 2014 12:54:41 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E43370F@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E43370FAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ODcQk6drK1OrgMThe9kRTZfJpvk Subject: [lmap] important information for the lmap meeting in London X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 12:54:48 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E43370FAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The preliminary agenda for the LMAP meeting in London is available at https= ://datatracker.ietf.org/meeting/89/agenda/lmap/. Submission deadline for th= e final agenda is tomorrow Monday 2/14 - so please let us know if there are= any changes or additions. We need two minute takers. Early volunteering would be highly appreciated. Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E43370FAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi,

     

    The preliminary agenda for the LMAP meeting in Londo= n is available at https://da= tatracker.ietf.org/meeting/89/agenda/lmap/. Submission deadline for the= final agenda is tomorrow Monday 2/14 – so please let us know if ther= e are any changes or additions.

     

    We need two minute takers. Early volunteering would = be highly appreciated.

     

    Thanks and Regards,

     

    Jason and Dan

     

     

    --_000_9904FB1B0159DA42B0B887B7FA8119CA2E43370FAZFFEXMB04globa_-- From nobody Mon Feb 24 01:12:28 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1261A083D for ; Mon, 24 Feb 2014 01:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kOe0hZUq8RU for ; Mon, 24 Feb 2014 01:12:20 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id DC6A81A0404 for ; Mon, 24 Feb 2014 01:12:06 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 24 Feb 2014 09:12:07 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.168]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 24 Feb 2014 09:11:59 +0000 From: To: , Date: Mon, 24 Feb 2014 09:11:59 +0000 Thread-Topic: Channels (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8sj7u09pKTiHtDRoCijNvN4PBsBgCleWxgAAJn/dAAAgTjIAADkp2QAH6dAQA= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303EC384@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611303EC536@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303EC536@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/bwdOGprgX-HI58q2w3u0tBlB1LY Subject: Re: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 09:12:26 -0000 This is in -03 of the framework i-d and was in -02 > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: 21 February 2014 21:20 > To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org > Subject: RE: Channels (WGLC comments on draft-ietf-lmap-framework-03) >=20 > > the Instruction replaces (rather than adds to) the elements that it > > contains (the 5 elements are: configuration of measurement tasks, > > report channels, periodic schedules, one-off schedules and > suppression > > information.) So if an instruction contains config of measurement > > tasks, it replaces whatever measurement task config is in the MA. > > This was felt to be simpler. >=20 > I do not understand this assumptive leap, and disagree with it. >=20 > I went back and re-read the emails discussing Instruction definition. > I saw the proposal that Instruction be defined as: > Instruction: > The description of Measurement Tasks for a MA to perform and the > details of the Report(s) for it to send. It is the collective > description of the set of Measurement Schedules, the set of Measurement > Task configurations, the configuration of the Report Channel(s) and > details of Suppression (if any). The Controller sends a message over > the Control Channel to the MA, in order to update the Instruction or > elements of it. >=20 > I'm ok with this definition. >=20 > This indicates to me that "Instruction" is all of these data sets, as > they reside in the MA, and that it is possible to update specific > "elements" without updating everything. Note that "elements" is not > defined, and I did not see "elements" as necessarily being used to mean > "the 4 elements of the Instruction are the set of Measurement > Schedules, the set of Measurement Task configurations, the > configuration of the Report Channel(s) and details of Suppression (if > any)". My interpretation of "element" was that it referred to any > subset of the Instruction. >=20 > There is nothing in the definition that suggests the set of Measurement > Tasks cannot be updated, but must be replaced in its entirety when > changing the slightest thing. I have no problem with the Control > Protocol being able to behave in this manner, for those who wish to use > it in this manner. But I do not believe that such inefficient behavior > should be imposed on those who wish to be more efficient. Admittedly, > it is simple, but deployers of MAs should be allowed to choose to use > more intelligent Controllers that maintain knowledge of MA > configurations and are capable of sending updates and not just > replacement configurations. There is no need to require wholesale > replacement, as the only permitted manner in which a Control Protocol > can function. I believe that most of the protocols we are considering > are perfectly capable of doing updates. What you propose is an > unnecessary constraint. > Barbara From nobody Mon Feb 24 02:00:21 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8A61A084E for ; Mon, 24 Feb 2014 02:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.299 X-Spam-Level: * X-Spam-Status: No, score=1.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxih02ku8uI9 for ; Mon, 24 Feb 2014 02:00:18 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 530BC1A02FD for ; Mon, 24 Feb 2014 02:00:18 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 24 Feb 2014 10:00:20 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.169]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Mon, 24 Feb 2014 09:59:30 +0000 From: To: , , , , Date: Mon, 24 Feb 2014 09:59:23 +0000 Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8tlhV3TNdpUpq+Qpm+Dna82yWzGQAVWfYAAAGC+4AAB267AAA+u1HQAAITgRAAAFLUMACMyJMg Message-ID: References: <2845723087023D4CB5114223779FA9C8BC2BCF3A@njfpsrvexg8.research.att.com> <2D09D61DDFA73D4C884805CC7865E611303EC06E@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611303EC0CF@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303EC0CF@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/qpDXpeopYpowtWlmwDgk8hjBnQs Cc: lmap@ietf.org Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 10:00:20 -0000 Certainly the information model allows it. In the report header there is an= optional section for context (e.g. line characteristics) and of course eac= h measurement is also free to report such parameters in the result data col= umns. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000=20 >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H >Sent: 21 February 2014 14:56 >To: Eardley,PL,Philip,TUB8 R; jason.weil@twcable.com; MORTON JR., AL; >j.schoenwaelder@jacobs-university.de >Cc: lmap@ietf.org >Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draf= t- >ietf-lmap-framework-03) > >> Now I engage my brain, I remember (I think) that a while back we >> agreed that enhancing measurement data with subscriber info was a post >> collector activity. > >Minor nit to this remembrance... >My remembrance was that we agreed that this *could* be a post collector >activity, or it *could* be done by the MA and attached to reported results= . And >that lmap would not try to preclude or mandate how this would be accomplis= hed, >or define any method for acquiring the subscriber info. But I think that t= he Report >does need to *allow* for inclusion of such information, or else it would >effectively be precluding the MA-attachment model. > >Since you said you were ok with my suggested text, and my suggestion was t= o >allow for this inclusion, I'm hoping we're ok. >Barbara > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Feb 24 02:16:10 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32651A0433 for ; Mon, 24 Feb 2014 02:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRWVbHJsXveg for ; Mon, 24 Feb 2014 02:16:06 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2551A0432 for ; Mon, 24 Feb 2014 02:16:06 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1OAFxek026943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Feb 2014 04:15:59 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2F9851E0059; Mon, 24 Feb 2014 04:15:54 -0600 (CST) Received: from sudnp797.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id EBAF91E0049; Mon, 24 Feb 2014 04:15:53 -0600 (CST) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1OAFrV4009752; Mon, 24 Feb 2014 03:15:53 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s1OAFrZR009744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 03:15:53 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Mon, 24 Feb 2014 04:15:52 -0600 From: "Bugenhagen, Michael K" To: "Weil, Jason" Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8tlhV3TNdpUpq+Qpm+Dna82yWzGQAXcmcAAAGC/IAAB266AABKGXoAAAFyvgAAAGHmgAAAXsaAAIAjAkQ= Date: Mon, 24 Feb 2014 10:15:52 +0000 Message-ID: <116B98CD-8F19-42EF-8857-83636BDE550D@centurylink.com> References: <2D09D61DDFA73D4C884805CC7865E611303EC0CF@GAALPA1MSGUSR9L.ITServices.sbc.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/k4f2x6rEaKb88swl9YWR6LA8aQs Cc: "philip.eardley@bt.com" , "lmap@ietf.org" , "j.schoenwaelder@jacobs-university.de" , "STARK, BARBARA H" , "MORTON JR., AL" Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 10:16:09 -0000 I also think that this is important for a qualified test. If one doesn't = have the known service speed profile the test result shouldn't arbitrarily = be compared to what one thinks the speed is - it should be compared to what= the service said it is at the time of the test. That way there is no var= iation in any test result conducted by two parties. I.e. A customer runn= ing a test vs. a ISP should result in the same answer. This is why all those test environment attributes are so critical in making= a reproducible test. Without those recorded at the time of the test we w= e are left with having to guess what went wrong. Keep in mind they don't = weaken any test, but they do make the test result much stronger. Mike Sent from my iPhone > On Feb 21, 2014, at 4:07 PM, "Weil, Jason" wrote= : >=20 > I am inline with Barbara's thinking on this point so if the current text > works then I am ok on this point as well. >=20 > Jason >=20 > On 2/21/14 9:56 AM, "STARK, BARBARA H" wrote: >=20 >>> Now I engage my brain, I remember (I think) that a while back we agreed >>> that enhancing measurement data with subscriber info was a post >>> collector >>> activity. >>=20 >> Minor nit to this remembrance... >> My remembrance was that we agreed that this *could* be a post collector >> activity, or it *could* be done by the MA and attached to reported >> results. And that lmap would not try to preclude or mandate how this >> would be accomplished, or define any method for acquiring the subscriber >> info. But I think that the Report does need to *allow* for inclusion of >> such information, or else it would effectively be precluding the >> MA-attachment model. >>=20 >> Since you said you were ok with my suggested text, and my suggestion was >> to allow for this inclusion, I'm hoping we're ok. >> Barbara >>=20 >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight 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 t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Feb 24 02:27:51 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CAA1A0437 for ; Mon, 24 Feb 2014 02:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3XRyotoy_Xh for ; Mon, 24 Feb 2014 02:27:46 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id D173B1A0433 for ; Mon, 24 Feb 2014 02:27:45 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 24 Feb 2014 10:26:34 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.168]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Mon, 24 Feb 2014 10:27:26 +0000 From: To: , Date: Mon, 24 Feb 2014 10:27:25 +0000 Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8tlhV3TNdpUpq+Qpm+Dna82yWzGQAXcmcAAAGC/IAAB266AABKGXoAAAFyvgAAAGHmgAAAXsaAAIAjAkQAAFf1kA== Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303EC0CF@GAALPA1MSGUSR9L.ITServices.sbc.com>, <116B98CD-8F19-42EF-8857-83636BDE550D@centurylink.com> In-Reply-To: <116B98CD-8F19-42EF-8857-83636BDE550D@centurylink.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/WFpBQxb5r3hu8JO2Kz9zpr9pwNo Cc: lmap@ietf.org, j.schoenwaelder@jacobs-university.de, bs7652@att.com, acmorton@att.com Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 10:27:49 -0000 Mike - re your comment - Just as a side note, please remember the extensive= discussion we had many months ago about this point. However, it is not som= ething I want to re-start. > -----Original Message----- > From: Bugenhagen, Michael K > [mailto:Michael.K.Bugenhagen@centurylink.com] > Sent: 24 February 2014 10:16 > To: Weil, Jason > Cc: STARK, BARBARA H; Eardley,PL,Philip,TUB8 R; MORTON JR., AL; > j.schoenwaelder@jacobs-university.de; lmap@ietf.org > Subject: Re: [lmap] Reporting of service parameters (WGLC comments on > draft-ietf-lmap-framework-03) >=20 > I also think that this is important for a qualified test. If one > doesn't have the known service speed profile the test result shouldn't > arbitrarily be compared to what one thinks the speed is - it should be > compared to what the service said it is at the time of the test. That > way there is no variation in any test result conducted by two parties. > I.e. A customer running a test vs. a ISP should result in the same > answer. >=20 > This is why all those test environment attributes are so critical in > making a reproducible test. Without those recorded at the time of the > test we we are left with having to guess what went wrong. Keep in > mind they don't weaken any test, but they do make the test result much > stronger. >=20 > Mike >=20 > Sent from my iPhone >=20 > > On Feb 21, 2014, at 4:07 PM, "Weil, Jason" > wrote: > > > > I am inline with Barbara's thinking on this point so if the current > > text works then I am ok on this point as well. > > > > Jason > > > > On 2/21/14 9:56 AM, "STARK, BARBARA H" wrote: > > > >>> Now I engage my brain, I remember (I think) that a while back we > >>> agreed that enhancing measurement data with subscriber info was a > >>> post collector activity. > >> > >> Minor nit to this remembrance... > >> My remembrance was that we agreed that this *could* be a post > >> collector activity, or it *could* be done by the MA and attached to > >> reported results. And that lmap would not try to preclude or mandate > >> how this would be accomplished, or define any method for acquiring > >> the subscriber info. But I think that the Report does need to > *allow* > >> for inclusion of such information, or else it would effectively be > >> precluding the MA-attachment model. > >> > >> Since you said you were ok with my suggested text, and my suggestion > >> was to allow for this inclusion, I'm hoping we're ok. > >> Barbara > >> > >> _______________________________________________ > >> 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 that 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 From nobody Mon Feb 24 05:52:43 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA5C1A040E for ; Mon, 24 Feb 2014 05:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UycujQrtQOY4 for ; Mon, 24 Feb 2014 05:52:39 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id CF7B91A037D for ; Mon, 24 Feb 2014 05:52:38 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 24 Feb 2014 13:52:41 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.168]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Mon, 24 Feb 2014 13:52:07 +0000 From: To: , , Date: Mon, 24 Feb 2014 13:52:06 +0000 Thread-Topic: Channels (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8sj7u09pKTiHtDRoCijNvN4PBsBgCleWxgAAJn/dAAAgTjIAADkp2QAH6dAQAACdQD0A== Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303EC384@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611303EC536@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/b6TLyA04M55f-iewcDmb-YmIBIs Subject: Re: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 13:52:42 -0000 Barbara Let's talk about this in London. Maybe able to do something without changin= g the protocol (at least if we assumed RESTful - don't know whether this is= an acceptable assumption) phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 24 February 2014 09:12 > To: bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] Channels (WGLC comments on draft-ietf-lmap- > framework-03) >=20 > This is in -03 of the framework i-d and was in -02 >=20 > > -----Original Message----- > > From: STARK, BARBARA H [mailto:bs7652@att.com] > > Sent: 21 February 2014 21:20 > > To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org > > Subject: RE: Channels (WGLC comments on draft-ietf-lmap-framework-03) > > > > > the Instruction replaces (rather than adds to) the elements that it > > > contains (the 5 elements are: configuration of measurement tasks, > > > report channels, periodic schedules, one-off schedules and > > suppression > > > information.) So if an instruction contains config of measurement > > > tasks, it replaces whatever measurement task config is in the MA. > > > This was felt to be simpler. > > > > I do not understand this assumptive leap, and disagree with it. > > > > I went back and re-read the emails discussing Instruction definition. > > I saw the proposal that Instruction be defined as: > > Instruction: > > The description of Measurement Tasks for a MA to perform and the > > details of the Report(s) for it to send. It is the collective > > description of the set of Measurement Schedules, the set of > > Measurement Task configurations, the configuration of the Report > > Channel(s) and details of Suppression (if any). The Controller sends > a > > message over the Control Channel to the MA, in order to update the > > Instruction or elements of it. > > > > I'm ok with this definition. > > > > This indicates to me that "Instruction" is all of these data sets, as > > they reside in the MA, and that it is possible to update specific > > "elements" without updating everything. Note that "elements" is not > > defined, and I did not see "elements" as necessarily being used to > > mean "the 4 elements of the Instruction are the set of Measurement > > Schedules, the set of Measurement Task configurations, the > > configuration of the Report Channel(s) and details of Suppression (if > > any)". My interpretation of "element" was that it referred to any > > subset of the Instruction. > > > > There is nothing in the definition that suggests the set of > > Measurement Tasks cannot be updated, but must be replaced in its > > entirety when changing the slightest thing. I have no problem with > the > > Control Protocol being able to behave in this manner, for those who > > wish to use it in this manner. But I do not believe that such > > inefficient behavior should be imposed on those who wish to be more > > efficient. Admittedly, it is simple, but deployers of MAs should be > > allowed to choose to use more intelligent Controllers that maintain > > knowledge of MA configurations and are capable of sending updates and > > not just replacement configurations. There is no need to require > > wholesale replacement, as the only permitted manner in which a > Control > > Protocol can function. I believe that most of the protocols we are > > considering are perfectly capable of doing updates. What you propose > > is an unnecessary constraint. > > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Feb 24 06:04:29 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B6B1A0871 for ; Mon, 24 Feb 2014 06:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD18VUaKDURg for ; Mon, 24 Feb 2014 06:04:23 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 82C811A0880 for ; Mon, 24 Feb 2014 06:04:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8JAOhQC1PGmAcV/2dsb2JhbABZgkIjITtXqCwDmD6BFhZ0gicBAQMSCxBeARUVViYBBBsBGYdjAQyWGoRSqxwXjhMBAR6CZw9mgRQEnySLN4MtgXE5 X-IronPort-AV: E=Sophos; i="4.97,535,1389762000"; d="scan'208,217"; a="50768360" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Feb 2014 09:04:22 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 24 Feb 2014 08:52:18 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 24 Feb 2014 15:04:20 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Reminder - WG Last call for LMAP use cases Thread-Index: Ac8xaU+TJSIUuovsR7ek3L+8rdrqJw== Date: Mon, 24 Feb 2014 14:04:19 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E435672@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E435672AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/WfRmvYeB6BtUUlW5cSxRW3CrsIk Subject: [lmap] Reminder - WG Last call for LMAP use cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 14:04:25 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E435672AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reminder - there is a Working Group Last Call for the Internet-Draft 'Large= -Scale Broadband Measurement Use Cases' which can be found at http://www.ie= tf.org/id/draft-ietf-lmap-use-cases-02.txt. Please send your comments about= this I-D to the WG mail list until 2/27/13. If you have no comments but y= ou believe that the document is ready to be submitted to the IESG for consi= deration as Informational RFC a short mail stating this is also welcome. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E435672AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Reminder – there is a Working = Group Last Call for the Internet-Draft ‘Large-Scale Broadband Measure= ment Use Cases’ which can be found at http://www.ietf.org/id/draft-ie= tf-lmap-use-cases-02.txt. Please send your comments about this I-D to the WG mail list until 2/27/13= .  If you have no comments but you believe that the document is ready = to be submitted to the IESG for consideration as Informational RFC a short = mail stating this is also welcome.

     

    Thanks and Regards,

     

    Dan

     

    --_000_9904FB1B0159DA42B0B887B7FA8119CA2E435672AZFFEXMB04globa_-- From nobody Mon Feb 24 06:05:11 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553331A088B for ; Mon, 24 Feb 2014 06:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.146 X-Spam-Level: X-Spam-Status: No, score=-3.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weXqc4qDcmjT for ; Mon, 24 Feb 2014 06:05:08 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 43D021A0887 for ; Mon, 24 Feb 2014 06:05:08 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIJAKxQC1PGmAcV/2dsb2JhbABZgkIjITtXqCwDmD6BFhZ0giUBAQEBAxILEFwCAQgNBAQBAQsdBzIUCQgBAQQTCAEZh2MBDJpsqxwXjhMBAR43AYMkgRQEnySLN4MtgXE5 X-IronPort-AV: E=Sophos; i="4.97,535,1389762000"; d="scan'208,217"; a="44049921" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Feb 2014 09:05:06 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 24 Feb 2014 08:53:02 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 24 Feb 2014 15:05:04 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Reminder - WG Last call for LMAP use cases Thread-Index: Ac8xaU+TJSIUuovsR7ek3L+8rdrqJwAABBKQ Date: Mon, 24 Feb 2014 14:05:03 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E435683@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E435672@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E435672@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E435683AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2xp4WquB1u_cB8n9g0TSezOAUKw Subject: Re: [lmap] Reminder - WG Last call for LMAP use cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 14:05:10 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E435683AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And I mean 2/27/14 - of course! From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Monday, February 24, 2014 4:04 PM To: lmap@ietf.org Subject: [lmap] Reminder - WG Last call for LMAP use cases Reminder - there is a Working Group Last Call for the Internet-Draft 'Large= -Scale Broadband Measurement Use Cases' which can be found at http://www.ie= tf.org/id/draft-ietf-lmap-use-cases-02.txt. Please send your comments about= this I-D to the WG mail list until 2/27/13. If you have no comments but y= ou believe that the document is ready to be submitted to the IESG for consi= deration as Informational RFC a short mail stating this is also welcome. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E435683AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    And I mean 2/27/14 = 211; of course!

     

    From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
    Sent: Monday, February 24, 2014 4:04 PM
    To: lmap@ietf.org
    Subject: [lmap] Reminder - WG Last call for LMAP use cases

     

    Reminder – there is a Working = Group Last Call for the Internet-Draft ‘Large-Scale Broadband Measure= ment Use Cases’ which can be found at http://= www.ietf.org/id/draft-ietf-lmap-use-cases-02.txt. Please send your comm= ents about this I-D to the WG mail list until 2/27/13.  If you have no= comments but you believe that the document is ready to be submitted to the IESG for consideration as Informational RF= C a short mail stating this is also welcome.

     

    Thanks and Regards,

     

    Dan

     

    --_000_9904FB1B0159DA42B0B887B7FA8119CA2E435683AZFFEXMB04globa_-- From nobody Mon Feb 24 06:13:27 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C355F1A088C for ; Mon, 24 Feb 2014 06:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhOiDmdr9e_Q for ; Mon, 24 Feb 2014 06:13:25 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 408BC1A0109 for ; Mon, 24 Feb 2014 06:13:25 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 5835b035.2ac42221c940.1062026.00-2492.2851134.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 24 Feb 2014 14:13:25 +0000 (UTC) X-MXL-Hash: 530b5385240ce98d-7da8b82d167b244bdaa45197283f751d008ffb67 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id a735b035.0.1061946.00-2375.2850913.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 24 Feb 2014 14:13:15 +0000 (UTC) X-MXL-Hash: 530b537b3787b5a4-d65233f4880b7bb0b71d18cda08668f7dc5ef15f Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1OEDEde032334; Mon, 24 Feb 2014 09:13:14 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1OED5BV032238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Feb 2014 09:13:08 -0500 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 24 Feb 2014 14:12:57 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0174.001; Mon, 24 Feb 2014 09:12:57 -0500 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Channels (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8sj7u09pKTiHtDRoCijNvN4PBsBgCleWxgAAJn/dAAAgTjIAADkp2QAH6dAQAACdQD0AAAOXrg Date: Mon, 24 Feb 2014 14:12:57 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303EDF1D@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611303EC384@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611303EC536@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.66.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=SddAgItu c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=uqi3naUUzQUA:10 a=ofMgfj31e3cA:10 a=Nqn56bYHQNoA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=gWR9lkOfTb4A:10 a=CH4CTWcEmrDQhMs2hZoA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/U8wMbJizhGKtAC_5kB6358IKI9Q Subject: Re: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 14:13:27 -0000 > Barbara > Let's talk about this in London. Maybe able to do something without chang= ing > the protocol (at least if we assumed RESTful - don't know whether this is= an > acceptable assumption) >=20 > phil Hi Phil, That sounds good. I had not read in to the existing language that there wou= ld be a firm constraint on the Control Protocol and the MA, Controller, and= Control Protocol MUST NOT allow for updating of portions of an Instruction= , and MUST restrict the Controller and MA interaction to require sending of= an Instruction in its entirety. I suspect that some of this comes from continued misunderstanding by some o= f us that every time "Instruction" is used in framework, it refers to the e= ntirety of the information and can never be used to refer to just a part of= it. I admit that I was personally unclear on this. While this sort of lang= uage (restricting and limiting Control Protocol capabilities) has indeed be= en in several drafts of framework, I only now am really understanding its i= mplications. And disagreeing with those implications. I continue to believe= that it would be better if unnecessary restrictions were not imposed in fr= amework. Barbara =20 > > This is in -03 of the framework i-d and was in -02 > > > > > > the Instruction replaces (rather than adds to) the elements that > > > > it contains (the 5 elements are: configuration of measurement > > > > tasks, report channels, periodic schedules, one-off schedules and > > > suppression > > > > information.) So if an instruction contains config of measurement > > > > tasks, it replaces whatever measurement task config is in the MA. > > > > This was felt to be simpler. > > > > > > I do not understand this assumptive leap, and disagree with it. > > > > > > I went back and re-read the emails discussing Instruction definition. > > > I saw the proposal that Instruction be defined as: > > > Instruction: > > > The description of Measurement Tasks for a MA to perform and the > > > details of the Report(s) for it to send. The Instruction is sent by a > > > Controller to a Measurement Agent. From nobody Tue Feb 25 04:02:08 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CE71A06B5 for ; Tue, 25 Feb 2014 04:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.435 X-Spam-Level: ** X-Spam-Status: No, score=2.435 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7E58bY3kfK0 for ; Tue, 25 Feb 2014 04:02:04 -0800 (PST) Received: from nsolon.eett.gr (nsolon.eett.gr [193.201.166.71]) by ietfa.amsl.com (Postfix) with ESMTP id D13B31A06BB for ; Tue, 25 Feb 2014 04:02:03 -0800 (PST) X-EETT-MailScanner-From: apragiati@eett.gr X-EETT-MailScanner: Found to be clean X-EETT-MailScanner-ID: 2D71E196240.A6318 X-EETT-MailScanner-Information: Please contact the ISP for more information Received: from teiresias.EETT.GR (unknown [172.16.200.25]) by nsolon.eett.gr (Postfix) with ESMTP id 2D71E196240 for ; Tue, 25 Feb 2014 14:01:47 +0200 (EET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF3221.5BA48724" Date: Tue, 25 Feb 2014 14:01:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on LMAP use cases Thread-Index: Ac8yIVsvc/mWvBcgRMmJFiZ1wD8gtw== From: "Pragiati Aggeliki" To: Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/EQhWd6UqcuAaaj67qwTZ9MnNXKI Cc: hyperiontest Subject: [lmap] comments on LMAP use cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 12:02:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF3221.5BA48724 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on EETT experience from the development of http://hyperiontest.gr/, please consider some comments below regarding Chapter 4 of the Internet-Draft 'Large-Scale Broadband Measurement Use Cases'. >From the regulator point of view, the key objectives for measuring broadband performance on a large scale are three-fold depending on the actors of the use cases. Consumers:=20 * Promoting transparency and fair competition on Quality of Service=20 * Provide personalized services for detecting performance improvement or degradation or possible cabling faults. * Export measurements data for helping consumers to understand and evaluate connection performance issues and report problems to operators and/or NRA * Geo-mapping the performance of broadband connections around the country =20 Local authorities and ISPs:=20 * Geo-mapping broadband performance to ease coordination during deployment of networks and infrastructure. NRA: * Tools to support statistical methods, analysis, reporting, identification of possible problems and trends =09 Overall the above objectives form a set of requirements regarding the test results of any measuring process: * Data concluded by the measurement process must be consistent. In order to achieve that a set of parameters during measurement needs to be verified i.e. the user's location, Access-Technology used, the Agreed-Service-Limitations. The verification process may be achieved via user authentication and via verification by the ISP of the information provided by the user * The overall picture of the broadband network performance achieved must be consistent. In order to achieve that, measurements must be performed periodically, at different times of a day, either initiated by the user or scheduled automatically. It also requires a sufficient large number of end users and measurements in a short period of time.=20 Kind regards, Aggeliki =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 Dr. Aggeliki Pragiati Telecommunications Division Hellenic Telecommunications & Post Commission (E.E.T.T.) 60 Kifissias Avenue, 15125 Maroussi, Athens, GREECE=20 Tel.: +30 210 6151 218, +30 210 615 1000 =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 ------_=_NextPart_001_01CF3221.5BA48724 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable comments on LMAP use cases

    Based on EETT experience from the development of http://hyperiontest.gr/, = please consider some comments below regarding Chapter 4 of the Internet-Draft ‘Large-Scale Broadband = Measurement Use Cases’.

    From the regulator point of = view, the key objectives = for measuring broadband performance on a large = scale are three-fold depending on the actors of the use = cases.

    Consumers:

    ·       Promoting transparency and fair competition on = Quality of Service

    ·       Provide personalized services for detecting performance improvement or degradation or = possible cabling faults.

    ·       Export measurements data for helping consumers to understand and = evaluate  connection performance issues and report problems to = operators and/or NRA

    ·       Geo-mapping the = performance of broadband connections around the country  =

    Local authorities and ISPs:

    ·       Geo-mapping broadband performance to ease = coordination during deployment of networks and = infrastructure.

    NRA:

    ·       Tools to support statistical methods, analysis, = reporting, identification of possible problems and = trends

    Overall the above = objectives form a = set of requirements regarding the test results of any measuring process:

    ¡       Data concluded by the measurement process must = be consistent. In order to achieve that a set of parameters during = measurement needs to be verified i.e. the user’s location, = Access-Technology used, the Agreed-Service-Limitations. The verification = process may be achieved via user authentication and via verification by = the ISP of the information provided by the user

    ¡       The overall picture of the = broadband network performance achieved must be consistent. In order to = achieve that, measurements must be performed periodically, at different = times of a day, either initiated by the user or scheduled automatically. = It also requires a sufficient large number of end users and measurements = in a short period of time.

    Kind = regards,

    Aggeliki

    =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

    Dr. Aggeliki Pragiati

    Telecommunications Division

    Hellenic Telecommunications & Post Commission (E.E.T.T.)

    60 Kifissias Avenue, 15125 Maroussi, Athens, = GREECE

    Tel.: +30 210 6151 218, +30 210 615 = 1000

    =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

    ------_=_NextPart_001_01CF3221.5BA48724-- From nobody Thu Feb 27 04:56:48 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07821A028B for ; Thu, 27 Feb 2014 04:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjxF1DWxUrmD for ; Thu, 27 Feb 2014 04:56:45 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id CDFAC1A0249 for ; Thu, 27 Feb 2014 04:56:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcRAJc1D1PGmAcV/2dsb2JhbABagkIjITtXqCgEBphYgRkWdIIlAQEBAQIBEgsQUQ0BFQUQFgM9Fw8BBBsBEgeHTwgBDJoihFOrbI19J4JmD2aBFASJEpYYiziBb4E+gWhC X-IronPort-AV: E=Sophos; i="4.97,554,1389762000"; d="scan'208,217"; a="51334561" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 27 Feb 2014 07:56:29 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 27 Feb 2014 07:44:15 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 27 Feb 2014 13:56:27 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: comments to the Working Group Last Call for http://www.ietf.org/id/draft-ietf-lmap-use-cases-02.txt Thread-Index: Ac8zu1GYrbsou501SJWdmEmD2NEffw== Date: Thu, 27 Feb 2014 12:56:27 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E43BA30@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E43BA30AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Wsp14Uc0G0exjucOHZ0uxSoM7Go Subject: [lmap] comments to the Working Group Last Call for http://www.ietf.org/id/draft-ietf-lmap-use-cases-02.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 12:56:47 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E43BA30AZFFEXMB04globa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Here are my comments to the Working Group Last Call for http://www.ietf.org= /id/draft-ietf-lmap-use-cases-02.txt. Please consider these as contributor = comments and address them together with the other WGLC comments. 1. The second sentence in the Abstract talks about measurement contro= ller and measurement server. I believe that the abstract should be more gen= eral and talk about the scope of the document (use cases) without making as= sumptions about the solutions and architecture of the solutions. 2. The first paragraph in the introduction should add that the use ca= ses described in the document are not necessarily all use cases involving l= arge-scale measurement, but the focus agreed by consensus for a first phase= of this work. 3. The first sentence in Section 2 is not clear to me. What does 'met= rics for instructions' mean? 4. In the same paragraph 'layer 2 technologies' uses OSI layering spe= ak. In the IETF we rather refer to this as to the data-link layer 5. There are many acronyms that are not expanded - FTTP, FTTC, ADSL, = etc. - please expand these (excepting the very obvious) at first occurrence 6. In Section 3.3: > With better information, capacity planning and network design can be more effective. Such planning typically uses simulations to emulate the measured performance of the current network and understand the likely impact of new capacity and potential changes to the topology. It may also be possible to run stress tests for risk analysis, for example 'if whizzy new application (or device) becomes popular, which parts of my network would struggle, what would be the impact on other services and how many customers would be affected'. What-if simulations could help quantify the advantage that a new technology brings and support the business case for larger roll-out. This approach should allow good results with measurements from a limited panel of customers. I am not sure what this paragraph is supposed to convene and how what-if si= mulations are related to LMAP 7. Rest of section 3.3 (last three paragraphs) seems to deal with a s= eparate issue (SLAs) and seem to deserve a separate sub-section of their ow= n 8. Section 4.3 probably needs an update following recent development= s in the US concerning the FCC net neutrality rules 9. In the security consideration section: =D8 a measurement system that is vague about who is the "data controller": the party legally responsible for privacy (data protection). It is not clear to me what is meant here by "data controller" - is this a s= pecific architecture to protect privacy? I would rather see the requirement= for privacy being clearly articulated in all necessary details (what data = needs to be protected? User? Control? Measurement results?) 10. I do not believe that we need a reference or text about the 2119 key = words, as this is an informational document, and key words are not used thr= ough it. 11. I do not believe that there is need for any Normative References in t= his document. All references can be moved to Informational References. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E43BA30AZFFEXMB04globa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hi,

     

    Here are my comments to the Working Group Last Call = for http://www.ietf.org/id/draft-ietf-lmap-use-cases-02.txt. Please conside= r these as contributor comments and address them together with the other WG= LC comments.

     

    1.     &= nbsp; The second sentence in the= Abstract talks about measurement controller and measurement server. I beli= eve that the abstract should be more general and talk about the scope of th= e document (use cases) without making assumptions about the solutions and architecture of the solutions.

    2.     &= nbsp; The first paragraph in the= introduction should add that the use cases described in the document are n= ot necessarily all use cases involving large-scale measurement, but the foc= us agreed by consensus for a first phase of this work.

    3.     &= nbsp; The first sentence in Sect= ion 2 is not clear to me. What does ‘metrics for instructions’ = mean?

    4.     &= nbsp; In the same paragraph R= 16;layer 2 technologies’ uses OSI layering speak. In the IETF we rath= er refer to this as to the data-link layer

    5.     &= nbsp; There are many acronyms th= at are not expanded – FTTP, FTTC, ADSL, etc. – please expand th= ese (excepting the very obvious) at first occurrence

    6.     &= nbsp; In Section 3.3:

    >  With better information, capacit= y planning and network design can be

       more effective. Such planning = typically uses simulations to emulate

       the measured performance of th= e current network and understand the

       likely impact of new capacity = and potential changes to the topology.

       It may also be possible to run= stress tests for risk analysis, for

       example 'if whizzy new applica= tion (or device) becomes popular, which

       parts of my network would stru= ggle, what would be the impact on other

       services and how many customer= s would be affected'. What-if

       simulations could help quantif= y the advantage that a new technology

       brings and support the busines= s case for larger roll-out. This

       approach should allow good res= ults with measurements from a limited

       panel of customers.=

     

    I am not sure what this paragraph is supposed to con= vene and how what-if simulations are related to LMAP

     

    7.     &= nbsp; Rest of section 3.3 (last = three paragraphs) seems to deal with a separate issue (SLAs) and seem to de= serve a separate sub-section of their own

    8.     &= nbsp;  Section 4.3 probably= needs an update following recent developments in the US concerning the FCC= net neutrality rules

    9.     &= nbsp; In the security considerat= ion section:

    =D8&= nbsp;    a measurement system tha= t is vague about who is the "data

          controller&q= uot;: the party legally responsible for privacy (data

          protection).=

    It is not clear to me what is meant here by “d= ata controller” – is this a specific architecture to protect pr= ivacy? I would rather see the requirement for privacy being clearly articul= ated in all necessary details (what data needs to be protected? User?  Control? Measurement results?)

    10.   I do not believe that we n= eed a reference or text about the 2119 key words, as this is an information= al document, and key words are not used through it.

    11.   I do not believe that ther= e is need for any Normative References in this document. All references can= be moved to Informational References.

     

    Regards,

     

    Dan

     

    --_000_9904FB1B0159DA42B0B887B7FA8119CA2E43BA30AZFFEXMB04globa_-- From nobody Thu Feb 27 05:01:01 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286D21A0256 for ; Thu, 27 Feb 2014 05:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_72=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S9bDiN4PSWU for ; Thu, 27 Feb 2014 05:00:56 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id D60911A021A for ; Thu, 27 Feb 2014 05:00:55 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1RD0igI016399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Feb 2014 07:00:44 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 26BD51E0049; Thu, 27 Feb 2014 07:00:39 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id DB9291E006F; Thu, 27 Feb 2014 07:00:38 -0600 (CST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1RD0cqr028674; Thu, 27 Feb 2014 06:00:38 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1RD0bQB028643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 06:00:38 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 27 Feb 2014 07:00:37 -0600 From: "Bugenhagen, Michael K" To: "philip.eardley@bt.com" , "Cook, Charles" Thread-Topic: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) Thread-Index: Ac8tlhV3TNdpUpq+Qpm+Dna82yWzGQAXcmcAAAGC/IAAB266AABKGXoAAAFyvgAAAGHmgAAAXsaAAIAjAkQAAFf1kACcSMSy Date: Thu, 27 Feb 2014 13:00:36 +0000 Message-ID: <92223550-2F38-4D15-845C-57AB0DD28154@centurylink.com> References: <2D09D61DDFA73D4C884805CC7865E611303EC0CF@GAALPA1MSGUSR9L.ITServices.sbc.com>, <116B98CD-8F19-42EF-8857-83636BDE550D@centurylink.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/seZRXZCkMmTzFUJbumGGvBk7QD8 Cc: "j.schoenwaelder@jacobs-university.de" , "lmap@ietf.org" , "acmorton@att.com" , "bs7652@att.com" , "jason.weil@twcable.com" Subject: Re: [lmap] Reporting of service parameters (WGLC comments on draft-ietf-lmap-framework-03) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 13:00:58 -0000 So is the result that we have alignment between the BBF and IETF on the rep= orting of the test environment in the results ? I couldn't tell from your reply. Mike Sent from my iPhone > On Feb 24, 2014, at 4:27 AM, "philip.eardley@bt.com" wrote: >=20 > Mike - re your comment - Just as a side note, please remember the extensi= ve discussion we had many months ago about this point. However, it is not s= omething I want to re-start. >=20 >> -----Original Message----- >> From: Bugenhagen, Michael K >> [mailto:Michael.K.Bugenhagen@centurylink.com] >> Sent: 24 February 2014 10:16 >> To: Weil, Jason >> Cc: STARK, BARBARA H; Eardley,PL,Philip,TUB8 R; MORTON JR., AL; >> j.schoenwaelder@jacobs-university.de; lmap@ietf.org >> Subject: Re: [lmap] Reporting of service parameters (WGLC comments on >> draft-ietf-lmap-framework-03) >>=20 >> I also think that this is important for a qualified test. If one >> doesn't have the known service speed profile the test result shouldn't >> arbitrarily be compared to what one thinks the speed is - it should be >> compared to what the service said it is at the time of the test. That >> way there is no variation in any test result conducted by two parties. >> I.e. A customer running a test vs. a ISP should result in the same >> answer. >>=20 >> This is why all those test environment attributes are so critical in >> making a reproducible test. Without those recorded at the time of the >> test we we are left with having to guess what went wrong. Keep in >> mind they don't weaken any test, but they do make the test result much >> stronger. >>=20 >> Mike >>=20 >> Sent from my iPhone >>=20 >>>> On Feb 21, 2014, at 4:07 PM, "Weil, Jason" >>> wrote: >>>=20 >>> I am inline with Barbara's thinking on this point so if the current >>> text works then I am ok on this point as well. >>>=20 >>> Jason >>>=20 >>> On 2/21/14 9:56 AM, "STARK, BARBARA H" wrote: >>>=20 >>>>> Now I engage my brain, I remember (I think) that a while back we >>>>> agreed that enhancing measurement data with subscriber info was a >>>>> post collector activity. >>>>=20 >>>> Minor nit to this remembrance... >>>> My remembrance was that we agreed that this *could* be a post >>>> collector activity, or it *could* be done by the MA and attached to >>>> reported results. And that lmap would not try to preclude or mandate >>>> how this would be accomplished, or define any method for acquiring >>>> the subscriber info. But I think that the Report does need to >> *allow* >>>> for inclusion of such information, or else it would effectively be >>>> precluding the MA-attachment model. >>>>=20 >>>> Since you said you were ok with my suggested text, and my suggestion >>>> was to allow for this inclusion, I'm hoping we're ok. >>>> Barbara >>>>=20 >>>> _______________________________________________ >>>> lmap mailing list >>>> lmap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lmap >>>=20 >>>=20 >>> 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 that 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. >>>=20 >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap