From nobody Thu May 1 05:56:19 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 0A94B1A88E8 for ; Thu, 1 May 2014 05:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 R2Hg6bYRhQuZ for ; Thu, 1 May 2014 05:56:18 -0700 (PDT) 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 D926E1A08C4 for ; Thu, 1 May 2014 05:56:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsJAAdDYlOHCzIm/2dsb2JhbABZgmUhgSaCZ6dgAQEBAQEEAZoKGXcWdIIlAQEBAQMSERFRBAIBCA0EBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgaiB8BmzyKR6QEF4EqhCyISzgGgmk1gRUEoDmLZIMzgis X-IronPort-AV: E=Sophos;i="4.97,964,1389762000"; d="scan'208";a="52641230" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 May 2014 08:56:14 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 01 May 2014 08:55:03 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 1 May 2014 08:56:12 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: lmap - New Meeting Session Request for IETF 90 Thread-Index: AQHPZTwj2GhtaZGi20ShfxsE4coYipsrrr8w Date: Thu, 1 May 2014 12:56:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7CE378@AZ-FFEXMB04.global.avaya.com> References: <20140501125158.22244.53022.idtracker@ietfa.amsl.com> In-Reply-To: <20140501125158.22244.53022.idtracker@ietfa.amsl.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/CCrRxjs0rjbSWFVL3QaRRWierkE Subject: [lmap] FW: lmap - New Meeting Session Request for IETF 90 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, 01 May 2014 12:56:19 -0000 SGksDQoNCkkgcmVxdWVzdGVkIG9uZSAyLjUgaG91cnMgbWVldGluZyBzbG90IGZvciBJRVRGLTkw LiBUaGUgaW5mb3JtYXRpb24gSSBwcm92aWRlZCBpcyAgY29uc2lzdGVudCB3aXRoIHRoZSBvbmUg YXQgSUVURi04OS4gSWYgSSBtaXNzZWQgYW55IGltcG9ydGFudCBjb25mbGljdHMgcGxlYXNlIGxl dCBtZSBrbm93IGFuZCBJIHdpbGwgdXBkYXRlIHRoZSByZXF1ZXN0LiANCg0KVGhhbmtzIGFuZCBS ZWdhcmRzLA0KDQpEYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiAi SUVURiBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sIg0KPiBbbWFpbHRvOnNlc3Npb25fcmVx dWVzdF9kZXZlbG9wZXJzQGlldGYub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDAxLCAyMDE0 IDM6NTIgUE0NCj4gVG86IHNlc3Npb24tcmVxdWVzdEBpZXRmLm9yZw0KPiBDYzogbG1hcC1hZHNA dG9vbHMuaWV0Zi5vcmc7IFJvbWFzY2FudSwgRGFuIChEYW4pOw0KPiBqYXNvbi53ZWlsQHR3Y2Fi bGUuY29tDQo+IFN1YmplY3Q6IGxtYXAgLSBOZXcgTWVldGluZyBTZXNzaW9uIFJlcXVlc3QgZm9y IElFVEYgOTANCj4gDQo+IA0KPiANCj4gQSBuZXcgbWVldGluZyBzZXNzaW9uIHJlcXVlc3QgaGFz IGp1c3QgYmVlbiBzdWJtaXR0ZWQgYnkgRGFuIFJvbWFzY2FudSwNCj4gYSBDaGFpciBvZiB0aGUg bG1hcCB3b3JraW5nIGdyb3VwLg0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBXb3JraW5nIEdyb3VwIE5hbWU6IExh cmdlLVNjYWxlIE1lYXN1cmVtZW50IG9mIEJyb2FkYmFuZCBQZXJmb3JtYW5jZQ0KPiBBcmVhIE5h bWU6IE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQgQXJlYSBTZXNzaW9uIFJlcXVlc3RlcjogRGFu DQo+IFJvbWFzY2FudQ0KPiANCj4gTnVtYmVyIG9mIFNlc3Npb25zOiAxDQo+IExlbmd0aCBvZiBT ZXNzaW9uKHMpOiAgMi41IEhvdXJzDQo+IE51bWJlciBvZiBBdHRlbmRlZXM6IDgwDQo+IENvbmZs aWN0cyB0byBBdm9pZDoNCj4gIEZpcnN0IFByaW9yaXR5OiBpcHBtIGVjcml0IGJtd2cgZGlzcGF0 Y2ggbG1hcCBtcHRjcCBuZXRjb25mIG5ldG1vZCBkaW1lDQo+IG9wc2FyZWEgb3BzYXdnIHJhZGV4 dCBzYWNtIHhyYmxvY2sgcnRjd2ViIHRpY3RvYyBpcnRmb3Blbg0KPiANCj4gDQo+IA0KPiANCj4g U3BlY2lhbCBSZXF1ZXN0czoNCj4gICBNZWV0ZWNobyAtIHdlIGhhdmUgYXQgbGVhc3Qgb25lIGNv cmUgY29udHJpYnV0b3Igd2hvIHdpbGwgYmUgcGFydGljaXBhdGluZw0KPiByZW1vdGVseQ0KPiAN Cj4gQXQgSUVURi04OSB0aGUgbWVldGluZyB3YXMgc2NoZWR1bGVkIG9uIEZyaWRheS4gSXQgd291 bGQgYmUgbmljZSBhbmQgZmFpciB0bw0KPiBhdm9pZCBzdWNoIHNjaGVkdWxpbmcgdGhpcyB0aW1l DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQo= From nobody Thu May 1 06:23: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 C51CD1A890F for ; Thu, 1 May 2014 06:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 WEiWEua7p9ep for ; Thu, 1 May 2014 06:23:14 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id A69C61A890E for ; Thu, 1 May 2014 06:23:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcJAFdJYlOHCzIm/2dsb2JhbABZgkIjIU9XqkcBAQEBAQQBmgqBERZ0gicBAQMSG14BFRVWJgEEGxqIHwGWaIRZrksXhVaIS4NcgRUEoDmLZIMzgis X-IronPort-AV: E=Sophos; i="4.97,965,1389762000"; d="scan'208,217"; a="60407850" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 May 2014 09:23:12 -0400 X-OutboundMail_SMTP: 1 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; 01 May 2014 09:22:02 -0400 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, 1 May 2014 15:23:10 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: status of draft-ietf-lmap-use-cases Thread-Index: Ac9lQH8HygaLp9v5R6eYiCeTqw575g== Date: Thu, 1 May 2014 13:23:10 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7CE3C9@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_9904FB1B0159DA42B0B887B7FA8119CA5C7CE3C9AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/cVd-N-rAPfen0j96A_TEANDIQyY Subject: [lmap] status of draft-ietf-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: Thu, 01 May 2014 13:23:15 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7CE3C9AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The 2nd WGLC of draft-ietf-lmap-use-cases passed without any comments or ob= jections (unless I missed something). I have two questions: 1. Do the authors feel that the document is ready to be submitted to = the IESG for consideration as Informational RFC? 2. Does any other WG participant have any objections to submitting th= e document to the IESG for consideration as Informational RFC? Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7CE3C9AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The 2nd WGLC of draft-ietf-lmap-use-cases= passed without any comments or objections (unless I missed something).

 

I have two questions:

 

1.     &= nbsp; Do the authors feel that t= he document is ready to be submitted to the IESG for consideration as Infor= mational RFC?

2.     &= nbsp; Does any other WG particip= ant have any objections to submitting the document to the IESG for consider= ation as Informational RFC?

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C7CE3C9AZFFEXMB04globa_-- From nobody Thu May 1 06:29: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 5EC171A8909 for ; Thu, 1 May 2014 06:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 K2Y0Tug9MZl6 for ; Thu, 1 May 2014 06:29:53 -0700 (PDT) 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 C47611A8908 for ; Thu, 1 May 2014 06:29:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcJADpLYlPGmAcV/2dsb2JhbABZgkIjIU9XqkcBAQEBAQQBmgqBERZ0gicBAQMSG14BDAkVViYBBBsaiB8BlnKEWa5MF4VWiEuDXIEVBKA5i2SDM4Ir X-IronPort-AV: E=Sophos; i="4.97,965,1389762000"; d="scan'208,217"; a="52646227" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 May 2014 09:29:49 -0400 X-OutboundMail_SMTP: 1 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; 01 May 2014 09:13:50 -0400 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; Thu, 1 May 2014 15:29:47 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: status of draft-ietf-lmap-framework Thread-Index: Ac9lQWszsEFFzJ3WQVGDECGoagKgxg== Date: Thu, 1 May 2014 13:29:46 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7CE3EE@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_9904FB1B0159DA42B0B887B7FA8119CA5C7CE3EEAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/qByqfMysIaS-SN22umA-SD7YLHQ Subject: [lmap] status of draft-ietf-lmap-framework 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, 01 May 2014 13:29:54 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7CE3EEAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Can we get a short status assessment from the authors of draft-ietf-lmap-fr= amework about where we are with this document after the 2nd WGLC? We receiv= ed at least two sets of solid comments - will these be addressed soon by a = revised I-D? Do we need another WGLC? Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7CE3EEAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Can we get a short status assessment from the author= s of draft-ietf-lmap-framework about where we are with this document after = the 2nd WGLC? We received at least two sets of solid comments &#= 8211; will these be addressed soon by a revised I-D? Do we need another WGLC?

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C7CE3EEAZFFEXMB04globa_-- From nobody Thu May 1 08:10: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 732321A0900 for ; Thu, 1 May 2014 08:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 pYKwovb2WOhS for ; Thu, 1 May 2014 08:10:28 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id D2E2A1A08E9 for ; Thu, 1 May 2014 08:10:27 -0700 (PDT) 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 B43B3120845; Thu, 1 May 2014 11:11:15 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id 4A599E200A; Thu, 1 May 2014 11:10:13 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Thu, 1 May 2014 11:10:25 -0400 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Date: Thu, 1 May 2014 11:10:24 -0400 Thread-Topic: status of draft-ietf-lmap-framework Thread-Index: Ac9lQWszsEFFzJ3WQVGDECGoagKgxgADXX+g Message-ID: <2845723087023D4CB5114223779FA9C801795CD13A@njfpsrvexg8.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C7CE3EE@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C7CE3EE@AZ-FFEXMB04.global.avaya.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_2845723087023D4CB5114223779FA9C801795CD13Anjfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Pq-X8vGyn9JW3Hn442eUdX8OKH8 Subject: Re: [lmap] status of draft-ietf-lmap-framework 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, 01 May 2014 15:10:29 -0000 --_000_2845723087023D4CB5114223779FA9C801795CD13Anjfpsrvexg8re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, Give us a few days to gather our thoughts, early next week perhaps. We still have editing to do (and I have the token, no pressure ;-) ) but hopefully it all comes together very soon. regards, Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, May 01, 2014 9:30 AM To: lmap@ietf.org Subject: [lmap] status of draft-ietf-lmap-framework Hi, Can we get a short status assessment from the authors of draft-ietf-lmap-fr= amework about where we are with this document after the 2nd WGLC? We receiv= ed at least two sets of solid comments - will these be addressed soon by a = revised I-D? Do we need another WGLC? Thanks and Regards, Dan --_000_2845723087023D4CB5114223779FA9C801795CD13Anjfpsrvexg8re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan,

Give us a few days to gather our thought= s, early next week perhaps.

We still have editing= to do (and I have the token, no pressure ;-) )

b= ut hopefully it all comes together very soon.

 

regards,

Al

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of R= omascanu, Dan (Dan)
Sent: Thursday, May 01, 2014 9:30 AM
To= : lmap@ietf.org
Subject: [lmap] status of draft-ietf-lmap-fra= mework

 

Hi,

&nb= sp;

Can we get a short status assessment from= the authors of draft-ietf-lmap-framework about where we are with this docu= ment after the 2nd WGLC? We received at least two sets of solid = comments – will these be addressed soon by a revised I-D? Do we need = another WGLC?

 

Thanks and Regards,

 

Dan

 

= --_000_2845723087023D4CB5114223779FA9C801795CD13Anjfpsrvexg8re_-- From nobody Fri May 2 00:37: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 3F87F1A6EFF for ; Fri, 2 May 2014 00:37:44 -0700 (PDT) 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 NqzbpcSOfTKZ for ; Fri, 2 May 2014 00:37:42 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4FF1A0A59 for ; Fri, 2 May 2014 00:37:41 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 2 May 2014 08:37:52 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 2 May 2014 08:37:37 +0100 From: To: , , Date: Fri, 2 May 2014 08:37:36 +0100 Thread-Topic: status of draft-ietf-lmap-framework Thread-Index: Ac9lQWszsEFFzJ3WQVGDECGoagKgxgADXX+gACKVnCA= Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C7CE3EE@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C801795CD13A@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C801795CD13A@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_A2E337CDB7BC4145B018B9BEE8EB3E0D40F40AEC29EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/CkydxYichpzk-E6ZTworFAx3wYQ Subject: Re: [lmap] status of draft-ietf-lmap-framework 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, 02 May 2014 07:37:44 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F40AEC29EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We've been working through the comments and making the minor changes needed= . Just a couple left to do. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: 01 May 2014 16:10 To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] status of draft-ietf-lmap-framework Hi Dan, Give us a few days to gather our thoughts, early next week perhaps. We still have editing to do (and I have the token, no pressure ;-) ) but hopefully it all comes together very soon. regards, Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, May 01, 2014 9:30 AM To: lmap@ietf.org Subject: [lmap] status of draft-ietf-lmap-framework Hi, Can we get a short status assessment from the authors of draft-ietf-lmap-fr= amework about where we are with this document after the 2nd WGLC? We receiv= ed at least two sets of solid comments - will these be addressed soon by a = revised I-D? Do we need another WGLC? Thanks and Regards, Dan --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F40AEC29EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve be= en working through the comments and making the minor changes needed. Just a= couple left to do.

&nbs= p;

From:= lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MO= RTON, ALFRED C (AL)
Sent: 01 May 2014 16:10
To: Romasca= nu, Dan (Dan); lmap@ietf.org
Subject: Re: [lmap] status of draft-= ietf-lmap-framework

<= o:p> 

Hi Dan,

 

Give us a few days = to gather our thoughts, early next week perhaps.

We still have editing to do (and I have the token, no pressure= ;-) )

but hopefully it all comes = together very soon.

 

regards,

 

From: lmap= [mailto:lmap-bounces@ietf.org= ] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, May 01= , 2014 9:30 AM
To: lmap@ietf.org=
Subject: [lmap] status of draft-ietf-lmap-framework

 = ;

Hi,

 

Can we get a short status assessme= nt from the authors of draft-ietf-lmap-framework about where we are with th= is document after the 2nd WGLC? We received at least two sets of= solid comments – will these be addressed soon by a revised I-D? Do w= e need another WGLC?

 

Thanks and Regards,

 

Dan

&nb= sp;

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F40AEC29EMV67UKRDdoma_-- From nobody Fri May 2 00: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 AEA121A6EFF for ; Fri, 2 May 2014 00:41:11 -0700 (PDT) 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 rvD0FGEXX4xU for ; Fri, 2 May 2014 00:41:09 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 312A31A6EEF for ; Fri, 2 May 2014 00:41:09 -0700 (PDT) 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, 2 May 2014 08:38:14 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 2 May 2014 08:40:47 +0100 From: To: Date: Fri, 2 May 2014 08:40:46 +0100 Thread-Topic: [lmap] framework comments Thread-Index: Ac9jw29hqu4ZMMjPSwWtix06PhIitgCFj3bA Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130429D2C@GAALPA1MSGUSR9L.ITServices.sbc.com> <535FCB60.9040304@centurylink.com> In-Reply-To: <535FCB60.9040304@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/hJMhfDpVL0ZLfmVLNezZrRvmHL4 Cc: bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] framework comments 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, 02 May 2014 07:41:11 -0000 Since this is an informational framework, I think this document is probably= the wrong place to define such a default time. phil > -----Original Message----- > From: Charles Cook [mailto:charles.cook2@centurylink.com] > Sent: 29 April 2014 16:55 > To: Eardley,PL,Philip,TUB8 R > Cc: bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] framework comments >=20 > Phil, >=20 > Regarding prevention of the MA from continuously executing Measurement > Tasks when contact with the Controller has been lost, I believe there > needs to be a default time. See inline below. >=20 > Charles >=20 > On 4/29/2014 4:31 AM, philip.eardley@bt.com wrote: > > Thanks! > > > >>> [phil] I agree with you, the MA does not have to be in the > >>> customer's premises. > >>> S6 - if anyone can contribute text of MAs located elsewhere, that > >>> would be very helpful. > >> Yes, I'll propose some additional text. I'll do that in a > >> separate email later this week. > > Al wrote this text, what do you reckon? > > > > 6.2.5. Measurement Agent embedded in ISP Networks > > > > A MA may be embedded on a device that is part of an ISP's network, > > such as a router or switch. Usually the network devices with an > > embedded MA will be stategically located, such as a Carrier Grade > NAT > > or ISP Gateway. [I-D.ietf-ippm-lmap-path] gives many examples > where > > a MA might be located within a network to provide an intermediate > > measurement point on the end-to-end path. Other examples include > a > > network device whose primary role is to host MA functions and the > > necessary measurement protocol. > > > >>>> To avoid the MA generating > >>>> traffic forever after a Controller has permanently failed , it > >> is > >>>> suggested that the Measurement Schedule includes a time > limit... > >>>> Comment: I thought we were also going to allow for the MA to just > >>>> stop doing measurements if it didn't hear from the Controller in a > >> while. > >>> [phil] seems to me that these are equivalent, though I don't mind > >> adding it. > >> Given the extensive discussion that was had about this, I'm > >> curious as to what others think. > > [phil] ok. I have changed to say: > > To avoid the MA generating > > traffic forever after a Controller has permanently failed, the MA > can > > be configured with a time limit; if the MA doesn't hear from the > > Controller for this length of time, thenl it stops operating > > Measurement Tasks. > I don't think this solves the problem unless there is a default > time limit that is used if a time interval is not specifically > configured. >=20 > Perhaps something like, >=20 > "To avoid the MA generating traffic forever after a Controller has > permanently failed, the MA will stop operating Measurement Tasks if the > MA does not hear from the Controller for a default length of > time. Optionally, the MA can be configured with a specific time limit; > if the MA doesn't hear from the Controller for this length of time, > then it stops operating Measurement Tasks." >=20 >=20 > > > >>> ... > >>> > >>>> 5.5. Operation of LMAP over the underlying transport protocol > And > >>>> subsequent uses of "underlying transport protocol" in this > section. > >>>> Comment: The description of "transport protocol" in this section > is > >>>> unlike any use of "transport protocol" I've ever seen. Especially > >>>> the part about there being Push, Pull, and multicast transport > >> protocols. > >>>> Multicast only happens at IP or Ethernet, to the best of my > >> knowledge. > >>>> I've never heard of a higher layer protocol capable of multicast. > I > >>>> usually associate "transport protocol" with protocols that operate > >>>> at the transport layer, like TCP and UDP, or with protocols like > >> RTP > >>>> (that has Transport Protocol in its name). But RTP, TCP, UDP and > >>>> such have no Push, Pull, or multicast characteristics. I'm not > sure > >>>> what to recommend about this section -- parts seem usable, but the > >>>> way it's described doesn't relate to my understanding of the > nature > >>>> of various protocols. > >>> Very open to suggested phrasings. > >>> Key word is "underlying". > >>> Simply mean that (say) the LMAP Control Protocol is Controller to > >>> MA, but for instance if it operates over http, then at this > "underlying" > >>> layer the MA does a request (pull) to the Controller and its reply > >>> includes the LMAP Control Protocol info. Or the "underlying" layer > >> may be push or even multicast. > >>> "transport" didn't mean layer 4 but something transporting the LMAP > >> info. > >>> Would "underlying packet transfer mechanism" or "model" be clearer? > >> So what I read you saying is that there are some > >> characteristics that the Control or Report Protocol can "inherit" > >> from underlying protocols (effectively defined as any protocol at > any > >> layer that is below the Control or Report Protocol). This much I > >> agree with, and I think it would be good to rephrase along this > line. > >> However, http does not necessarily imply "Pull". Just because 2 > >> endpoints are in a client/server relationship for a Control or > Report > >> Protocol, doesn't mean that they maintain that same client/server > >> relationship as it relates to http. That is, it's possible for the > >> Controller to be the http client that initiates a http session to > the > >> MA (which is the http server). It can be the higher layer Control or > >> Report protocol that dictates which endpoint can or must be the http > >> client/server. For example, TR-069 does allow the TR-069 config > >> server to initiate http with the TR-069 client for the purpose of > >> sending a "connect to your config server ASAP" message. But only the > >> TR-069 client can initiate a http session for purpose of receiving > >> configuration info (in which case the TR-069 client is the http > >> client and the TR-069 config server is the http server). And so I > >> consider TR- > >> 069 to be a "Pull" protocol. But it doesn't inherit this from http. > >> Because either side can initiate http to the other at different > times. > >> It is TR-069 itself that defines the RPCs (remote procedure calls) > >> and when different RPCs can be used. > >> So I still have a problem with the idea that Push and Pull are > >> necessarily inherited from underlying protocols, or that http > implies > >> "Pull". > >> I agree that multicast is inherited. > >> > > In terms of how to change the text, the first 2 paras seem ok, but > replace the last sentence with: > > How this is done depends on the design of the Control and Report > Protocols, the underlying packet transfer mechanism and how it is > configured (for example, which endpoint is the HTTP client and which > the server). > > > > And then change to: > > For the Control Protocol, the underlying packet transfer mechanism > could be used in a: > > > > o a 'push' mode (that is, from the Controller to the MA) > > > > and similar change for the other bullets. > > > > Does this work? > > > >> > ....................................................................... > >>>> ..... > >>>> 5.6.1. End-user-controlled measurement system ... > >>>> Note that a user can't directly initiate a Measurement > >>>> Task on an ISP- (or regulator-) controlled MA. > >>>> Comment: Why not? Why isn't it allowed to include this ability in > a > >>>> MA design (such as one that is just for the ISP use case and has > >>>> nothing to do with regulatory use case)? > >>> [phil] then there would be two ways of controlling the MA, which is > >>> something we want to avoid. > >> Multiple methods of remote configuration are indeed > >> complicated, which was why I very much agreed with the "one > Controller" restriction. > >> But we have a lot of experience in coordinating between > >> person-directed local configuration and remote automated > >> configuration on various devices. Which is why I don't see it > necessary to forbid this. > > Would be interested to read more about this, do you have a ref > please. > > > >>>> 6.2.3. Measurement Agent embedded behind site NAT /Firewall > >>>> > >>>> The Measurement Agent could also be embedded behind a NAT, a > >>>> firewall, or both. In this case the Controller may not be able > >> to > >>>> unilaterally contact the Measurement Agent unless either static > >> port > >>>> forwarding configuration or firewall pin holing is configured. > >> For > >>>> the former, protocols such as PCP [RFC6887], TR-069 [TR-069]or > >> UPnP > >>>> [UPnP]could be used. For the latter, the Measurement Agent > >> could > >>>> send keepalives towards the Controller to prop open the > firewall > >>>> (and > >>>> perhaps use these also as a network reachability test). > >>>> Comment: Regarding the last sentence, I don't understand what > >>>> keepalives has to do with UPnP. Why not just mention STUN as an > >>>> option for keeping NAT table entries from timing out? > >>> [phil] "for the former" refers to "static port forwarding > >>> configuration" and "for the latter" to "firewall pin holing" > >> Hmm. I think we have terminology-understanding differences at > >> multiple levels here. In my use of the words, a port forwarding rule > >> or mapping is a pinhole. They can be statically (manually, TR-069, > >> SNMP) or dynamically (UPnP IGD, PCP) configured, or dynamically > >> generated as a result of outbound TCP and UDP packets. Because > >> pinholes configured through PCP and UPnP IGD do expire after a > while, > >> and are created on an "as needed" basis, they tend to be considered > dynamic and not static. > >> Pinholes dynamically generated by the NAT or firewall processes as a > >> result of outbound TCP or UDP packets don't tend to be considered > >> "configured". I would suggest rewording this to: > >> The Measurement Agent could also be embedded behind a NAT, a > >> stateful-packet inspection firewall, or both. In this case the > >> Controller may not be able to unilaterally contact the Measurement > >> Agent unless configured or dynamically-generated pinholes exist. > >> Protocols such as PCP [RFC6887], CWMP [TR-069] or UPnP IGD [UPnP > >> IGD] can be used to configure pinholes. For pinholes that are > >> dynamically- generated as a result of outbound TCP or UDP packets, > >> the Measurement Agent could > >> send keepalives, such as those of the STUN protocol [STUN], towards > >> the Controller to keep open the pinholes (and perhaps use these also > >> as a network reachability test). > >> > >> I recommend referencing UPnP IGD, and not just UPnP. And calling the > >> protocol described in TR-069 "CWMP". > > Wfm. Thanks for the text. > > > >>>> -------------------------------- > >>>> 8.3. Key Distinction Between Active and Passive Measurement Tasks > >>>> > >>>> Passive and Active Measurement Tasks raise different privacy > >> issues. > >>>> Passive Measurement Tasks are conducted on a user's traffic > ,... > >>>> Comment: This is not necessarily true if it is possible for the MA > >>>> not to be located in a place where it is associated with a single > >> end user > >>>> or subscriber. I recommend " Passive Measurement Tasks can be > >>>> conducted on a user's traffic ,..." > >>> [phil] how about " Passive Measurement Tasks are conducted on user > >>> traffic"? > >>> (I think "can be conducted" misleadingly hints "but may not be") > >> As has been discussed on this list, Passive Measurements can > >> also be conducted on Active Measurement traffic. I don't consider > MA- > >> or MP- generated Active Measurement traffic to be user traffic. For > >> MAs located outside the customer premises, it is also possible for > an > >> ISP to measure management traffic (between its network elements and > >> systems). > > Good point. > > > > Thanks > > Phil. > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > -- >=20 > 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 Fri May 2 05:30: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 83BE51A6F44 for ; Fri, 2 May 2014 05:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WLhX1pnK20cY for ; Fri, 2 May 2014 05:30:09 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id C2FD61A6F74 for ; Fri, 2 May 2014 05:30:09 -0700 (PDT) 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 s42CU14J014413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2014 06:30:01 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 423A81E0079; Fri, 2 May 2014 07:29:56 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 119011E0076; Fri, 2 May 2014 07:29:56 -0500 (CDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s42CTtMw014593; Fri, 2 May 2014 06:29:55 -0600 (MDT) Received: from [10.188.210.174] (x1069818.dhcp.intranet [10.188.210.174]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s42CTsag014585; Fri, 2 May 2014 06:29:54 -0600 (MDT) Message-ID: <53638FC1.6020002@centurylink.com> Date: Fri, 02 May 2014 06:29:53 -0600 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: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130429D2C@GAALPA1MSGUSR9L.ITServices.sbc.com> <535FCB60.9040304@centurylink.com> In-Reply-To: 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/w54VS3LSgOtST4Xz4EBc90RoJsg Cc: bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] framework comments 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, 02 May 2014 12:30:11 -0000 I'm ok if the default time is defined else where. But I do believe it is appropriate to mention that there is a default time to prevent an MA from continuing indefinitely after losing contact with a Controller. Charles On 5/2/2014 1:40 AM, philip.eardley@bt.com wrote: > Since this is an informational framework, I think this document is probably the wrong place to define such a default time. > > phil > >> -----Original Message----- >> From: Charles Cook [mailto:charles.cook2@centurylink.com] >> Sent: 29 April 2014 16:55 >> To: Eardley,PL,Philip,TUB8 R >> Cc: bs7652@att.com; lmap@ietf.org >> Subject: Re: [lmap] framework comments >> >> Phil, >> >> Regarding prevention of the MA from continuously executing Measurement >> Tasks when contact with the Controller has been lost, I believe there >> needs to be a default time. See inline below. >> >> Charles >> >> On 4/29/2014 4:31 AM, philip.eardley@bt.com wrote: >>> Thanks! >>> >>>>> [phil] I agree with you, the MA does not have to be in the >>>>> customer's premises. >>>>> S6 - if anyone can contribute text of MAs located elsewhere, that >>>>> would be very helpful. >>>> Yes, I'll propose some additional text. I'll do that in a >>>> separate email later this week. >>> Al wrote this text, what do you reckon? >>> >>> 6.2.5. Measurement Agent embedded in ISP Networks >>> >>> A MA may be embedded on a device that is part of an ISP's network, >>> such as a router or switch. Usually the network devices with an >>> embedded MA will be stategically located, such as a Carrier Grade >> NAT >>> or ISP Gateway. [I-D.ietf-ippm-lmap-path] gives many examples >> where >>> a MA might be located within a network to provide an intermediate >>> measurement point on the end-to-end path. Other examples include >> a >>> network device whose primary role is to host MA functions and the >>> necessary measurement protocol. >>> >>>>>> To avoid the MA generating >>>>>> traffic forever after a Controller has permanently failed , it >>>> is >>>>>> suggested that the Measurement Schedule includes a time >> limit... >>>>>> Comment: I thought we were also going to allow for the MA to just >>>>>> stop doing measurements if it didn't hear from the Controller in a >>>> while. >>>>> [phil] seems to me that these are equivalent, though I don't mind >>>> adding it. >>>> Given the extensive discussion that was had about this, I'm >>>> curious as to what others think. >>> [phil] ok. I have changed to say: >>> To avoid the MA generating >>> traffic forever after a Controller has permanently failed, the MA >> can >>> be configured with a time limit; if the MA doesn't hear from the >>> Controller for this length of time, thenl it stops operating >>> Measurement Tasks. >> I don't think this solves the problem unless there is a default >> time limit that is used if a time interval is not specifically >> configured. >> >> Perhaps something like, >> >> "To avoid the MA generating traffic forever after a Controller has >> permanently failed, the MA will stop operating Measurement Tasks if the >> MA does not hear from the Controller for a default length of >> time. Optionally, the MA can be configured with a specific time limit; >> if the MA doesn't hear from the Controller for this length of time, >> then it stops operating Measurement Tasks." >> >> >>>>> ... >>>>> >>>>>> 5.5. Operation of LMAP over the underlying transport protocol >> And >>>>>> subsequent uses of "underlying transport protocol" in this >> section. >>>>>> Comment: The description of "transport protocol" in this section >> is >>>>>> unlike any use of "transport protocol" I've ever seen. Especially >>>>>> the part about there being Push, Pull, and multicast transport >>>> protocols. >>>>>> Multicast only happens at IP or Ethernet, to the best of my >>>> knowledge. >>>>>> I've never heard of a higher layer protocol capable of multicast. >> I >>>>>> usually associate "transport protocol" with protocols that operate >>>>>> at the transport layer, like TCP and UDP, or with protocols like >>>> RTP >>>>>> (that has Transport Protocol in its name). But RTP, TCP, UDP and >>>>>> such have no Push, Pull, or multicast characteristics. I'm not >> sure >>>>>> what to recommend about this section -- parts seem usable, but the >>>>>> way it's described doesn't relate to my understanding of the >> nature >>>>>> of various protocols. >>>>> Very open to suggested phrasings. >>>>> Key word is "underlying". >>>>> Simply mean that (say) the LMAP Control Protocol is Controller to >>>>> MA, but for instance if it operates over http, then at this >> "underlying" >>>>> layer the MA does a request (pull) to the Controller and its reply >>>>> includes the LMAP Control Protocol info. Or the "underlying" layer >>>> may be push or even multicast. >>>>> "transport" didn't mean layer 4 but something transporting the LMAP >>>> info. >>>>> Would "underlying packet transfer mechanism" or "model" be clearer? >>>> So what I read you saying is that there are some >>>> characteristics that the Control or Report Protocol can "inherit" >>>> from underlying protocols (effectively defined as any protocol at >> any >>>> layer that is below the Control or Report Protocol). This much I >>>> agree with, and I think it would be good to rephrase along this >> line. >>>> However, http does not necessarily imply "Pull". Just because 2 >>>> endpoints are in a client/server relationship for a Control or >> Report >>>> Protocol, doesn't mean that they maintain that same client/server >>>> relationship as it relates to http. That is, it's possible for the >>>> Controller to be the http client that initiates a http session to >> the >>>> MA (which is the http server). It can be the higher layer Control or >>>> Report protocol that dictates which endpoint can or must be the http >>>> client/server. For example, TR-069 does allow the TR-069 config >>>> server to initiate http with the TR-069 client for the purpose of >>>> sending a "connect to your config server ASAP" message. But only the >>>> TR-069 client can initiate a http session for purpose of receiving >>>> configuration info (in which case the TR-069 client is the http >>>> client and the TR-069 config server is the http server). And so I >>>> consider TR- >>>> 069 to be a "Pull" protocol. But it doesn't inherit this from http. >>>> Because either side can initiate http to the other at different >> times. >>>> It is TR-069 itself that defines the RPCs (remote procedure calls) >>>> and when different RPCs can be used. >>>> So I still have a problem with the idea that Push and Pull are >>>> necessarily inherited from underlying protocols, or that http >> implies >>>> "Pull". >>>> I agree that multicast is inherited. >>>> >>> In terms of how to change the text, the first 2 paras seem ok, but >> replace the last sentence with: >>> How this is done depends on the design of the Control and Report >> Protocols, the underlying packet transfer mechanism and how it is >> configured (for example, which endpoint is the HTTP client and which >> the server). >>> And then change to: >>> For the Control Protocol, the underlying packet transfer mechanism >> could be used in a: >>> o a 'push' mode (that is, from the Controller to the MA) >>> >>> and similar change for the other bullets. >>> >>> Does this work? >>> >> ....................................................................... >>>>>> ..... >>>>>> 5.6.1. End-user-controlled measurement system ... >>>>>> Note that a user can't directly initiate a Measurement >>>>>> Task on an ISP- (or regulator-) controlled MA. >>>>>> Comment: Why not? Why isn't it allowed to include this ability in >> a >>>>>> MA design (such as one that is just for the ISP use case and has >>>>>> nothing to do with regulatory use case)? >>>>> [phil] then there would be two ways of controlling the MA, which is >>>>> something we want to avoid. >>>> Multiple methods of remote configuration are indeed >>>> complicated, which was why I very much agreed with the "one >> Controller" restriction. >>>> But we have a lot of experience in coordinating between >>>> person-directed local configuration and remote automated >>>> configuration on various devices. Which is why I don't see it >> necessary to forbid this. >>> Would be interested to read more about this, do you have a ref >> please. >>>>>> 6.2.3. Measurement Agent embedded behind site NAT /Firewall >>>>>> >>>>>> The Measurement Agent could also be embedded behind a NAT, a >>>>>> firewall, or both. In this case the Controller may not be able >>>> to >>>>>> unilaterally contact the Measurement Agent unless either static >>>> port >>>>>> forwarding configuration or firewall pin holing is configured. >>>> For >>>>>> the former, protocols such as PCP [RFC6887], TR-069 [TR-069]or >>>> UPnP >>>>>> [UPnP]could be used. For the latter, the Measurement Agent >>>> could >>>>>> send keepalives towards the Controller to prop open the >> firewall >>>>>> (and >>>>>> perhaps use these also as a network reachability test). >>>>>> Comment: Regarding the last sentence, I don't understand what >>>>>> keepalives has to do with UPnP. Why not just mention STUN as an >>>>>> option for keeping NAT table entries from timing out? >>>>> [phil] "for the former" refers to "static port forwarding >>>>> configuration" and "for the latter" to "firewall pin holing" >>>> Hmm. I think we have terminology-understanding differences at >>>> multiple levels here. In my use of the words, a port forwarding rule >>>> or mapping is a pinhole. They can be statically (manually, TR-069, >>>> SNMP) or dynamically (UPnP IGD, PCP) configured, or dynamically >>>> generated as a result of outbound TCP and UDP packets. Because >>>> pinholes configured through PCP and UPnP IGD do expire after a >> while, >>>> and are created on an "as needed" basis, they tend to be considered >> dynamic and not static. >>>> Pinholes dynamically generated by the NAT or firewall processes as a >>>> result of outbound TCP or UDP packets don't tend to be considered >>>> "configured". I would suggest rewording this to: >>>> The Measurement Agent could also be embedded behind a NAT, a >>>> stateful-packet inspection firewall, or both. In this case the >>>> Controller may not be able to unilaterally contact the Measurement >>>> Agent unless configured or dynamically-generated pinholes exist. >>>> Protocols such as PCP [RFC6887], CWMP [TR-069] or UPnP IGD [UPnP >>>> IGD] can be used to configure pinholes. For pinholes that are >>>> dynamically- generated as a result of outbound TCP or UDP packets, >>>> the Measurement Agent could >>>> send keepalives, such as those of the STUN protocol [STUN], towards >>>> the Controller to keep open the pinholes (and perhaps use these also >>>> as a network reachability test). >>>> >>>> I recommend referencing UPnP IGD, and not just UPnP. And calling the >>>> protocol described in TR-069 "CWMP". >>> Wfm. Thanks for the text. >>> >>>>>> -------------------------------- >>>>>> 8.3. Key Distinction Between Active and Passive Measurement Tasks >>>>>> >>>>>> Passive and Active Measurement Tasks raise different privacy >>>> issues. >>>>>> Passive Measurement Tasks are conducted on a user's traffic >> ,... >>>>>> Comment: This is not necessarily true if it is possible for the MA >>>>>> not to be located in a place where it is associated with a single >>>> end user >>>>>> or subscriber. I recommend " Passive Measurement Tasks can be >>>>>> conducted on a user's traffic ,..." >>>>> [phil] how about " Passive Measurement Tasks are conducted on user >>>>> traffic"? >>>>> (I think "can be conducted" misleadingly hints "but may not be") >>>> As has been discussed on this list, Passive Measurements can >>>> also be conducted on Active Measurement traffic. I don't consider >> MA- >>>> or MP- generated Active Measurement traffic to be user traffic. For >>>> MAs located outside the customer premises, it is also possible for >> an >>>> ISP to measure management traffic (between its network elements and >>>> systems). >>> Good point. >>> >>> Thanks >>> Phil. >>> >>> _______________________________________________ >>> 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 -- 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 Fri May 2 06:17: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 032671A0829 for ; Fri, 2 May 2014 06:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-0.651] 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 4khJfDCBwh9m for ; Fri, 2 May 2014 06:17:41 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id E5E341A081E for ; Fri, 2 May 2014 06:17:40 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F2C20A06A7; Fri, 2 May 2014 09:17:37 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id B09ABA06A2; Fri, 2 May 2014 09:17:37 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.242]) by SPQCCAS01.exfo.com ([10.28.36.8]) with mapi id 14.03.0174.001; Fri, 2 May 2014 09:17:37 -0400 From: Sharam Hakimi To: "charles.cook2@centurylink.com" , "philip.eardley@bt.com" Thread-Topic: [lmap] framework comments Thread-Index: Ac9cl9SeoAXxoO+sT62j3uhhwzLuTwBfuc6wASn/ldAANLjhAAAU1CwAAIWbOwAAChjogAAHAGxQ Date: Fri, 2 May 2014 13:17:36 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70438BD@SPQCMBX02.exfo.com> References: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130429D2C@GAALPA1MSGUSR9L.ITServices.sbc.com> <535FCB60.9040304@centurylink.com> <53638FC1.6020002@centurylink.com> In-Reply-To: <53638FC1.6020002@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20668.007 X-TM-AS-Result: No--27.274-5.0-31-10 X-imss-scan-details: No--27.274-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20668.007 X-TMASE-Result: 10--27.273700-5.000000 X-TMASE-MatchedRID: 2KXnFOCVn1Utjw5zGtj91BfY306nA3bo1pnvzMqQcsY0gq6kEa3hCKLo SLE/BAxZZxsSrBqm18536j1DqLiz4vJMF6pylZNWSEQN/D/3cG7jAcZeNJgY9247M5sxfdoId5H 6Aix830BNEWVDgPyDmOU9Y5l2egV8+FujNfhAEcZwUSK4/EeOxVxIyn/X4SmnmVYUc/lHQj2myQ VG1kMNfzqU0eXxXArVzLI42UCz6JZCBQieSpAGz6TRUmfgmDPOZAQzy8TR+Qb7I1hjCeCvFucSJ UnbpVerJLIhkEaqtVgtw2HA9y0L+SFfnnxrNZ4kFYJUGv4DL3yWesyrtKuK7S8zQZ2rR/OppIxg la/nV+B8XOAEXzLbpSXejxvLc3EHSSNF8PKk19sSWCj0fkOcnILsLasl5ROh3Zxj3iBGfms70QE sR+5bRnlKl0stxy4rxtgTkG+GaOcALfxbHOcBRmA/V00XWjDtIR1rLBJm/M5q4coTktrGX+DGTN UP2XLw9diZlAndvVK1jsgoaF7GUwhyclIVCUaFZbgjf4gKTk1bAoaK+wS4jfgnJH5vm2+gmm4Rk aGfby1dsxfiS2NfxLFLSYt4kEAsGaKXE/SfD/Wcnm0v4tsY43idToq2MMwDLcVjbs+keaxLbTUf +O4SvPtZpCb/JALHOHY3aadbY812HzNb3Bcc3iVypP66BP0Q1kqyrcMalqVb6PBUqmq+UqQy/Pu w9Doy0Q2PKuAVSm4xeamNUxAG99ra5QHNzf1z7spMO3HwKCAZKp0SZ4P+dXR4qaW1T8XgthULH5 OIOlyx79vDD0CA9/XxGThQLh69n/m18ngarmueAiCmPx4NwMidYBYDjITp+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/DIPgVMNUsXTdHlZbrNux6-GymY4 Cc: "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] framework comments 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, 02 May 2014 13:17:45 -0000 A while back I had proposed that if the MA could not contact the controller= in three attempts that it should stop testing until it was able to achieve= contact with the controller. The timer for this could be defined elsewhere= and can be a user configurable parameter, but I do agree with Charles that= a default timer is a good idea so that there is an initial bound. Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook Sent: Friday, May 02, 2014 8:30 AM To: philip.eardley@bt.com Cc: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] framework comments I'm ok if the default time is defined else where. But I do believe it is appropriate to mention that there is a default time to prevent an MA from continuing indefinitely after losing contact with a Controller. Charles On 5/2/2014 1:40 AM, philip.eardley@bt.com wrote: > Since this is an informational framework, I think this document is probab= ly the wrong place to define such a default time. > > phil > >> -----Original Message----- >> From: Charles Cook [mailto:charles.cook2@centurylink.com] >> Sent: 29 April 2014 16:55 >> To: Eardley,PL,Philip,TUB8 R >> Cc: bs7652@att.com; lmap@ietf.org >> Subject: Re: [lmap] framework comments >> >> Phil, >> >> Regarding prevention of the MA from continuously executing Measurement >> Tasks when contact with the Controller has been lost, I believe there >> needs to be a default time. See inline below. >> >> Charles >> >> On 4/29/2014 4:31 AM, philip.eardley@bt.com wrote: >>> Thanks! >>> >>>>> [phil] I agree with you, the MA does not have to be in the >>>>> customer's premises. >>>>> S6 - if anyone can contribute text of MAs located elsewhere, that >>>>> would be very helpful. >>>> Yes, I'll propose some additional text. I'll do that in a >>>> separate email later this week. >>> Al wrote this text, what do you reckon? >>> >>> 6.2.5. Measurement Agent embedded in ISP Networks >>> >>> A MA may be embedded on a device that is part of an ISP's network, >>> such as a router or switch. Usually the network devices with an >>> embedded MA will be stategically located, such as a Carrier Grade >> NAT >>> or ISP Gateway. [I-D.ietf-ippm-lmap-path] gives many examples >> where >>> a MA might be located within a network to provide an intermediate >>> measurement point on the end-to-end path. Other examples include >> a >>> network device whose primary role is to host MA functions and the >>> necessary measurement protocol. >>> >>>>>> To avoid the MA generating >>>>>> traffic forever after a Controller has permanently failed , it >>>> is >>>>>> suggested that the Measurement Schedule includes a time >> limit... >>>>>> Comment: I thought we were also going to allow for the MA to just >>>>>> stop doing measurements if it didn't hear from the Controller in a >>>> while. >>>>> [phil] seems to me that these are equivalent, though I don't mind >>>> adding it. >>>> Given the extensive discussion that was had about this, I'm >>>> curious as to what others think. >>> [phil] ok. I have changed to say: >>> To avoid the MA generating >>> traffic forever after a Controller has permanently failed, the MA >> can >>> be configured with a time limit; if the MA doesn't hear from the >>> Controller for this length of time, thenl it stops operating >>> Measurement Tasks. >> I don't think this solves the problem unless there is a default >> time limit that is used if a time interval is not specifically >> configured. >> >> Perhaps something like, >> >> "To avoid the MA generating traffic forever after a Controller has >> permanently failed, the MA will stop operating Measurement Tasks if the >> MA does not hear from the Controller for a default length of >> time. Optionally, the MA can be configured with a specific time limit; >> if the MA doesn't hear from the Controller for this length of time, >> then it stops operating Measurement Tasks." >> >> >>>>> ... >>>>> >>>>>> 5.5. Operation of LMAP over the underlying transport protocol >> And >>>>>> subsequent uses of "underlying transport protocol" in this >> section. >>>>>> Comment: The description of "transport protocol" in this section >> is >>>>>> unlike any use of "transport protocol" I've ever seen. Especially >>>>>> the part about there being Push, Pull, and multicast transport >>>> protocols. >>>>>> Multicast only happens at IP or Ethernet, to the best of my >>>> knowledge. >>>>>> I've never heard of a higher layer protocol capable of multicast. >> I >>>>>> usually associate "transport protocol" with protocols that operate >>>>>> at the transport layer, like TCP and UDP, or with protocols like >>>> RTP >>>>>> (that has Transport Protocol in its name). But RTP, TCP, UDP and >>>>>> such have no Push, Pull, or multicast characteristics. I'm not >> sure >>>>>> what to recommend about this section -- parts seem usable, but the >>>>>> way it's described doesn't relate to my understanding of the >> nature >>>>>> of various protocols. >>>>> Very open to suggested phrasings. >>>>> Key word is "underlying". >>>>> Simply mean that (say) the LMAP Control Protocol is Controller to >>>>> MA, but for instance if it operates over http, then at this >> "underlying" >>>>> layer the MA does a request (pull) to the Controller and its reply >>>>> includes the LMAP Control Protocol info. Or the "underlying" layer >>>> may be push or even multicast. >>>>> "transport" didn't mean layer 4 but something transporting the LMAP >>>> info. >>>>> Would "underlying packet transfer mechanism" or "model" be clearer? >>>> So what I read you saying is that there are some >>>> characteristics that the Control or Report Protocol can "inherit" >>>> from underlying protocols (effectively defined as any protocol at >> any >>>> layer that is below the Control or Report Protocol). This much I >>>> agree with, and I think it would be good to rephrase along this >> line. >>>> However, http does not necessarily imply "Pull". Just because 2 >>>> endpoints are in a client/server relationship for a Control or >> Report >>>> Protocol, doesn't mean that they maintain that same client/server >>>> relationship as it relates to http. That is, it's possible for the >>>> Controller to be the http client that initiates a http session to >> the >>>> MA (which is the http server). It can be the higher layer Control or >>>> Report protocol that dictates which endpoint can or must be the http >>>> client/server. For example, TR-069 does allow the TR-069 config >>>> server to initiate http with the TR-069 client for the purpose of >>>> sending a "connect to your config server ASAP" message. But only the >>>> TR-069 client can initiate a http session for purpose of receiving >>>> configuration info (in which case the TR-069 client is the http >>>> client and the TR-069 config server is the http server). And so I >>>> consider TR- >>>> 069 to be a "Pull" protocol. But it doesn't inherit this from http. >>>> Because either side can initiate http to the other at different >> times. >>>> It is TR-069 itself that defines the RPCs (remote procedure calls) >>>> and when different RPCs can be used. >>>> So I still have a problem with the idea that Push and Pull are >>>> necessarily inherited from underlying protocols, or that http >> implies >>>> "Pull". >>>> I agree that multicast is inherited. >>>> >>> In terms of how to change the text, the first 2 paras seem ok, but >> replace the last sentence with: >>> How this is done depends on the design of the Control and Report >> Protocols, the underlying packet transfer mechanism and how it is >> configured (for example, which endpoint is the HTTP client and which >> the server). >>> And then change to: >>> For the Control Protocol, the underlying packet transfer mechanism >> could be used in a: >>> o a 'push' mode (that is, from the Controller to the MA) >>> >>> and similar change for the other bullets. >>> >>> Does this work? >>> >> ....................................................................... >>>>>> ..... >>>>>> 5.6.1. End-user-controlled measurement system ... >>>>>> Note that a user can't directly initiate a Measurement >>>>>> Task on an ISP- (or regulator-) controlled MA. >>>>>> Comment: Why not? Why isn't it allowed to include this ability in >> a >>>>>> MA design (such as one that is just for the ISP use case and has >>>>>> nothing to do with regulatory use case)? >>>>> [phil] then there would be two ways of controlling the MA, which is >>>>> something we want to avoid. >>>> Multiple methods of remote configuration are indeed >>>> complicated, which was why I very much agreed with the "one >> Controller" restriction. >>>> But we have a lot of experience in coordinating between >>>> person-directed local configuration and remote automated >>>> configuration on various devices. Which is why I don't see it >> necessary to forbid this. >>> Would be interested to read more about this, do you have a ref >> please. >>>>>> 6.2.3. Measurement Agent embedded behind site NAT /Firewall >>>>>> >>>>>> The Measurement Agent could also be embedded behind a NAT, a >>>>>> firewall, or both. In this case the Controller may not be able >>>> to >>>>>> unilaterally contact the Measurement Agent unless either static >>>> port >>>>>> forwarding configuration or firewall pin holing is configured. >>>> For >>>>>> the former, protocols such as PCP [RFC6887], TR-069 [TR-069]or >>>> UPnP >>>>>> [UPnP]could be used. For the latter, the Measurement Agent >>>> could >>>>>> send keepalives towards the Controller to prop open the >> firewall >>>>>> (and >>>>>> perhaps use these also as a network reachability test). >>>>>> Comment: Regarding the last sentence, I don't understand what >>>>>> keepalives has to do with UPnP. Why not just mention STUN as an >>>>>> option for keeping NAT table entries from timing out? >>>>> [phil] "for the former" refers to "static port forwarding >>>>> configuration" and "for the latter" to "firewall pin holing" >>>> Hmm. I think we have terminology-understanding differences at >>>> multiple levels here. In my use of the words, a port forwarding rule >>>> or mapping is a pinhole. They can be statically (manually, TR-069, >>>> SNMP) or dynamically (UPnP IGD, PCP) configured, or dynamically >>>> generated as a result of outbound TCP and UDP packets. Because >>>> pinholes configured through PCP and UPnP IGD do expire after a >> while, >>>> and are created on an "as needed" basis, they tend to be considered >> dynamic and not static. >>>> Pinholes dynamically generated by the NAT or firewall processes as a >>>> result of outbound TCP or UDP packets don't tend to be considered >>>> "configured". I would suggest rewording this to: >>>> The Measurement Agent could also be embedded behind a NAT, a >>>> stateful-packet inspection firewall, or both. In this case the >>>> Controller may not be able to unilaterally contact the Measurement >>>> Agent unless configured or dynamically-generated pinholes exist. >>>> Protocols such as PCP [RFC6887], CWMP [TR-069] or UPnP IGD [UPnP >>>> IGD] can be used to configure pinholes. For pinholes that are >>>> dynamically- generated as a result of outbound TCP or UDP packets, >>>> the Measurement Agent could >>>> send keepalives, such as those of the STUN protocol [STUN], towards >>>> the Controller to keep open the pinholes (and perhaps use these also >>>> as a network reachability test). >>>> >>>> I recommend referencing UPnP IGD, and not just UPnP. And calling the >>>> protocol described in TR-069 "CWMP". >>> Wfm. Thanks for the text. >>> >>>>>> -------------------------------- >>>>>> 8.3. Key Distinction Between Active and Passive Measurement Tasks >>>>>> >>>>>> Passive and Active Measurement Tasks raise different privacy >>>> issues. >>>>>> Passive Measurement Tasks are conducted on a user's traffic >> ,... >>>>>> Comment: This is not necessarily true if it is possible for the MA >>>>>> not to be located in a place where it is associated with a single >>>> end user >>>>>> or subscriber. I recommend " Passive Measurement Tasks can be >>>>>> conducted on a user's traffic ,..." >>>>> [phil] how about " Passive Measurement Tasks are conducted on user >>>>> traffic"? >>>>> (I think "can be conducted" misleadingly hints "but may not be") >>>> As has been discussed on this list, Passive Measurements can >>>> also be conducted on Active Measurement traffic. I don't consider >> MA- >>>> or MP- generated Active Measurement traffic to be user traffic. For >>>> MAs located outside the customer premises, it is also possible for >> an >>>> ISP to measure management traffic (between its network elements and >>>> systems). >>> Good point. >>> >>> Thanks >>> Phil. >>> >>> _______________________________________________ >>> 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 --=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 May 2 18:49: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 AC1F81A6F53 for ; Fri, 2 May 2014 18:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ohm2M_bv9Aij for ; Fri, 2 May 2014 18:49:54 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 02D671A0987 for ; Fri, 2 May 2014 18:49:53 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id il7so881653vcb.24 for ; Fri, 02 May 2014 18:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=pjrcGd2QP71/Sr28jQorUlW86ETpsw/tuVPhWAekWF0=; b=vOVZo0qk9x7AyDZ4bFHSid+A+0vYCvsDL/rKmvgRDdbhbm+8ujJEGXr5cjmr/ywwAA /Grf0ffYi6A5AQz1rLJ1x5jwYem2GMoi3XaJZdDP7Z5c+zrpYE4PHKbzgxiAfocKtfcL SS21NjIDsUD/Vm59oUV224hyuOcZq+AnugdtFmyzyg+UTCX9vrbdKEi1mJR1mozL9JSs DOK5LqVfNnqbTOyqY/IdN1qfoANSk+a0pGX29lK6uXM+hcsBTr9t3swGbz3/cvwYdFPZ xKIM6BaghqvQLRtuNlZWBzoTR/kIlOLA/ZKM1iTiIhDw2WpRZaCfwd97JhFhWWrtw4Ra vGsg== MIME-Version: 1.0 X-Received: by 10.58.74.38 with SMTP id q6mr15356702vev.7.1399081791277; Fri, 02 May 2014 18:49:51 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Fri, 2 May 2014 18:49:51 -0700 (PDT) In-Reply-To: <20140428202335.GF25535@elstar.local> References: <20140401153808.GA74655@elstar.local> <2D09D61DDFA73D4C884805CC7865E611304167DE@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140401162700.GA74749@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416931@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140402055542.GA75833@elstar.local> <20140402092859.GA76386@elstar.local> <20140428192856.GA25535@elstar.local> <535EB6EA.5020402@centurylink.com> <20140428202335.GF25535@elstar.local> Date: Fri, 2 May 2014 18:49:51 -0700 Message-ID: From: Greg Mirsky To: Juergen Schoenwaelder , Charles Cook , "philip.eardley@bt.com" , bs7652@att.com, "lmap@ietf.org" Content-Type: multipart/alternative; boundary=047d7bacbedc2e4f6804f8751d74 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2lICtEEOSTDRVt9k0xcZHuM5n7w Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.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: Sat, 03 May 2014 01:49:55 -0000 --047d7bacbedc2e4f6804f8751d74 Content-Type: text/plain; charset=UTF-8 Hi Juergen, et. al, is the Suppression viewed as result of explicit command from MA Controller to MA Agent or it may be implicitly determined by an MA based on certain conditions of network environment? If that is the former, then I think that there may be not one but two types of Suppression: - suppression of Measurement Task(s) - suppression of reporting Results (but not suppressing failure notification) And if that is the latter, then both types seems be valid as well: - certain Measurement Tasks may be suppressed as resource utilization threshold crossed - posting Results would be suppressed if Data Collector deemed unavailable But I'm not sure to what level of details we need to characterize and describe Suppression mechanism in the framework document. I think that details may be placed and explained in specification of the Control protocol while LMAP framework would mention Suppression mechanism in very generic terms leaving details for further study. Regards, Greg On Mon, Apr 28, 2014 at 1:23 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Apr 28, 2014 at 02:15:38PM -0600, Charles Cook wrote: > > It is good we are having this discussion. I am not sure if I am saying > > the same as what Juergen is saying in b), but my understanding is that: > > > > Default Suppression means that all Measurement Tasks that generate > > traffic are suppressed (however the MA decides how to do that - > > filtering at the MA so that no traffic is generated could be one way to > > do it, cancelling the current instance of the Measurement Task could be > > another way to do it). Schedules stay in place such that if an > > un-Suppression is received, that a scheduled Measurement Task will > > commence when the time comes (as long as the scheduled time for the > > Measurement Task to be executed occurs after the un-Suppression has been > > received). > > > > I prefer to have a precise definition what suppression means. I can > easily picture measurement tasks where leaving the task running while > temporarily block the traffic leads to different results compared to > stopping the task and restarting it later. In terms of the traffic > generated during suppression, the result may be the same but a restart > causes measurement task internal context information to get lost, > which can be more disruptive to the measurement. > > /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 > --047d7bacbedc2e4f6804f8751d74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juergen, et. al,
is t= he Suppression viewed as result of explicit command from MA Controller to M= A Agent or it may be implicitly determined by an MA based on certain condit= ions of network environment? If that is the former, then I think that there= may be not one but two types of Suppression:
  • suppression of Measurement Task(s)
  • suppression of reporting= Results (but not suppressing failure notification)
And = if that is the latter, then both types seems be valid as well:
  • certain Measurement Tasks may be suppressed as resource utilization= threshold crossed
  • posting Results would be suppressed if Data Coll= ector deemed unavailable
But I'm not sure to what level = of details we need to characterize and describe Suppression mechanism in th= e framework document. I think that details may be placed and explained in s= pecification of the Control protocol while LMAP framework would mention Sup= pression mechanism in very generic terms leaving details for further study.=

Regards,
Greg


On Mon, Apr 28, 2014 at 1:23 PM, Juergen Schoenwaeld= er <j.schoenwaelder@jacobs-university.de>= wrote:
On Mon, Apr 28, 2014 at 02:1= 5:38PM -0600, Charles Cook wrote:
> It is good we are having this discussion. =C2=A0I am not sure if I am = saying
> the same as what Juergen is saying in b), but my understanding is that= :
>
> Default Suppression means that all Measurement Tasks that generate
> traffic are suppressed (however the MA decides how to do that -
> filtering at the MA so that no traffic is generated could be one way t= o
> do it, cancelling the current instance of the Measurement Task could b= e
> another way to do it). =C2=A0Schedules stay in place such that if an > un-Suppression is received, that a scheduled Measurement Task will
> commence when the time comes (as long as the scheduled time for the > Measurement Task to be executed occurs after the un-Suppression has be= en
> received).
>

I prefer to have a precise definition what suppression means. I can easily picture measurement tasks where leaving the task running while
temporarily block the traffic leads to different results compared to
stopping the task and restarting it later. In terms of the traffic
generated during suppression, the result may be the same but a restart
causes measurement task internal context information to get lost,
which can be more disruptive to the measurement.

/js

--
Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University = Bremen gGmbH
Phone: +49= 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Bremen, = Germany
Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-university.de/= >

_____________________________= __________________
lmap mailing list
lmap@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lmap

--047d7bacbedc2e4f6804f8751d74-- From nobody Sat May 3 05:57: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 432B81A00A3 for ; Sat, 3 May 2014 05:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 u2bL60GW3k-l for ; Sat, 3 May 2014 05:57:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 023D71A009C for ; Sat, 3 May 2014 05:57:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DA4B311F9; Sat, 3 May 2014 14:57:44 +0200 (CEST) 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 493ATBX6WOON; Sat, 3 May 2014 14:57:44 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 3 May 2014 14:57:44 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5C442002C; Sat, 3 May 2014 14:57:43 +0200 (CEST) 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 OCxzQGZ1GVFS; Sat, 3 May 2014 14:57:42 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 639C220013; Sat, 3 May 2014 14:57:42 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 35BCC2CC8857; Sat, 3 May 2014 14:57:42 +0200 (CEST) Date: Sat, 3 May 2014 14:57:42 +0200 From: Juergen Schoenwaelder To: Greg Mirsky Message-ID: <20140503125742.GB38536@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Greg Mirsky , Charles Cook , "philip.eardley@bt.com" , bs7652@att.com, "lmap@ietf.org" References: <20140401162700.GA74749@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416931@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140402055542.GA75833@elstar.local> <20140402092859.GA76386@elstar.local> <20140428192856.GA25535@elstar.local> <535EB6EA.5020402@centurylink.com> <20140428202335.GF25535@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Rwr1iVs-vl-N770hNXJCHmqgPS8 Cc: "philip.eardley@bt.com" , Charles Cook , bs7652@att.com, "lmap@ietf.org" Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt 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: Sat, 03 May 2014 12:57:50 -0000 On Fri, May 02, 2014 at 06:49:51PM -0700, Greg Mirsky wrote: > Hi Juergen, et. al, > is the Suppression viewed as result of explicit command from MA Controller > to MA Agent or it may be implicitly determined by an MA based on certain > conditions of network environment? If that is the former, then I think that > there may be not one but two types of Suppression: > > - suppression of Measurement Task(s) > - suppression of reporting Results (but not suppressing failure > notification) In the -00 information model, suppression is communicated from the Controller to the MA and suppression can be time scheduled. > And if that is the latter, then both types seems be valid as well: > > - certain Measurement Tasks may be suppressed as resource utilization > threshold crossed > - posting Results would be suppressed if Data Collector deemed > unavailable > > But I'm not sure to what level of details we need to characterize and > describe Suppression mechanism in the framework document. I think that > details may be placed and explained in specification of the Control > protocol while LMAP framework would mention Suppression mechanism in very > generic terms leaving details for further study. There was some discussion to consider reporting a reporting task that gets schedulued list a measurement task and in that case suppression could easily applied to both kind of tasks. But this is not in -00. /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 Sat May 3 23:47: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 525211A00A7 for ; Sat, 3 May 2014 23:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 q420eoKqVthn for ; Sat, 3 May 2014 23:47:31 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id B9F5B1A0095 for ; Sat, 3 May 2014 23:47:30 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15365e262e94-ace94; Sun, 04 May 2014 14:46:58 +0800 (CST) X-RM-TRANSID: 2ee15365e262e94-ace94 Received: from cmccPC (unknown[10.2.43.246]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15365e261272-3a517; Sun, 04 May 2014 14:46:58 +0800 (CST) X-RM-TRANSID: 2ee15365e261272-3a517 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'Juergen Schoenwaelder'" , "'Greg Mirsky'" References: <20140401162700.GA74749@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416931@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140402055542.GA75833@elstar.local> <20140402092859.GA76386@elstar.local> <20140428192856.GA25535@elstar.local> <535EB6EA.5020402@centurylink.com> <20140428202335.GF25535@elstar.local> <20140503125742.GB38536@elstar.jacobs.jacobs-university.de> In-Reply-To: <20140503125742.GB38536@elstar.jacobs.jacobs-university.de> Date: Sun, 4 May 2014 14:47:19 +0800 Message-ID: <001e01cf6764$b1e43fb0$15acbf10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9mzz+z/FCV5H9DTiqY2nQz6WqpiwAkyPHg Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ENrVk_xccbycC9OoLJIcbAJmAbA Cc: philip.eardley@bt.com, 'Charles Cook' , bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.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, 04 May 2014 06:47:33 -0000 Hi all, Following up the suppression discussion, I also have a question (inline = below) regarding the framework draft. Lingli > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Saturday, May 03, 2014 8:58 PM > To: Greg Mirsky > Cc: philip.eardley@bt.com; Charles Cook; bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for > draft-ietf-lmap-framework-04.txt >=20 > On Fri, May 02, 2014 at 06:49:51PM -0700, Greg Mirsky wrote: > > Hi Juergen, et. al, > > is the Suppression viewed as result of explicit command from MA = Controller > > to MA Agent or it may be implicitly determined by an MA based on = certain > > conditions of network environment? If that is the former, then I = think that > > there may be not one but two types of Suppression: > > > > - suppression of Measurement Task(s) > > - suppression of reporting Results (but not suppressing failure > > notification) >=20 > In the -00 information model, suppression is communicated from the > Controller to the MA and suppression can be time scheduled. [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] There is an element in the = instruction structure, under the name of "suppression information (if = any)" in the current framework draft. When I read through the draft, I assumed that it was for the second case = that Greg mentioned as suppressions "implicitly determined by an MA = based on certain conditions of network environment". However, I could not find any clear = explanation in the text to justify this speculation. As it simply states = " (see Section 5.2.1.1) " and without any further information actually = given in Section 5.2.1.1. I would like to see more text to clarify the = purpose and content of this element. >=20 > > And if that is the latter, then both types seems be valid as well: > > > > - certain Measurement Tasks may be suppressed as resource = utilization > > threshold crossed > > - posting Results would be suppressed if Data Collector deemed > > unavailable > > > > But I'm not sure to what level of details we need to characterize = and > > describe Suppression mechanism in the framework document. I think = that > > details may be placed and explained in specification of the Control > > protocol while LMAP framework would mention Suppression mechanism in > very > > generic terms leaving details for further study. >=20 > There was some discussion to consider reporting a reporting task that > gets schedulued list a measurement task and in that case suppression > could easily applied to both kind of tasks. But this is not in -00. >=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 nobody Sun May 4 01:31: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 8E9C01A0045 for ; Sun, 4 May 2014 01:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.028 X-Spam-Level: X-Spam-Status: No, score=-0.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 KwlFVNnCUJ5E for ; Sun, 4 May 2014 01:31:51 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 8AAAB1A0043 for ; Sun, 4 May 2014 01:31:50 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15365fad8c7c-aec7c; Sun, 04 May 2014 16:31:20 +0800 (CST) X-RM-TRANSID: 2ee15365fad8c7c-aec7c Received: from cmccPC (unknown[10.2.43.246]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15365fad578e-3aa34; Sun, 04 May 2014 16:31:20 +0800 (CST) X-RM-TRANSID: 2ee15365fad578e-3aa34 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: , , , References: <9904FB1B0159DA42B0B887B7FA8119CA5C7CE3EE@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C801795CD13A@njfpsrvexg8.research.att.com> In-Reply-To: Date: Sun, 4 May 2014 16:31:41 +0800 Message-ID: <004201cf6773$4650bcb0$d2f23610$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01CF67B6.5473FCB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9lQWszsEFFzJ3WQVGDECGoagKgxgADXX+gACKVnCAAZguNMA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/83xiTbJAZKNaN8my0MheWH4g10s Subject: Re: [lmap] status of draft-ietf-lmap-framework 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, 04 May 2014 08:31:53 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0043_01CF67B6.5473FCB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Phil and all, =20 Two nits in the current -04 framework draft ^-^ =20 1, In section 6.1, third paragraph: s/Typically/Typical/ 2, In section 7, page 29, last paragraph: s/push/pull/ =20 Lingli =20 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com Sent: Friday, May 02, 2014 3:38 PM To: acmorton@att.com; dromasca@avaya.com; lmap@ietf.org Subject: Re: [lmap] status of draft-ietf-lmap-framework =20 We=E2=80=99ve been working through the comments and making the minor = changes needed. Just a couple left to do. =20 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C = (AL) Sent: 01 May 2014 16:10 To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] status of draft-ietf-lmap-framework =20 Hi Dan, =20 Give us a few days to gather our thoughts, early next week perhaps. We still have editing to do (and I have the token, no pressure ;-) ) but hopefully it all comes together very soon. =20 regards, Al =20 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan = (Dan) Sent: Thursday, May 01, 2014 9:30 AM To: lmap@ietf.org Subject: [lmap] status of draft-ietf-lmap-framework =20 Hi, =20 Can we get a short status assessment from the authors of = draft-ietf-lmap-framework about where we are with this document after = the 2nd WGLC? We received at least two sets of solid comments =E2=80=93 = will these be addressed soon by a revised I-D? Do we need another WGLC?=20 =20 Thanks and Regards, =20 Dan =20 ------=_NextPart_000_0043_01CF67B6.5473FCB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Phil and = all,

 

Two nits in the current -04 = framework draft ^-^

 

1, In section 6.1, third = paragraph: s/Typically/Typical/

2, In section 7, page 29, last = paragraph: s/push/pull/

 

Lingli

 

From:= lmap = [mailto:lmap-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: Friday, May 02, 2014 3:38 = PM
To: acmorton@att.com; dromasca@avaya.com; = lmap@ietf.org
Subject: Re: [lmap] status of = draft-ietf-lmap-framework

 

We= =E2=80=99ve been working through the comments and making the minor = changes needed. Just a couple left to do.

 

From:= lmap = [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C = (AL)
Sent: 01 May 2014 16:10
To: Romascanu, Dan = (Dan); lmap@ietf.org
Subject: Re: [lmap] status of = draft-ietf-lmap-framework

 

Hi = Dan,

 

Give = us a few days to gather our thoughts, early next week = perhaps.

We still have = editing to do (and I have the token, no pressure ;-) = )

but hopefully it = all comes together very soon.

 

regards,

Al

 

From:= lmap [mailto:lmap-bounces@ietf.org] = On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, May = 01, 2014 9:30 AM
To: lmap@ietf.org
Subject: = [lmap] status of = draft-ietf-lmap-framework

 

Hi,

 

Can we get a short status = assessment from the authors of draft-ietf-lmap-framework about where we = are with this document after the 2nd WGLC? We received at = least two sets of solid comments =E2=80=93 will these be addressed soon = by a revised I-D? Do we need another WGLC?

 

Thanks and = Regards,

 

Dan

 

<= /html> ------=_NextPart_000_0043_01CF67B6.5473FCB0-- From nobody Mon May 5 05:48: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 B44201A0320 for ; Mon, 5 May 2014 05:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 1V1y1z2h1vaa for ; Mon, 5 May 2014 05:47:57 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id E95591A0079 for ; Mon, 5 May 2014 05:47:56 -0700 (PDT) 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 97887635.0.8818103.00-2304.24609147.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 05 May 2014 12:47:53 +0000 (UTC) X-MXL-Hash: 53678879356c4e28-7aabebc1b7297182d88092d6d5279f5d08886357 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 s45ClrgB027835 for ; Mon, 5 May 2014 08:47:53 -0400 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 s45ClkD4027756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 May 2014 08:47:47 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi131.aldc.att.com (RSA Interceptor) for ; Mon, 5 May 2014 12:47:39 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; Mon, 5 May 2014 08:47:39 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: Suppress suppression? Thread-Index: Ac9oYDGZamI4eQWTTe+RPRKfmLhJLw== Date: Mon, 5 May 2014 12:47:38 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113042B519@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.72.97] 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=QZ3RSLnv c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=GR14d-V_0qwA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=mg7yAwt6W] X-AnalysisOut: [2gj20JGYv8A: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/A0YDchCTVXt60qWUFdxy2cWnbHY Subject: [lmap] Suppress suppression? 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, 05 May 2014 12:47:58 -0000 Given all of the Suppression difficulty we're having, I'd like to suggest a= radically different approach: either don't define it at all, or define it = as a loose, optional concept. We know that it's possible to stop any or all measurements or reports simpl= y by updating the Instruction. So we don't absolutely need Suppression. I'm becoming convinced that Suppression is rapidly becoming bigger and more= complex, the more we discuss it. The more tightly defined it is, the more = bells and whistles that get added, the more complex it becomes. Complexity = =3D cost. For me, the complexity is getting to the point that the disadvant= ages of this ever-increasing complexity are starting to outweigh any potent= ial benefit of having something simple that can stop measurement traffic fr= om originating from an MA. My summary of positions regarding Suppression are: Position 1: Suppression must cause X to happen. Reason: This is lowest comp= lexity for my expected design. Position 2: No, Suppression must cause subset-of-X to happen. Reason: This = is lowest complexity for my expected design. Suggestion: Can we allow for S= uppression to cause X or subset-of-X? Either way, subset-of-X happens. Position 3: No, we cannot allow for ambiguity in Suppression behavior. I'm not seeing any near-term coming together of positions happening. If we get rid of Suppression in LMAP, and don't mention it at all, then the= re is no ambiguity. It wouldn't be forbidden (because it wouldn't be mentio= ned). So if implementers or other orgs choose to do something along this li= ne, that's ok. Barbara From nobody Mon May 5 19:36: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 E7A511A0207 for ; Mon, 5 May 2014 19:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 tuFPPSGJxerF for ; Mon, 5 May 2014 19:36:47 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 71B921A0572 for ; Mon, 5 May 2014 19:36:45 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee153684a9c672-d7672; Tue, 06 May 2014 10:36:12 +0800 (CST) X-RM-TRANSID: 2ee153684a9c672-d7672 Received: from cmccPC (unknown[10.2.43.246]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee153684a9b179-42422; Tue, 06 May 2014 10:36:12 +0800 (CST) X-RM-TRANSID: 2ee153684a9b179-42422 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'STARK, BARBARA H'" , References: <2D09D61DDFA73D4C884805CC7865E6113042B519@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113042B519@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Tue, 6 May 2014 10:36:33 +0800 Message-ID: <005001cf68d3$ff06fd30$fd14f790$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9oYDGZamI4eQWTTe+RPRKfmLhJLwAcde2g Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_LcpS2Im2blsrx4VU9h8Qg9SLeg Subject: Re: [lmap] Suppress suppression? 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, 06 May 2014 02:36:49 -0000 Hi Barbara, I don't think we should avoid defining suppression. As I view it as an = important feature for active measurement management. > We know that it's possible to stop any or all measurements or reports = simply by > updating the Instruction. So we don't absolutely need Suppression. [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] I suppose this holds for = controller directly triggered suppression only. It would be of value if = one can indicate in an instruction to guide MA's locally triggered = suppression based on certain conditions for resource-demanding active = measurement tasks. Lingli > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA = H > Sent: Monday, May 05, 2014 8:48 PM > To: lmap@ietf.org > Subject: [lmap] Suppress suppression? >=20 > Given all of the Suppression difficulty we're having, I'd like to = suggest a radically > different approach: either don't define it at all, or define it as a = loose, optional > concept. >=20 > We know that it's possible to stop any or all measurements or reports = simply by > updating the Instruction. So we don't absolutely need Suppression. > I'm becoming convinced that Suppression is rapidly becoming bigger and = more > complex, the more we discuss it. The more tightly defined it is, the = more bells > and whistles that get added, the more complex it becomes. Complexity = =3D cost. > For me, the complexity is getting to the point that the disadvantages = of this > ever-increasing complexity are starting to outweigh any potential = benefit of > having something simple that can stop measurement traffic from = originating > from an MA. >=20 > My summary of positions regarding Suppression are: > Position 1: Suppression must cause X to happen. Reason: This is lowest > complexity for my expected design. > Position 2: No, Suppression must cause subset-of-X to happen. Reason: = This is > lowest complexity for my expected design. Suggestion: Can we allow for > Suppression to cause X or subset-of-X? Either way, subset-of-X = happens. > Position 3: No, we cannot allow for ambiguity in Suppression behavior. >=20 > I'm not seeing any near-term coming together of positions happening. >=20 > If we get rid of Suppression in LMAP, and don't mention it at all, = then there is no > ambiguity. It wouldn't be forbidden (because it wouldn't be = mentioned). So if > implementers or other orgs choose to do something along this line, = that's ok. > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue May 6 02:51: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 F07F81A0173 for ; Tue, 6 May 2014 02:51:42 -0700 (PDT) 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 OTe1FEhqTEZw for ; Tue, 6 May 2014 02:51:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 46CFC1A0660 for ; Tue, 6 May 2014 02:51:39 -0700 (PDT) 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; Tue, 6 May 2014 10:48:47 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Tue, 6 May 2014 10:51:25 +0100 From: To: , , , Date: Tue, 6 May 2014 10:51:24 +0100 Thread-Topic: [lmap] status of draft-ietf-lmap-framework Thread-Index: Ac9lQWszsEFFzJ3WQVGDECGoagKgxgADXX+gACKVnCAAZguNMABn0iWQ Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C7CE3EE@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C801795CD13A@njfpsrvexg8.research.att.com> <004201cf6773$4650bcb0$d2f23610$@com> In-Reply-To: <004201cf6773$4650bcb0$d2f23610$@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_A2E337CDB7BC4145B018B9BEE8EB3E0D40F40AF003EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/aMmvm_8aVpvJGPDiBtxz09T8ytg Subject: Re: [lmap] status of draft-ietf-lmap-framework 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, 06 May 2014 09:51:43 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F40AF003EMV67UKRDdoma_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzDQoNCkZyb206IOmCk+eBteiOiS9MaW5nbGkgRGVuZyBbbWFpbHRvOmRlbmdsaW5nbGlA Y2hpbmFtb2JpbGUuY29tXQ0KU2VudDogMDQgTWF5IDIwMTQgMDk6MzINClRvOiBFYXJkbGV5LFBM LFBoaWxpcCxUVUI4IFI7IGFjbW9ydG9uQGF0dC5jb207IGRyb21hc2NhQGF2YXlhLmNvbTsgbG1h cEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtsbWFwXSBzdGF0dXMgb2YgZHJhZnQtaWV0Zi1sbWFw LWZyYW1ld29yaw0KDQpIaSBQaGlsIGFuZCBhbGwsDQoNClR3byBuaXRzIGluIHRoZSBjdXJyZW50 IC0wNCBmcmFtZXdvcmsgZHJhZnQgXi1eDQoNCjEsIEluIHNlY3Rpb24gNi4xLCB0aGlyZCBwYXJh Z3JhcGg6IHMvVHlwaWNhbGx5L1R5cGljYWwvDQoyLCBJbiBzZWN0aW9uIDcsIHBhZ2UgMjksIGxh c3QgcGFyYWdyYXBoOiBzL3B1c2gvcHVsbC8NCg0KTGluZ2xpDQoNCkZyb206IGxtYXAgW21haWx0 bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBwaGlsaXAuZWFyZGxleUBidC5j b208bWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbT4NClNlbnQ6IEZyaWRheSwgTWF5IDAyLCAy MDE0IDM6MzggUE0NClRvOiBhY21vcnRvbkBhdHQuY29tPG1haWx0bzphY21vcnRvbkBhdHQuY29t PjsgZHJvbWFzY2FAYXZheWEuY29tPG1haWx0bzpkcm9tYXNjYUBhdmF5YS5jb20+OyBsbWFwQGll dGYub3JnPG1haWx0bzpsbWFwQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtsbWFwXSBzdGF0dXMg b2YgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yaw0KDQpXZeKAmXZlIGJlZW4gd29ya2luZyB0aHJv dWdoIHRoZSBjb21tZW50cyBhbmQgbWFraW5nIHRoZSBtaW5vciBjaGFuZ2VzIG5lZWRlZC4gSnVz dCBhIGNvdXBsZSBsZWZ0IHRvIGRvLg0KDQpGcm9tOiBsbWFwIFttYWlsdG86bG1hcC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTU9SVE9OLCBBTEZSRUQgQyAoQUwpDQpTZW50OiAwMSBN YXkgMjAxNCAxNjoxMA0KVG86IFJvbWFzY2FudSwgRGFuIChEYW4pOyBsbWFwQGlldGYub3JnPG1h aWx0bzpsbWFwQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtsbWFwXSBzdGF0dXMgb2YgZHJhZnQt aWV0Zi1sbWFwLWZyYW1ld29yaw0KDQpIaSBEYW4sDQoNCkdpdmUgdXMgYSBmZXcgZGF5cyB0byBn YXRoZXIgb3VyIHRob3VnaHRzLCBlYXJseSBuZXh0IHdlZWsgcGVyaGFwcy4NCldlIHN0aWxsIGhh dmUgZWRpdGluZyB0byBkbyAoYW5kIEkgaGF2ZSB0aGUgdG9rZW4sIG5vIHByZXNzdXJlIDstKSAp DQpidXQgaG9wZWZ1bGx5IGl0IGFsbCBjb21lcyB0b2dldGhlciB2ZXJ5IHNvb24uDQoNCnJlZ2Fy ZHMsDQpBbA0KDQpGcm9tOiBsbWFwIFttYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgUm9tYXNjYW51LCBEYW4gKERhbikNClNlbnQ6IFRodXJzZGF5LCBNYXkgMDEsIDIw MTQgOTozMCBBTQ0KVG86IGxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbbG1hcF0gc3RhdHVzIG9mIGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmsNCg0KSGksDQoN CkNhbiB3ZSBnZXQgYSBzaG9ydCBzdGF0dXMgYXNzZXNzbWVudCBmcm9tIHRoZSBhdXRob3JzIG9m IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmsgYWJvdXQgd2hlcmUgd2UgYXJlIHdpdGggdGhpcyBk b2N1bWVudCBhZnRlciB0aGUgMm5kIFdHTEM/IFdlIHJlY2VpdmVkIGF0IGxlYXN0IHR3byBzZXRz IG9mIHNvbGlkIGNvbW1lbnRzIOKAkyB3aWxsIHRoZXNlIGJlIGFkZHJlc3NlZCBzb29uIGJ5IGEg cmV2aXNlZCBJLUQ/IERvIHdlIG5lZWQgYW5vdGhlciBXR0xDPw0KDQpUaGFua3MgYW5kIFJlZ2Fy ZHMsDQoNCkRhbg0KDQo= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F40AF003EMV67UKRDdoma_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6UE1pbmdMaVU7DQoJ cGFub3NlLTE6MiAyIDUgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlBNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiA1IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAUE1pbmdMaVUiOw0KCXBh bm9zZS0xOjIgMiA1IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLmEsIGxpLmEsIGRpdi5hDQoJe21zby1zdHlsZS1u YW1lOuaJueazqOahhuaWh+acrDsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENo YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibHVlOw0KCWZvbnQtd2VpZ2h0Om5v cm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30N CnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibHVlOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tR0IgbGluaz1ibHVlIHZsaW5r PXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6Ymx1ZSc+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29O b3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi UE1pbmdMaVUiLCJzZXJpZiInPumCk+eBteiOiTwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+L0xp bmdsaSBEZW5nIFttYWlsdG86ZGVuZ2xpbmdsaUBjaGluYW1vYmlsZS5jb21dIDxicj48Yj5TZW50 OjwvYj4gMDQgTWF5IDIwMTQgMDk6MzI8YnI+PGI+VG86PC9iPiBFYXJkbGV5LFBMLFBoaWxpcCxU VUI4IFI7IGFjbW9ydG9uQGF0dC5jb207IGRyb21hc2NhQGF2YXlhLmNvbTsgbG1hcEBpZXRmLm9y Zzxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtsbWFwXSBzdGF0dXMgb2YgZHJhZnQtaWV0Zi1sbWFw LWZyYW1ld29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTic+SGkgUGhpbCBhbmQgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+ VHdvIG5pdHMgaW4gdGhlIGN1cnJlbnQgLTA0IGZyYW1ld29yayBkcmFmdCBeLV48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04nPjEsIEluIHNlY3Rpb24gNi4xLCB0aGlyZCBwYXJhZ3JhcGg6IHMvVHlw aWNhbGx5L1R5cGljYWwvPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPjIsIEluIHNlY3Rpb24gNywgcGFnZSAyOSwgbGFzdCBw YXJhZ3JhcGg6IHMvcHVzaC9wdWxsLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+TGluZ2xpPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04nPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQn PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz4gbG1hcCBbPGEg aHJlZj0ibWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmxtYXAtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOnBoaWxpcC5l YXJkbGV5QGJ0LmNvbSI+cGhpbGlwLmVhcmRsZXlAYnQuY29tPC9hPjxicj48Yj5TZW50OjwvYj4g RnJpZGF5LCBNYXkgMDIsIDIwMTQgMzozOCBQTTxicj48Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0 bzphY21vcnRvbkBhdHQuY29tIj5hY21vcnRvbkBhdHQuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRv OmRyb21hc2NhQGF2YXlhLmNvbSI+ZHJvbWFzY2FAYXZheWEuY29tPC9hPjsgPGEgaHJlZj0ibWFp bHRvOmxtYXBAaWV0Zi5vcmciPmxtYXBAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBS ZTogW2xtYXBdIHN0YXR1cyBvZiBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOJz5XZeKAmXZlIGJlZW4gd29ya2luZyB0aHJvdWdoIHRoZSBjb21tZW50cyBh bmQgbWFraW5nIHRoZSBtaW5vciBjaGFuZ2VzIG5lZWRlZC4gSnVzdCBhIGNvdXBsZSBsZWZ0IHRv IGRvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 Ymx1ZTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+ PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04nPiBsbWFwIFs8YSBocmVmPSJtYWlsdG86bG1hcC1ib3VuY2VzQGlldGYu b3JnIj5tYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwv Yj5NT1JUT04sIEFMRlJFRCBDIChBTCk8YnI+PGI+U2VudDo8L2I+IDAxIE1heSAyMDE0IDE2OjEw PGJyPjxiPlRvOjwvYj4gUm9tYXNjYW51LCBEYW4gKERhbik7IDxhIGhyZWY9Im1haWx0bzpsbWFw QGlldGYub3JnIj5sbWFwQGlldGYub3JnPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtsbWFw XSBzdGF0dXMgb2YgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yazxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+SGkgRGFuLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+R2l2ZSB1cyBhIGZl dyBkYXlzIHRvIGdhdGhlciBvdXIgdGhvdWdodHMsIGVhcmx5IG5leHQgd2VlayBwZXJoYXBzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOJz5XZSBzdGlsbCBoYXZlIGVkaXRpbmcgdG8gZG8gKGFuZCBJIGhh dmUgdGhlIHRva2VuLCBubyBwcmVzc3VyZSA7LSkgKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz5idXQg aG9wZWZ1bGx5IGl0IGFsbCBjb21lcyB0b2dldGhlciB2ZXJ5IHNvb24uPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04nPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz5yZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOJz5BbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48 cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04nPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTic+IGxtYXAgWzxhIGhyZWY9Im1haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5v cmciPm1haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9i PlJvbWFzY2FudSwgRGFuIChEYW4pPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWF5IDAxLCAy MDE0IDk6MzAgQU08YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bG1hcEBpZXRmLm9yZyI+ bG1hcEBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFtsbWFwXSBzdGF0dXMgb2YgZHJh ZnQtaWV0Zi1sbWFwLWZyYW1ld29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04nPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPkNhbiB3ZSBnZXQgYSBzaG9ydCBzdGF0dXMgYXNzZXNzbWVu dCBmcm9tIHRoZSBhdXRob3JzIG9mIGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmsgYWJvdXQgd2hl cmUgd2UgYXJlIHdpdGggdGhpcyBkb2N1bWVudCBhZnRlciB0aGUgMjxzdXA+bmQ8L3N1cD4gV0dM Qz8gV2UgcmVjZWl2ZWQgYXQgbGVhc3QgdHdvIHNldHMgb2Ygc29saWQgY29tbWVudHMg4oCTIHdp bGwgdGhlc2UgYmUgYWRkcmVzc2VkIHNvb24gYnkgYSByZXZpc2VkIEktRD8gRG8gd2UgbmVlZCBh bm90aGVyIFdHTEM/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPlRoYW5rcyBhbmQgUmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOJz5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PC9ib2R5PjwvaHRtbD4= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F40AF003EMV67UKRDdoma_-- From nobody Tue May 6 02:57: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 7C2FB1A078C for ; Tue, 6 May 2014 02:57:50 -0700 (PDT) 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 Fu5SLRra4hd9 for ; Tue, 6 May 2014 02:57:49 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 527F51A0774 for ; Tue, 6 May 2014 02:57:49 -0700 (PDT) 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; Tue, 6 May 2014 10:54:57 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Tue, 6 May 2014 10:57:00 +0100 From: To: , , Date: Tue, 6 May 2014 10:56:59 +0100 Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: Ac9mzz+z/FCV5H9DTiqY2nQz6WqpiwAkyPHgAGubCmA= Message-ID: References: <20140401162700.GA74749@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416931@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140402055542.GA75833@elstar.local> <20140402092859.GA76386@elstar.local> <20140428192856.GA25535@elstar.local> <535EB6EA.5020402@centurylink.com> <20140428202335.GF25535@elstar.local> <20140503125742.GB38536@elstar.jacobs.jacobs-university.de> <001e01cf6764$b1e43fb0$15acbf10$@com> In-Reply-To: <001e01cf6764$b1e43fb0$15acbf10$@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/rtS8gXV8cO4p_mG4H-WOWDO8EAk Cc: charles.cook2@centurylink.com, bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.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: Tue, 06 May 2014 09:57:50 -0000 PiBb6YKT54G16I6JL0xpbmdsaSBEZW5nXSBUaGVyZSBpcyBhbiBlbGVtZW50IGluIHRoZSBpbnN0 cnVjdGlvbiBzdHJ1Y3R1cmUsDQo+IHVuZGVyIHRoZSBuYW1lIG9mICJzdXBwcmVzc2lvbiBpbmZv cm1hdGlvbiAoaWYgYW55KSIgaW4gdGhlIGN1cnJlbnQNCj4gZnJhbWV3b3JrIGRyYWZ0Lg0KPiBX aGVuIEkgcmVhZCB0aHJvdWdoIHRoZSBkcmFmdCwgSSBhc3N1bWVkIHRoYXQgaXQgd2FzIGZvciB0 aGUgc2Vjb25kDQo+IGNhc2UgdGhhdCBHcmVnIG1lbnRpb25lZCBhcyBzdXBwcmVzc2lvbnMgImlt cGxpY2l0bHkgZGV0ZXJtaW5lZCBieSBhbg0KPiBNQSBiYXNlZCBvbiBjZXJ0YWluIGNvbmRpdGlv bnMgb2YgbmV0d29yayBlbnZpcm9ubWVudCIuIEhvd2V2ZXIsIEkNCj4gY291bGQgbm90IGZpbmQg YW55IGNsZWFyIGV4cGxhbmF0aW9uIGluIHRoZSB0ZXh0IHRvIGp1c3RpZnkgdGhpcw0KPiBzcGVj dWxhdGlvbi4gQXMgaXQgc2ltcGx5IHN0YXRlcyAiIChzZWUgU2VjdGlvbiA1LjIuMS4xKSAiIGFu ZCB3aXRob3V0DQo+IGFueSBmdXJ0aGVyIGluZm9ybWF0aW9uIGFjdHVhbGx5IGdpdmVuIGluIFNl Y3Rpb24gNS4yLjEuMS4gSSB3b3VsZCBsaWtlDQo+IHRvIHNlZSBtb3JlIHRleHQgdG8gY2xhcmlm eSB0aGUgcHVycG9zZSBhbmQgY29udGVudCBvZiB0aGlzIGVsZW1lbnQuDQo+ID4NCg0KVGhlcmUn cyBhIHR5cG8gaW4gdGhlIHJlZmVyZW5jZSAtIGl0IHNob3VsZCBiZSAic2VlIFNlY3Rpb24gNS4z LjEuMSINClN1cHByZXNzaW9uIGlzIHBhcnQgb2YgdGhlIEluc3RydWN0aW9uLCBpZSB3aGF0IHRo ZSBDb250cm9sbGVyIHRlbGxzIHRoZSBNQSB0byBkby4NCkl0IGlzIGFsc28gcG9zc2libGUgdGhh dCB0aGUgTUEgY2FuIGRlY2lkZSBub3QgdG8gcnVuIFRhc2socyksICJpbXBsaWNpdGx5IGRldGVy bWluZWQgYnkgYW4NCk1BIGJhc2VkIG9uIGNlcnRhaW4gY29uZGl0aW9ucyBvZiBuZXR3b3JrIGVu dmlyb25tZW50Ii4gVGhpcyBpcyBub3Qgc3VwcHJlc3Npb24uIEl0IGlzIGRpc2N1c3NlZCBpbiBT NS40LjEsICJTdGFydGluZyBhbmQgc3RvcHBpbmcgTWVhc3VyZW1lbnQgVGFza3MiIChTNSBpcyBh Ym91dCBob3cgdGhlIE1BIG9wZXJhdGVzIE1lYXN1cmVtZW50IFRhc2tzKS4NCg0KVGhhbmtzDQpw aGlsDQo= From nobody Tue May 6 03:21: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 5F96C1A069E for ; Tue, 6 May 2014 03:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 MJKSBsMY_cAW for ; Tue, 6 May 2014 03:21:36 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id D5A781A029F for ; Tue, 6 May 2014 03:21:35 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15368b78b298-e0298; Tue, 06 May 2014 18:20:59 +0800 (CST) X-RM-TRANSID: 2ee15368b78b298-e0298 Received: from cmccPC (unknown[10.2.43.246]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15368b78783c-43ae8; Tue, 06 May 2014 18:20:59 +0800 (CST) X-RM-TRANSID: 2ee15368b78783c-43ae8 From: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: , , References: <20140401162700.GA74749@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416931@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140402055542.GA75833@elstar.local> <20140402092859.GA76386@elstar.local> <20140428192856.GA25535@elstar.local> <535EB6EA.5020402@centurylink.com> <20140428202335.GF25535@elstar.local> <20140503125742.GB38536@elstar.jacobs.jacobs-university.de> <001e01cf6764$b1e43fb0$15acbf10$@com> In-Reply-To: Date: Tue, 6 May 2014 18:21:19 +0800 Message-ID: <001301cf6914$ed310970$c7931c50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9mzz+z/FCV5H9DTiqY2nQz6WqpiwAkyPHgAGubCmAAAN/joA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/PRy8r79uPYPvNzAYFggp49TTYp0 Cc: charles.cook2@centurylink.com, bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.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: Tue, 06 May 2014 10:21:38 -0000 Hi Phil, Thanks for the clarification.=20 However, I really doubt that we are looking at the same version of the = document. Plz see more inline. Lingli > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: Tuesday, May 06, 2014 5:57 PM > To: denglingli@chinamobile.com; j.schoenwaelder@jacobs-university.de; > gregimirsky@gmail.com > Cc: charles.cook2@centurylink.com; bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for > draft-ietf-lmap-framework-04.txt >=20 > > [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] There is an element in the = instruction structure, > > under the name of "suppression information (if any)" in the current > > framework draft. > > When I read through the draft, I assumed that it was for the second > > case that Greg mentioned as suppressions "implicitly determined by = an > > MA based on certain conditions of network environment". However, I > > could not find any clear explanation in the text to justify this > > speculation. As it simply states " (see Section 5.2.1.1) " and = without > > any further information actually given in Section 5.2.1.1. I would = like > > to see more text to clarify the purpose and content of this element. > > > >=20 > There's a typo in the reference - it should be "see Section 5.3.1.1" [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] I am afraid I cannot find = Section 5.3.1.1 in the current -04 version. > Suppression is part of the Instruction, ie what the Controller tells = the MA to do. > It is also possible that the MA can decide not to run Task(s), = "implicitly > determined by an > MA based on certain conditions of network environment". This is not > suppression. It is discussed in S5.4.1, "Starting and stopping = Measurement > Tasks" (S5 is about how the MA operates Measurement Tasks). [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] I understand your point. = However, in the version that I am looking at, "Starting and stopping = Measurement Tasks" is labeled as Section 5.3.1 rather than 5.4.1. >=20 > Thanks > phil > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue May 6 03:25: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 A61871A065C for ; Tue, 6 May 2014 03:25:15 -0700 (PDT) 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 pD0I2E8nlIeP for ; Tue, 6 May 2014 03:25:13 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 101921A02A1 for ; Tue, 6 May 2014 03:25:12 -0700 (PDT) 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; Tue, 6 May 2014 11:22:20 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 6 May 2014 11:25:07 +0100 From: To: , , Date: Tue, 6 May 2014 11:25:05 +0100 Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: Ac9mzz+z/FCV5H9DTiqY2nQz6WqpiwAkyPHgAGubCmAAAN/joAAAP+5w Message-ID: References: <20140401162700.GA74749@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416931@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140402055542.GA75833@elstar.local> <20140402092859.GA76386@elstar.local> <20140428192856.GA25535@elstar.local> <535EB6EA.5020402@centurylink.com> <20140428202335.GF25535@elstar.local> <20140503125742.GB38536@elstar.jacobs.jacobs-university.de> <001e01cf6764$b1e43fb0$15acbf10$@com> <001301cf6914$ed310970$c7931c50$@com> In-Reply-To: <001301cf6914$ed310970$c7931c50$@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/H-tiXqBOELrUmqHytwQSHSkM-Us Cc: charles.cook2@centurylink.com, bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.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: Tue, 06 May 2014 10:25:15 -0000 U29ycnksIHlvdSdyZSByaWdodCBhYm91dCB0aGUgc2VjdGlvbiBudW1iZXJpbmcgKHdhcyBsb29r aW5nIGF0IG15IHdvcmtpbmcgdmVyc2lvbiBvZiAtMDUpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTog6YKT54G16I6JL0xpbmdsaSBEZW5nIFttYWlsdG86ZGVuZ2xpbmds aUBjaGluYW1vYmlsZS5jb21dDQo+IFNlbnQ6IDA2IE1heSAyMDE0IDExOjIxDQo+IFRvOiBFYXJk bGV5LFBMLFBoaWxpcCxUVUI4IFI7IGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k ZTsNCj4gZ3JlZ2ltaXJza3lAZ21haWwuY29tDQo+IENjOiBjaGFybGVzLmNvb2syQGNlbnR1cnls aW5rLmNvbTsgYnM3NjUyQGF0dC5jb207IGxtYXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFts bWFwXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWxtYXAtDQo+ IGZyYW1ld29yay0wNC50eHQNCj4gDQo+IEhpIFBoaWwsDQo+IA0KPiBUaGFua3MgZm9yIHRoZSBj bGFyaWZpY2F0aW9uLg0KPiBIb3dldmVyLCBJIHJlYWxseSBkb3VidCB0aGF0IHdlIGFyZSBsb29r aW5nIGF0IHRoZSBzYW1lIHZlcnNpb24gb2YgdGhlDQo+IGRvY3VtZW50Lg0KPiBQbHogc2VlIG1v cmUgaW5saW5lLg0KPiANCj4gTGluZ2xpDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gRnJvbTogbG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mDQo+ID4gcGhpbGlwLmVhcmRsZXlAYnQuY29tDQo+ID4gU2VudDogVHVlc2RheSwgTWF5 IDA2LCAyMDE0IDU6NTcgUE0NCj4gPiBUbzogZGVuZ2xpbmdsaUBjaGluYW1vYmlsZS5jb207IGou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTsNCj4gPiBncmVnaW1pcnNreUBnbWFp bC5jb20NCj4gPiBDYzogY2hhcmxlcy5jb29rMkBjZW50dXJ5bGluay5jb207IGJzNzY1MkBhdHQu Y29tOyBsbWFwQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtsbWFwXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDQudHh0 DQo+ID4NCj4gPiA+IFvpgpPngbXojokvTGluZ2xpIERlbmddIFRoZXJlIGlzIGFuIGVsZW1lbnQg aW4gdGhlIGluc3RydWN0aW9uDQo+IHN0cnVjdHVyZSwNCj4gPiA+IHVuZGVyIHRoZSBuYW1lIG9m ICJzdXBwcmVzc2lvbiBpbmZvcm1hdGlvbiAoaWYgYW55KSIgaW4gdGhlIGN1cnJlbnQNCj4gPiA+ IGZyYW1ld29yayBkcmFmdC4NCj4gPiA+IFdoZW4gSSByZWFkIHRocm91Z2ggdGhlIGRyYWZ0LCBJ IGFzc3VtZWQgdGhhdCBpdCB3YXMgZm9yIHRoZSBzZWNvbmQNCj4gPiA+IGNhc2UgdGhhdCBHcmVn IG1lbnRpb25lZCBhcyBzdXBwcmVzc2lvbnMgImltcGxpY2l0bHkgZGV0ZXJtaW5lZCBieQ0KPiA+ ID4gYW4gTUEgYmFzZWQgb24gY2VydGFpbiBjb25kaXRpb25zIG9mIG5ldHdvcmsgZW52aXJvbm1l bnQiLiBIb3dldmVyLA0KPiA+ID4gSSBjb3VsZCBub3QgZmluZCBhbnkgY2xlYXIgZXhwbGFuYXRp b24gaW4gdGhlIHRleHQgdG8ganVzdGlmeSB0aGlzDQo+ID4gPiBzcGVjdWxhdGlvbi4gQXMgaXQg c2ltcGx5IHN0YXRlcyAiIChzZWUgU2VjdGlvbiA1LjIuMS4xKSAiIGFuZA0KPiA+ID4gd2l0aG91 dCBhbnkgZnVydGhlciBpbmZvcm1hdGlvbiBhY3R1YWxseSBnaXZlbiBpbiBTZWN0aW9uIDUuMi4x LjEuDQo+IEkNCj4gPiA+IHdvdWxkIGxpa2UgdG8gc2VlIG1vcmUgdGV4dCB0byBjbGFyaWZ5IHRo ZSBwdXJwb3NlIGFuZCBjb250ZW50IG9mDQo+IHRoaXMgZWxlbWVudC4NCj4gPiA+ID4NCj4gPg0K PiA+IFRoZXJlJ3MgYSB0eXBvIGluIHRoZSByZWZlcmVuY2UgLSBpdCBzaG91bGQgYmUgInNlZSBT ZWN0aW9uIDUuMy4xLjEiDQo+IFvpgpPngbXojokvTGluZ2xpIERlbmddIEkgYW0gYWZyYWlkIEkg Y2Fubm90IGZpbmQgU2VjdGlvbiA1LjMuMS4xIGluIHRoZQ0KPiBjdXJyZW50IC0wNCB2ZXJzaW9u Lg0KPiANCj4gPiBTdXBwcmVzc2lvbiBpcyBwYXJ0IG9mIHRoZSBJbnN0cnVjdGlvbiwgaWUgd2hh dCB0aGUgQ29udHJvbGxlciB0ZWxscw0KPiB0aGUgTUEgdG8gZG8uDQo+ID4gSXQgaXMgYWxzbyBw b3NzaWJsZSB0aGF0IHRoZSBNQSBjYW4gZGVjaWRlIG5vdCB0byBydW4gVGFzayhzKSwNCj4gPiAi aW1wbGljaXRseSBkZXRlcm1pbmVkIGJ5IGFuIE1BIGJhc2VkIG9uIGNlcnRhaW4gY29uZGl0aW9u cyBvZg0KPiBuZXR3b3JrDQo+ID4gZW52aXJvbm1lbnQiLiBUaGlzIGlzIG5vdCBzdXBwcmVzc2lv bi4gSXQgaXMgZGlzY3Vzc2VkIGluIFM1LjQuMSwNCj4gPiAiU3RhcnRpbmcgYW5kIHN0b3BwaW5n IE1lYXN1cmVtZW50IFRhc2tzIiAoUzUgaXMgYWJvdXQgaG93IHRoZSBNQQ0KPiA+IG9wZXJhdGVz IE1lYXN1cmVtZW50IFRhc2tzKS4NCj4gW+mCk+eBteiOiS9MaW5nbGkgRGVuZ10gSSB1bmRlcnN0 YW5kIHlvdXIgcG9pbnQuIEhvd2V2ZXIsIGluIHRoZSB2ZXJzaW9uDQo+IHRoYXQgSSBhbSBsb29r aW5nIGF0LCAiU3RhcnRpbmcgYW5kIHN0b3BwaW5nIE1lYXN1cmVtZW50IFRhc2tzIiBpcw0KPiBs YWJlbGVkIGFzIFNlY3Rpb24gNS4zLjEgcmF0aGVyIHRoYW4gNS40LjEuDQo+ID4NCj4gPiBUaGFu a3MNCj4gPiBwaGlsDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBsbWFwIG1haWxpbmcgbGlzdA0KPiA+IGxtYXBAaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCj4gDQo+IA0KDQo= From nobody Tue May 6 05:50:19 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 E86F51A02F5 for ; Tue, 6 May 2014 05:50:17 -0700 (PDT) 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 6mC31xCFBFKI for ; Tue, 6 May 2014 05:50:14 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id DA68D1A02F8 for ; Tue, 6 May 2014 05:50:13 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 6 May 2014 13:50:15 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Tue, 6 May 2014 13:50:07 +0100 From: To: , Date: Tue, 6 May 2014 13:50:06 +0100 Thread-Topic: [lmap] framework comments Thread-Index: Ac9cl9SeoAXxoO+sT62j3uhhwzLuTwBfuc6wASn/ldAANLjhAAAU1CwAAIWbOwAAChjogAAHAGxQALO+hmA= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130429D2C@GAALPA1MSGUSR9L.ITServices.sbc.com> <535FCB60.9040304@centurylink.com> <53638FC1.6020002@centurylink.com> <89294A6F3C6C91459E52E4128C4B02B70438BD@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70438BD@SPQCMBX02.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/K3-kayS6ybq9SX6CTt8BiKZkYUc Cc: bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] framework comments 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, 06 May 2014 12:50:18 -0000 The approach "stop testing if the MA could not contact the controller in th= ree attempts" works if the MA 'pulls' its Instruction from the Controller, = but not if the Controller pushes to MA. > -----Original Message----- > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: 02 May 2014 14:18 > To: charles.cook2@centurylink.com; Eardley,PL,Philip,TUB8 R > Cc: bs7652@att.com; lmap@ietf.org > Subject: RE: [lmap] framework comments > > A while back I had proposed that if the MA could not contact the > controller in three attempts that it should stop testing until it was > able to achieve contact with the controller. The timer for this could > be defined elsewhere and can be a user configurable parameter, but I do > agree with Charles that a default timer is a good idea so that there is > an initial bound. > > Sharam > > > > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook > Sent: Friday, May 02, 2014 8:30 AM > To: philip.eardley@bt.com > Cc: bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] framework comments > > I'm ok if the default time is defined else where. But I do believe it > is appropriate to mention that there is a default time to prevent an MA > from continuing indefinitely after losing contact with a Controller. > > Charles > > On 5/2/2014 1:40 AM, philip.eardley@bt.com wrote: > > Since this is an informational framework, I think this document is > probably the wrong place to define such a default time. > > > > phil > > > >> -----Original Message----- > >> From: Charles Cook [mailto:charles.cook2@centurylink.com] > >> Sent: 29 April 2014 16:55 > >> To: Eardley,PL,Philip,TUB8 R > >> Cc: bs7652@att.com; lmap@ietf.org > >> Subject: Re: [lmap] framework comments > >> > >> Phil, > >> > >> Regarding prevention of the MA from continuously executing > >> Measurement Tasks when contact with the Controller has been lost, I > >> believe there needs to be a default time. See inline below. > >> > >> Charles > >> > >> On 4/29/2014 4:31 AM, philip.eardley@bt.com wrote: > >>> Thanks! > >>> > >>>>> [phil] I agree with you, the MA does not have to be in the > >>>>> customer's premises. > >>>>> S6 - if anyone can contribute text of MAs located elsewhere, that > >>>>> would be very helpful. > >>>> Yes, I'll propose some additional text. I'll do that in a > >>>> separate email later this week. > >>> Al wrote this text, what do you reckon? > >>> > >>> 6.2.5. Measurement Agent embedded in ISP Networks > >>> > >>> A MA may be embedded on a device that is part of an ISP's > network, > >>> such as a router or switch. Usually the network devices with an > >>> embedded MA will be stategically located, such as a Carrier > Grade > >> NAT > >>> or ISP Gateway. [I-D.ietf-ippm-lmap-path] gives many examples > >> where > >>> a MA might be located within a network to provide an > intermediate > >>> measurement point on the end-to-end path. Other examples > include > >> a > >>> network device whose primary role is to host MA functions and > the > >>> necessary measurement protocol. > >>> > >>>>>> To avoid the MA generating > >>>>>> traffic forever after a Controller has permanently failed , > it > >>>> is > >>>>>> suggested that the Measurement Schedule includes a time > >> limit... > >>>>>> Comment: I thought we were also going to allow for the MA to > just > >>>>>> stop doing measurements if it didn't hear from the Controller in > >>>>>> a > >>>> while. > >>>>> [phil] seems to me that these are equivalent, though I don't mind > >>>> adding it. > >>>> Given the extensive discussion that was had about this, I'm > >>>> curious as to what others think. > >>> [phil] ok. I have changed to say: > >>> To avoid the MA generating > >>> traffic forever after a Controller has permanently failed, the > MA > >> can > >>> be configured with a time limit; if the MA doesn't hear from the > >>> Controller for this length of time, thenl it stops operating > >>> Measurement Tasks. > >> I don't think this solves the problem unless there is a default > >> time limit that is used if a time interval is not specifically > >> configured. > >> > >> Perhaps something like, > >> > >> "To avoid the MA generating traffic forever after a Controller has > >> permanently failed, the MA will stop operating Measurement Tasks if > >> the MA does not hear from the Controller for a default length > >> of time. Optionally, the MA can be configured with a specific time > >> limit; if the MA doesn't hear from the Controller for this length of > >> time, then it stops operating Measurement Tasks." > >> > >> > >>>>> ... > >>>>> > >>>>>> 5.5. Operation of LMAP over the underlying transport protocol > >> And > >>>>>> subsequent uses of "underlying transport protocol" in this > >> section. > >>>>>> Comment: The description of "transport protocol" in this section > >> is > >>>>>> unlike any use of "transport protocol" I've ever seen. > Especially > >>>>>> the part about there being Push, Pull, and multicast transport > >>>> protocols. > >>>>>> Multicast only happens at IP or Ethernet, to the best of my > >>>> knowledge. > >>>>>> I've never heard of a higher layer protocol capable of > multicast. > >> I > >>>>>> usually associate "transport protocol" with protocols that > >>>>>> operate at the transport layer, like TCP and UDP, or with > >>>>>> protocols like > >>>> RTP > >>>>>> (that has Transport Protocol in its name). But RTP, TCP, UDP and > >>>>>> such have no Push, Pull, or multicast characteristics. I'm not > >> sure > >>>>>> what to recommend about this section -- parts seem usable, but > >>>>>> the way it's described doesn't relate to my understanding of the > >> nature > >>>>>> of various protocols. > >>>>> Very open to suggested phrasings. > >>>>> Key word is "underlying". > >>>>> Simply mean that (say) the LMAP Control Protocol is Controller to > >>>>> MA, but for instance if it operates over http, then at this > >> "underlying" > >>>>> layer the MA does a request (pull) to the Controller and its > reply > >>>>> includes the LMAP Control Protocol info. Or the "underlying" > layer > >>>> may be push or even multicast. > >>>>> "transport" didn't mean layer 4 but something transporting the > >>>>> LMAP > >>>> info. > >>>>> Would "underlying packet transfer mechanism" or "model" be > clearer? > >>>> So what I read you saying is that there are some > >>>> characteristics that the Control or Report Protocol can "inherit" > >>>> from underlying protocols (effectively defined as any protocol at > >> any > >>>> layer that is below the Control or Report Protocol). This much I > >>>> agree with, and I think it would be good to rephrase along this > >> line. > >>>> However, http does not necessarily imply "Pull". Just because 2 > >>>> endpoints are in a client/server relationship for a Control or > >> Report > >>>> Protocol, doesn't mean that they maintain that same client/server > >>>> relationship as it relates to http. That is, it's possible for the > >>>> Controller to be the http client that initiates a http session to > >> the > >>>> MA (which is the http server). It can be the higher layer Control > >>>> or Report protocol that dictates which endpoint can or must be the > >>>> http client/server. For example, TR-069 does allow the TR-069 > >>>> config server to initiate http with the TR-069 client for the > >>>> purpose of sending a "connect to your config server ASAP" message. > >>>> But only the > >>>> TR-069 client can initiate a http session for purpose of receiving > >>>> configuration info (in which case the TR-069 client is the http > >>>> client and the TR-069 config server is the http server). And so I > >>>> consider TR- > >>>> 069 to be a "Pull" protocol. But it doesn't inherit this from > http. > >>>> Because either side can initiate http to the other at different > >> times. > >>>> It is TR-069 itself that defines the RPCs (remote procedure calls) > >>>> and when different RPCs can be used. > >>>> So I still have a problem with the idea that Push and Pull are > >>>> necessarily inherited from underlying protocols, or that http > >> implies > >>>> "Pull". > >>>> I agree that multicast is inherited. > >>>> > >>> In terms of how to change the text, the first 2 paras seem ok, but > >> replace the last sentence with: > >>> How this is done depends on the design of the Control and Report > >> Protocols, the underlying packet transfer mechanism and how it is > >> configured (for example, which endpoint is the HTTP client and which > >> the server). > >>> And then change to: > >>> For the Control Protocol, the underlying packet transfer mechanism > >> could be used in a: > >>> o a 'push' mode (that is, from the Controller to the MA) > >>> > >>> and similar change for the other bullets. > >>> > >>> Does this work? > >>> > >> > ....................................................................... > >>>>>> ..... > >>>>>> 5.6.1. End-user-controlled measurement system ... > >>>>>> Note that a user can't directly initiate a Measurement > >>>>>> Task on an ISP- (or regulator-) controlled MA. > >>>>>> Comment: Why not? Why isn't it allowed to include this ability > in > >> a > >>>>>> MA design (such as one that is just for the ISP use case and has > >>>>>> nothing to do with regulatory use case)? > >>>>> [phil] then there would be two ways of controlling the MA, which > >>>>> is something we want to avoid. > >>>> Multiple methods of remote configuration are indeed > >>>> complicated, which was why I very much agreed with the "one > >> Controller" restriction. > >>>> But we have a lot of experience in coordinating between > >>>> person-directed local configuration and remote automated > >>>> configuration on various devices. Which is why I don't see it > >> necessary to forbid this. > >>> Would be interested to read more about this, do you have a ref > >> please. > >>>>>> 6.2.3. Measurement Agent embedded behind site NAT /Firewall > >>>>>> > >>>>>> The Measurement Agent could also be embedded behind a NAT, a > >>>>>> firewall, or both. In this case the Controller may not be > >>>>>> able > >>>> to > >>>>>> unilaterally contact the Measurement Agent unless either > >>>>>> static > >>>> port > >>>>>> forwarding configuration or firewall pin holing is > configured. > >>>> For > >>>>>> the former, protocols such as PCP [RFC6887], TR-069 [TR- > 069]or > >>>> UPnP > >>>>>> [UPnP]could be used. For the latter, the Measurement Agent > >>>> could > >>>>>> send keepalives towards the Controller to prop open the > >> firewall > >>>>>> (and > >>>>>> perhaps use these also as a network reachability test). > >>>>>> Comment: Regarding the last sentence, I don't understand what > >>>>>> keepalives has to do with UPnP. Why not just mention STUN as an > >>>>>> option for keeping NAT table entries from timing out? > >>>>> [phil] "for the former" refers to "static port forwarding > >>>>> configuration" and "for the latter" to "firewall pin holing" > >>>> Hmm. I think we have terminology-understanding differences > at > >>>> multiple levels here. In my use of the words, a port forwarding > >>>> rule or mapping is a pinhole. They can be statically (manually, > >>>> TR-069, > >>>> SNMP) or dynamically (UPnP IGD, PCP) configured, or dynamically > >>>> generated as a result of outbound TCP and UDP packets. Because > >>>> pinholes configured through PCP and UPnP IGD do expire after a > >> while, > >>>> and are created on an "as needed" basis, they tend to be > considered > >> dynamic and not static. > >>>> Pinholes dynamically generated by the NAT or firewall processes as > >>>> a result of outbound TCP or UDP packets don't tend to be > considered > >>>> "configured". I would suggest rewording this to: > >>>> The Measurement Agent could also be embedded behind a NAT, a > >>>> stateful-packet inspection firewall, or both. In this case the > >>>> Controller may not be able to unilaterally contact the > Measurement > >>>> Agent unless configured or dynamically-generated pinholes exist. > >>>> Protocols such as PCP [RFC6887], CWMP [TR-069] or UPnP IGD [UPnP > >>>> IGD] can be used to configure pinholes. For pinholes that are > >>>> dynamically- generated as a result of outbound TCP or UDP packets, > >>>> the Measurement Agent could > >>>> send keepalives, such as those of the STUN protocol [STUN], > >>>> towards the Controller to keep open the pinholes (and perhaps use > >>>> these also as a network reachability test). > >>>> > >>>> I recommend referencing UPnP IGD, and not just UPnP. And calling > >>>> the protocol described in TR-069 "CWMP". > >>> Wfm. Thanks for the text. > >>> > >>>>>> -------------------------------- > >>>>>> 8.3. Key Distinction Between Active and Passive Measurement > >>>>>> Tasks > >>>>>> > >>>>>> Passive and Active Measurement Tasks raise different privacy > >>>> issues. > >>>>>> Passive Measurement Tasks are conducted on a user's traffic > >> ,... > >>>>>> Comment: This is not necessarily true if it is possible for the > >>>>>> MA not to be located in a place where it is associated with a > >>>>>> single > >>>> end user > >>>>>> or subscriber. I recommend " Passive Measurement Tasks can be > >>>>>> conducted on a user's traffic ,..." > >>>>> [phil] how about " Passive Measurement Tasks are conducted on > user > >>>>> traffic"? > >>>>> (I think "can be conducted" misleadingly hints "but may not be") > >>>> As has been discussed on this list, Passive Measurements can > >>>> also be conducted on Active Measurement traffic. I don't consider > >> MA- > >>>> or MP- generated Active Measurement traffic to be user traffic. > For > >>>> MAs located outside the customer premises, it is also possible for > >> an > >>>> ISP to measure management traffic (between its network elements > and > >>>> systems). > >>> Good point. > >>> > >>> Thanks > >>> Phil. > >>> > >>> _______________________________________________ > >>> 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 > > -- > > 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 From nobody Tue May 6 12:53: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 4508F1A0466 for ; Tue, 6 May 2014 12:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-0.651] 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 ilo8SKcaHkI8 for ; Tue, 6 May 2014 12:52:55 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id D81031A040C for ; Tue, 6 May 2014 12:52:52 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8A87FA06D1; Tue, 6 May 2014 15:52:48 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 41DD2A06C0; Tue, 6 May 2014 15:52:48 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.242]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Tue, 6 May 2014 15:52:48 -0400 From: Sharam Hakimi To: "philip.eardley@bt.com" , "charles.cook2@centurylink.com" Thread-Topic: [lmap] framework comments Thread-Index: Ac9cl9SeoAXxoO+sT62j3uhhwzLuTwBfuc6wASn/ldAANLjhAAAU1CwAAIWbOwAAChjogAAHAGxQALO+hmAAFUDAcA== Date: Tue, 6 May 2014 19:52:47 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B704449D@SPQCMBX02.exfo.com> References: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130429D2C@GAALPA1MSGUSR9L.ITServices.sbc.com> <535FCB60.9040304@centurylink.com> <53638FC1.6020002@centurylink.com> <89294A6F3C6C91459E52E4128C4B02B70438BD@SPQCMBX02.exfo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20678.001 X-TM-AS-Result: No--35.983-5.0-31-10 X-imss-scan-details: No--35.983-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20678.001 X-TMASE-Result: 10--35.982800-5.000000 X-TMASE-MatchedRID: 7Xuofmx3S/Atjw5zGtj91NlHf9Z3qZKTsAstBIeBlyRuOzObMX3aCGQL vGnFNX2zVCHk5OCyKJS12myWr05SDhjNRuD6vS9UgOqr/r0d+Cx5y+Nu7/EOOkuCjz4ggdtw8mi BZ1i+wWv6/lbPW/eAnVLOW0HbYP2w+VdtpE9/9fb6YdEve7M6Im79evoIpeI36i5zlFx/UHQfMl akxW5H5k2HaLS+mGndFS3S9Z0iFQqMLrybB70fruYAh37ZsBDCouFA0oJLajEujyxRHwe+HFRYa 84A4jISNNxw+hQKBG7UUmvdr/+iZk8atZ6WWf7zwT5e5LDjyQIK3n1SHen81TCmUYns3FLT8rK/ 0wUyv6DZbv5JO/yz/6PjUcoN9IlBzMuituH4rKtjuN6nCSmvr/sxkEGymdAKs/uo6bL1AFSgn7Q T2jBG7X5UUmN1XSGJaulLGGssQIMaPxeMMHjQbuGonqgs5zxBkT7cMJfe6JtoNGY/OdYkWYpGtC muhU7rxlU17SYc7SwyoA6iXyxBR2e90Z2gWyxa2MMmxTWvrZvFnoVLhjstj9zOQo7mTgA+HACUc DvcWyBdsxfiS2NfxLFLSYt4kEAsGaKXE/SfD/Wcnm0v4tsY43idToq2MMwDLcVjbs+keaxLbTUf +O4SvPtZpCb/JALHOHY3aadbY812HzNb3Bcc3iVypP66BP0Q1kqyrcMalqVb6PBUqmq+UqQy/Pu w9Doy0Q2PKuAVSm4xeamNUxAG99ra5QHNzf1z7spMO3HwKCAZKp0SZ4P+dXR4qaW1T8XgthULH5 OIOlyx79vDD0CA9/XxGThQLh69n/m18ngarmueAiCmPx4NwMidYBYDjITpp2c3EY8h4cmrusVRy 4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/6Vg_07m8eVADmID2Zyn4UPSVquk Cc: "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] framework comments 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, 06 May 2014 19:52:59 -0000 I do not believe that Pull/Push would have an effect as the existence of th= e controller is checked by the MA after the MA has its instructions. It cou= ld be a simple ping of the controller while the instructions are in effect.= We could make it more complicated if desired later. Sharam=20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Tuesday, May 06, 2014 8:50 AM To: Sharam Hakimi; charles.cook2@centurylink.com Cc: bs7652@att.com; lmap@ietf.org Subject: RE: [lmap] framework comments The approach "stop testing if the MA could not contact the controller in th= ree attempts" works if the MA 'pulls' its Instruction from the Controller, = but not if the Controller pushes to MA. > -----Original Message----- > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: 02 May 2014 14:18 > To: charles.cook2@centurylink.com; Eardley,PL,Philip,TUB8 R > Cc: bs7652@att.com; lmap@ietf.org > Subject: RE: [lmap] framework comments > > A while back I had proposed that if the MA could not contact the > controller in three attempts that it should stop testing until it was > able to achieve contact with the controller. The timer for this could > be defined elsewhere and can be a user configurable parameter, but I do > agree with Charles that a default timer is a good idea so that there is > an initial bound. > > Sharam > > > > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook > Sent: Friday, May 02, 2014 8:30 AM > To: philip.eardley@bt.com > Cc: bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] framework comments > > I'm ok if the default time is defined else where. But I do believe it > is appropriate to mention that there is a default time to prevent an MA > from continuing indefinitely after losing contact with a Controller. > > Charles > > On 5/2/2014 1:40 AM, philip.eardley@bt.com wrote: > > Since this is an informational framework, I think this document is > probably the wrong place to define such a default time. > > > > phil > > > >> -----Original Message----- > >> From: Charles Cook [mailto:charles.cook2@centurylink.com] > >> Sent: 29 April 2014 16:55 > >> To: Eardley,PL,Philip,TUB8 R > >> Cc: bs7652@att.com; lmap@ietf.org > >> Subject: Re: [lmap] framework comments > >> > >> Phil, > >> > >> Regarding prevention of the MA from continuously executing > >> Measurement Tasks when contact with the Controller has been lost, I > >> believe there needs to be a default time. See inline below. > >> > >> Charles > >> > >> On 4/29/2014 4:31 AM, philip.eardley@bt.com wrote: > >>> Thanks! > >>> > >>>>> [phil] I agree with you, the MA does not have to be in the > >>>>> customer's premises. > >>>>> S6 - if anyone can contribute text of MAs located elsewhere, that > >>>>> would be very helpful. > >>>> Yes, I'll propose some additional text. I'll do that in a > >>>> separate email later this week. > >>> Al wrote this text, what do you reckon? > >>> > >>> 6.2.5. Measurement Agent embedded in ISP Networks > >>> > >>> A MA may be embedded on a device that is part of an ISP's > network, > >>> such as a router or switch. Usually the network devices with an > >>> embedded MA will be stategically located, such as a Carrier > Grade > >> NAT > >>> or ISP Gateway. [I-D.ietf-ippm-lmap-path] gives many examples > >> where > >>> a MA might be located within a network to provide an > intermediate > >>> measurement point on the end-to-end path. Other examples > include > >> a > >>> network device whose primary role is to host MA functions and > the > >>> necessary measurement protocol. > >>> > >>>>>> To avoid the MA generating > >>>>>> traffic forever after a Controller has permanently failed , > it > >>>> is > >>>>>> suggested that the Measurement Schedule includes a time > >> limit... > >>>>>> Comment: I thought we were also going to allow for the MA to > just > >>>>>> stop doing measurements if it didn't hear from the Controller in > >>>>>> a > >>>> while. > >>>>> [phil] seems to me that these are equivalent, though I don't mind > >>>> adding it. > >>>> Given the extensive discussion that was had about this, I'm > >>>> curious as to what others think. > >>> [phil] ok. I have changed to say: > >>> To avoid the MA generating > >>> traffic forever after a Controller has permanently failed, the > MA > >> can > >>> be configured with a time limit; if the MA doesn't hear from the > >>> Controller for this length of time, thenl it stops operating > >>> Measurement Tasks. > >> I don't think this solves the problem unless there is a default > >> time limit that is used if a time interval is not specifically > >> configured. > >> > >> Perhaps something like, > >> > >> "To avoid the MA generating traffic forever after a Controller has > >> permanently failed, the MA will stop operating Measurement Tasks if > >> the MA does not hear from the Controller for a default length > >> of time. Optionally, the MA can be configured with a specific time > >> limit; if the MA doesn't hear from the Controller for this length of > >> time, then it stops operating Measurement Tasks." > >> > >> > >>>>> ... > >>>>> > >>>>>> 5.5. Operation of LMAP over the underlying transport protocol > >> And > >>>>>> subsequent uses of "underlying transport protocol" in this > >> section. > >>>>>> Comment: The description of "transport protocol" in this section > >> is > >>>>>> unlike any use of "transport protocol" I've ever seen. > Especially > >>>>>> the part about there being Push, Pull, and multicast transport > >>>> protocols. > >>>>>> Multicast only happens at IP or Ethernet, to the best of my > >>>> knowledge. > >>>>>> I've never heard of a higher layer protocol capable of > multicast. > >> I > >>>>>> usually associate "transport protocol" with protocols that > >>>>>> operate at the transport layer, like TCP and UDP, or with > >>>>>> protocols like > >>>> RTP > >>>>>> (that has Transport Protocol in its name). But RTP, TCP, UDP and > >>>>>> such have no Push, Pull, or multicast characteristics. I'm not > >> sure > >>>>>> what to recommend about this section -- parts seem usable, but > >>>>>> the way it's described doesn't relate to my understanding of the > >> nature > >>>>>> of various protocols. > >>>>> Very open to suggested phrasings. > >>>>> Key word is "underlying". > >>>>> Simply mean that (say) the LMAP Control Protocol is Controller to > >>>>> MA, but for instance if it operates over http, then at this > >> "underlying" > >>>>> layer the MA does a request (pull) to the Controller and its > reply > >>>>> includes the LMAP Control Protocol info. Or the "underlying" > layer > >>>> may be push or even multicast. > >>>>> "transport" didn't mean layer 4 but something transporting the > >>>>> LMAP > >>>> info. > >>>>> Would "underlying packet transfer mechanism" or "model" be > clearer? > >>>> So what I read you saying is that there are some > >>>> characteristics that the Control or Report Protocol can "inherit" > >>>> from underlying protocols (effectively defined as any protocol at > >> any > >>>> layer that is below the Control or Report Protocol). This much I > >>>> agree with, and I think it would be good to rephrase along this > >> line. > >>>> However, http does not necessarily imply "Pull". Just because 2 > >>>> endpoints are in a client/server relationship for a Control or > >> Report > >>>> Protocol, doesn't mean that they maintain that same client/server > >>>> relationship as it relates to http. That is, it's possible for the > >>>> Controller to be the http client that initiates a http session to > >> the > >>>> MA (which is the http server). It can be the higher layer Control > >>>> or Report protocol that dictates which endpoint can or must be the > >>>> http client/server. For example, TR-069 does allow the TR-069 > >>>> config server to initiate http with the TR-069 client for the > >>>> purpose of sending a "connect to your config server ASAP" message. > >>>> But only the > >>>> TR-069 client can initiate a http session for purpose of receiving > >>>> configuration info (in which case the TR-069 client is the http > >>>> client and the TR-069 config server is the http server). And so I > >>>> consider TR- > >>>> 069 to be a "Pull" protocol. But it doesn't inherit this from > http. > >>>> Because either side can initiate http to the other at different > >> times. > >>>> It is TR-069 itself that defines the RPCs (remote procedure calls) > >>>> and when different RPCs can be used. > >>>> So I still have a problem with the idea that Push and Pull are > >>>> necessarily inherited from underlying protocols, or that http > >> implies > >>>> "Pull". > >>>> I agree that multicast is inherited. > >>>> > >>> In terms of how to change the text, the first 2 paras seem ok, but > >> replace the last sentence with: > >>> How this is done depends on the design of the Control and Report > >> Protocols, the underlying packet transfer mechanism and how it is > >> configured (for example, which endpoint is the HTTP client and which > >> the server). > >>> And then change to: > >>> For the Control Protocol, the underlying packet transfer mechanism > >> could be used in a: > >>> o a 'push' mode (that is, from the Controller to the MA) > >>> > >>> and similar change for the other bullets. > >>> > >>> Does this work? > >>> > >> > ....................................................................... > >>>>>> ..... > >>>>>> 5.6.1. End-user-controlled measurement system ... > >>>>>> Note that a user can't directly initiate a Measurement > >>>>>> Task on an ISP- (or regulator-) controlled MA. > >>>>>> Comment: Why not? Why isn't it allowed to include this ability > in > >> a > >>>>>> MA design (such as one that is just for the ISP use case and has > >>>>>> nothing to do with regulatory use case)? > >>>>> [phil] then there would be two ways of controlling the MA, which > >>>>> is something we want to avoid. > >>>> Multiple methods of remote configuration are indeed > >>>> complicated, which was why I very much agreed with the "one > >> Controller" restriction. > >>>> But we have a lot of experience in coordinating between > >>>> person-directed local configuration and remote automated > >>>> configuration on various devices. Which is why I don't see it > >> necessary to forbid this. > >>> Would be interested to read more about this, do you have a ref > >> please. > >>>>>> 6.2.3. Measurement Agent embedded behind site NAT /Firewall > >>>>>> > >>>>>> The Measurement Agent could also be embedded behind a NAT, a > >>>>>> firewall, or both. In this case the Controller may not be > >>>>>> able > >>>> to > >>>>>> unilaterally contact the Measurement Agent unless either > >>>>>> static > >>>> port > >>>>>> forwarding configuration or firewall pin holing is > configured. > >>>> For > >>>>>> the former, protocols such as PCP [RFC6887], TR-069 [TR- > 069]or > >>>> UPnP > >>>>>> [UPnP]could be used. For the latter, the Measurement Agent > >>>> could > >>>>>> send keepalives towards the Controller to prop open the > >> firewall > >>>>>> (and > >>>>>> perhaps use these also as a network reachability test). > >>>>>> Comment: Regarding the last sentence, I don't understand what > >>>>>> keepalives has to do with UPnP. Why not just mention STUN as an > >>>>>> option for keeping NAT table entries from timing out? > >>>>> [phil] "for the former" refers to "static port forwarding > >>>>> configuration" and "for the latter" to "firewall pin holing" > >>>> Hmm. I think we have terminology-understanding differences > at > >>>> multiple levels here. In my use of the words, a port forwarding > >>>> rule or mapping is a pinhole. They can be statically (manually, > >>>> TR-069, > >>>> SNMP) or dynamically (UPnP IGD, PCP) configured, or dynamically > >>>> generated as a result of outbound TCP and UDP packets. Because > >>>> pinholes configured through PCP and UPnP IGD do expire after a > >> while, > >>>> and are created on an "as needed" basis, they tend to be > considered > >> dynamic and not static. > >>>> Pinholes dynamically generated by the NAT or firewall processes as > >>>> a result of outbound TCP or UDP packets don't tend to be > considered > >>>> "configured". I would suggest rewording this to: > >>>> The Measurement Agent could also be embedded behind a NAT, a > >>>> stateful-packet inspection firewall, or both. In this case the > >>>> Controller may not be able to unilaterally contact the > Measurement > >>>> Agent unless configured or dynamically-generated pinholes exist. > >>>> Protocols such as PCP [RFC6887], CWMP [TR-069] or UPnP IGD [UPnP > >>>> IGD] can be used to configure pinholes. For pinholes that are > >>>> dynamically- generated as a result of outbound TCP or UDP packets, > >>>> the Measurement Agent could > >>>> send keepalives, such as those of the STUN protocol [STUN], > >>>> towards the Controller to keep open the pinholes (and perhaps use > >>>> these also as a network reachability test). > >>>> > >>>> I recommend referencing UPnP IGD, and not just UPnP. And calling > >>>> the protocol described in TR-069 "CWMP". > >>> Wfm. Thanks for the text. > >>> > >>>>>> -------------------------------- > >>>>>> 8.3. Key Distinction Between Active and Passive Measurement > >>>>>> Tasks > >>>>>> > >>>>>> Passive and Active Measurement Tasks raise different privacy > >>>> issues. > >>>>>> Passive Measurement Tasks are conducted on a user's traffic > >> ,... > >>>>>> Comment: This is not necessarily true if it is possible for the > >>>>>> MA not to be located in a place where it is associated with a > >>>>>> single > >>>> end user > >>>>>> or subscriber. I recommend " Passive Measurement Tasks can be > >>>>>> conducted on a user's traffic ,..." > >>>>> [phil] how about " Passive Measurement Tasks are conducted on > user > >>>>> traffic"? > >>>>> (I think "can be conducted" misleadingly hints "but may not be") > >>>> As has been discussed on this list, Passive Measurements can > >>>> also be conducted on Active Measurement traffic. I don't consider > >> MA- > >>>> or MP- generated Active Measurement traffic to be user traffic. > For > >>>> MAs located outside the customer premises, it is also possible for > >> an > >>>> ISP to measure management traffic (between its network elements > and > >>>> systems). > >>> Good point. > >>> > >>> Thanks > >>> Phil. > >>> > >>> _______________________________________________ > >>> 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 > > -- > > 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 From nobody Tue May 6 14:43: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 18FB91A049C for ; Tue, 6 May 2014 14:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 Gl2oqP_0ksCp for ; Tue, 6 May 2014 14:43:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id ECC891A049F for ; Tue, 6 May 2014 14:42:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8C2D0AA9; Tue, 6 May 2014 23:42:53 +0200 (CEST) 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 w2nZo8S8ErZ3; Tue, 6 May 2014 23:42:53 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 6 May 2014 23:42:53 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E72A520017; Tue, 6 May 2014 23:42:52 +0200 (CEST) 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 NloLYj9Na99A; Tue, 6 May 2014 23:42:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2CA220013; Tue, 6 May 2014 23:42:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AE2FD2CCABEE; Tue, 6 May 2014 23:42:50 +0200 (CEST) Date: Tue, 6 May 2014 23:42:50 +0200 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20140506214250.GA70197@elstar.local> Mail-Followup-To: Sharam Hakimi , "philip.eardley@bt.com" , "charles.cook2@centurylink.com" , "bs7652@att.com" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130429D2C@GAALPA1MSGUSR9L.ITServices.sbc.com> <535FCB60.9040304@centurylink.com> <53638FC1.6020002@centurylink.com> <89294A6F3C6C91459E52E4128C4B02B70438BD@SPQCMBX02.exfo.com> <89294A6F3C6C91459E52E4128C4B02B704449D@SPQCMBX02.exfo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B704449D@SPQCMBX02.exfo.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/H4QZcZtUxO5LQBuMt8uWZ98kSJc Cc: "philip.eardley@bt.com" , "charles.cook2@centurylink.com" , "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] framework comments 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, 06 May 2014 21:43:02 -0000 On Tue, May 06, 2014 at 07:52:47PM +0000, Sharam Hakimi wrote: > I do not believe that Pull/Push would have an effect as the > existence of the controller is checked by the MA after the MA has > its instructions. It could be a simple ping of the controller while > the instructions are in effect. A ping only tells you that something uses a given IP address (or an IP address derived from a DNS name). This is not really the same as "I can talk to my controller" or "my controller can talk to me". Hence, I believe an MA should shut down if communication between the MA and the controller has not taken place for a certain amount of time. (It could be that for example the security credentials get out of sync - in that case, you still may want to shut down after say a months or a year. /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 May 9 09:30: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 61EBC1A02F2 for ; Fri, 9 May 2014 09:29:57 -0700 (PDT) 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 qeBSSWWYIST2 for ; Fri, 9 May 2014 09:29:54 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 784CF1A02EA for ; Fri, 9 May 2014 09:29:45 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 9 May 2014 17:29:44 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 9 May 2014 17:29:38 +0100 From: To: , Date: Fri, 9 May 2014 17:29:35 +0100 Thread-Topic: status of draft-ietf-lmap-use-cases Thread-Index: Ac9lQH8HygaLp9v5R6eYiCeTqw575gGYxHaQ Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C7CE3C9@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C7CE3C9@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_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4151B52EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/XwyC2va7sm66NzHGJeuMJQaEKSQ Subject: Re: [lmap] status of draft-ietf-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: Fri, 09 May 2014 16:29:57 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4151B52EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 1 - personally yes Sorry for the slow reply, missed this email phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 01 May 2014 14:23 To: lmap@ietf.org Subject: [lmap] status of draft-ietf-lmap-use-cases Hi, The 2nd WGLC of draft-ietf-lmap-use-cases passed without any comments or ob= jections (unless I missed something). I have two questions: 1. Do the authors feel that the document is ready to be submitted to = the IESG for consideration as Informational RFC? 2. Does any other WG participant have any objections to submitting th= e document to the IESG for consideration as Informational RFC? Thanks and Regards, Dan --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4151B52EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On 1 – p= ersonally yes

 =

Sorry for the slow reply, missed this ema= il

 

=

phil

 

= From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of <= /b>Romascanu, Dan (Dan)
Sent: 01 May 2014 14:23
To: lma= p@ietf.org
Subject: [lmap] status of draft-ietf-lmap-use-cases

 

Hi,

 

The 2nd WGLC of draft-ietf-lmap-use-cases p= assed without any comments or objections (unless I missed something). =

 <= /span>

I have two questions:

 

1.  =      = Do the authors feel that the document is ready to be submitted to the IESG = for consideration as Informational RFC?

2.       = Does any other WG partici= pant have any objections to submitting the document to the IESG for conside= ration as Informational RFC?

 

Thanks and Regards,

 

Dan

<= o:p> 

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4151B52EMV67UKRDdoma_-- From nobody Sat May 10 08:49: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 2BE031A000C for ; Sat, 10 May 2014 08:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 tx6iL_fLUvOT for ; Sat, 10 May 2014 08:49:53 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3036A1A0268 for ; Sat, 10 May 2014 08:49:52 -0700 (PDT) Received: from [85.158.137.68:39110] by server-16.bemta-3.messagelabs.com id 6C/7E-13481-B9A4E635; Sat, 10 May 2014 15:49:47 +0000 X-Env-Sender: frode.sorensen@npt.no X-Msg-Ref: server-13.tower-31.messagelabs.com!1399736986!3064413!1 X-Originating-IP: [213.225.64.154] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31310 invoked from network); 10 May 2014 15:49:46 -0000 Received: from unknown (HELO EXCAS.npta.no) (213.225.64.154) by server-13.tower-31.messagelabs.com with AES128-SHA encrypted SMTP; 10 May 2014 15:49:46 -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; Sat, 10 May 2014 17:49:45 +0200 From: =?iso-8859-1?Q?S=F8rensen=2C_Frode?= To: "dromasca@avaya.com" , "lmap@ietf.org" Thread-Topic: status of draft-ietf-lmap-use-cases Thread-Index: Ac9lQH8HygaLp9v5R6eYiCeTqw575gGYxHaQADDxTMA= Date: Sat, 10 May 2014 15:49:44 +0000 Message-ID: <793D91975B99224DA9777562FF192808A34356CC@exmbx01> References: <9904FB1B0159DA42B0B887B7FA8119CA5C7CE3C9@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.2.44] x-tm-as-product-ver: SMEX-11.0.0.1251-7.500.1017-20684.002 x-tm-as-result: No--34.113200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_793D91975B99224DA9777562FF192808A34356CCexmbx01_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/KzblT4_ZgztFj43-ySrCcXohO5g Subject: Re: [lmap] status of draft-ietf-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: Sat, 10 May 2014 15:49:56 -0000 --_000_793D91975B99224DA9777562FF192808A34356CCexmbx01_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I also answer yes to the first question. Frode Fra: lmap [mailto:lmap-bounces@ietf.org] P=E5 vegne av philip.eardley@bt.co= m Sendt: 9. mai 2014 18:30 Til: dromasca@avaya.com; lmap@ietf.org Emne: Re: [lmap] status of draft-ietf-lmap-use-cases On 1 - personally yes Sorry for the slow reply, missed this email phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 01 May 2014 14:23 To: lmap@ietf.org Subject: [lmap] status of draft-ietf-lmap-use-cases Hi, The 2nd WGLC of draft-ietf-lmap-use-cases passed without any comments or ob= jections (unless I missed something). I have two questions: 1. Do the authors feel that the document is ready to be submitted to = the IESG for consideration as Informational RFC? 2. Does any other WG participant have any objections to submitting th= e document to the IESG for consideration as Informational RFC? Thanks and Regards, Dan --_000_793D91975B99224DA9777562FF192808A34356CCexmbx01_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I also = answer yes to the first question.

&n= bsp;

Frode

 

Fra: lmap [mai= lto:lmap-bounces@ietf.org] P=E5 vegne av philip.eardley@bt.com
Sendt: 9. mai 2014 18:30
Til: dromasca@avaya.com; lmap@ietf.org
Emne: Re: [lmap] status of draft-ietf-lmap-use-cases

 

On 1 – pe= rsonally yes

 

Sorry for the s= low reply, missed this email

 

phil=

 

From: lmap [mailto= :lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: 01 May 2014 14:23
To: lmap@ietf.org
Subject: [lmap] status of draft-ietf-lmap-use-cases

 

Hi,

 

The 2nd WGLC of draf= t-ietf-lmap-use-cases passed without any comments or objections (unless I m= issed something).

 

I have two questions:

 

1. &nbs= p;     Do the authors feel tha= t the document is ready to be submitted to the IESG for consideration as In= formational RFC?

2. &nbs= p;     Does any other WG parti= cipant have any objections to submitting the document to the IESG for consi= deration as Informational RFC?

 

Thanks and Regards,<= /span>

 

Dan

 

--_000_793D91975B99224DA9777562FF192808A34356CCexmbx01_-- From nobody Sat May 10 11: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 7CE701A009A for ; Sat, 10 May 2014 11:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-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 gOFPZcNFUhLJ for ; Sat, 10 May 2014 11:53:10 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3B21C1A0078 for ; Sat, 10 May 2014 11:53:09 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s4AIqtpi021941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 May 2014 13:52:56 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s4AIqq7T012989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 May 2014 14:52:53 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Sat, 10 May 2014 14:52:51 -0400 From: "Carey, Timothy (Timothy)" To: KEN KO , "marc.ibrahim" , "Sharam Hakimi" , Juergen Schoenwaelder Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAMH2AAABWvrAAAELs4AAIod6AAAAj6gAAAZ1bAAAAx60AAAFrJIAAAEmdgAAIBF/A///+ooCAAEZwgIAA3ImA/+awS0A= Date: Sat, 10 May 2014 18:52:50 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> <20140423145224.M63656@usj.edu.lb> <20140423151059.GE1056@elstar.local> <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> <20140423221748.M2036@usj.edu.lb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] 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/3idZeSixbHSiS8qHmiuvU5YXgjo Cc: "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Timer: Poisson distribution question 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: Sat, 10 May 2014 18:53:15 -0000 Ken, I am in the process of commenting on the BBF model TR-181i2a8 for StrawBall= ot. While you are correct in your assumption the Ti isn't really known when you= setup the timer (which also could be used for multiple Tis). So I plan to = keep what Marc was saying. My question to the group is should we limit the Randomness to just the dist= ribution to what Marc suggested or should we keep the capability for multip= le distributions. - If so is this the Uniform-Discrete distribution? Thanks, Tim -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com]=20 Sent: Thursday, April 24, 2014 7:17 AM To: marc.ibrahim; Sharam Hakimi; Juergen Schoenwaelder Cc: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Since Ti+Xmin is non-random, Xmin is not really needed as a separate parame= ter. Just offset Ti to the desired minimum time and let the spread range fr= om Ti to Ti+Xmax. Other than that nit, +1 -----Original Message----- From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb]=20 Sent: Wednesday, April 23, 2014 7:08 PM To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; lmap@ietf.or= g Subject: Re: [lmap] Timer: Poisson distribution question Based on what has been exchanged, I suggest the following: 1- Exact randomness definition and operation -------------------------------------------- IMHO, we need to define how exactly the randomness is applied. For a given event E (e.g. running a measurement task, start reporting,...),= let Ti be the predefined (scheduled) instant of the ith occurrence of E.=20 Adding randomness means that the event E will happen at time Ti + X instead= of Ti, where X is a random variable. If Xmin and Xmax denote the minimum a= nd maximum possible values of X repectively, then the event E will take pla= ce at an instant randomly chosen between=20 Ti+Xmin and Ti+Xmax. The spread is equal to Xmax-Xmin Ti+Xmin Ti Ti+Xmax ---------|-----------------|-------------------|----------- <-------------------------------------> Spread Note that Xmin could be negative if E can occur before Ti like in the figur= e. I think that the most common values of Xmin would be 0 or (-spread/2). 2- Random generation of X --------------------------- To make it simple as stated by many, X could an integer number of milliseco= nds uniformly chosen in the interval [Xmin, Xmax]. Xmin, Xmax, and hence spread, are all integers (milliseconds). Then the MA has to define a function UNIF(Xmin, Xmax) or equivalently UNIF(= Xmin, spread) that generates a random number of milliseconds from [Xmin, Xm= ax] interval. The controller has just to send two integer variables (Xmin, Xmax) or (Xmin= , spread) to the MA in the timing object. In this minimalist approach, no need to specify the nature of distribution = in the timing object since it is assumed to be the uniform one.=20 BR, Marc. On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote > This example confuses resolution of the measurement result with resolutio= n and=20 > accuracy of the time at which the measurement is initiated. Measuring rou= nd=20 > trip latencies on a Gigabit LAN may well require microsecond resolution, = which=20 > could be within the capabilities of a higher end MA. But that doesn't req= uire=20 > microsecond resolution of the time at which the measurement is initiated.= In=20 > addition, for microsecond resolution on the Timer to be meaningful would= =20 > require synchronization to that resolution across different MAs in the ne= twork. >=20 > I'm in favor of keeping things simple and specifying Timer resolution in = milliseconds. >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi > Sent: Wednesday, April 23, 2014 11:33 AM > To: Juergen Schoenwaelder; marc.ibrahim > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; lmap@ietf.= org > Subject: Re: [lmap] Timer: Poisson distribution question >=20 > It depends what the performance goal of the measurement is. A ping packet= in a=20 > Gigabit network is just under 1 microseconds and with fast processors a p= acket=20 > can be sent and received at the same time if granularity is milliseconds. >=20 > This does not even take into account 10Gig networks, not that they would = be at=20 > consumer sites, but they would sure exist inside a ISP network. >=20 > Sharam >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, April 23, 2014 11:11 AM > To: marc.ibrahim > Cc: trevor.burbridge@bt.com; Sharam Hakimi; timothy.carey@alcatel-lucent.= com;=20 lmap@ietf.org > Subject: Re: [lmap] Timer: Poisson distribution question >=20 > I believe randomization with a granularity of milliseconds is good enough= .=20 > Within an implementation of a measurement task, one may use more precise= =20 > timers. But for the randomization of the start of measurement tasks or th= e=20 > sending of reports, milliseconds seem to be sufficient (since there will = be=20 > likely other delays introduced by the operating system that may get into = the=20 > some order for starting a measurement task or triggering a report). >=20 > /js >=20 > On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote: > > I would say that choosing the millisecond as atomic time alleviates=20 > > constraints on both timer granularity and generator capacity. > >=20 > > I still don't see a real measurement example where few microseconds wou= ld really=20 matter. > >=20 > > Practically, can a program deal with microseconds timers in computers a= nd=20 smartphones?=20 > > This is the scale of the OS, no? > >=20 > > Marc. > >=20 > > On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote > > > So the question is really do we want to design for extremely=20 > > > constrained devices? I'd argue that if this is a problem for them=20 > > > then they are really going to struggle with the Instruction informati= on or=20 measurement results. > > >=20 > > > Trevor. > > >=20 > > > >-----Original Message----- > > > >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > > > >Sent: 23 April 2014 15:00 > > > >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com;=20 > > > >timothy.carey@alcatel-lucent.com; lmap@ietf.org > > > >Subject: Re: [lmap] Timer: Poisson distribution question > > > > > > > >Here is how I see the problem. > > > > > > > >First we have to separate time granularity and random generation. > > > > > > > >Time granularity depends on the timer running on the MA. e.g=20 > > > >microseconds scale means that the MA timer increment each microsecon= d. > > > > > > > >When MA wants to generate a random time, he has to choose an=20 > > > >integer number of microseconds to count. So the problem is always=20 > > > >an integer (discrete) number generation. > > > > > > > >Now, if the random generator can attain the maximum integer (so the= =20 > > > >maximum possible random time), then, as Trevor says, no need for=20 > > > >the timeStep I talked about, since all possible durations will be ex= pressed as=20 multiple of microseconds. > > > > > > > > > > > >For example, a 32 bits random generator could generate up to a=20 > > > >maximum value of 4 billions. In microseconds, this is equal to less = than 2 hours. > > > > > > > >It all depends on the capacity of the generator. > > > >Marc. > > > > > > > > > > > >On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote > > > >> So what is the argument for the latter (discrete) option? > > > >> > > > >> Trevor. > > > >> > > > >> >-----Original Message----- > > > >> >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > > > >> >Sent: 23 April 2014 14:10 > > > >> >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com;=20 > > > >> >timothy.carey@alcatel-lucent.com; lmap@ietf.org > > > >> >Subject: Re: [lmap] Timer: Poisson distribution question > > > >> > > > > >> >Trevor, you're right. > > > >> >it is just about whether we want a discrete or continuous generat= or. > > > >> >If we use a continuous uniform generator, than it is enough to=20 > > > >> >specify the maximum time. > > > >> >With a discrete random generator, you need to specify an=20 > > > >> >additional time granularity. > > > >> > > > > >> >BR, > > > >> > > > > >> >Marc. > > > >> > > > > >> > > > > >> >On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote > > > >> >> I'm not sure I get the point of allowing coarser granularity=20 > > > >> >> that the MA is capable of. If I want the MA to test/report=20 > > > >> >> sometime within a minute window, why not allow that to happen=20 > > > >> >> with the maximum resolution the MA is capable > > > >> >of? > > > >> >> > > > >> >> 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.=20 > > > >> >> If you're not the intended recipient, note that disclosing,=20 > > > >> >> copying, distributing or using this information is prohibited.= =20 > > > >> >> If you've received this email in error, please let me know=20 > > > >> >> immediately on the email address above. Thank you. We monitor=20 > > > >> >> our email system, and may record your emails. British=20 > > > >> >> Telecommunications plc Registered > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in=20 > > > >> >> England > > > >> >no: > > > >> >> 1800000 > > > >> >> > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam=20 > > > >> >> Hakimi > > > >> >> Sent: 23 April 2014 13:58 > > > >> >> To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R;=20 > > > >> >> lmap@ietf.org > > > >> >> Subject: Re: [lmap] Timer: Poisson distribution question > > > >> >> > > > >> >> Marc's suggestion works for me. That allows better=20 > > > >> >> interoperability in my > > > >> >opinion. > > > >> >> > > > >> >> I do agree that we need a common "structure" and "names". > > > >> >> > > > >> >> Thanks, > > > >> >> Sharam > > > >> >> > > > >> >> From: Carey, Timothy (Timothy)=20 > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > >> >> Sent: Wednesday, April 23, 2014 8:47 AM > > > >> >> To: trevor.burbridge@bt.com;=20 > > > >> >> Sharam > > > >> >Hakimi; > > > >> >lmap@ietf.org > > > >> >> Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> Trevor, > > > >> >> > > > >> >> No - I am using the variable of your Information Model=20 > > > >> >> (LowerLimit, > > > >> >UpperLimit, > > > >> >> Spread) - works so far. Marc suggested a TimeStep parameter=20 > > > >> >> so we don't lockin on a specific microsecond, millisecond,=20 > > > >> >> second thing - I am open > > > >to that. > > > >> >> > > > >> >> BR, > > > >> >> Tim > > > >> >> > > > >> >> From: trevor.burbridge@bt.com > > > >> >[mailto:trevor.burbridge@bt.com] > > > >> >> Sent: Wednesday, April 23, 2014 7:41 AM > > > >> >> To: Carey, Timothy (Timothy); > > > >> >> sharam.hakimi@exfo.com; > > > >> >lmap@ietf.org > > > >> >> Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> Agree we need to have well defined function names. I thought=20 > > > >> >> you were also suggesting different functions needed different i= nput=20 parameters. > > > >> >> > > > >> >> 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.=20 > > > >> >> If you're not the intended recipient, note that disclosing,=20 > > > >> >> copying, distributing or using this information is prohibited.= =20 > > > >> >> If you've received this email in error, please let me know=20 > > > >> >> immediately on the email address above. Thank you. We monitor=20 > > > >> >> our email system, and may record your emails. British=20 > > > >> >> Telecommunications plc Registered > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in=20 > > > >> >> England > > > >> >no: > > > >> >> 1800000 > > > >> >> > > > >> >> From: Carey, Timothy (Timothy)=20 > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > >> >> Sent: 23 April 2014 13:36 > > > >> >> To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; > > > >> >lmap@ietf.org > > > >> >> Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> Its not that the Measurement controller has to configure the=20 > > > >> >> timer for the > > > >MA. > > > >> >> > > > >> >> If we do not specify the functions and variable names, the=20 > > > >> >> measurement controller doesn't have a standard way of configuri= ng a timer. > > > >> >> > > > >> >> For example - If I specify for a Uniform distribution function= =20 > > > >> >> called "Uniform" you have a variable called "UpperLimit", the= =20 > > > >> >> MA will implement the specification; the controller will=20 > > > >> >> implement the > > > >specification and things work. > > > >> >> > > > >> >> If I do not specify anything for the Uniform distribution=20 > > > >> >> function > > > >> >> - MA vendor > > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" and=20 > > > >> >> maybe an > > > >"Enable" > > > >> >> parameter for good measure; MA vendor 2 can call it "U" and=20 > > > >> >> have an attribute "X that is an integer". > > > >> >> > > > >> >> Now put that variation on steroids based on the number of MA=20 > > > >> >> vendors - That is why we specify things, right? > > > >> >> > > > >> >> BR, > > > >> >> Tim > > > >> >> > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > >> >> Sent: Wednesday, April 23, 2014 7:24 AM > > > >> >> To: Carey, Timothy (Timothy); > > > >> >> trevor.burbridge@bt.com; > > > >> >lmap@ietf.org > > > >> >> Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> The measurement controller has to communicate what tests have=20 > > > >> >> to be run on > > > >> >an > > > >> >> MA, for how long, when to run them, what test results are=20 > > > >> >> generated, etc. Why would configuring this parameter be any=20 > > > >> >> different. Maybe I am missing > > > >> >something. > > > >> >> > > > >> >> From: Carey, Timothy (Timothy)=20 > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > >> >> Sent: Wednesday, April 23, 2014 8:16 AM > > > >> >> To: Sharam Hakimi; > > > >> >trevor.burbridge@bt.com; > > > >> >lmap@ietf.org > > > >> >> Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> So the burden is on the Measurement controller to know the=20 > > > >> >> functions and inputs specifications for each possible MA=20 > > > >> >> vendor; not something I would want to have to do as a=20 > > > >> >> Measurement controller > > > >vendor. > > > >> >> > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > >> >> Sent: Wednesday, April 23, 2014 7:14 AM > > > >> >> To: Carey, Timothy (Timothy); > > > >> >> trevor.burbridge@bt.com; > > > >> >lmap@ietf.org > > > >> >> Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> I do not see why vendor A or B or C matters. They would all be= =20 > > > >> >> under the control of one Measurement Controller which would=20 > > > >> >> specify what inputs to use for all MAs in a group. > > > >> >> > > > >> >> As Trevor also mentioned this timer can be used for both=20 > > > >> >> testing and reporting and I would strongly suggest to have=20 > > > >> >> microsecond granularity. For reporting one could choose=20 > > > >> >> seconds in terms of > > > >microseconds. > > > >> >> > > > >> >> Thanks, > > > >> >> Sharam > > > >> >> > > > >> >> From: Carey, Timothy (Timothy)=20 > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > >> >> Sent: Wednesday, April 23, 2014 8:04 AM > > > >> >> To: trevor.burbridge@bt.com;=20 > > > >> >> Sharam > > > >> >Hakimi; > > > >> >lmap@ietf.org > > > >> >> Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> Trevor, > > > >> >> > > > >> >> If we don't define the inputs for each function (leaving the=20 > > > >> >> inputs > > > >> >> opaque) you will have interop problems. MA vendor 1 uses=20 > > > >> >> these 2 inputs > > > >named "A" > > > >> >and > > > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" for the=20 > > > >> >> same > > > >function. > > > >> >> > > > >> >> I think we need to avoid that if we realistically want the=20 > > > >> >> Randomness function to be used efficiently. > > > >> >> > > > >> >> BR, > > > >> >> Tim > > > >> >> > > > >> >> From: trevor.burbridge@bt.com > > > >> >[mailto:trevor.burbridge@bt.com] > > > >> >> Sent: Wednesday, April 23, 2014 2:55 AM > > > >> >> To: Carey, Timothy (Timothy); > > > >> >> sharam.hakimi@exfo.com; > > > >> >lmap@ietf.org > > > >> >> Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> The random timing can be used for both specifying when a test=20 > > > >> >> runs, or when a report is sent (or any other task such as=20 > > > >> >> contacting the Controller). It doesn't have to be used, but it = can be. > > > >> >> > > > >> >> I don't really want different input variable for different=20 > > > >> >> functions. I don't see we need to. Also if we do, then we=20 > > > >> >> would have to have schema for each function to specify which=20 > > > >> >> inputs are expected (like the measurement task registry). I'd l= ike to avoid=20 that. > > > >> >> > > > >> >> 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.=20 > > > >> >> If you're not the intended recipient, note that disclosing,=20 > > > >> >> copying, distributing or using this information is prohibited.= =20 > > > >> >> If you've received this email in error, please let me know=20 > > > >> >> immediately on the email address above. Thank you. We monitor=20 > > > >> >> our email system, and may record your emails. British=20 > > > >> >> Telecommunications plc Registered > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in=20 > > > >> >> England > > > >> >no: > > > >> >> 1800000 > > > >> >> > > > >> >> From: Carey, Timothy (Timothy)=20 > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > >> >> Sent: 22 April 2014 22:07 > > > >> >> To: Sharam Hakimi; lmap@ietf.org; > > > >> >> Burbridge,T,Trevor, > > > >> >> TUB8 R Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> Sharam, > > > >> >> > > > >> >> We are talking about offsets for when to report; in the world=20 > > > >> >> we live in milliseconds is sufficient - IMHO. > > > >> >> > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > >> >> Sent: Tuesday, April 22, 2014 3:59 PM > > > >> >> To: Carey, Timothy (Timothy);=20 > > > >> >> lmap@ietf.org; > > > >> >trevor.burbridge@bt.com > > > >> >> Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> Tim, > > > >> >> I think the min/max should have microseconds granularity. > > > >> >> Milliseconds would not be accurate enough. > > > >> >> > > > >> >> Personally, I would not trust my periodic tests in a large=20 > > > >> >> scale deployment to a random number generator and would want=20 > > > >> >> to know exactly how and when > > > >> >tests > > > >> >> would be run. > > > >> >> > > > >> >> Thanks, > > > >> >> Sharam > > > >> >> > > > >> >> From: Carey, Timothy (Timothy)=20 > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > >> >> Sent: Tuesday, April 22, 2014 3:16 PM > > > >> >> To: Sharam Hakimi; lmap@ietf.org; > > > >> >trevor.burbridge@bt.com > > > >> >> Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> Trevor, > > > >> >> > > > >> >> The data model is extensible by vendors so we can add=20 > > > >> >> functions and input variables as we need. > > > >> >> > > > >> >> However we have to decide on which small subset we actually=20 > > > >> >> want to > > > >> >standardize. > > > >> >> > > > >> >> You suggested the Uniform and Normal which is fine but for the= =20 > > > >> >> model we need to go farther by defining the specific function=20 > > > >> >> along with which inputs are used by the function to derive=20 > > > >> >> what random number. Otherwise we will have 2 implementers of=20 > > > >> >> the same standard algorithm implement different variations. - = Not good. > > > >> >> > > > >> >> So I suggest we keep this simple. > > > >> >> > > > >> >> Uniform Discrete - input variables - maximum [positive=20 > > > >> >> integer] Gaussian -input variables - mean of min/max, spread = =3D=20 > > > >> >> standard deviation > > > >> >> > > > >> >> The min/max would be milliseconds - Spread would be an integer. > > > >> >> > > > >> >> This sound OK? > > > >> >> > > > >> >> BR > > > >> >> Tim > > > >> >> > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > >> >> Sent: Tuesday, April 22, 2014 8:23 AM > > > >> >> To: Carey, Timothy (Timothy);=20 > > > >> >> lmap@ietf.org; > > > >> >trevor.burbridge@bt.com > > > >> >> Subject: RE: Timer: Poisson distribution question > > > >> >> > > > >> >> Tim, > > > >> >> I think the Periodic Timer distribution needs to have closer=20 > > > >> >> configuration control by the user and I think your 2nd choice= =20 > > > >> >> attempts to provide it but having a discrete interval=20 > > > >> >> definition is a better way > > > >to go. > > > >> >> > > > >> >> Sharam > > > >> >> > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > > > >> >trevor.burbridge@bt.com > > > >> >> Sent: Tuesday, April 22, 2014 4:35 AM > > > >> >> To:=20 > > > >> >> timothy.carey@alcatel-lucent.com > > >> >lucent.com>; > > > >> >> lmap@ietf.org Subject: Re: [lmap] Timer: > > > >> >> Poisson distribution question > > > >> >> > > > >> >> On continuous counterparts of Poisson I'm far from any expert=20 > > > >> >> and it would certainly be up to the user to decide if such=20 > > > >> >> functions were suitable replacements for the discrete Poisson=20 > > > >> >> function. Yes it would be a different function even if there=20 > > > >> >> was perfect fit (which they are not) as one is continuous and o= ne is=20 discrete: > > > >> >> http://cmscience.blogspot.co.uk/2008/04/mt- > > > >> >6- > > > >> >> poisson-and-gamma-distribution.html=20 > > > >> >> http://arxiv.org/abs/1303.5990 > > > >> >> > > > >> >> As I tried to say the current Information Model can take=20 > > > >> >> either discrete or continuous functions - only that there is=20 > > > >> >> currently no explicit support for specifying the interval used= =20 > > > >> >> for a discrete function. I was questioning the need to add this= . > > > >> >> > > > >> >> Personally I'd think that Normal and Uniform distributions=20 > > > >> >> would cover most needs, but the framework should be flexible in= this regard. > > > >> >> > > > >> >> Trevor. > > > >> >> > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey,=20 > > > >> >> Timothy > > > >> >(Timothy) > > > >> >> Sent: 19 April 2014 20:24 > > > >> >> To: lmap@ietf.org > > > >> >> Subject: [lmap] Timer: Poisson distribution question > > > >> >> > > > >> >> Team, > > > >> >> > > > >> >> The BBF is looking at standardizing the model for Timers as=20 > > > >> >> suggested by the IETF LMAP information model. > > > >> >> > > > >> >> During the review of the timers we had addition questions=20 > > > >> >> regarding Trevors response to the Poisson distribution for the= =20 > > > >> >> Randomness of the > > > >Periodic Timer. > > > >> >> > > > >> >> Trevor responded: > > > >> >> > > > >> >> "Yes this does need to be clarified. I was assuming a=20 > > > >> >> distribution about the mean (i.e. the timing given is the=20 > > > >> >> mean). The spread would be the standard deviation (could use=20 > > > >> >> mean deviation or something else but I see no advantage as=20 > > > >> >> long as we all know what it refers to) and need to change to a= =20 > > > >> >> float. The upper and lower cuts would be in seconds +/- the=20 > > > >> >> mean (also needs to change > > > >> >to > > > >> >> float) and are simply used to trim the function - obviously=20 > > > >> >> needed on a uniform distribution but useful to constrain other = functions. > > > >> >> > > > >> >> I will make all this clear in the next release. > > > >> >> > > > >> >> As for poisson I think there are 3 options: > > > >> >> > > > >> >> - Use a continuous form instead > > > >> >> > > > >> >> - Have the discrete interval implicit in the function ch= oice > > > >> >e.g."poisson_1_sec" > > > >> >> > > > >> >> - Add an interval to the information model. > > > >> >> > > > >> >> I was really thinking about the first, but I don't see the=20 > > > >> >> problem with the second. However I wouldn't do the third=20 > > > >> >> unless they was a demonstrable value to supporting discrete=20 > > > >> >> functions (rather than continuous > > > >versions of them). " > > > >> >> > > > >> >> But as people looked at Trevors response there were additional = questions: > > > >> >> > > > >> >> I don't understand what Trevor means about the Poisson=20 > > > >> >> distribution. As far as I know, it is a discrete=20 > > > >> >> distribution, so a "continuous form" would be a different=20 > > > >> >> distribution and not Poisson. And I believe that we do need a = continuous=20 distribution. > > > >> >> But what matters is that the definition is clear, not the=20 > > > >> >> particular > > distribution > > > >(I don't have an opinion on that). > > > >> >> > > > >> >> Could some please clarify this for us - Are we planning=20 > > > >> >> something other than Poisson method; better yet is there a=20 > > > >> >> definition for the types of > > > >> >> distribution: Poisson, Normal and Uniform. > > > >> >> > > > >> >> Thanks, > > > >> >> Tim > > > >> > > > > >> > > > > >> >-- > > > >> >Open WebMail Project (http://openwebmail.org) > > > >> > > > >> _______________________________________________ > > > >> lmap mailing list > > > >> lmap@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > > >-- > > > >Open WebMail Project (http://openwebmail.org) > > >=20 > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > >=20 > >=20 > > -- > > Open WebMail Project (http://openwebmail.org) > >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=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 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Open WebMail Project (http://openwebmail.org) From nobody Sat May 10 13:17: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 A04CD1A028F for ; Sat, 10 May 2014 13:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.048 X-Spam-Level: * X-Spam-Status: No, score=1.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.651, 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 GIoLVVRtJVBN for ; Sat, 10 May 2014 13:17:24 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id D42BB1A028A for ; Sat, 10 May 2014 13:17:22 -0700 (PDT) X-ASG-Debug-ID: 1399753162-05fac1536b21d440001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id WIUL5VrTYtEMXMbV; Sat, 10 May 2014 23:19:22 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from usj.edu.lb (localhost.localdomain [127.0.0.1]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4AKGuqO009272; Sat, 10 May 2014 23:16:58 +0300 From: "marc.ibrahim" To: "Carey, Timothy (Timothy)" , KEN KO , "Sharam Hakimi" , Juergen Schoenwaelder Date: Sat, 10 May 2014 23:16:55 +0300 X-ASG-Orig-Subj: RE: [lmap] Timer: Poisson distribution question Message-Id: <20140510193741.M70435@usj.edu.lb> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> <20140423145224.M63656@usj.edu.lb> <20140423151059.GE1056@elstar.local> <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> <20140423221748.M2036@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcate l-lucent.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 46.19.194.254 (marc.ibrahim) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1399753162 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.5702 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/yQ5iHjx8uwdwUGSU1XwmMLJAzVo Cc: "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Timer: Poisson distribution question 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: Sat, 10 May 2014 20:17:30 -0000 Tim, > While you are correct in your assumption the Ti isn't really known when you > setup the timer (which also could be used for multiple Tis). So I plan to keep > what Marc was saying. I agree with Ken that Xmin is superfluous. The essential parameter is the spread. I suggested Xmin just to be able to control the spread around Ti, but this is not really important. We can just say that the time values will be chosen between Ti and Ti+spread. > My question to the group is should we limit the Randomness to just the > distribution to what Marc suggested or should we keep the capability for > multiple distributions. As the draft says, the goal of randomness is to spread the load by preventing multiple events from occurring simultaneously. Given the spread interval, the uniform distribution is mathematically the best to achieve it. I don't see why we should use normal distribution, which will tend to concentrate values around some mean. >If so is this the Uniform-Discrete distribution? I suggested to express the randomness as an integer number of milliseconds. So the answer is yes. Finally, I would like to add a comment about the Poisson distribution that was the initial cause of this discussion about timer. I think that there was a confusion with the Poisson process used to randomize the instants of packets transmission in active measurements. In fact, Poisson in measurement context is a process describing the occurrence of events and not a probability distribution for a time interval (the related distribution is exponential as explained below). So, if a Poisson process is to be used in lmap context, it applies in my opinion only to periodic schedules as follows: - The period specified in the timing object is in fact an average period. For example, if an MA event occurs at Ti, the next event will occur in average at Ti+period - After an event occurs at Ti, the MA will choose a real number X according to an exponential distribution of mean = period. Next event will then occur at Ti+X. - When the inter-event time is exponential, the whole process is known as a Poisson process of rate = 1/period. - In this approach, we do not specify a spread around predefined instants Tis. We rather randomize the whole interval separating two consecutive Tis. This could be another viable (but may be more complicated??) approach for periodic events. BR, Marc. On Sat, 10 May 2014 18:52:50 +0000, Carey, Timothy (Timothy) wrote > Ken, > > I am in the process of commenting on the BBF model TR-181i2a8 for StrawBallot. > While you are correct in your assumption the Ti isn't really known when you > setup the timer (which also could be used for multiple Tis). So I plan to keep > what Marc was saying. > > My question to the group is should we limit the Randomness to just the > distribution to what Marc suggested or should we keep the capability for > multiple distributions. - If so is this the Uniform-Discrete distribution? > > Thanks, > Tim > > -----Original Message----- > From: KEN KO [mailto:KEN.KO@adtran.com] > Sent: Thursday, April 24, 2014 7:17 AM > To: marc.ibrahim; Sharam Hakimi; Juergen Schoenwaelder > Cc: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org > Subject: RE: [lmap] Timer: Poisson distribution question > > Since Ti+Xmin is non-random, Xmin is not really needed as a separate > parameter. Just offset Ti to the desired minimum time and let the spread range > from Ti to Ti+Xmax. > > Other than that nit, +1 > > -----Original Message----- > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > Sent: Wednesday, April 23, 2014 7:08 PM > To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; lmap@ietf.org > Subject: Re: [lmap] Timer: Poisson distribution question > > Based on what has been exchanged, I suggest the following: > > 1- Exact randomness definition and operation > -------------------------------------------- > IMHO, we need to define how exactly the randomness is applied. > > For a given event E (e.g. running a measurement task, start reporting,...), > let Ti be the predefined (scheduled) instant of the ith occurrence of E. > Adding randomness means that the event E will happen at time Ti + X instead of > Ti, where X is a random variable. If Xmin and Xmax denote the minimum and > maximum possible values of X repectively, then the event E will take place at > an instant randomly chosen between Ti+Xmin and Ti+Xmax. The spread is equal to > Xmax-Xmin > > Ti+Xmin Ti Ti+Xmax > ---------|-----------------|-------------------|----------- > > <-------------------------------------> > Spread > > Note that Xmin could be negative if E can occur before Ti like in the figure. > I think that the most common values of Xmin would be 0 or (-spread/2). > > 2- Random generation of X > --------------------------- > To make it simple as stated by many, X could an integer number of milliseconds > uniformly chosen in the interval [Xmin, Xmax]. Xmin, Xmax, and hence spread, > are all integers (milliseconds). > > Then the MA has to define a function UNIF(Xmin, Xmax) or equivalently > UNIF(Xmin, spread) that generates a random number of milliseconds from [Xmin, > Xmax] interval. The controller has just to send two integer variables (Xmin, > Xmax) or (Xmin, spread) to the MA in the timing object. > > In this minimalist approach, no need to specify the nature of distribution in > the timing object since it is assumed to be the uniform one. > > BR, > > Marc. > > On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote > > This example confuses resolution of the measurement result with resolution and > > accuracy of the time at which the measurement is initiated. Measuring round > > trip latencies on a Gigabit LAN may well require microsecond resolution, which > > could be within the capabilities of a higher end MA. But that doesn't require > > microsecond resolution of the time at which the measurement is initiated. In > > addition, for microsecond resolution on the Timer to be meaningful would > > require synchronization to that resolution across different MAs in the network. > > > > I'm in favor of keeping things simple and specifying Timer resolution in milliseconds. > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi > > Sent: Wednesday, April 23, 2014 11:33 AM > > To: Juergen Schoenwaelder; marc.ibrahim > > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; lmap@ietf.org > > Subject: Re: [lmap] Timer: Poisson distribution question > > > > It depends what the performance goal of the measurement is. A ping packet in a > > Gigabit network is just under 1 microseconds and with fast processors a packet > > can be sent and received at the same time if granularity is milliseconds. > > > > This does not even take into account 10Gig networks, not that they would be at > > consumer sites, but they would sure exist inside a ISP network. > > > > Sharam > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, April 23, 2014 11:11 AM > > To: marc.ibrahim > > Cc: trevor.burbridge@bt.com; Sharam Hakimi; timothy.carey@alcatel-lucent.com; > lmap@ietf.org > > Subject: Re: [lmap] Timer: Poisson distribution question > > > > I believe randomization with a granularity of milliseconds is good enough. > > Within an implementation of a measurement task, one may use more precise > > timers. But for the randomization of the start of measurement tasks or the > > sending of reports, milliseconds seem to be sufficient (since there will be > > likely other delays introduced by the operating system that may get into the > > some order for starting a measurement task or triggering a report). > > > > /js > > > > On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote: > > > I would say that choosing the millisecond as atomic time alleviates > > > constraints on both timer granularity and generator capacity. > > > > > > I still don't see a real measurement example where few microseconds would really > matter. > > > > > > Practically, can a program deal with microseconds timers in computers and > smartphones? > > > This is the scale of the OS, no? > > > > > > Marc. > > > > > > On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote > > > > So the question is really do we want to design for extremely > > > > constrained devices? I'd argue that if this is a problem for them > > > > then they are really going to struggle with the Instruction information or > measurement results. > > > > > > > > Trevor. > > > > > > > > >-----Original Message----- > > > > >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > > > > >Sent: 23 April 2014 15:00 > > > > >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; > > > > >timothy.carey@alcatel-lucent.com; lmap@ietf.org > > > > >Subject: Re: [lmap] Timer: Poisson distribution question > > > > > > > > > >Here is how I see the problem. > > > > > > > > > >First we have to separate time granularity and random generation. > > > > > > > > > >Time granularity depends on the timer running on the MA. e.g > > > > >microseconds scale means that the MA timer increment each microsecond. > > > > > > > > > >When MA wants to generate a random time, he has to choose an > > > > >integer number of microseconds to count. So the problem is always > > > > >an integer (discrete) number generation. > > > > > > > > > >Now, if the random generator can attain the maximum integer (so the > > > > >maximum possible random time), then, as Trevor says, no need for > > > > >the timeStep I talked about, since all possible durations will be expressed as > multiple of microseconds. > > > > > > > > > > > > > > >For example, a 32 bits random generator could generate up to a > > > > >maximum value of 4 billions. In microseconds, this is equal to less than 2 hours. > > > > > > > > > >It all depends on the capacity of the generator. > > > > >Marc. > > > > > > > > > > > > > > >On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote > > > > >> So what is the argument for the latter (discrete) option? > > > > >> > > > > >> Trevor. > > > > >> > > > > >> >-----Original Message----- > > > > >> >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > > > > >> >Sent: 23 April 2014 14:10 > > > > >> >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; > > > > >> >timothy.carey@alcatel-lucent.com; lmap@ietf.org > > > > >> >Subject: Re: [lmap] Timer: Poisson distribution question > > > > >> > > > > > >> >Trevor, you're right. > > > > >> >it is just about whether we want a discrete or continuous generator. > > > > >> >If we use a continuous uniform generator, than it is enough to > > > > >> >specify the maximum time. > > > > >> >With a discrete random generator, you need to specify an > > > > >> >additional time granularity. > > > > >> > > > > > >> >BR, > > > > >> > > > > > >> >Marc. > > > > >> > > > > > >> > > > > > >> >On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote > > > > >> >> I'm not sure I get the point of allowing coarser granularity > > > > >> >> that the MA is capable of. If I want the MA to test/report > > > > >> >> sometime within a minute window, why not allow that to happen > > > > >> >> with the maximum resolution the MA is capable > > > > >> >of? > > > > >> >> > > > > >> >> 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 not the intended recipient, note that disclosing, > > > > >> >> copying, distributing or using 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. British > > > > >> >> Telecommunications plc Registered > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in > > > > >> >> England > > > > >> >no: > > > > >> >> 1800000 > > > > >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam > > > > >> >> Hakimi > > > > >> >> Sent: 23 April 2014 13:58 > > > > >> >> To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R; > > > > >> >> lmap@ietf.org > > > > >> >> Subject: Re: [lmap] Timer: Poisson distribution question > > > > >> >> > > > > >> >> Marc's suggestion works for me. That allows better > > > > >> >> interoperability in my > > > > >> >opinion. > > > > >> >> > > > > >> >> I do agree that we need a common "structure" and "names". > > > > >> >> > > > > >> >> Thanks, > > > > >> >> Sharam > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy) > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: Wednesday, April 23, 2014 8:47 AM > > > > >> >> To: trevor.burbridge@bt.com; > > > > >> >> Sharam > > > > >> >Hakimi; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Trevor, > > > > >> >> > > > > >> >> No - I am using the variable of your Information Model > > > > >> >> (LowerLimit, > > > > >> >UpperLimit, > > > > >> >> Spread) - works so far. Marc suggested a TimeStep parameter > > > > >> >> so we don't lockin on a specific microsecond, millisecond, > > > > >> >> second thing - I am open > > > > >to that. > > > > >> >> > > > > >> >> BR, > > > > >> >> Tim > > > > >> >> > > > > >> >> From: trevor.burbridge@bt.com > > > > >> >[mailto:trevor.burbridge@bt.com] > > > > >> >> Sent: Wednesday, April 23, 2014 7:41 AM > > > > >> >> To: Carey, Timothy (Timothy); > > > > >> >> sharam.hakimi@exfo.com; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Agree we need to have well defined function names. I thought > > > > >> >> you were also suggesting different functions needed different input > parameters. > > > > >> >> > > > > >> >> 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 not the intended recipient, note that disclosing, > > > > >> >> copying, distributing or using 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. British > > > > >> >> Telecommunications plc Registered > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in > > > > >> >> England > > > > >> >no: > > > > >> >> 1800000 > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy) > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: 23 April 2014 13:36 > > > > >> >> To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Its not that the Measurement controller has to configure the > > > > >> >> timer for the > > > > >MA. > > > > >> >> > > > > >> >> If we do not specify the functions and variable names, the > > > > >> >> measurement controller doesn't have a standard way of configuring a timer. > > > > >> >> > > > > >> >> For example - If I specify for a Uniform distribution function > > > > >> >> called "Uniform" you have a variable called "UpperLimit", the > > > > >> >> MA will implement the specification; the controller will > > > > >> >> implement the > > > > >specification and things work. > > > > >> >> > > > > >> >> If I do not specify anything for the Uniform distribution > > > > >> >> function > > > > >> >> - MA vendor > > > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" and > > > > >> >> maybe an > > > > >"Enable" > > > > >> >> parameter for good measure; MA vendor 2 can call it "U" and > > > > >> >> have an attribute "X that is an integer". > > > > >> >> > > > > >> >> Now put that variation on steroids based on the number of MA > > > > >> >> vendors - That is why we specify things, right? > > > > >> >> > > > > >> >> BR, > > > > >> >> Tim > > > > >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > >> >> Sent: Wednesday, April 23, 2014 7:24 AM > > > > >> >> To: Carey, Timothy (Timothy); > > > > >> >> trevor.burbridge@bt.com; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> The measurement controller has to communicate what tests have > > > > >> >> to be run on > > > > >> >an > > > > >> >> MA, for how long, when to run them, what test results are > > > > >> >> generated, etc. Why would configuring this parameter be any > > > > >> >> different. Maybe I am missing > > > > >> >something. > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy) > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: Wednesday, April 23, 2014 8:16 AM > > > > >> >> To: Sharam Hakimi; > > > > >> >trevor.burbridge@bt.com; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> So the burden is on the Measurement controller to know the > > > > >> >> functions and inputs specifications for each possible MA > > > > >> >> vendor; not something I would want to have to do as a > > > > >> >> Measurement controller > > > > >vendor. > > > > >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > >> >> Sent: Wednesday, April 23, 2014 7:14 AM > > > > >> >> To: Carey, Timothy (Timothy); > > > > >> >> trevor.burbridge@bt.com; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> I do not see why vendor A or B or C matters. They would all be > > > > >> >> under the control of one Measurement Controller which would > > > > >> >> specify what inputs to use for all MAs in a group. > > > > >> >> > > > > >> >> As Trevor also mentioned this timer can be used for both > > > > >> >> testing and reporting and I would strongly suggest to have > > > > >> >> microsecond granularity. For reporting one could choose > > > > >> >> seconds in terms of > > > > >microseconds. > > > > >> >> > > > > >> >> Thanks, > > > > >> >> Sharam > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy) > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: Wednesday, April 23, 2014 8:04 AM > > > > >> >> To: trevor.burbridge@bt.com; > > > > >> >> Sharam > > > > >> >Hakimi; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Trevor, > > > > >> >> > > > > >> >> If we don't define the inputs for each function (leaving the > > > > >> >> inputs > > > > >> >> opaque) you will have interop problems. MA vendor 1 uses > > > > >> >> these 2 inputs > > > > >named "A" > > > > >> >and > > > > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" for the > > > > >> >> same > > > > >function. > > > > >> >> > > > > >> >> I think we need to avoid that if we realistically want the > > > > >> >> Randomness function to be used efficiently. > > > > >> >> > > > > >> >> BR, > > > > >> >> Tim > > > > >> >> > > > > >> >> From: trevor.burbridge@bt.com > > > > >> >[mailto:trevor.burbridge@bt.com] > > > > >> >> Sent: Wednesday, April 23, 2014 2:55 AM > > > > >> >> To: Carey, Timothy (Timothy); > > > > >> >> sharam.hakimi@exfo.com; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> The random timing can be used for both specifying when a test > > > > >> >> runs, or when a report is sent (or any other task such as > > > > >> >> contacting the Controller). It doesn't have to be used, but it can be. > > > > >> >> > > > > >> >> I don't really want different input variable for different > > > > >> >> functions. I don't see we need to. Also if we do, then we > > > > >> >> would have to have schema for each function to specify which > > > > >> >> inputs are expected (like the measurement task registry). I'd like to avoid > that. > > > > >> >> > > > > >> >> 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 not the intended recipient, note that disclosing, > > > > >> >> copying, distributing or using 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. British > > > > >> >> Telecommunications plc Registered > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in > > > > >> >> England > > > > >> >no: > > > > >> >> 1800000 > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy) > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: 22 April 2014 22:07 > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; > > > > >> >> Burbridge,T,Trevor, > > > > >> >> TUB8 R Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Sharam, > > > > >> >> > > > > >> >> We are talking about offsets for when to report; in the world > > > > >> >> we live in milliseconds is sufficient - IMHO. > > > > >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > >> >> Sent: Tuesday, April 22, 2014 3:59 PM > > > > >> >> To: Carey, Timothy (Timothy); > > > > >> >> lmap@ietf.org; > > > > >> >trevor.burbridge@bt.com > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Tim, > > > > >> >> I think the min/max should have microseconds granularity. > > > > >> >> Milliseconds would not be accurate enough. > > > > >> >> > > > > >> >> Personally, I would not trust my periodic tests in a large > > > > >> >> scale deployment to a random number generator and would want > > > > >> >> to know exactly how and when > > > > >> >tests > > > > >> >> would be run. > > > > >> >> > > > > >> >> Thanks, > > > > >> >> Sharam > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy) > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: Tuesday, April 22, 2014 3:16 PM > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; > > > > >> >trevor.burbridge@bt.com > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Trevor, > > > > >> >> > > > > >> >> The data model is extensible by vendors so we can add > > > > >> >> functions and input variables as we need. > > > > >> >> > > > > >> >> However we have to decide on which small subset we actually > > > > >> >> want to > > > > >> >standardize. > > > > >> >> > > > > >> >> You suggested the Uniform and Normal which is fine but for the > > > > >> >> model we need to go farther by defining the specific function > > > > >> >> along with which inputs are used by the function to derive > > > > >> >> what random number. Otherwise we will have 2 implementers of > > > > >> >> the same standard algorithm implement different variations. - Not good. > > > > >> >> > > > > >> >> So I suggest we keep this simple. > > > > >> >> > > > > >> >> Uniform Discrete - input variables - maximum [positive > > > > >> >> integer] Gaussian -input variables - mean of min/max, spread = > > > > >> >> standard deviation > > > > >> >> > > > > >> >> The min/max would be milliseconds - Spread would be an integer. > > > > >> >> > > > > >> >> This sound OK? > > > > >> >> > > > > >> >> BR > > > > >> >> Tim > > > > >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > >> >> Sent: Tuesday, April 22, 2014 8:23 AM > > > > >> >> To: Carey, Timothy (Timothy); > > > > >> >> lmap@ietf.org; > > > > >> >trevor.burbridge@bt.com > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Tim, > > > > >> >> I think the Periodic Timer distribution needs to have closer > > > > >> >> configuration control by the user and I think your 2nd choice > > > > >> >> attempts to provide it but having a discrete interval > > > > >> >> definition is a better way > > > > >to go. > > > > >> >> > > > > >> >> Sharam > > > > >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > > > > >> >trevor.burbridge@bt.com > > > > >> >> Sent: Tuesday, April 22, 2014 4:35 AM > > > > >> >> To: > > > > >> >> timothy.carey@alcatel-lucent.com > > > >> >lucent.com>; > > > > >> >> lmap@ietf.org Subject: Re: [lmap] Timer: > > > > >> >> Poisson distribution question > > > > >> >> > > > > >> >> On continuous counterparts of Poisson I'm far from any expert > > > > >> >> and it would certainly be up to the user to decide if such > > > > >> >> functions were suitable replacements for the discrete Poisson > > > > >> >> function. Yes it would be a different function even if there > > > > >> >> was perfect fit (which they are not) as one is continuous and one is > discrete: > > > > >> >> http://cmscience.blogspot.co.uk/2008/04/mt- > > > > >> >6- > > > > >> >> poisson-and-gamma-distribution.html > > > > >> >> http://arxiv.org/abs/1303.5990 > > > > >> >> > > > > >> >> As I tried to say the current Information Model can take > > > > >> >> either discrete or continuous functions - only that there is > > > > >> >> currently no explicit support for specifying the interval used > > > > >> >> for a discrete function. I was questioning the need to add this. > > > > >> >> > > > > >> >> Personally I'd think that Normal and Uniform distributions > > > > >> >> would cover most needs, but the framework should be flexible in this regard. > > > > >> >> > > > > >> >> Trevor. > > > > >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, > > > > >> >> Timothy > > > > >> >(Timothy) > > > > >> >> Sent: 19 April 2014 20:24 > > > > >> >> To: lmap@ietf.org > > > > >> >> Subject: [lmap] Timer: Poisson distribution question > > > > >> >> > > > > >> >> Team, > > > > >> >> > > > > >> >> The BBF is looking at standardizing the model for Timers as > > > > >> >> suggested by the IETF LMAP information model. > > > > >> >> > > > > >> >> During the review of the timers we had addition questions > > > > >> >> regarding Trevors response to the Poisson distribution for the > > > > >> >> Randomness of the > > > > >Periodic Timer. > > > > >> >> > > > > >> >> Trevor responded: > > > > >> >> > > > > >> >> "Yes this does need to be clarified. I was assuming a > > > > >> >> distribution about the mean (i.e. the timing given is the > > > > >> >> mean). The spread would be the standard deviation (could use > > > > >> >> mean deviation or something else but I see no advantage as > > > > >> >> long as we all know what it refers to) and need to change to a > > > > >> >> float. The upper and lower cuts would be in seconds +/- the > > > > >> >> mean (also needs to change > > > > >> >to > > > > >> >> float) and are simply used to trim the function - obviously > > > > >> >> needed on a uniform distribution but useful to constrain other functions. > > > > >> >> > > > > >> >> I will make all this clear in the next release. > > > > >> >> > > > > >> >> As for poisson I think there are 3 options: > > > > >> >> > > > > >> >> - Use a continuous form instead > > > > >> >> > > > > >> >> - Have the discrete interval implicit in the function choice > > > > >> >e.g."poisson_1_sec" > > > > >> >> > > > > >> >> - Add an interval to the information model. > > > > >> >> > > > > >> >> I was really thinking about the first, but I don't see the > > > > >> >> problem with the second. However I wouldn't do the third > > > > >> >> unless they was a demonstrable value to supporting discrete > > > > >> >> functions (rather than continuous > > > > >versions of them). " > > > > >> >> > > > > >> >> But as people looked at Trevors response there were additional questions: > > > > >> >> > > > > >> >> I don't understand what Trevor means about the Poisson > > > > >> >> distribution. As far as I know, it is a discrete > > > > >> >> distribution, so a "continuous form" would be a different > > > > >> >> distribution and not Poisson. And I believe that we do need a continuous > distribution. > > > > >> >> But what matters is that the definition is clear, not the > > > > >> >> particular > > > distribution > > > > >(I don't have an opinion on that). > > > > >> >> > > > > >> >> Could some please clarify this for us - Are we planning > > > > >> >> something other than Poisson method; better yet is there a > > > > >> >> definition for the types of > > > > >> >> distribution: Poisson, Normal and Uniform. > > > > >> >> > > > > >> >> Thanks, > > > > >> >> Tim > > > > >> > > > > > >> > > > > > >> >-- > > > > >> >Open WebMail Project (http://openwebmail.org) > > > > >> > > > > >> _______________________________________________ > > > > >> lmap mailing list > > > > >> lmap@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > > > > > >-- > > > > >Open WebMail Project (http://openwebmail.org) > > > > > > > > _______________________________________________ > > > > lmap mailing list > > > > lmap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > -- > > > Open WebMail Project (http://openwebmail.org) > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > 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 > > -- > Open WebMail Project (http://openwebmail.org) -- Open WebMail Project (http://openwebmail.org) From nobody Sat May 10 13:44:19 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 80E711A00E8 for ; Sat, 10 May 2014 13:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-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 VgBnNgEOjCt4 for ; Sat, 10 May 2014 13:44:12 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 546321A00C9 for ; Sat, 10 May 2014 13:44:12 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4AKhvas012079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 May 2014 15:43:57 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s4AKhunO022359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 May 2014 16:43:56 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Sat, 10 May 2014 16:43:56 -0400 From: "Carey, Timothy (Timothy)" To: "marc.ibrahim" , KEN KO , "Sharam Hakimi" , Juergen Schoenwaelder Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAMH2AAABWvrAAAELs4AAIod6AAAAj6gAAAZ1bAAAAx60AAAFrJIAAAEmdgAAIBF/A///+ooCAAEZwgIAA3ImA/+awS0CAMvsTgIAAPebw Date: Sat, 10 May 2014 20:43:54 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771954016F@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> <20140423145224.M63656@usj.edu.lb> <20140423151059.GE1056@elstar.local> <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> <20140423221748.M2036@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcate l-lucent.com> <20140510193741.M70435@usj.edu.lb> In-Reply-To: <20140510193741.M70435@usj.edu.lb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] 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/BIJgtn1kOCTU016N_-wP7-7HiWM Cc: "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Timer: Poisson distribution question 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: Sat, 10 May 2014 20:44:16 -0000 Marc, So we can do Xmin + spread or Xmax - spread or Xmax-Xmin but you need the o= ffset from Ti to allow for a negative spread from Ti, right? BR, Tim -----Original Message----- From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb]=20 Sent: Saturday, May 10, 2014 3:17 PM To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen Schoenwaelder Cc: trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Tim, > While you are correct in your assumption the Ti isn't really known when y= ou=20 > setup the timer (which also could be used for multiple Tis). So I plan to= keep=20 > what Marc was saying. I agree with Ken that Xmin is superfluous. The essential parameter is the s= pread. I=20 suggested Xmin just to be able to control the spread around Ti, but this i= s not really=20 important. We can just say that the time values will be chosen between Ti a= nd Ti+spread. > My question to the group is should we limit the Randomness to just the=20 > distribution to what Marc suggested or should we keep the capability for= =20 > multiple distributions. As the draft says, the goal of randomness is to spread the load by preventi= ng multiple=20 events from occurring simultaneously. Given the spread interval, the unifor= m=20 distribution is mathematically the best to achieve it. I don't see why we s= hould use =20 normal distribution, which will tend to concentrate values around some mean= . >If so is this the Uniform-Discrete distribution? I suggested to express the randomness as an integer number of milliseconds.= So the=20 answer is yes. Finally, I would like to add a comment about the Poisson distribution that = was the=20 initial cause of this discussion about timer. I think that there was a conf= usion with=20 the Poisson process used to randomize the instants of packets transmission = in active=20 measurements. In fact, Poisson in measurement context is a process describi= ng the=20 occurrence of events and not a probability distribution for a time interval= (the related=20 distribution is exponential as explained below). So, if a Poisson process i= s to be used=20 in lmap context, it applies in my opinion only to periodic schedules as fol= lows: - The period specified in the timing object is in fact an average perio= d. For=20 example, if an MA event occurs at Ti, the next event will occur in average = at Ti+period =20 - After an event occurs at Ti, the MA will choose a real number X accor= ding to an=20 exponential distribution of mean =3D period. Next event will then occur at = Ti+X. - When the inter-event time is exponential, the whole process is known = as a Poisson=20 process of rate =3D 1/period.=20 - In this approach, we do not specify a spread around predefined instan= ts Tis. We=20 rather randomize the whole interval separating two consecutive Tis. This could be another viable (but may be more complicated??) approach for p= eriodic=20 events.=20 BR, Marc. On Sat, 10 May 2014 18:52:50 +0000, Carey, Timothy (Timothy) wrote > Ken, >=20 > I am in the process of commenting on the BBF model TR-181i2a8 for StrawBa= llot. > While you are correct in your assumption the Ti isn't really known when y= ou=20 > setup the timer (which also could be used for multiple Tis). So I plan to= keep=20 > what Marc was saying. >=20 > My question to the group is should we limit the Randomness to just the=20 > distribution to what Marc suggested or should we keep the capability for= =20 > multiple distributions. - If so is this the Uniform-Discrete distribution= ? >=20 > Thanks, > Tim >=20 > -----Original Message----- > From: KEN KO [mailto:KEN.KO@adtran.com]=20 > Sent: Thursday, April 24, 2014 7:17 AM > To: marc.ibrahim; Sharam Hakimi; Juergen Schoenwaelder > Cc: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org > Subject: RE: [lmap] Timer: Poisson distribution question >=20 > Since Ti+Xmin is non-random, Xmin is not really needed as a separate=20 > parameter. Just offset Ti to the desired minimum time and let the spread = range=20 > from Ti to Ti+Xmax. >=20 > Other than that nit, +1 >=20 > -----Original Message----- > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb]=20 > Sent: Wednesday, April 23, 2014 7:08 PM > To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; lmap@ietf.= org > Subject: Re: [lmap] Timer: Poisson distribution question >=20 > Based on what has been exchanged, I suggest the following: >=20 > 1- Exact randomness definition and operation > -------------------------------------------- > IMHO, we need to define how exactly the randomness is applied. >=20 > For a given event E (e.g. running a measurement task, start reporting,...= ), > let Ti be the predefined (scheduled) instant of the ith occurrence of E.= =20 > Adding randomness means that the event E will happen at time Ti + X inste= ad of=20 > Ti, where X is a random variable. If Xmin and Xmax denote the minimum and= =20 > maximum possible values of X repectively, then the event E will take plac= e at=20 > an instant randomly chosen between Ti+Xmin and Ti+Xmax. The spread is equ= al to=20 > Xmax-Xmin >=20 > Ti+Xmin Ti Ti+Xmax > ---------|-----------------|-------------------|----------- >=20 > <-------------------------------------> > Spread >=20 > Note that Xmin could be negative if E can occur before Ti like in the fig= ure.=20 > I think that the most common values of Xmin would be 0 or (-spread/2). >=20 > 2- Random generation of X > --------------------------- > To make it simple as stated by many, X could an integer number of millise= conds=20 > uniformly chosen in the interval [Xmin, Xmax]. Xmin, Xmax, and hence spre= ad,=20 > are all integers (milliseconds). >=20 > Then the MA has to define a function UNIF(Xmin, Xmax) or equivalently=20 > UNIF(Xmin, spread) that generates a random number of milliseconds from [X= min, > Xmax] interval. The controller has just to send two integer variables (X= min, > Xmax) or (Xmin, spread) to the MA in the timing object. >=20 > In this minimalist approach, no need to specify the nature of distributio= n in=20 > the timing object since it is assumed to be the uniform one. >=20 > BR, >=20 > Marc. >=20 > On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote > > This example confuses resolution of the measurement result with resolut= ion and=20 > > accuracy of the time at which the measurement is initiated. Measuring r= ound=20 > > trip latencies on a Gigabit LAN may well require microsecond resolution= , which=20 > > could be within the capabilities of a higher end MA. But that doesn't r= equire=20 > > microsecond resolution of the time at which the measurement is initiate= d. In=20 > > addition, for microsecond resolution on the Timer to be meaningful woul= d=20 > > require synchronization to that resolution across different MAs in the = network. > >=20 > > I'm in favor of keeping things simple and specifying Timer resolution i= n=20 milliseconds. > >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi > > Sent: Wednesday, April 23, 2014 11:33 AM > > To: Juergen Schoenwaelder; marc.ibrahim > > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; lmap@iet= f.org > > Subject: Re: [lmap] Timer: Poisson distribution question > >=20 > > It depends what the performance goal of the measurement is. A ping pack= et in a=20 > > Gigabit network is just under 1 microseconds and with fast processors a= packet=20 > > can be sent and received at the same time if granularity is millisecond= s. > >=20 > > This does not even take into account 10Gig networks, not that they woul= d be at=20 > > consumer sites, but they would sure exist inside a ISP network. > >=20 > > Sharam > >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e] > > Sent: Wednesday, April 23, 2014 11:11 AM > > To: marc.ibrahim > > Cc: trevor.burbridge@bt.com; Sharam Hakimi; timothy.carey@alcatel-lucen= t.com;=20 > lmap@ietf.org > > Subject: Re: [lmap] Timer: Poisson distribution question > >=20 > > I believe randomization with a granularity of milliseconds is good enou= gh.=20 > > Within an implementation of a measurement task, one may use more precis= e=20 > > timers. But for the randomization of the start of measurement tasks or = the=20 > > sending of reports, milliseconds seem to be sufficient (since there wil= l be=20 > > likely other delays introduced by the operating system that may get int= o the=20 > > some order for starting a measurement task or triggering a report). > >=20 > > /js > >=20 > > On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote: > > > I would say that choosing the millisecond as atomic time alleviates=20 > > > constraints on both timer granularity and generator capacity. > > >=20 > > > I still don't see a real measurement example where few microseconds w= ould really=20 > matter. > > >=20 > > > Practically, can a program deal with microseconds timers in computers= and=20 > smartphones?=20 > > > This is the scale of the OS, no? > > >=20 > > > Marc. > > >=20 > > > On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote > > > > So the question is really do we want to design for extremely=20 > > > > constrained devices? I'd argue that if this is a problem for them=20 > > > > then they are really going to struggle with the Instruction informa= tion or=20 > measurement results. > > > >=20 > > > > Trevor. > > > >=20 > > > > >-----Original Message----- > > > > >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > > > > >Sent: 23 April 2014 15:00 > > > > >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com;=20 > > > > >timothy.carey@alcatel-lucent.com; lmap@ietf.org > > > > >Subject: Re: [lmap] Timer: Poisson distribution question > > > > > > > > > >Here is how I see the problem. > > > > > > > > > >First we have to separate time granularity and random generation. > > > > > > > > > >Time granularity depends on the timer running on the MA. e.g=20 > > > > >microseconds scale means that the MA timer increment each microsec= ond. > > > > > > > > > >When MA wants to generate a random time, he has to choose an=20 > > > > >integer number of microseconds to count. So the problem is always= =20 > > > > >an integer (discrete) number generation. > > > > > > > > > >Now, if the random generator can attain the maximum integer (so th= e=20 > > > > >maximum possible random time), then, as Trevor says, no need for=20 > > > > >the timeStep I talked about, since all possible durations will be = expressed as=20 > multiple of microseconds. > > > > > > > > > > > > > > >For example, a 32 bits random generator could generate up to a=20 > > > > >maximum value of 4 billions. In microseconds, this is equal to les= s than 2=20 hours. > > > > > > > > > >It all depends on the capacity of the generator. > > > > >Marc. > > > > > > > > > > > > > > >On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote > > > > >> So what is the argument for the latter (discrete) option? > > > > >> > > > > >> Trevor. > > > > >> > > > > >> >-----Original Message----- > > > > >> >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > > > > >> >Sent: 23 April 2014 14:10 > > > > >> >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com;=20 > > > > >> >timothy.carey@alcatel-lucent.com; lmap@ietf.org > > > > >> >Subject: Re: [lmap] Timer: Poisson distribution question > > > > >> > > > > > >> >Trevor, you're right. > > > > >> >it is just about whether we want a discrete or continuous gener= ator. > > > > >> >If we use a continuous uniform generator, than it is enough to= =20 > > > > >> >specify the maximum time. > > > > >> >With a discrete random generator, you need to specify an=20 > > > > >> >additional time granularity. > > > > >> > > > > > >> >BR, > > > > >> > > > > > >> >Marc. > > > > >> > > > > > >> > > > > > >> >On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote > > > > >> >> I'm not sure I get the point of allowing coarser granularity= =20 > > > > >> >> that the MA is capable of. If I want the MA to test/report=20 > > > > >> >> sometime within a minute window, why not allow that to happen= =20 > > > > >> >> with the maximum resolution the MA is capable > > > > >> >of? > > > > >> >> > > > > >> >> Trevor. > > > > >> >> > > > > >> >> Trevor Burbridge > > > > >> >> Network Infrastructure & Innovation | BT Innovate & Design > > > > >> >> Tel: 01473 645115 > > > > >> >> Fax: 01473 640929 > > > > >> >> > > > > >> >> This email contains BT information, which may be privileged o= r=20 confidential. > > > > >> >> It's meant only for the individual(s) or entity named above.= =20 > > > > >> >> If you're not the intended recipient, note that disclosing,=20 > > > > >> >> copying, distributing or using this information is prohibited= .=20 > > > > >> >> If you've received this email in error, please let me know=20 > > > > >> >> immediately on the email address above. Thank you. We monitor= =20 > > > > >> >> our email system, and may record your emails. British=20 > > > > >> >> Telecommunications plc Registered > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in=20 > > > > >> >> England > > > > >> >no: > > > > >> >> 1800000 > > > > >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam= =20 > > > > >> >> Hakimi > > > > >> >> Sent: 23 April 2014 13:58 > > > > >> >> To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R;=20 > > > > >> >> lmap@ietf.org > > > > >> >> Subject: Re: [lmap] Timer: Poisson distribution question > > > > >> >> > > > > >> >> Marc's suggestion works for me. That allows better=20 > > > > >> >> interoperability in my > > > > >> >opinion. > > > > >> >> > > > > >> >> I do agree that we need a common "structure" and "names". > > > > >> >> > > > > >> >> Thanks, > > > > >> >> Sharam > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy)=20 > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: Wednesday, April 23, 2014 8:47 AM > > > > >> >> To: trevor.burbridge@bt.com;= =20 > > > > >> >> Sharam > > > > >> >Hakimi; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Trevor, > > > > >> >> > > > > >> >> No - I am using the variable of your Information Model=20 > > > > >> >> (LowerLimit, > > > > >> >UpperLimit, > > > > >> >> Spread) - works so far. Marc suggested a TimeStep parameter= =20 > > > > >> >> so we don't lockin on a specific microsecond, millisecond,=20 > > > > >> >> second thing - I am open > > > > >to that. > > > > >> >> > > > > >> >> BR, > > > > >> >> Tim > > > > >> >> > > > > >> >> From: trevor.burbridge@bt.com > > > > >> >[mailto:trevor.burbridge@bt.com] > > > > >> >> Sent: Wednesday, April 23, 2014 7:41 AM > > > > >> >> To: Carey, Timothy (Timothy); > > > > >> >> sharam.hakimi@exfo.com; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Agree we need to have well defined function names. I thought= =20 > > > > >> >> you were also suggesting different functions needed different= input=20 > parameters. > > > > >> >> > > > > >> >> Trevor. > > > > >> >> > > > > >> >> Trevor Burbridge > > > > >> >> Network Infrastructure & Innovation | BT Innovate & Design > > > > >> >> Tel: 01473 645115 > > > > >> >> Fax: 01473 640929 > > > > >> >> > > > > >> >> This email contains BT information, which may be privileged o= r=20 confidential. > > > > >> >> It's meant only for the individual(s) or entity named above.= =20 > > > > >> >> If you're not the intended recipient, note that disclosing,=20 > > > > >> >> copying, distributing or using this information is prohibited= .=20 > > > > >> >> If you've received this email in error, please let me know=20 > > > > >> >> immediately on the email address above. Thank you. We monitor= =20 > > > > >> >> our email system, and may record your emails. British=20 > > > > >> >> Telecommunications plc Registered > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in=20 > > > > >> >> England > > > > >> >no: > > > > >> >> 1800000 > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy)=20 > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: 23 April 2014 13:36 > > > > >> >> To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Its not that the Measurement controller has to configure the= =20 > > > > >> >> timer for the > > > > >MA. > > > > >> >> > > > > >> >> If we do not specify the functions and variable names, the=20 > > > > >> >> measurement controller doesn't have a standard way of configu= ring a timer. > > > > >> >> > > > > >> >> For example - If I specify for a Uniform distribution functio= n=20 > > > > >> >> called "Uniform" you have a variable called "UpperLimit", th= e=20 > > > > >> >> MA will implement the specification; the controller will=20 > > > > >> >> implement the > > > > >specification and things work. > > > > >> >> > > > > >> >> If I do not specify anything for the Uniform distribution=20 > > > > >> >> function > > > > >> >> - MA vendor > > > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" and= =20 > > > > >> >> maybe an > > > > >"Enable" > > > > >> >> parameter for good measure; MA vendor 2 can call it "U" and=20 > > > > >> >> have an attribute "X that is an integer". > > > > >> >> > > > > >> >> Now put that variation on steroids based on the number of MA= =20 > > > > >> >> vendors - That is why we specify things, right? > > > > >> >> > > > > >> >> BR, > > > > >> >> Tim > > > > >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > >> >> Sent: Wednesday, April 23, 2014 7:24 AM > > > > >> >> To: Carey, Timothy (Timothy); > > > > >> >> trevor.burbridge@bt.com; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> The measurement controller has to communicate what tests have= =20 > > > > >> >> to be run on > > > > >> >an > > > > >> >> MA, for how long, when to run them, what test results are=20 > > > > >> >> generated, etc. Why would configuring this parameter be any=20 > > > > >> >> different. Maybe I am missing > > > > >> >something. > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy)=20 > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: Wednesday, April 23, 2014 8:16 AM > > > > >> >> To: Sharam Hakimi; > > > > >> >trevor.burbridge@bt.com; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> So the burden is on the Measurement controller to know the=20 > > > > >> >> functions and inputs specifications for each possible MA=20 > > > > >> >> vendor; not something I would want to have to do as a=20 > > > > >> >> Measurement controller > > > > >vendor. > > > > >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > >> >> Sent: Wednesday, April 23, 2014 7:14 AM > > > > >> >> To: Carey, Timothy (Timothy); > > > > >> >> trevor.burbridge@bt.com; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> I do not see why vendor A or B or C matters. They would all b= e=20 > > > > >> >> under the control of one Measurement Controller which would=20 > > > > >> >> specify what inputs to use for all MAs in a group. > > > > >> >> > > > > >> >> As Trevor also mentioned this timer can be used for both=20 > > > > >> >> testing and reporting and I would strongly suggest to have=20 > > > > >> >> microsecond granularity. For reporting one could choose=20 > > > > >> >> seconds in terms of > > > > >microseconds. > > > > >> >> > > > > >> >> Thanks, > > > > >> >> Sharam > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy)=20 > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: Wednesday, April 23, 2014 8:04 AM > > > > >> >> To: trevor.burbridge@bt.com;= =20 > > > > >> >> Sharam > > > > >> >Hakimi; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Trevor, > > > > >> >> > > > > >> >> If we don't define the inputs for each function (leaving the= =20 > > > > >> >> inputs > > > > >> >> opaque) you will have interop problems. MA vendor 1 uses=20 > > > > >> >> these 2 inputs > > > > >named "A" > > > > >> >and > > > > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" for the= =20 > > > > >> >> same > > > > >function. > > > > >> >> > > > > >> >> I think we need to avoid that if we realistically want the=20 > > > > >> >> Randomness function to be used efficiently. > > > > >> >> > > > > >> >> BR, > > > > >> >> Tim > > > > >> >> > > > > >> >> From: trevor.burbridge@bt.com > > > > >> >[mailto:trevor.burbridge@bt.com] > > > > >> >> Sent: Wednesday, April 23, 2014 2:55 AM > > > > >> >> To: Carey, Timothy (Timothy); > > > > >> >> sharam.hakimi@exfo.com; > > > > >> >lmap@ietf.org > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> The random timing can be used for both specifying when a test= =20 > > > > >> >> runs, or when a report is sent (or any other task such as=20 > > > > >> >> contacting the Controller). It doesn't have to be used, but i= t can be. > > > > >> >> > > > > >> >> I don't really want different input variable for different=20 > > > > >> >> functions. I don't see we need to. Also if we do, then we=20 > > > > >> >> would have to have schema for each function to specify which= =20 > > > > >> >> inputs are expected (like the measurement task registry). I'd= like to=20 avoid=20 > that. > > > > >> >> > > > > >> >> Trevor. > > > > >> >> > > > > >> >> Trevor Burbridge > > > > >> >> Network Infrastructure & Innovation | BT Innovate & Design > > > > >> >> Tel: 01473 645115 > > > > >> >> Fax: 01473 640929 > > > > >> >> > > > > >> >> This email contains BT information, which may be privileged o= r=20 confidential. > > > > >> >> It's meant only for the individual(s) or entity named above.= =20 > > > > >> >> If you're not the intended recipient, note that disclosing,=20 > > > > >> >> copying, distributing or using this information is prohibited= .=20 > > > > >> >> If you've received this email in error, please let me know=20 > > > > >> >> immediately on the email address above. Thank you. We monitor= =20 > > > > >> >> our email system, and may record your emails. British=20 > > > > >> >> Telecommunications plc Registered > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in=20 > > > > >> >> England > > > > >> >no: > > > > >> >> 1800000 > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy)=20 > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: 22 April 2014 22:07 > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; > > > > >> >> Burbridge,T,Trevor, > > > > >> >> TUB8 R Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Sharam, > > > > >> >> > > > > >> >> We are talking about offsets for when to report; in the world= =20 > > > > >> >> we live in milliseconds is sufficient - IMHO. > > > > >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > >> >> Sent: Tuesday, April 22, 2014 3:59 PM > > > > >> >> To: Carey, Timothy (Timothy);=20 > > > > >> >> lmap@ietf.org; > > > > >> >trevor.burbridge@bt.com > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Tim, > > > > >> >> I think the min/max should have microseconds granularity. > > > > >> >> Milliseconds would not be accurate enough. > > > > >> >> > > > > >> >> Personally, I would not trust my periodic tests in a large=20 > > > > >> >> scale deployment to a random number generator and would want= =20 > > > > >> >> to know exactly how and when > > > > >> >tests > > > > >> >> would be run. > > > > >> >> > > > > >> >> Thanks, > > > > >> >> Sharam > > > > >> >> > > > > >> >> From: Carey, Timothy (Timothy)=20 > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > >> >> Sent: Tuesday, April 22, 2014 3:16 PM > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; > > > > >> >trevor.burbridge@bt.com > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Trevor, > > > > >> >> > > > > >> >> The data model is extensible by vendors so we can add=20 > > > > >> >> functions and input variables as we need. > > > > >> >> > > > > >> >> However we have to decide on which small subset we actually=20 > > > > >> >> want to > > > > >> >standardize. > > > > >> >> > > > > >> >> You suggested the Uniform and Normal which is fine but for th= e=20 > > > > >> >> model we need to go farther by defining the specific function= =20 > > > > >> >> along with which inputs are used by the function to derive=20 > > > > >> >> what random number. Otherwise we will have 2 implementers of= =20 > > > > >> >> the same standard algorithm implement different variations. -= Not good. > > > > >> >> > > > > >> >> So I suggest we keep this simple. > > > > >> >> > > > > >> >> Uniform Discrete - input variables - maximum [positive=20 > > > > >> >> integer] Gaussian -input variables - mean of min/max, spread = =3D=20 > > > > >> >> standard deviation > > > > >> >> > > > > >> >> The min/max would be milliseconds - Spread would be an intege= r. > > > > >> >> > > > > >> >> This sound OK? > > > > >> >> > > > > >> >> BR > > > > >> >> Tim > > > > >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > >> >> Sent: Tuesday, April 22, 2014 8:23 AM > > > > >> >> To: Carey, Timothy (Timothy);=20 > > > > >> >> lmap@ietf.org; > > > > >> >trevor.burbridge@bt.com > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > >> >> > > > > >> >> Tim, > > > > >> >> I think the Periodic Timer distribution needs to have closer= =20 > > > > >> >> configuration control by the user and I think your 2nd choic= e=20 > > > > >> >> attempts to provide it but having a discrete interval=20 > > > > >> >> definition is a better way > > > > >to go. > > > > >> >> > > > > >> >> Sharam > > > > >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > > > > >> >trevor.burbridge@bt.com > > > > >> >> Sent: Tuesday, April 22, 2014 4:35 AM > > > > >> >> To:=20 > > > > >> >> timothy.carey@alcatel-lucent.com > > > >> >lucent.com>; > > > > >> >> lmap@ietf.org Subject: Re: [lmap] Timer= : > > > > >> >> Poisson distribution question > > > > >> >> > > > > >> >> On continuous counterparts of Poisson I'm far from any expert= =20 > > > > >> >> and it would certainly be up to the user to decide if such=20 > > > > >> >> functions were suitable replacements for the discrete Poisson= =20 > > > > >> >> function. Yes it would be a different function even if there= =20 > > > > >> >> was perfect fit (which they are not) as one is continuous and= one is=20 > discrete: > > > > >> >> http://cmscience.blogspot.co.uk/2008/04/mt- > > > > >> >6- > > > > >> >> poisson-and-gamma-distribution.html=20 > > > > >> >> http://arxiv.org/abs/1303.5990 > > > > >> >> > > > > >> >> As I tried to say the current Information Model can take=20 > > > > >> >> either discrete or continuous functions - only that there is= =20 > > > > >> >> currently no explicit support for specifying the interval use= d=20 > > > > >> >> for a discrete function. I was questioning the need to add th= is. > > > > >> >> > > > > >> >> Personally I'd think that Normal and Uniform distributions=20 > > > > >> >> would cover most needs, but the framework should be flexible = in this=20 regard. > > > > >> >> > > > > >> >> Trevor. > > > > >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey,= =20 > > > > >> >> Timothy > > > > >> >(Timothy) > > > > >> >> Sent: 19 April 2014 20:24 > > > > >> >> To: lmap@ietf.org > > > > >> >> Subject: [lmap] Timer: Poisson distribution question > > > > >> >> > > > > >> >> Team, > > > > >> >> > > > > >> >> The BBF is looking at standardizing the model for Timers as=20 > > > > >> >> suggested by the IETF LMAP information model. > > > > >> >> > > > > >> >> During the review of the timers we had addition questions=20 > > > > >> >> regarding Trevors response to the Poisson distribution for th= e=20 > > > > >> >> Randomness of the > > > > >Periodic Timer. > > > > >> >> > > > > >> >> Trevor responded: > > > > >> >> > > > > >> >> "Yes this does need to be clarified. I was assuming a=20 > > > > >> >> distribution about the mean (i.e. the timing given is the=20 > > > > >> >> mean). The spread would be the standard deviation (could use= =20 > > > > >> >> mean deviation or something else but I see no advantage as=20 > > > > >> >> long as we all know what it refers to) and need to change to = a=20 > > > > >> >> float. The upper and lower cuts would be in seconds +/- the=20 > > > > >> >> mean (also needs to change > > > > >> >to > > > > >> >> float) and are simply used to trim the function - obviously=20 > > > > >> >> needed on a uniform distribution but useful to constrain othe= r functions. > > > > >> >> > > > > >> >> I will make all this clear in the next release. > > > > >> >> > > > > >> >> As for poisson I think there are 3 options: > > > > >> >> > > > > >> >> - Use a continuous form instead > > > > >> >> > > > > >> >> - Have the discrete interval implicit in the function = choice > > > > >> >e.g."poisson_1_sec" > > > > >> >> > > > > >> >> - Add an interval to the information model. > > > > >> >> > > > > >> >> I was really thinking about the first, but I don't see the=20 > > > > >> >> problem with the second. However I wouldn't do the third=20 > > > > >> >> unless they was a demonstrable value to supporting discrete=20 > > > > >> >> functions (rather than continuous > > > > >versions of them). " > > > > >> >> > > > > >> >> But as people looked at Trevors response there were additiona= l questions: > > > > >> >> > > > > >> >> I don't understand what Trevor means about the Poisson=20 > > > > >> >> distribution. As far as I know, it is a discrete=20 > > > > >> >> distribution, so a "continuous form" would be a different=20 > > > > >> >> distribution and not Poisson. And I believe that we do need = a continuous=20 > distribution. > > > > >> >> But what matters is that the definition is clear, not the=20 > > > > >> >> particular > > > distribution > > > > >(I don't have an opinion on that). > > > > >> >> > > > > >> >> Could some please clarify this for us - Are we planning=20 > > > > >> >> something other than Poisson method; better yet is there a=20 > > > > >> >> definition for the types of > > > > >> >> distribution: Poisson, Normal and Uniform. > > > > >> >> > > > > >> >> Thanks, > > > > >> >> Tim > > > > >> > > > > > >> > > > > > >> >-- > > > > >> >Open WebMail Project (http://openwebmail.org) > > > > >> > > > > >> _______________________________________________ > > > > >> lmap mailing list > > > > >> lmap@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > > > > > >-- > > > > >Open WebMail Project (http://openwebmail.org) > > > >=20 > > > > _______________________________________________ > > > > lmap mailing list > > > > lmap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/lmap > > >=20 > > >=20 > > > -- > > > Open WebMail Project (http://openwebmail.org) > > >=20 > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > >=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 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > -- > Open WebMail Project (http://openwebmail.org) -- Open WebMail Project (http://openwebmail.org) From nobody Sat May 10 14:03: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 963D91A00D7 for ; Sat, 10 May 2014 14:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.048 X-Spam-Level: * X-Spam-Status: No, score=1.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.651, 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 pHixUK75O0Lu for ; Sat, 10 May 2014 14:03:35 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id B231D1A001B for ; Sat, 10 May 2014 14:03:34 -0700 (PDT) X-ASG-Debug-ID: 1399755936-05fac1101377efb0001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id nVpKYg8Vvpl1CGoE; Sun, 11 May 2014 00:05:36 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from usj.edu.lb (localhost.localdomain [127.0.0.1]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4AL3EMn013492; Sun, 11 May 2014 00:03:16 +0300 From: "marc.ibrahim" To: "Carey, Timothy (Timothy)" , KEN KO , "Sharam Hakimi" , Juergen Schoenwaelder Date: Sun, 11 May 2014 00:03:14 +0300 X-ASG-Orig-Subj: RE: [lmap] Timer: Poisson distribution question Message-Id: <20140510205713.M39371@usj.edu.lb> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771954016F@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> <20140423145224.M63656@usj.edu.lb> <20140423151059.GE1056@elstar.local> <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> <20140423221748.M2036@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcate l-lucent.com> <20140510193741.M70435@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954016F@US70UWXCHMBA05.zam.alcatel-lucent.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 46.19.194.254 (marc.ibrahim) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1399755936 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.5703 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9vX4mh93dkYikwdPto_hZtbQbvM Cc: "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Timer: Poisson distribution question 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: Sat, 10 May 2014 21:03:40 -0000 The simplest to do, is to spread starting from Ti. So, all you need is to specify only one parameter: the spread. random values will be picked from between Ti and Ti+spread. If you want to control spread position, then yes, you need an offset parameter. Random values will then be picked between Ti+offset and Ti+offset + spread. BR, Marc. On Sat, 10 May 2014 20:43:54 +0000, Carey, Timothy (Timothy) wrote > Marc, > > So we can do Xmin + spread or Xmax - spread or Xmax-Xmin but you need the > offset from Ti to allow for a negative spread from Ti, right? > > BR, > Tim > > -----Original Message----- > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > Sent: Saturday, May 10, 2014 3:17 PM > To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen Schoenwaelder > Cc: trevor.burbridge@bt.com; lmap@ietf.org > Subject: RE: [lmap] Timer: Poisson distribution question > > Tim, > > > While you are correct in your assumption the Ti isn't really known when you > > setup the timer (which also could be used for multiple Tis). So I plan to keep > > what Marc was saying. > > I agree with Ken that Xmin is superfluous. The essential parameter is the > spread. I suggested Xmin just to be able to control the spread around Ti, but > this is not really important. We can just say that the time values will be > chosen between Ti and Ti+spread. > > > My question to the group is should we limit the Randomness to just the > > distribution to what Marc suggested or should we keep the capability for > > multiple distributions. > > As the draft says, the goal of randomness is to spread the load by preventing > multiple events from occurring simultaneously. Given the spread interval, the > uniform distribution is mathematically the best to achieve it. I don't see why > we should use normal distribution, which will tend to concentrate values > around some mean. > > >If so is this the Uniform-Discrete distribution? > > I suggested to express the randomness as an integer number of milliseconds. So > the answer is yes. > > Finally, I would like to add a comment about the Poisson distribution that was > the initial cause of this discussion about timer. I think that there was a > confusion with the Poisson process used to randomize the instants of packets > transmission in active measurements. In fact, Poisson in measurement context > is a process describing the occurrence of events and not a probability > distribution for a time interval (the related distribution is exponential as > explained below). So, if a Poisson process is to be used in lmap context, it > applies in my opinion only to periodic schedules as follows: > > - The period specified in the timing object is in fact an average period. > For example, if an MA event occurs at Ti, the next event will occur in average > at Ti+period > > - After an event occurs at Ti, the MA will choose a real number X > according to an exponential distribution of mean = period. Next event will > then occur at Ti+X. > > - When the inter-event time is exponential, the whole process is known as > a Poisson process of rate = 1/period. > > - In this approach, we do not specify a spread around predefined instants > Tis. We rather randomize the whole interval separating two consecutive Tis. > > This could be another viable (but may be more complicated??) approach for > periodic events. > > BR, > > Marc. > > On Sat, 10 May 2014 18:52:50 +0000, Carey, Timothy (Timothy) wrote > > Ken, > > > > I am in the process of commenting on the BBF model TR-181i2a8 for StrawBallot. > > While you are correct in your assumption the Ti isn't really known when you > > setup the timer (which also could be used for multiple Tis). So I plan to keep > > what Marc was saying. > > > > My question to the group is should we limit the Randomness to just the > > distribution to what Marc suggested or should we keep the capability for > > multiple distributions. - If so is this the Uniform-Discrete distribution? > > > > Thanks, > > Tim > > > > -----Original Message----- > > From: KEN KO [mailto:KEN.KO@adtran.com] > > Sent: Thursday, April 24, 2014 7:17 AM > > To: marc.ibrahim; Sharam Hakimi; Juergen Schoenwaelder > > Cc: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org > > Subject: RE: [lmap] Timer: Poisson distribution question > > > > Since Ti+Xmin is non-random, Xmin is not really needed as a separate > > parameter. Just offset Ti to the desired minimum time and let the spread range > > from Ti to Ti+Xmax. > > > > Other than that nit, +1 > > > > -----Original Message----- > > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > > Sent: Wednesday, April 23, 2014 7:08 PM > > To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder > > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; lmap@ietf.org > > Subject: Re: [lmap] Timer: Poisson distribution question > > > > Based on what has been exchanged, I suggest the following: > > > > 1- Exact randomness definition and operation > > -------------------------------------------- > > IMHO, we need to define how exactly the randomness is applied. > > > > For a given event E (e.g. running a measurement task, start reporting,...), > > let Ti be the predefined (scheduled) instant of the ith occurrence of E. > > Adding randomness means that the event E will happen at time Ti + X instead of > > Ti, where X is a random variable. If Xmin and Xmax denote the minimum and > > maximum possible values of X repectively, then the event E will take place at > > an instant randomly chosen between Ti+Xmin and Ti+Xmax. The spread is equal to > > Xmax-Xmin > > > > Ti+Xmin Ti Ti+Xmax > > ---------|-----------------|-------------------|----------- > > > > <-------------------------------------> > > Spread > > > > Note that Xmin could be negative if E can occur before Ti like in the figure. > > I think that the most common values of Xmin would be 0 or (-spread/2). > > > > 2- Random generation of X > > --------------------------- > > To make it simple as stated by many, X could an integer number of milliseconds > > uniformly chosen in the interval [Xmin, Xmax]. Xmin, Xmax, and hence spread, > > are all integers (milliseconds). > > > > Then the MA has to define a function UNIF(Xmin, Xmax) or equivalently > > UNIF(Xmin, spread) that generates a random number of milliseconds from [Xmin, > > Xmax] interval. The controller has just to send two integer variables (Xmin, > > Xmax) or (Xmin, spread) to the MA in the timing object. > > > > In this minimalist approach, no need to specify the nature of distribution in > > the timing object since it is assumed to be the uniform one. > > > > BR, > > > > Marc. > > > > On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote > > > This example confuses resolution of the measurement result with resolution and > > > accuracy of the time at which the measurement is initiated. Measuring round > > > trip latencies on a Gigabit LAN may well require microsecond resolution, which > > > could be within the capabilities of a higher end MA. But that doesn't require > > > microsecond resolution of the time at which the measurement is initiated. In > > > addition, for microsecond resolution on the Timer to be meaningful would > > > require synchronization to that resolution across different MAs in the network. > > > > > > I'm in favor of keeping things simple and specifying Timer resolution in > milliseconds. > > > > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi > > > Sent: Wednesday, April 23, 2014 11:33 AM > > > To: Juergen Schoenwaelder; marc.ibrahim > > > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; lmap@ietf.org > > > Subject: Re: [lmap] Timer: Poisson distribution question > > > > > > It depends what the performance goal of the measurement is. A ping packet in a > > > Gigabit network is just under 1 microseconds and with fast processors a packet > > > can be sent and received at the same time if granularity is milliseconds. > > > > > > This does not even take into account 10Gig networks, not that they would be at > > > consumer sites, but they would sure exist inside a ISP network. > > > > > > Sharam > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Wednesday, April 23, 2014 11:11 AM > > > To: marc.ibrahim > > > Cc: trevor.burbridge@bt.com; Sharam Hakimi; timothy.carey@alcatel-lucent.com; > > lmap@ietf.org > > > Subject: Re: [lmap] Timer: Poisson distribution question > > > > > > I believe randomization with a granularity of milliseconds is good enough. > > > Within an implementation of a measurement task, one may use more precise > > > timers. But for the randomization of the start of measurement tasks or the > > > sending of reports, milliseconds seem to be sufficient (since there will be > > > likely other delays introduced by the operating system that may get into the > > > some order for starting a measurement task or triggering a report). > > > > > > /js > > > > > > On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote: > > > > I would say that choosing the millisecond as atomic time alleviates > > > > constraints on both timer granularity and generator capacity. > > > > > > > > I still don't see a real measurement example where few microseconds would really > > matter. > > > > > > > > Practically, can a program deal with microseconds timers in computers and > > smartphones? > > > > This is the scale of the OS, no? > > > > > > > > Marc. > > > > > > > > On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote > > > > > So the question is really do we want to design for extremely > > > > > constrained devices? I'd argue that if this is a problem for them > > > > > then they are really going to struggle with the Instruction information or > > measurement results. > > > > > > > > > > Trevor. > > > > > > > > > > >-----Original Message----- > > > > > >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > > > > > >Sent: 23 April 2014 15:00 > > > > > >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; > > > > > >timothy.carey@alcatel-lucent.com; lmap@ietf.org > > > > > >Subject: Re: [lmap] Timer: Poisson distribution question > > > > > > > > > > > >Here is how I see the problem. > > > > > > > > > > > >First we have to separate time granularity and random generation. > > > > > > > > > > > >Time granularity depends on the timer running on the MA. e.g > > > > > >microseconds scale means that the MA timer increment each microsecond. > > > > > > > > > > > >When MA wants to generate a random time, he has to choose an > > > > > >integer number of microseconds to count. So the problem is always > > > > > >an integer (discrete) number generation. > > > > > > > > > > > >Now, if the random generator can attain the maximum integer (so the > > > > > >maximum possible random time), then, as Trevor says, no need for > > > > > >the timeStep I talked about, since all possible durations will be expressed as > > multiple of microseconds. > > > > > > > > > > > > > > > > > >For example, a 32 bits random generator could generate up to a > > > > > >maximum value of 4 billions. In microseconds, this is equal to less than 2 > hours. > > > > > > > > > > > >It all depends on the capacity of the generator. > > > > > >Marc. > > > > > > > > > > > > > > > > > >On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote > > > > > >> So what is the argument for the latter (discrete) option? > > > > > >> > > > > > >> Trevor. > > > > > >> > > > > > >> >-----Original Message----- > > > > > >> >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > > > > > >> >Sent: 23 April 2014 14:10 > > > > > >> >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; > > > > > >> >timothy.carey@alcatel-lucent.com; lmap@ietf.org > > > > > >> >Subject: Re: [lmap] Timer: Poisson distribution question > > > > > >> > > > > > > >> >Trevor, you're right. > > > > > >> >it is just about whether we want a discrete or continuous generator. > > > > > >> >If we use a continuous uniform generator, than it is enough to > > > > > >> >specify the maximum time. > > > > > >> >With a discrete random generator, you need to specify an > > > > > >> >additional time granularity. > > > > > >> > > > > > > >> >BR, > > > > > >> > > > > > > >> >Marc. > > > > > >> > > > > > > >> > > > > > > >> >On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote > > > > > >> >> I'm not sure I get the point of allowing coarser granularity > > > > > >> >> that the MA is capable of. If I want the MA to test/report > > > > > >> >> sometime within a minute window, why not allow that to happen > > > > > >> >> with the maximum resolution the MA is capable > > > > > >> >of? > > > > > >> >> > > > > > >> >> 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 not the intended recipient, note that disclosing, > > > > > >> >> copying, distributing or using 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. British > > > > > >> >> Telecommunications plc Registered > > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in > > > > > >> >> England > > > > > >> >no: > > > > > >> >> 1800000 > > > > > >> >> > > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam > > > > > >> >> Hakimi > > > > > >> >> Sent: 23 April 2014 13:58 > > > > > >> >> To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R; > > > > > >> >> lmap@ietf.org > > > > > >> >> Subject: Re: [lmap] Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> Marc's suggestion works for me. That allows better > > > > > >> >> interoperability in my > > > > > >> >opinion. > > > > > >> >> > > > > > >> >> I do agree that we need a common "structure" and "names". > > > > > >> >> > > > > > >> >> Thanks, > > > > > >> >> Sharam > > > > > >> >> > > > > > >> >> From: Carey, Timothy (Timothy) > > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > > >> >> Sent: Wednesday, April 23, 2014 8:47 AM > > > > > >> >> To: trevor.burbridge@bt.com; > > > > > >> >> Sharam > > > > > >> >Hakimi; > > > > > >> >lmap@ietf.org > > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> Trevor, > > > > > >> >> > > > > > >> >> No - I am using the variable of your Information Model > > > > > >> >> (LowerLimit, > > > > > >> >UpperLimit, > > > > > >> >> Spread) - works so far. Marc suggested a TimeStep parameter > > > > > >> >> so we don't lockin on a specific microsecond, millisecond, > > > > > >> >> second thing - I am open > > > > > >to that. > > > > > >> >> > > > > > >> >> BR, > > > > > >> >> Tim > > > > > >> >> > > > > > >> >> From: trevor.burbridge@bt.com > > > > > >> >[mailto:trevor.burbridge@bt.com] > > > > > >> >> Sent: Wednesday, April 23, 2014 7:41 AM > > > > > >> >> To: Carey, Timothy (Timothy); > > > > > >> >> sharam.hakimi@exfo.com; > > > > > >> >lmap@ietf.org > > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> Agree we need to have well defined function names. I thought > > > > > >> >> you were also suggesting different functions needed different input > > parameters. > > > > > >> >> > > > > > >> >> 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 not the intended recipient, note that disclosing, > > > > > >> >> copying, distributing or using 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. British > > > > > >> >> Telecommunications plc Registered > > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in > > > > > >> >> England > > > > > >> >no: > > > > > >> >> 1800000 > > > > > >> >> > > > > > >> >> From: Carey, Timothy (Timothy) > > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > > >> >> Sent: 23 April 2014 13:36 > > > > > >> >> To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; > > > > > >> >lmap@ietf.org > > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> Its not that the Measurement controller has to configure the > > > > > >> >> timer for the > > > > > >MA. > > > > > >> >> > > > > > >> >> If we do not specify the functions and variable names, the > > > > > >> >> measurement controller doesn't have a standard way of configuring a timer. > > > > > >> >> > > > > > >> >> For example - If I specify for a Uniform distribution function > > > > > >> >> called "Uniform" you have a variable called "UpperLimit", the > > > > > >> >> MA will implement the specification; the controller will > > > > > >> >> implement the > > > > > >specification and things work. > > > > > >> >> > > > > > >> >> If I do not specify anything for the Uniform distribution > > > > > >> >> function > > > > > >> >> - MA vendor > > > > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" and > > > > > >> >> maybe an > > > > > >"Enable" > > > > > >> >> parameter for good measure; MA vendor 2 can call it "U" and > > > > > >> >> have an attribute "X that is an integer". > > > > > >> >> > > > > > >> >> Now put that variation on steroids based on the number of MA > > > > > >> >> vendors - That is why we specify things, right? > > > > > >> >> > > > > > >> >> BR, > > > > > >> >> Tim > > > > > >> >> > > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > > >> >> Sent: Wednesday, April 23, 2014 7:24 AM > > > > > >> >> To: Carey, Timothy (Timothy); > > > > > >> >> trevor.burbridge@bt.com; > > > > > >> >lmap@ietf.org > > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> The measurement controller has to communicate what tests have > > > > > >> >> to be run on > > > > > >> >an > > > > > >> >> MA, for how long, when to run them, what test results are > > > > > >> >> generated, etc. Why would configuring this parameter be any > > > > > >> >> different. Maybe I am missing > > > > > >> >something. > > > > > >> >> > > > > > >> >> From: Carey, Timothy (Timothy) > > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > > >> >> Sent: Wednesday, April 23, 2014 8:16 AM > > > > > >> >> To: Sharam Hakimi; > > > > > >> >trevor.burbridge@bt.com; > > > > > >> >lmap@ietf.org > > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> So the burden is on the Measurement controller to know the > > > > > >> >> functions and inputs specifications for each possible MA > > > > > >> >> vendor; not something I would want to have to do as a > > > > > >> >> Measurement controller > > > > > >vendor. > > > > > >> >> > > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > > >> >> Sent: Wednesday, April 23, 2014 7:14 AM > > > > > >> >> To: Carey, Timothy (Timothy); > > > > > >> >> trevor.burbridge@bt.com; > > > > > >> >lmap@ietf.org > > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> I do not see why vendor A or B or C matters. They would all be > > > > > >> >> under the control of one Measurement Controller which would > > > > > >> >> specify what inputs to use for all MAs in a group. > > > > > >> >> > > > > > >> >> As Trevor also mentioned this timer can be used for both > > > > > >> >> testing and reporting and I would strongly suggest to have > > > > > >> >> microsecond granularity. For reporting one could choose > > > > > >> >> seconds in terms of > > > > > >microseconds. > > > > > >> >> > > > > > >> >> Thanks, > > > > > >> >> Sharam > > > > > >> >> > > > > > >> >> From: Carey, Timothy (Timothy) > > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > > >> >> Sent: Wednesday, April 23, 2014 8:04 AM > > > > > >> >> To: trevor.burbridge@bt.com; > > > > > >> >> Sharam > > > > > >> >Hakimi; > > > > > >> >lmap@ietf.org > > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> Trevor, > > > > > >> >> > > > > > >> >> If we don't define the inputs for each function (leaving the > > > > > >> >> inputs > > > > > >> >> opaque) you will have interop problems. MA vendor 1 uses > > > > > >> >> these 2 inputs > > > > > >named "A" > > > > > >> >and > > > > > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" for the > > > > > >> >> same > > > > > >function. > > > > > >> >> > > > > > >> >> I think we need to avoid that if we realistically want the > > > > > >> >> Randomness function to be used efficiently. > > > > > >> >> > > > > > >> >> BR, > > > > > >> >> Tim > > > > > >> >> > > > > > >> >> From: trevor.burbridge@bt.com > > > > > >> >[mailto:trevor.burbridge@bt.com] > > > > > >> >> Sent: Wednesday, April 23, 2014 2:55 AM > > > > > >> >> To: Carey, Timothy (Timothy); > > > > > >> >> sharam.hakimi@exfo.com; > > > > > >> >lmap@ietf.org > > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> The random timing can be used for both specifying when a test > > > > > >> >> runs, or when a report is sent (or any other task such as > > > > > >> >> contacting the Controller). It doesn't have to be used, but it can be. > > > > > >> >> > > > > > >> >> I don't really want different input variable for different > > > > > >> >> functions. I don't see we need to. Also if we do, then we > > > > > >> >> would have to have schema for each function to specify which > > > > > >> >> inputs are expected (like the measurement task registry). I'd like to > avoid > > that. > > > > > >> >> > > > > > >> >> 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 not the intended recipient, note that disclosing, > > > > > >> >> copying, distributing or using 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. British > > > > > >> >> Telecommunications plc Registered > > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in > > > > > >> >> England > > > > > >> >no: > > > > > >> >> 1800000 > > > > > >> >> > > > > > >> >> From: Carey, Timothy (Timothy) > > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > > >> >> Sent: 22 April 2014 22:07 > > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; > > > > > >> >> Burbridge,T,Trevor, > > > > > >> >> TUB8 R Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> Sharam, > > > > > >> >> > > > > > >> >> We are talking about offsets for when to report; in the world > > > > > >> >> we live in milliseconds is sufficient - IMHO. > > > > > >> >> > > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > > >> >> Sent: Tuesday, April 22, 2014 3:59 PM > > > > > >> >> To: Carey, Timothy (Timothy); > > > > > >> >> lmap@ietf.org; > > > > > >> >trevor.burbridge@bt.com > > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> Tim, > > > > > >> >> I think the min/max should have microseconds granularity. > > > > > >> >> Milliseconds would not be accurate enough. > > > > > >> >> > > > > > >> >> Personally, I would not trust my periodic tests in a large > > > > > >> >> scale deployment to a random number generator and would want > > > > > >> >> to know exactly how and when > > > > > >> >tests > > > > > >> >> would be run. > > > > > >> >> > > > > > >> >> Thanks, > > > > > >> >> Sharam > > > > > >> >> > > > > > >> >> From: Carey, Timothy (Timothy) > > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] > > > > > >> >> Sent: Tuesday, April 22, 2014 3:16 PM > > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; > > > > > >> >trevor.burbridge@bt.com > > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> Trevor, > > > > > >> >> > > > > > >> >> The data model is extensible by vendors so we can add > > > > > >> >> functions and input variables as we need. > > > > > >> >> > > > > > >> >> However we have to decide on which small subset we actually > > > > > >> >> want to > > > > > >> >standardize. > > > > > >> >> > > > > > >> >> You suggested the Uniform and Normal which is fine but for the > > > > > >> >> model we need to go farther by defining the specific function > > > > > >> >> along with which inputs are used by the function to derive > > > > > >> >> what random number. Otherwise we will have 2 implementers of > > > > > >> >> the same standard algorithm implement different variations. - Not good. > > > > > >> >> > > > > > >> >> So I suggest we keep this simple. > > > > > >> >> > > > > > >> >> Uniform Discrete - input variables - maximum [positive > > > > > >> >> integer] Gaussian -input variables - mean of min/max, spread = > > > > > >> >> standard deviation > > > > > >> >> > > > > > >> >> The min/max would be milliseconds - Spread would be an integer. > > > > > >> >> > > > > > >> >> This sound OK? > > > > > >> >> > > > > > >> >> BR > > > > > >> >> Tim > > > > > >> >> > > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > > > > > >> >> Sent: Tuesday, April 22, 2014 8:23 AM > > > > > >> >> To: Carey, Timothy (Timothy); > > > > > >> >> lmap@ietf.org; > > > > > >> >trevor.burbridge@bt.com > > > > > >> >> Subject: RE: Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> Tim, > > > > > >> >> I think the Periodic Timer distribution needs to have closer > > > > > >> >> configuration control by the user and I think your 2nd choice > > > > > >> >> attempts to provide it but having a discrete interval > > > > > >> >> definition is a better way > > > > > >to go. > > > > > >> >> > > > > > >> >> Sharam > > > > > >> >> > > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > > > > > >> >trevor.burbridge@bt.com > > > > > >> >> Sent: Tuesday, April 22, 2014 4:35 AM > > > > > >> >> To: > > > > > >> >> timothy.carey@alcatel-lucent.com > > > > >> >lucent.com>; > > > > > >> >> lmap@ietf.org Subject: Re: [lmap] Timer: > > > > > >> >> Poisson distribution question > > > > > >> >> > > > > > >> >> On continuous counterparts of Poisson I'm far from any expert > > > > > >> >> and it would certainly be up to the user to decide if such > > > > > >> >> functions were suitable replacements for the discrete Poisson > > > > > >> >> function. Yes it would be a different function even if there > > > > > >> >> was perfect fit (which they are not) as one is continuous and one is > > discrete: > > > > > >> >> http://cmscience.blogspot.co.uk/2008/04/mt- > > > > > >> >6- > > > > > >> >> poisson-and-gamma-distribution.html > > > > > >> >> http://arxiv.org/abs/1303.5990 > > > > > >> >> > > > > > >> >> As I tried to say the current Information Model can take > > > > > >> >> either discrete or continuous functions - only that there is > > > > > >> >> currently no explicit support for specifying the interval used > > > > > >> >> for a discrete function. I was questioning the need to add this. > > > > > >> >> > > > > > >> >> Personally I'd think that Normal and Uniform distributions > > > > > >> >> would cover most needs, but the framework should be flexible in this > regard. > > > > > >> >> > > > > > >> >> Trevor. > > > > > >> >> > > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, > > > > > >> >> Timothy > > > > > >> >(Timothy) > > > > > >> >> Sent: 19 April 2014 20:24 > > > > > >> >> To: lmap@ietf.org > > > > > >> >> Subject: [lmap] Timer: Poisson distribution question > > > > > >> >> > > > > > >> >> Team, > > > > > >> >> > > > > > >> >> The BBF is looking at standardizing the model for Timers as > > > > > >> >> suggested by the IETF LMAP information model. > > > > > >> >> > > > > > >> >> During the review of the timers we had addition questions > > > > > >> >> regarding Trevors response to the Poisson distribution for the > > > > > >> >> Randomness of the > > > > > >Periodic Timer. > > > > > >> >> > > > > > >> >> Trevor responded: > > > > > >> >> > > > > > >> >> "Yes this does need to be clarified. I was assuming a > > > > > >> >> distribution about the mean (i.e. the timing given is the > > > > > >> >> mean). The spread would be the standard deviation (could use > > > > > >> >> mean deviation or something else but I see no advantage as > > > > > >> >> long as we all know what it refers to) and need to change to a > > > > > >> >> float. The upper and lower cuts would be in seconds +/- the > > > > > >> >> mean (also needs to change > > > > > >> >to > > > > > >> >> float) and are simply used to trim the function - obviously > > > > > >> >> needed on a uniform distribution but useful to constrain other functions. > > > > > >> >> > > > > > >> >> I will make all this clear in the next release. > > > > > >> >> > > > > > >> >> As for poisson I think there are 3 options: > > > > > >> >> > > > > > >> >> - Use a continuous form instead > > > > > >> >> > > > > > >> >> - Have the discrete interval implicit in the function choice > > > > > >> >e.g."poisson_1_sec" > > > > > >> >> > > > > > >> >> - Add an interval to the information model. > > > > > >> >> > > > > > >> >> I was really thinking about the first, but I don't see the > > > > > >> >> problem with the second. However I wouldn't do the third > > > > > >> >> unless they was a demonstrable value to supporting discrete > > > > > >> >> functions (rather than continuous > > > > > >versions of them). " > > > > > >> >> > > > > > >> >> But as people looked at Trevors response there were additional questions: > > > > > >> >> > > > > > >> >> I don't understand what Trevor means about the Poisson > > > > > >> >> distribution. As far as I know, it is a discrete > > > > > >> >> distribution, so a "continuous form" would be a different > > > > > >> >> distribution and not Poisson. And I believe that we do need a continuous > > distribution. > > > > > >> >> But what matters is that the definition is clear, not the > > > > > >> >> particular > > > > distribution > > > > > >(I don't have an opinion on that). > > > > > >> >> > > > > > >> >> Could some please clarify this for us - Are we planning > > > > > >> >> something other than Poisson method; better yet is there a > > > > > >> >> definition for the types of > > > > > >> >> distribution: Poisson, Normal and Uniform. > > > > > >> >> > > > > > >> >> Thanks, > > > > > >> >> Tim > > > > > >> > > > > > > >> > > > > > > >> >-- > > > > > >> >Open WebMail Project (http://openwebmail.org) > > > > > >> > > > > > >> _______________________________________________ > > > > > >> lmap mailing list > > > > > >> lmap@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > > > > > > > > >-- > > > > > >Open WebMail Project (http://openwebmail.org) > > > > > > > > > > _______________________________________________ > > > > > lmap mailing list > > > > > lmap@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > > > -- > > > > Open WebMail Project (http://openwebmail.org) > > > > > > > > _______________________________________________ > > > > 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 > > > > > > _______________________________________________ > > > 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 > > > > -- > > Open WebMail Project (http://openwebmail.org) > > -- > Open WebMail Project (http://openwebmail.org) -- Open WebMail Project (http://openwebmail.org) From nobody Tue May 13 10:22: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 953961A013C; Tue, 13 May 2014 10:22:01 -0700 (PDT) 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 2MvuSswiu5OP; Tue, 13 May 2014 10:22:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B78331A017F; Tue, 13 May 2014 10:21:59 -0700 (PDT) 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.4.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140513172159.14622.51471.idtracker@ietfa.amsl.com> Date: Tue, 13 May 2014 10:21:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/zsmuhJg-RzM3nlpQ2SdIoYspd9g Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-05.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: Tue, 13 May 2014 17:22:01 -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 : A framework for large-scale measurement platforms (LMAP) Authors : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-05.txt Pages : 54 Date : 2014-05-13 Abstract: Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (large-scale measurement platforms). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-framework-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-05 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 Tue May 13 10: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 2BE9C1A0116 for ; Tue, 13 May 2014 10:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=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 itJSyzDbxd9B for ; Tue, 13 May 2014 10:53:14 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8FB1A0101 for ; Tue, 13 May 2014 10:53:13 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 13 May 2014 18:53:13 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 13 May 2014 18:53:06 +0100 From: To: Date: Tue, 13 May 2014 18:53:04 +0100 Thread-Topic: New Version Notification for draft-ietf-lmap-framework-05.txt Thread-Index: Ac9uz9nXm3u3FQVFQ1+beT7U94BHdgAAEUSg Message-ID: References: <20140513172159.14622.62002.idtracker@ietfa.amsl.com> In-Reply-To: <20140513172159.14622.62002.idtracker@ietfa.amsl.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/BdSFXzqE_f3jmLH3iIqqfH5i8kI Subject: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-05.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: Tue, 13 May 2014 17:53:16 -0000 SGksDQoNCldlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGZyYW1ld29yay4g VGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhlIGNvbW1lbnRzIGFuZCBkaXNjdXNzaW9uIGR1cmluZyB0 aGUgMm5kIFdHTEMsIHRoaW5rIHRoZXkncmUgYWxsIHJlc29sdmVkLiBTb3JyeSBpZiB3ZSBtaXNz ZWQgYW55LCBwbGVhc2UgbGV0IHVzIGtub3cgaWYgbm90IChvZmYtbGlzdCBpZiBhIG5pdCkuDQoN CkhlcmUgYXJlIHRoZSBtYWluIGNoYW5nZXM6DQoNCjEyLjUuICBGcm9tIC0wNCB0byAtMDUNCg0K ICAgbyAgY2xhcmlmaWVkIHZhcmlvdXMgc2NvcGluZyBjb21tZW50cyBieSB1c2luZyB0aGUgcGhy YXNlICJzY29wZSBvZg0KICAgICAgaW5pdGlhbCBMTUFQIHdvcmsiIChhdm9pZGluZyAic2NvcGUg b2YgTE1BUCBXRyIgc2luY2UgdGhpcyBtYXkNCiAgICAgIGNoYW5nZSBpbiB0aGUgZnV0dXJlKQ0K DQogICBvICBhZGRlZCBhIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgLSBhbGxvd3MgdGhlIENvbnRy b2xsZXIgdG8gdXBkYXRlDQogICAgICB0aGUgTUEgYWJvdXQgaW5mb3JtYXRpb24gdGhhdCBpdCBv YnRhaW5lZCBkdXJpbmcgdGhlIGJvb3RzdHJhcHBpbmcNCiAgICAgIHByb2Nlc3MgKGZvciBjb25z aXN0ZW5jeSB3aXRoIEluZm9ybWF0aW9uIE1vZGVsKQ0KDQogICBvICBSZW1vdmVkIG92ZXItZGV0 YWlsZWQgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuDQogICAgICB0 aGUgZGlmZmVyZW50IGl0ZW1zIGluIEluc3RydWN0aW9uLCBhcyB0aGlzIHNlZW1zIG1vcmUgYXBw cm9wcmlhdGUNCiAgICAgIGZvciB0aGUgaW5mb3JtYXRpb24gbW9kZWwuICBDbGFyaWZpZWQgdGhh dCB0aGUgbGlzdHMgZ2l2ZW4gYXJlDQogICAgICBhYm91dCB0aGUgYWltcyBhbmQgbm90IGEgbGlz dCBvZiBpbmZvcm1hdGlvbiBlbGVtZW50cyAodGhlc2Ugd2lsbA0KICAgICAgYmUgZGVmaW5lZCBp biBkcmFmdC1pZXRmLWluZm9ybWF0aW9uLW1vZGVsKS4NCg0KICAgbyAgdGhlIE1lYXN1cmVtZW50 IE1ldGhvZCwgc3BlY2lmaWVkIGFzIGEgVVJJIHRvIGEgcmVnaXN0cnkgZW50cnkgLQ0KICAgICAg cmF0aGVyIHRoYW4gYSBVUk4NCg0KICAgbyAgTUEgY29uZmlndXJlZCB3aXRoIHRpbWUgbGltaXQg YWZ0ZXIgd2hpY2gsIGlmIGl0IGhhc24ndCBoZWFyZCBmcm9tDQogICAgICBDb250cm9sbGVyLCB0 aGVuIGl0IHN0b3BzIHJ1bm5pbmcgTWVhc3VyZW1lbnQgVGFza3MgKHJhdGhlciB0aGFuDQogICAg ICB0aGlzIGJlaW5nIHBhcnQgb2YgYSBTY2hlZHVsZSkNCg0KICAgbyAgY2xhcmlmaWVkIHRoZXJl IGlzIG5vIGRpc3RpbmN0aW9uIGJldHdlZW4gaG93IGNhcGFiaWxpdGllcywNCiAgICAgIGZhaWx1 cmUgYW5kIGxvZ2dpbmcgaW5mb3JtYXRpb24gYXJlIHRyYW5zZmVycmVkIChhbGwgY2FuIGJlIHdo ZW4NCiAgICAgIHJlcXVlc3RlZCBieSBDb250cm9sbGVyIG9yIGJ5IE1BIG9uIGl0cyBvd24gaW5p dGlhdGl2ZSkuDQoNCiAgIG8gIHJlbW92ZWQgbWVudGlvbiBvZiBEYXRhIFRyYW5zZmVyIFRhc2tz LiAgVGhpcyBhYnN0cmFjdGlvbiBpcyBsZWZ0DQogICAgICB0byB0aGUgaW5mb3JtYXRpb24gbW9k ZWwgaS1kDQoNCiAgIG8gIGFkZGVkIERlcGxveW1lbnQgc3ViLXNlY3Rpb24gYWJvdXQgTWVhc3Vy ZW1lbnQgQWdlbnQgZW1iZWRkZWQgaW4NCiAgICAgIElTUCBOZXR3b3JrDQoNCiAgIG8gIHZhcmlv dXMgb3RoZXIgc21hbGxlciBpbXByb3ZlbWVudHMsIGFyaXNpbmcgZnJvbSB0aGUgMm5kIFdHTEMN Cg0KDQpTdXBwcmVzc2lvbjotDQpUaGUgcmVjZW50IGRpc2N1c3Npb24gYWJvdXQgc3VwcHJlc3Np b24gZG9lc27igJl0IHNlZW0gdG8gaGF2ZSBiZWVuIGNvbmNsdXNpdmUuIEluIG9yZGVyIHRvIG1h a2UgcHJvZ3Jlc3MsIGFuZCBhcyB0aGUgLTA0IHRleHQgcmVmbGVjdGVkIHRoZSBkaXNjdXNzaW9u cyAvYWdyZWVtZW50IGR1cmluZyB0aGUgTG9uZG9uIElFVEYsIG91ciBzdWdnZXN0aW9uIGlzIG5v dCB0byBtYWtlIGNoYW5nZXMgdG8gdGhpcyBzZWN0aW9uLiBXZSBjaGVja2VkIHdpdGggYSBmZXcg bm9uLWF1dGhvcnMgKEJhcmJhcmEsIEtlbiwgSnVlcmdlbikgd2hvJ2QgYmVlbiBtb3N0IGFjdGl2 ZSBvbiB0aGlzIHRvcGljIGFuZCB0aGV5J3JlIE9LIHdpdGggdGhpcyBhcHByb2FjaC4NCg0KDQpU aGFua3MNClBoaWwgYW5kIGZyaWVuZHMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQpTZW50OiAxMyBNYXkgMjAxNCAxODoyMg0KVG86IEFhbWVyIEFraHRlcjsgQWwgQy4g TW9ydG9uOyBBbCBNb3J0b247IEVhcmRsZXksUEwsUGhpbGlwLFRVQjggUjsgUGF1bCBBaXRrZW47 IFBhdWwgQWl0a2VuOyBNYXJjZWxvIEJhZ251bG87IEVhcmRsZXksUEwsUGhpbGlwLFRVQjggUjsg TWFyY2VsbyBCYWdudWxvOyBCdXJicmlkZ2UsVCxUcmV2b3IsVFVCOCBSOyBBYW1lciBBa2h0ZXI7 IEJ1cmJyaWRnZSxULFRyZXZvcixUVUI4IFINClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wNS50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wNS50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGhpbGlwIEVhcmRsZXkgYW5kIHBvc3RlZCB0byB0aGUN CklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmsNClJl dmlzaW9uOgkwNQ0KVGl0bGU6CQlBIGZyYW1ld29yayBmb3IgbGFyZ2Utc2NhbGUgbWVhc3VyZW1l bnQgcGxhdGZvcm1zIChMTUFQKQ0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wNS0xMw0KR3JvdXA6CQls bWFwDQpQYWdlczoJCTU0DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wNS50eHQNClN0YXR1czogICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxtYXAtZnJh bWV3b3JrLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtbG1hcC1mcmFtZXdvcmstMDUNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA1DQoNCkFic3RyYWN0 Og0KICAgTWVhc3VyaW5nIGJyb2FkYmFuZCBzZXJ2aWNlIG9uIGEgbGFyZ2Ugc2NhbGUgcmVxdWly ZXMgYSBkZXNjcmlwdGlvbg0KICAgb2YgdGhlIGxvZ2ljYWwgYXJjaGl0ZWN0dXJlIGFuZCBzdGFu ZGFyZGlzYXRpb24gb2YgdGhlIGtleSBwcm90b2NvbHMNCiAgIHRoYXQgY29vcmRpbmF0ZSBpbnRl cmFjdGlvbnMgYmV0d2VlbiB0aGUgY29tcG9uZW50cy4gIFRoZSBkb2N1bWVudA0KICAgcHJlc2Vu dHMgYW4gb3ZlcmFsbCBmcmFtZXdvcmsgZm9yIGxhcmdlLXNjYWxlIG1lYXN1cmVtZW50cy4gIEl0 IGFsc28NCiAgIGRlZmluZXMgdGVybWlub2xvZ3kgZm9yIExNQVAgKGxhcmdlLXNjYWxlIG1lYXN1 cmVtZW50IHBsYXRmb3JtcykuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue May 13 11:45: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 595AC1A0096 for ; Tue, 13 May 2014 11:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 5bID9AstR1BP for ; Tue, 13 May 2014 11:45:25 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C410F1A00DD for ; Tue, 13 May 2014 11:45:24 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s4DIjHgB025820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 May 2014 13:45:18 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s4DIjG1f010488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 13 May 2014 14:45:17 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Tue, 13 May 2014 14:45:16 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFA== Date: Tue, 13 May 2014 18:45:16 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771954227DUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/gno7y-ACM38JIAh2rQOUt4lW9vA Subject: [lmap] Question on information model - Suppression 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, 13 May 2014 18:45:27 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771954227DUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, In the information model we defined suppression as: object { boolean ma-suppression-enabled; [datetime ma-suppression-start;] // default: immediate [datetime ma-suppression-end;] // default: indefinite [string ma-suppression-task-names<0..*>;] // default: all tasks if // ma-suppression-task-names is empty [string ma-suppression-schedule-names<0..*>;] // default: all schedules if // ma-suppression-schedule-names is empty } ma-suppression-obj; In the BBF review of the LMAP model - a question was asked regarding the re= lationship between tasks and schedules elements. What are the rules: 1) If Tasks is non-empty and Schedules is non-empty a. : I think this would suppress the listed tasks with the listed sche= dules 2) If Tasks is empty and Schedules is non-empty a. : I think this would suppress all tasks for the listed schedules 3) If Tasks is non-empty and Schedules is empty a. : I think this would suppress listed tasks for all schedules of the= task 4) If Tasks and Schedules are empty a. : I think this would suppress all tasks regardless of schedule Is this the teams understanding? Thanks, tim --_000_9966516C6EB5FC4381E05BF80AA55F771954227DUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

In the information model we defined suppression as:<= o:p>

 

object {

boolean ma-suppression-enabled;

[datetime ma-suppression-start;] // default:= immediate

[datetime ma-suppression-end;] // default: i= ndefinite

[string ma-suppression-task-names<0..*>= ;;]

// default: all tasks if

// ma-suppression-task-names is empty

[string ma-suppression-schedule-names<0..= *>;]

// default: all schedules if

// ma-suppression-schedule-names is empty

} ma-suppression-obj;

 

 

In the BBF review of the LMAP model – a question was asked regarding= the relationship between tasks and schedules elements.

 

What are the rules:

 

1) If Tasks is non-empty and Schedules is non-empty=

<= span style=3D"mso-list:Ignore">a. <TAC>: I think this would suppress the listed tasks with the= listed schedules

2) If Tasks is empty and Schedules is non-empty

<= span style=3D"mso-list:Ignore">a. <TAC>: I think this would suppress all tasks for the listed = schedules

3) If Tasks is non-empty and Schedules is empty

<= span style=3D"mso-list:Ignore">a. <TAC>: I think this would suppress listed tasks for all sche= dules of the task

4) If Tasks and Schedules are empty

<= span style=3D"mso-list:Ignore">a. <TAC>: I think this would suppress all tasks regardless of s= chedule

 

 

Is this the teams understanding?

 

Thanks,

tim

--_000_9966516C6EB5FC4381E05BF80AA55F771954227DUS70UWXCHMBA05z_-- From nobody Tue May 13 13:46: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 7ACED1A019C for ; Tue, 13 May 2014 13:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-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 FOQTEPZUduAY for ; Tue, 13 May 2014 13:46:00 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCCC1A01D5 for ; Tue, 13 May 2014 13:46:00 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4DKjo8K009323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2014 15:45:51 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s4DKjlQF027225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 16:45:50 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Tue, 13 May 2014 16:45:48 -0400 From: "Carey, Timothy (Timothy)" To: "marc.ibrahim" , "lmap@ietf.org" Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFAAKXpIAAAa3M5A= Date: Tue, 13 May 2014 20:45:47 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719542394@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513190715.M29517@mail.usj.edu.lb> In-Reply-To: <20140513190715.M29517@mail.usj.edu.lb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] 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/rgCJ_CNkP2UtgvnjkEsfyAD6RW8 Subject: Re: [lmap] Question on information model - Suppression 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, 13 May 2014 20:46:04 -0000 Marc, Inline -----Original Message----- From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb]=20 Sent: Tuesday, May 13, 2014 2:42 PM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression Tim, > 1) If Tasks is non-empty and Schedules is non-empty >=20 > a. : I think this would suppress the listed tasks with the listed sc= hedules While I agree with b. c. and d., a. seems unclear to me. Let me take a prac= tical=20 example: Assume an MA has 3 tasks: T1, T2, and T3 with 2 schedules S1(T1,T2) and S2(= T1,T2,T3). If MA receives the message SUPPRESS([T1], [S1, S2]), I understand the follo= wing: - MA will stop running T1 according to schedule S1 and S2 - MA will keep running T1 according to S2.=20 - T2 and T3 are intact and still running according to S1 and S2.=20 In conclusion, we just suppressed T1 from S1 and S2. Is this right? No I would have thought T1 would be suppressed for S1= and S2; if there was an S3 for T1 then that would execute. If yes, let's assume I want to send a suppress message asking MA to suppres= s T1 from S1=20 and T2 from S1 and S2. If we send : SUPPRESS([T1,T2],[S1,S2]), it will dele= te T1 and T2=20 from both schedules. We need then two suppress messages to do it: 1- SUPPRESS ([T1], [S1]) 2- SUPPRESS ([T2], [S1,S2]) To be brief, since there is no association between tasks and schedules to s= uppress, more=20 than one suppress messages would be needed to accomplish a given suppressio= n scenario.=20 To avoid this (if this is a pb), I think we should send suppression command= as an array=20 of pairs (Ti,Si). (Ti,Si) =3D> suppress Ti from Si (Ti,*)=3D>suppress Ti from all Schedules (*,Si)=3D>suppress schedule Si=20 I would agree that a list of pairs would provide a more flexible app= roach - just wasn't the way it was currently modeled.... BR, Marc. On Tue, 13 May 2014 18:45:16 +0000, Carey, Timothy (Timothy) wrote > Trevor, >=20 > In the information model we defined suppression as: >=20 > object { > boolean ma-suppression-enabled; > [datetime ma-suppression-start;] // default: immediate > [datetime ma-suppression-end;] // default: indefinite > [string ma-suppression-task-names<0..*>;] > // default: all tasks if > // ma-suppression-task-names is empty > [string ma-suppression-schedule-names<0..*>;] > // default: all schedules if > // ma-suppression-schedule-names is empty > } ma-suppression-obj; >=20 > In the BBF review of the LMAP model - a question was asked regarding the= =20 > relationship between tasks and schedules elements. >=20 > What are the rules: >=20 > 1) If Tasks is non-empty and Schedules is non-empty >=20 > a. : I think this would suppress the listed tasks with the listed sc= hedules >=20 > 2) If Tasks is empty and Schedules is non-empty >=20 > a. : I think this would suppress all tasks for the listed schedules >=20 > 3) If Tasks is non-empty and Schedules is empty >=20 > a. : I think this would suppress listed tasks for all schedules of t= he task >=20 > 4) If Tasks and Schedules are empty >=20 > a. : I think this would suppress all tasks regardless of schedule >=20 > Is this the teams understanding? >=20 > Thanks, > tim -- Open WebMail Project (http://openwebmail.org) From nobody Tue May 13 14:02: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 F17FA1A01FE for ; Tue, 13 May 2014 14:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RP_MATCHES_RCVD=-0.651, 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 fvcKHVnk89zZ for ; Tue, 13 May 2014 14:02:51 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id EAE5B1A0202 for ; Tue, 13 May 2014 14:02:50 -0700 (PDT) X-ASG-Debug-ID: 1400015105-05fac103c44e230001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id 6CPUAb21htYVT29t; Wed, 14 May 2014 00:05:05 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from usj.edu.lb (localhost.localdomain [127.0.0.1]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4DL2TEu017808; Wed, 14 May 2014 00:02:32 +0300 From: "marc.ibrahim" To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" Date: Wed, 14 May 2014 00:02:29 +0300 X-ASG-Orig-Subj: RE: [lmap] Question on information model - Suppression Message-Id: <20140513205525.M76695@usj.edu.lb> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719542394@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513190715.M29517@mail.usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F7719542394@US70UWXCHMBA05.zam.alcatel-lucent.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 46.19.194.254 (marc.ibrahim) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1400015105 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.5784 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/i-43Mq7QiXsouf-p4QcyrON30Og Subject: Re: [lmap] Question on information model - Suppression 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, 13 May 2014 21:02:55 -0000 Inline. On Tue, 13 May 2014 20:45:47 +0000, Carey, Timothy (Timothy) wrote > Marc, > > Inline > > -----Original Message----- > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] > Sent: Tuesday, May 13, 2014 2:42 PM > To: Carey, Timothy (Timothy); lmap@ietf.org > Subject: Re: [lmap] Question on information model - Suppression > > Tim, > > > 1) If Tasks is non-empty and Schedules is non-empty > > > > a. : I think this would suppress the listed tasks with the listed schedules > > While I agree with b. c. and d., a. seems unclear to me. Let me take a > practical example: > > Assume an MA has 3 tasks: T1, T2, and T3 with 2 schedules S1(T1,T2) and S2(T1, > T2,T3). > > If MA receives the message SUPPRESS([T1], [S1, S2]), I understand the > following: - MA will stop running T1 according to schedule S1 and S2 - MA will > keep running T1 according to S2. - T2 and T3 are intact and still running > according to S1 and S2. > > In conclusion, we just suppressed T1 from S1 and S2. > > Is this right? No I would have thought T1 would be suppressed for S1 > and S2; if there was an S3 for T1 then that would execute. Yes, in deed. Sorry, I added S2 in the suppress message and forgot to delete the erroneous sentence (MA will keep running T1 according to S2). So, I understand how it works. > > If yes, let's assume I want to send a suppress message asking MA to suppress > T1 from S1 and T2 from S1 and S2. If we send : SUPPRESS([T1,T2],[S1,S2]), it > will delete T1 and T2 from both schedules. We need then two suppress messages > to do it: > > 1- SUPPRESS ([T1], [S1]) 2- SUPPRESS ([T2], [S1,S2]) > > To be brief, since there is no association between tasks and schedules to > suppress, more than one suppress messages would be needed to accomplish a > given suppression scenario. To avoid this (if this is a pb), I think we should > send suppression command as an array of pairs (Ti,Si). > (Ti,Si) => suppress Ti from Si > (Ti,*)=>suppress Ti from all Schedules > (*,Si)=>suppress schedule Si > > I would agree that a list of pairs would provide a more flexible > approach - just wasn't the way it was currently modeled.... > Ok > BR, > > Marc. > > On Tue, 13 May 2014 18:45:16 +0000, Carey, Timothy (Timothy) wrote > > Trevor, > > > > In the information model we defined suppression as: > > > > object { > > boolean ma-suppression-enabled; > > [datetime ma-suppression-start;] // default: immediate > > [datetime ma-suppression-end;] // default: indefinite > > [string ma-suppression-task-names<0..*>;] > > // default: all tasks if > > // ma-suppression-task-names is empty > > [string ma-suppression-schedule-names<0..*>;] > > // default: all schedules if > > // ma-suppression-schedule-names is empty > > } ma-suppression-obj; > > > > > In the BBF review of the LMAP model - a question was asked regarding the > > relationship between tasks and schedules elements. > > > > What are the rules: > > > > 1) If Tasks is non-empty and Schedules is non-empty > > > > a. : I think this would suppress the listed tasks with the listed schedules > > > > 2) If Tasks is empty and Schedules is non-empty > > > > a. : I think this would suppress all tasks for the listed schedules > > > > 3) If Tasks is non-empty and Schedules is empty > > > > a. : I think this would suppress listed tasks for all schedules of the task > > > > 4) If Tasks and Schedules are empty > > > > a. : I think this would suppress all tasks regardless of schedule > > > > Is this the teams understanding? > > > > Thanks, > > tim > > -- > Open WebMail Project (http://openwebmail.org) -- Open WebMail Project (http://openwebmail.org) From nobody Tue May 13 14:16: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 272881A0207 for ; Tue, 13 May 2014 14:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 qzIL7SECOIig for ; Tue, 13 May 2014 14:16:12 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id EB2551A0206 for ; Tue, 13 May 2014 14:16:11 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s4DKtXcm006945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2014 16:16:02 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s4DJIqSK005721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 15:18:52 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 13 May 2014 15:18:52 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" , "trevor.burbridge@bt.com" Thread-Topic: Question on Information Model - Interface attribute on Channels Thread-Index: Ac9u4CvpWqabvtVFQDGBJxiIx1Qq7Q== Date: Tue, 13 May 2014 19:18:53 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77195422BA@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77195422BAUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/GjMWIfCRGagKo2JuBWsmJe8Wm-g Subject: [lmap] Question on Information Model - Interface attribute on Channels 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, 13 May 2014 21:16:14 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77195422BAUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, During the BBF review of the LMAP information model, the group had a questi= on regarding the usage of the Channel's interface name. Specifically they wanted to know if there was any limitations on the type o= f interface (e.g., Layer 3 interface only, WAN only)... My opinion is that any interface could be used and we shouldn't limit= the interface. Also - what is the behavior if the Interface name is not provided? My opinion if the Interface is used; the channel is restricted to the= interface; if it is not any available interface could be used... BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77195422BAUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

During the BBF review of the LMAP information model,= the group had a question regarding the usage of the Channel’s interf= ace name.

 

Specifically they wanted to know if there was any li= mitations on the type of interface (e.g., Layer 3 interface only, WAN only)= …

<TAC> My opinion is that any interface could b= e used and we shouldn’t limit the interface.

 

Also – what is the behavior if the Interface n= ame is not provided?

<TAC> My opinion if the Interface is used; the= channel is restricted to the interface; if it is not any available interfa= ce could be used…

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77195422BAUS70UWXCHMBA05z_-- From nobody Tue May 13 14:47: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 1CE701A01EB for ; Tue, 13 May 2014 14:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 oNLABbjsQTeE for ; Tue, 13 May 2014 14:47:07 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id AB4161A01C9 for ; Tue, 13 May 2014 14:47:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B23E5FAB; Tue, 13 May 2014 23:47:00 +0200 (CEST) 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 50ARd1MK5dFg; Tue, 13 May 2014 23:47:00 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 May 2014 23:47:00 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E792A20017; Tue, 13 May 2014 23:46:59 +0200 (CEST) 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 aVvxRtrVBLFF; Tue, 13 May 2014 23:46:58 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F2D820013; Tue, 13 May 2014 23:46:57 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id BF2632CD0D1B; Tue, 13 May 2014 23:46:56 +0200 (CEST) Date: Tue, 13 May 2014 23:46:56 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/OqC-6cCNd6f7ARCduQKFbD2_1gw Cc: "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 13 May 2014 21:47:10 -0000 On Tue, May 13, 2014 at 06:45:16PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, > > In the information model we defined suppression as: > > object { > boolean ma-suppression-enabled; > [datetime ma-suppression-start;] // default: immediate > [datetime ma-suppression-end;] // default: indefinite > [string ma-suppression-task-names<0..*>;] > // default: all tasks if > // ma-suppression-task-names is empty > [string ma-suppression-schedule-names<0..*>;] > // default: all schedules if > // ma-suppression-schedule-names is empty > } ma-suppression-obj; > > > In the BBF review of the LMAP model - a question was asked regarding the relationship between tasks and schedules elements. > > What are the rules: > > > 1) If Tasks is non-empty and Schedules is non-empty > > a. : I think this would suppress the listed tasks with the listed schedules > > 2) If Tasks is empty and Schedules is non-empty > > a. : I think this would suppress all tasks for the listed schedules > > 3) If Tasks is non-empty and Schedules is empty > > a. : I think this would suppress listed tasks for all schedules of the task > > 4) If Tasks and Schedules are empty > > a. : I think this would suppress all tasks regardless of schedule > > > Is this the teams understanding? Yes on 2) and 3) and 4). Concerning 1), I think the semantics are not spelled out this clearly is something that needs fixing. The question is what the semantics should be. One possible interpretation (the one you suggest above) is that the intersection would be suppressed. Another possible interpretation is that the union would be suppressed, that is, it supresses all listed tasks and all tasks triggered by for the listed schedules. I do not know what the 'right' answer is. Of course, the 'union' interpretation can always achieved by having two ma-suppression-objs (one listing the tasks, the second listing the schedules). This makes your interpretation somewhat appealing. I am not sure, however, whether this can make things tricky. Another option could also be to disallow 1). I am not sure what to do but I agree that this needs to be worked out, so thanks for bringing this up. /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 Tue May 13 14: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 436371A0206 for ; Tue, 13 May 2014 14:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 RXIRDmUxtFu3 for ; Tue, 13 May 2014 14:52:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id DBEF51A01FE for ; Tue, 13 May 2014 14:52:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 389A2FAB; Tue, 13 May 2014 23:52:34 +0200 (CEST) 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 6A0uEn-FOcld; Tue, 13 May 2014 23:52:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 May 2014 23:52:33 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E40820017; Tue, 13 May 2014 23:52:33 +0200 (CEST) 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 JOcGuXYKeExe; Tue, 13 May 2014 23:52:32 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F7DB20013; Tue, 13 May 2014 23:52:32 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 03E8E2CD0D46; Tue, 13 May 2014 23:52:31 +0200 (CEST) Date: Tue, 13 May 2014 23:52:31 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20140513215231.GB87889@elstar.jacobs.jacobs-university.de> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" , "trevor.burbridge@bt.com" References: <9966516C6EB5FC4381E05BF80AA55F77195422BA@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77195422BA@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/l0gEbTwBZ-32-JS6sobzVtIlNgc Cc: "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Question on Information Model - Interface attribute on Channels 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, 13 May 2014 21:52:42 -0000 On Tue, May 13, 2014 at 07:18:53PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, > > During the BBF review of the LMAP information model, the group had a question regarding the usage of the Channel's interface name. > > Specifically they wanted to know if there was any limitations on the type of interface (e.g., Layer 3 interface only, WAN only)... > My opinion is that any interface could be used and we shouldn't limit the interface. This is also my interpretation. > Also - what is the behavior if the Interface name is not provided? > My opinion if the Interface is used; the channel is restricted to the interface; if it is not any available interface could be used... Normally, the specification of the interface name is not needed since the IP layer decides which interface to use. An explicit interface definition is needed in cases where multiple choices are possible and it is necessary to exercise explicit control over the choice. So yes, it is any interface could be used (and which is being actually used is determined by the lower layers of the networking stack). I agree that this could be more explicitely described. /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 Tue May 13 22:52:25 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 168F61A0233 for ; Tue, 13 May 2014 22:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 yInTmns7iFS0 for ; Tue, 13 May 2014 22:52:22 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id A39381A0238 for ; Tue, 13 May 2014 22:52:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D2F3E708; Wed, 14 May 2014 07:52:15 +0200 (CEST) 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 2-98G6N_GrDb; Wed, 14 May 2014 07:52:15 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 14 May 2014 07:52:15 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 426F520017; Wed, 14 May 2014 07:52:15 +0200 (CEST) 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 i6sNPRZfC0ra; Wed, 14 May 2014 07:52:14 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1B0020013; Wed, 14 May 2014 07:52:13 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id C74C42CD13E5; Wed, 14 May 2014 07:52:12 +0200 (CEST) Date: Wed, 14 May 2014 07:52:12 +0200 From: Juergen Schoenwaelder To: "marc. ibrahim" Message-ID: <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> Mail-Followup-To: "marc. ibrahim" , "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140513220810.M26751@mail.usj.edu.lb> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/T25m5YLwGjBvyK9j7tW3As0wV4I Cc: "Carey, Timothy \(Timothy\)" , "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 14 May 2014 05:52:24 -0000 On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: > > ma-suppression-task-names<0..*> and > ma-suppression-schedule-names<0..*> are strings containing names of > tasks and schedules. If we just allow to have the same name multiple > times, a pairing association could be done between tasks without > changing the information model. > > For example, ma-suppression-task-names = [T1 T1 T2 T2 T3 *] and > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1 > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all > schedules, and schedule S4 will be suppressed. Does this change the > information model Tim? I do not think this is needed since you can have multiple suppression objects. But defining the intersection of ma-suppression-task-names = [T1 T2] ma-suppression-schedule-names = [S1 S2] may not be that clear. The union is clear, suppress tasks T1 and T2 and anything started by S1 and S2. Is the intersection interpretation suppress any T1 started by S1, any T2 started by S1, any T1 started by S2, any T2 started by S2? This is not really an intersection - a strict intersection interpretation would likely lead to an empty set. /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 May 14 00:00: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 CBF6A1A0230 for ; Wed, 14 May 2014 00:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 jNas0eKh-5MS for ; Tue, 13 May 2014 23:59:56 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id 175461A0265 for ; Tue, 13 May 2014 23:59:55 -0700 (PDT) X-ASG-Debug-ID: 1400050935-05fac1101384ba00001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id deER8vaOmxOM4G2E; Wed, 14 May 2014 10:02:15 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from usj.edu.lb (localhost.localdomain [127.0.0.1]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4E6xalx015233; Wed, 14 May 2014 09:59:38 +0300 From: "marc.ibrahim" To: Juergen Schoenwaelder Date: Wed, 14 May 2014 09:59:36 +0300 X-ASG-Orig-Subj: Re: [lmap] Question on information model - Suppression Message-Id: <20140514064545.M74784@usj.edu.lb> In-Reply-To: <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 77.42.251.110 (marc.ibrahim) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1400050935 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.5795 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/EJOywAddysslXlJkOWfQVKfOcms Cc: "Carey, Timothy \(Timothy\)" , "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 14 May 2014 07:00:04 -0000 On Wed, 14 May 2014 07:52:12 +0200, Juergen Schoenwaelder wrote > On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: > > > > ma-suppression-task-names<0..*> and > > ma-suppression-schedule-names<0..*> are strings containing names of > > tasks and schedules. If we just allow to have the same name multiple > > times, a pairing association could be done between tasks without > > changing the information model. > > > > For example, ma-suppression-task-names = [T1 T1 T2 T2 T3 *] and > > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1 > > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all > > schedules, and schedule S4 will be suppressed. Does this change the > > information model Tim? > > I do not think this is needed since you can have multiple suppression > objects. But defining the intersection of > > ma-suppression-task-names = [T1 T2] > ma-suppression-schedule-names = [S1 S2] > > may not be that clear. The union is clear, suppress tasks T1 and T2 > and anything started by S1 and S2. Is the intersection interpretation > suppress any T1 started by S1, any T2 started by S1, any T1 started by > S2, any T2 started by S2? This is not really an intersection - a > strict intersection interpretation would likely lead to an empty set. > No, this is my proposition. Intersection as I understood from Tim, is different. Let's have a general suppression object: ma-suppression-task-names = [T1 ... Tn] ma-suppression-schedule-names = [S1 ... Sm] Intersection means: Ti will be suppressed from any schedule S1 ... Sm starting Ti. Union means: Tasks T1 to Tn are all suppressed (from all MA schedules, isn't it JS?) and all tasks started by S1 to Sm should be suppressed too. Pairing: m=n. Ti suppressed from Si. I see the intersection (or another term) definition is as clear as union IMO. If I understood you well JS, I see that union cannot perform all suppression possibilities. For example, how to suppress only a subset from a given schedule? Intersection can do it with one or more suppression objects. Pairing solution needs only one object to do any suppression combination. BR, Marc. > /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 -- Open WebMail Project (http://openwebmail.org) From nobody Wed May 14 00:38: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 47ACB1A0273 for ; Wed, 14 May 2014 00:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 gJn7us5ATOf8 for ; Wed, 14 May 2014 00:38:09 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9A41A026F for ; Wed, 14 May 2014 00:38:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 99D1510AF; Wed, 14 May 2014 09:38:02 +0200 (CEST) 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 2M1IEsCntSci; Wed, 14 May 2014 09:38:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 14 May 2014 09:38:01 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C470720013; Wed, 14 May 2014 09:38:01 +0200 (CEST) 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 GL2GVCMcgDqQ; Wed, 14 May 2014 09:38:00 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 293212002C; Wed, 14 May 2014 09:38:00 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 62A782CD15EF; Wed, 14 May 2014 09:37:59 +0200 (CEST) Date: Wed, 14 May 2014 09:37:58 +0200 From: Juergen Schoenwaelder To: "marc. ibrahim" Message-ID: <20140514073758.GA91397@elstar.jacobs.jacobs-university.de> Mail-Followup-To: "marc. ibrahim" , "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <20140514064545.M74784@usj.edu.lb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140514064545.M74784@usj.edu.lb> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/lqdGsYQllIPkuYRpmIEb3Jov80w Cc: "Carey, Timothy \(Timothy\)" , "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 14 May 2014 07:38:11 -0000 On Wed, May 14, 2014 at 09:59:36AM +0300, marc. ibrahim wrote: > On Wed, 14 May 2014 07:52:12 +0200, Juergen Schoenwaelder wrote > > On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: > > > > > > ma-suppression-task-names<0..*> and > > > ma-suppression-schedule-names<0..*> are strings containing names of > > > tasks and schedules. If we just allow to have the same name multiple > > > times, a pairing association could be done between tasks without > > > changing the information model. > > > > > > For example, ma-suppression-task-names = [T1 T1 T2 T2 T3 *] and > > > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1 > > > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all > > > schedules, and schedule S4 will be suppressed. Does this change the > > > information model Tim? > > > > I do not think this is needed since you can have multiple suppression > > objects. But defining the intersection of > > > > ma-suppression-task-names = [T1 T2] > > ma-suppression-schedule-names = [S1 S2] > > > > may not be that clear. The union is clear, suppress tasks T1 and T2 > > and anything started by S1 and S2. Is the intersection interpretation > > suppress any T1 started by S1, any T2 started by S1, any T1 started by > > S2, any T2 started by S2? This is not really an intersection - a > > strict intersection interpretation would likely lead to an empty set. > > > > No, this is my proposition. Intersection as I understood from Tim, is different. > > Let's have a general suppression object: > > ma-suppression-task-names = [T1 ... Tn] > ma-suppression-schedule-names = [S1 ... Sm] > > > Intersection means: Ti will be suppressed from any schedule S1 ... Sm starting Ti. > > Union means: Tasks T1 to Tn are all suppressed (from all MA schedules, isn't it JS?) and > all tasks started by S1 to Sm should be suppressed too. > > Pairing: m=n. Ti suppressed from Si. > > I see the intersection (or another term) definition is as clear as union IMO. If I > understood you well JS, I see that union cannot perform all suppression possibilities. > For example, how to suppress only a subset from a given schedule? > Intersection can do it with one or more suppression objects. > Pairing solution needs only one object to do any suppression combination. > I do not like pairing. I am fine with intersection or alternatively to remove the capability to have both a task list and a schedule list in a suppression. I think we should not over engineer suppression. /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 May 14 02:02: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 99A711A0276 for ; Wed, 14 May 2014 02:02:30 -0700 (PDT) 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 nKwGi0gwhnz9 for ; Wed, 14 May 2014 02:02:28 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 3862A1A0273 for ; Wed, 14 May 2014 02:02:28 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 14 May 2014 10:02:23 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Wed, 14 May 2014 10:01:49 +0100 From: To: , Date: Wed, 14 May 2014 10:01:47 +0100 Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9vR4Gd4MZ3RAKbRiy4WcyMrhq21AACm2dA Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <20140514064545.M74784@usj.edu.lb> <20140514073758.GA91397@elstar.jacobs.jacobs-university.de> In-Reply-To: <20140514073758.GA91397@elstar.jacobs.jacobs-university.de> 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/H09JdUFl8SncGbyG6YDb4-sJobo Cc: timothy.carey@alcatel-lucent.com, lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 14 May 2014 09:02:30 -0000 I also would not over engineer suppression. I'd either interpret as the Uni= on, or else not allow both a task and schedule list in a suppression. > > Union means: Tasks T1 to Tn are all suppressed (from all MA > schedules, > > isn't it JS?) and all tasks started by S1 to Sm should be suppressed > too. > > > > Pairing: m=3Dn. Ti suppressed from Si. > > > > I see the intersection (or another term) definition is as clear as > > union IMO. If I understood you well JS, I see that union cannot > perform all suppression possibilities. > > For example, how to suppress only a subset from a given schedule? > > Intersection can do it with one or more suppression objects. > > Pairing solution needs only one object to do any suppression > combination. > > >=20 > I do not like pairing. I am fine with intersection or alternatively to > remove the capability to have both a task list and a schedule list in > a suppression. I think we should not over engineer suppression. >=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 nobody Wed May 14 02:54: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 A52E91A0299 for ; Wed, 14 May 2014 02:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.898 X-Spam-Level: ** X-Spam-Status: No, score=2.898 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=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 0upyvNs9ENAM for ; Wed, 14 May 2014 02:54:31 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 27ADD1A0298 for ; Wed, 14 May 2014 02:54:30 -0700 (PDT) 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; Wed, 14 May 2014 10:54:31 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Wed, 14 May 2014 10:53:38 +0100 From: To: , , , , Date: Wed, 14 May 2014 10:53:37 +0100 Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9sk0ny5phkhbGfT5ir/PpSZna0xACxrXAw Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> <20140423145224.M63656@usj.edu.lb> <20140423151059.GE1056@elstar.local> <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> <20140423221748.M2036@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcate l-lucent.com> <20140510193741.M70435@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954016F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140510205713.M39371@usj.edu.lb> In-Reply-To: <20140510205713.M39371@usj.edu.lb> 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/S6RoEgS-p_k56WK0GBuRFewJWxo Cc: lmap@ietf.org Subject: Re: [lmap] Timer: Poisson distribution question 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, 14 May 2014 09:54:36 -0000 Just to acknowledge that this (just having spread as a positive from Ti) is= what I'll implement in the next revision of the Information Model unless t= here are further discussions. Trevor Burbridge >-----Original Message----- >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >Sent: 10 May 2014 22:03 >To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen Schoenwaelder >Cc: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org >Subject: RE: [lmap] Timer: Poisson distribution question > >The simplest to do, is to spread starting from Ti. So, all you need is to = specify only >one parameter: the spread. random values will be picked from between Ti an= d >Ti+spread. > >If you want to control spread position, then yes, you need an offset param= eter. >Random values will then be picked between Ti+offset and Ti+offset + spread= . > >BR, > >Marc. > > >On Sat, 10 May 2014 20:43:54 +0000, Carey, Timothy (Timothy) wrote >> Marc, >> >> So we can do Xmin + spread or Xmax - spread or Xmax-Xmin but you need >> the offset from Ti to allow for a negative spread from Ti, right? >> >> BR, >> Tim >> >> -----Original Message----- >> From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> Sent: Saturday, May 10, 2014 3:17 PM >> To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen >> Schoenwaelder >> Cc: trevor.burbridge@bt.com; lmap@ietf.org >> Subject: RE: [lmap] Timer: Poisson distribution question >> >> Tim, >> >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> >> I agree with Ken that Xmin is superfluous. The essential parameter is >> the spread. I suggested Xmin just to be able to control the spread >> around Ti, but this is not really important. We can just say that the >> time values will be chosen between Ti and Ti+spread. >> >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. >> >> As the draft says, the goal of randomness is to spread the load by >> preventing multiple events from occurring simultaneously. Given the >> spread interval, the uniform distribution is mathematically the best >> to achieve it. I don't see why we should use normal distribution, >> which will tend to concentrate values around some mean. >> >> >If so is this the Uniform-Discrete distribution? >> >> I suggested to express the randomness as an integer number of >> milliseconds. So the answer is yes. >> >> Finally, I would like to add a comment about the Poisson distribution >> that was the initial cause of this discussion about timer. I think >> that there was a confusion with the Poisson process used to randomize >> the instants of packets transmission in active measurements. In fact, >> Poisson in measurement context is a process describing the occurrence >> of events and not a probability distribution for a time interval (the >> related distribution is exponential as explained below). So, if a >> Poisson process is to be used in lmap context, it applies in my opinion = only to >periodic schedules as follows: >> >> - The period specified in the timing object is in fact an average pe= riod. >> For example, if an MA event occurs at Ti, the next event will occur in >> average at Ti+period >> >> - After an event occurs at Ti, the MA will choose a real number X >> according to an exponential distribution of mean =3D period. Next event >> will then occur at Ti+X. >> >> - When the inter-event time is exponential, the whole process is >> known as a Poisson process of rate =3D 1/period. >> >> - In this approach, we do not specify a spread around predefined >> instants Tis. We rather randomize the whole interval separating two >consecutive Tis. >> >> This could be another viable (but may be more complicated??) approach >> for periodic events. >> >> BR, >> >> Marc. >> >> On Sat, 10 May 2014 18:52:50 +0000, Carey, Timothy (Timothy) wrote >> > Ken, >> > >> > I am in the process of commenting on the BBF model TR-181i2a8 for >StrawBallot. >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> > >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. - If so is this the Uniform-Dis= crete >distribution? >> > >> > Thanks, >> > Tim >> > >> > -----Original Message----- >> > From: KEN KO [mailto:KEN.KO@adtran.com] >> > Sent: Thursday, April 24, 2014 7:17 AM >> > To: marc.ibrahim; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org >> > Subject: RE: [lmap] Timer: Poisson distribution question >> > >> > Since Ti+Xmin is non-random, Xmin is not really needed as a separate >> > parameter. Just offset Ti to the desired minimum time and let the >> > spread range from Ti to Ti+Xmax. >> > >> > Other than that nit, +1 >> > >> > -----Original Message----- >> > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > Sent: Wednesday, April 23, 2014 7:08 PM >> > To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > lmap@ietf.org >> > Subject: Re: [lmap] Timer: Poisson distribution question >> > >> > Based on what has been exchanged, I suggest the following: >> > >> > 1- Exact randomness definition and operation >> > -------------------------------------------- >> > IMHO, we need to define how exactly the randomness is applied. >> > >> > For a given event E (e.g. running a measurement task, start >> > reporting,...), let Ti be the predefined (scheduled) instant of the i= th >occurrence of E. >> > Adding randomness means that the event E will happen at time Ti + X >> > instead of Ti, where X is a random variable. If Xmin and Xmax denote >> > the minimum and maximum possible values of X repectively, then the >> > event E will take place at an instant randomly chosen between >> > Ti+Xmin and Ti+Xmax. The spread is equal to Xmax-Xmin >> > >> > Ti+Xmin Ti Ti+Xmax >> > ---------|-----------------|-------------------|----------- >> > >> > <-------------------------------------> >> > Spread >> > >> > Note that Xmin could be negative if E can occur before Ti like in the = figure. >> > I think that the most common values of Xmin would be 0 or (-spread/2). >> > >> > 2- Random generation of X >> > --------------------------- >> > To make it simple as stated by many, X could an integer number of >> > milliseconds uniformly chosen in the interval [Xmin, Xmax]. Xmin, >> > Xmax, and hence spread, are all integers (milliseconds). >> > >> > Then the MA has to define a function UNIF(Xmin, Xmax) or >> > equivalently UNIF(Xmin, spread) that generates a random number of >> > milliseconds from [Xmin, Xmax] interval. The controller has just to >> > send two integer variables (Xmin, >> > Xmax) or (Xmin, spread) to the MA in the timing object. >> > >> > In this minimalist approach, no need to specify the nature of >> > distribution in the timing object since it is assumed to be the unifor= m one. >> > >> > BR, >> > >> > Marc. >> > >> > On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote >> > > This example confuses resolution of the measurement result with >> > > resolution and accuracy of the time at which the measurement is >> > > initiated. Measuring round trip latencies on a Gigabit LAN may >> > > well require microsecond resolution, which could be within the >> > > capabilities of a higher end MA. But that doesn't require >> > > microsecond resolution of the time at which the measurement is >> > > initiated. In addition, for microsecond resolution on the Timer to b= e >meaningful would require synchronization to that resolution across differe= nt MAs >in the network. >> > > >> > > I'm in favor of keeping things simple and specifying Timer >> > > resolution in >> milliseconds. >> > > >> > > -----Original Message----- >> > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam >> > > Hakimi >> > > Sent: Wednesday, April 23, 2014 11:33 AM >> > > To: Juergen Schoenwaelder; marc.ibrahim >> > > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > It depends what the performance goal of the measurement is. A ping >> > > packet in a Gigabit network is just under 1 microseconds and with >> > > fast processors a packet can be sent and received at the same time i= f >granularity is milliseconds. >> > > >> > > This does not even take into account 10Gig networks, not that they >> > > would be at consumer sites, but they would sure exist inside a ISP n= etwork. >> > > >> > > Sharam >> > > >> > > -----Original Message----- >> > > From: Juergen Schoenwaelder >> > > [mailto:j.schoenwaelder@jacobs-university.de] >> > > Sent: Wednesday, April 23, 2014 11:11 AM >> > > To: marc.ibrahim >> > > Cc: trevor.burbridge@bt.com; Sharam Hakimi; >> > > timothy.carey@alcatel-lucent.com; >> > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > I believe randomization with a granularity of milliseconds is good e= nough. >> > > Within an implementation of a measurement task, one may use more >> > > precise timers. But for the randomization of the start of >> > > measurement tasks or the sending of reports, milliseconds seem to >> > > be sufficient (since there will be likely other delays introduced >> > > by the operating system that may get into the some order for startin= g a >measurement task or triggering a report). >> > > >> > > /js >> > > >> > > On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote: >> > > > I would say that choosing the millisecond as atomic time >> > > > alleviates constraints on both timer granularity and generator cap= acity. >> > > > >> > > > I still don't see a real measurement example where few >> > > > microseconds would really >> > matter. >> > > > >> > > > Practically, can a program deal with microseconds timers in >> > > > computers and >> > smartphones? >> > > > This is the scale of the OS, no? >> > > > >> > > > Marc. >> > > > >> > > > On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote >> > > > > So the question is really do we want to design for extremely >> > > > > constrained devices? I'd argue that if this is a problem for >> > > > > them then they are really going to struggle with the >> > > > > Instruction information or >> > measurement results. >> > > > > >> > > > > Trevor. >> > > > > >> > > > > >-----Original Message----- >> > > > > >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >Sent: 23 April 2014 15:00 >> > > > > >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > > >> > > > > >Here is how I see the problem. >> > > > > > >> > > > > >First we have to separate time granularity and random generatio= n. >> > > > > > >> > > > > >Time granularity depends on the timer running on the MA. e.g >> > > > > >microseconds scale means that the MA timer increment each >microsecond. >> > > > > > >> > > > > >When MA wants to generate a random time, he has to choose an >> > > > > >integer number of microseconds to count. So the problem is >> > > > > >always an integer (discrete) number generation. >> > > > > > >> > > > > >Now, if the random generator can attain the maximum integer >> > > > > >(so the maximum possible random time), then, as Trevor says, >> > > > > >no need for the timeStep I talked about, since all possible >> > > > > >durations will be expressed >as >> > multiple of microseconds. >> > > > > > >> > > > > > >> > > > > >For example, a 32 bits random generator could generate up to >> > > > > >a maximum value of 4 billions. In microseconds, this is equal >> > > > > >to less than 2 >> hours. >> > > > > > >> > > > > >It all depends on the capacity of the generator. >> > > > > >Marc. >> > > > > > >> > > > > > >> > > > > >On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote >> > > > > >> So what is the argument for the latter (discrete) option? >> > > > > >> >> > > > > >> Trevor. >> > > > > >> >> > > > > >> >-----Original Message----- >> > > > > >> >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >> >Sent: 23 April 2014 14:10 >> > > > > >> >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >> >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >> >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> > >> > > > > >> >Trevor, you're right. >> > > > > >> >it is just about whether we want a discrete or continuous ge= nerator. >> > > > > >> >If we use a continuous uniform generator, than it is >> > > > > >> >enough to specify the maximum time. >> > > > > >> >With a discrete random generator, you need to specify an >> > > > > >> >additional time granularity. >> > > > > >> > >> > > > > >> >BR, >> > > > > >> > >> > > > > >> >Marc. >> > > > > >> > >> > > > > >> > >> > > > > >> >On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote >> > > > > >> >> I'm not sure I get the point of allowing coarser >> > > > > >> >> granularity that the MA is capable of. If I want the MA >> > > > > >> >> to test/report sometime within a minute window, why not >> > > > > >> >> allow that to happen with the maximum resolution the MA >> > > > > >> >> is capable >> > > > > >> >of? >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Sharam Hakimi >> > > > > >> >> Sent: 23 April 2014 13:58 >> > > > > >> >> To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R; >> > > > > >> >> lmap@ietf.org >> > > > > >> >> Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Marc's suggestion works for me. That allows better >> > > > > >> >> interoperability in my >> > > > > >> >opinion. >> > > > > >> >> >> > > > > >> >> I do agree that we need a common "structure" and "names". >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:47 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> No - I am using the variable of your Information Model >> > > > > >> >> (LowerLimit, >> > > > > >> >UpperLimit, >> > > > > >> >> Spread) - works so far. Marc suggested a TimeStep >> > > > > >> >> parameter so we don't lockin on a specific microsecond, >> > > > > >> >> millisecond, second thing - I am open >> > > > > >to that. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:41 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Agree we need to have well defined function names. I >> > > > > >> >> thought you were also suggesting different functions >> > > > > >> >> needed different input >> > parameters. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 23 April 2014 13:36 >> > > > > >> >> To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Its not that the Measurement controller has to configure >> > > > > >> >> the timer for the >> > > > > >MA. >> > > > > >> >> >> > > > > >> >> If we do not specify the functions and variable names, >> > > > > >> >> the measurement controller doesn't have a standard way >> > > > > >> >> of configuring a >timer. >> > > > > >> >> >> > > > > >> >> For example - If I specify for a Uniform distribution >> > > > > >> >> function called "Uniform" you have a variable called >> > > > > >> >> "UpperLimit", the MA will implement the specification; >> > > > > >> >> the controller will implement the >> > > > > >specification and things work. >> > > > > >> >> >> > > > > >> >> If I do not specify anything for the Uniform >> > > > > >> >> distribution function >> > > > > >> >> - MA vendor >> > > > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" >> > > > > >> >> and maybe an >> > > > > >"Enable" >> > > > > >> >> parameter for good measure; MA vendor 2 can call it "U" >> > > > > >> >> and have an attribute "X that is an integer". >> > > > > >> >> >> > > > > >> >> Now put that variation on steroids based on the number >> > > > > >> >> of MA vendors - That is why we specify things, right? >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:24 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The measurement controller has to communicate what tests >> > > > > >> >> have to be run on >> > > > > >> >an >> > > > > >> >> MA, for how long, when to run them, what test results >> > > > > >> >> are generated, etc. Why would configuring this parameter >> > > > > >> >> be any different. Maybe I am missing >> > > > > >> >something. >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:16 AM >> > > > > >> >> To: Sharam Hakimi; >> > > > > >> >trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> So the burden is on the Measurement controller to know >> > > > > >> >> the functions and inputs specifications for each >> > > > > >> >> possible MA vendor; not something I would want to have >> > > > > >> >> to do as a Measurement controller >> > > > > >vendor. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:14 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> I do not see why vendor A or B or C matters. They would >> > > > > >> >> all be under the control of one Measurement Controller >> > > > > >> >> which would specify what inputs to use for all MAs in a gr= oup. >> > > > > >> >> >> > > > > >> >> As Trevor also mentioned this timer can be used for both >> > > > > >> >> testing and reporting and I would strongly suggest to >> > > > > >> >> have microsecond granularity. For reporting one could >> > > > > >> >> choose seconds in terms of >> > > > > >microseconds. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:04 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> If we don't define the inputs for each function (leaving >> > > > > >> >> the inputs >> > > > > >> >> opaque) you will have interop problems. MA vendor 1 >> > > > > >> >> uses these 2 inputs >> > > > > >named "A" >> > > > > >> >and >> > > > > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" >> > > > > >> >> for the same >> > > > > >function. >> > > > > >> >> >> > > > > >> >> I think we need to avoid that if we realistically want >> > > > > >> >> the Randomness function to be used efficiently. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 2:55 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The random timing can be used for both specifying when a >> > > > > >> >> test runs, or when a report is sent (or any other task >> > > > > >> >> such as contacting the Controller). It doesn't have to be = used, but >it can be. >> > > > > >> >> >> > > > > >> >> I don't really want different input variable for >> > > > > >> >> different functions. I don't see we need to. Also if we >> > > > > >> >> do, then we would have to have schema for each function >> > > > > >> >> to specify which inputs are expected (like the >> > > > > >> >> measurement task registry). I'd like to >> avoid >> > that. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 22 April 2014 22:07 >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >> Burbridge,T,Trevor, >> > > > > >> >> TUB8 R Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Sharam, >> > > > > >> >> >> > > > > >> >> We are talking about offsets for when to report; in the >> > > > > >> >> world we live in milliseconds is sufficient - IMHO. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:59 PM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the min/max should have microseconds granularity. >> > > > > >> >> Milliseconds would not be accurate enough. >> > > > > >> >> >> > > > > >> >> Personally, I would not trust my periodic tests in a >> > > > > >> >> large scale deployment to a random number generator and >> > > > > >> >> would want to know exactly how and when >> > > > > >> >tests >> > > > > >> >> would be run. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:16 PM >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> The data model is extensible by vendors so we can add >> > > > > >> >> functions and input variables as we need. >> > > > > >> >> >> > > > > >> >> However we have to decide on which small subset we >> > > > > >> >> actually want to >> > > > > >> >standardize. >> > > > > >> >> >> > > > > >> >> You suggested the Uniform and Normal which is fine but >> > > > > >> >> for the model we need to go farther by defining the >> > > > > >> >> specific function along with which inputs are used by >> > > > > >> >> the function to derive what random number. Otherwise we >> > > > > >> >> will have 2 implementers of the same standard algorithm >implement different variations. - Not good. >> > > > > >> >> >> > > > > >> >> So I suggest we keep this simple. >> > > > > >> >> >> > > > > >> >> Uniform Discrete - input variables - maximum [positive >> > > > > >> >> integer] Gaussian -input variables - mean of min/max, >> > > > > >> >> spread =3D standard deviation >> > > > > >> >> >> > > > > >> >> The min/max would be milliseconds - Spread would be an int= eger. >> > > > > >> >> >> > > > > >> >> This sound OK? >> > > > > >> >> >> > > > > >> >> BR >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 8:23 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the Periodic Timer distribution needs to have >> > > > > >> >> closer configuration control by the user and I think >> > > > > >> >> your 2nd choice attempts to provide it but having a >> > > > > >> >> discrete interval definition is a better way >> > > > > >to go. >> > > > > >> >> >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Sent: Tuesday, April 22, 2014 4:35 AM >> > > > > >> >> To: >> > > > > >> >> timothy.carey@alcatel-lucent.com> > > > > >> >> catel- >> > > > > >> >lucent.com>; >> > > > > >> >> lmap@ietf.org Subject: Re: [lmap] Ti= mer: >> > > > > >> >> Poisson distribution question >> > > > > >> >> >> > > > > >> >> On continuous counterparts of Poisson I'm far from any >> > > > > >> >> expert and it would certainly be up to the user to >> > > > > >> >> decide if such functions were suitable replacements for >> > > > > >> >> the discrete Poisson function. Yes it would be a >> > > > > >> >> different function even if there was perfect fit (which >> > > > > >> >> they are not) as one is continuous and one is >> > discrete: >> > > > > >> >> http://cmscience.blogspot.co.uk/2008/04/mt- >> > > > > >> >6- >> > > > > >> >> poisson-and-gamma-distribution.html >> > > > > >> >> http://arxiv.org/abs/1303.5990 >> > > > > >> >> >> > > > > >> >> As I tried to say the current Information Model can take >> > > > > >> >> either discrete or continuous functions - only that >> > > > > >> >> there is currently no explicit support for specifying >> > > > > >> >> the interval used for a discrete function. I was questioni= ng the >need to add this. >> > > > > >> >> >> > > > > >> >> Personally I'd think that Normal and Uniform >> > > > > >> >> distributions would cover most needs, but the framework >> > > > > >> >> should be flexible in this >> regard. >> > > > > >> >> >> > > > > >> >> Trevor. >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Carey, Timothy >> > > > > >> >(Timothy) >> > > > > >> >> Sent: 19 April 2014 20:24 >> > > > > >> >> To: lmap@ietf.org >> > > > > >> >> Subject: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Team, >> > > > > >> >> >> > > > > >> >> The BBF is looking at standardizing the model for Timers >> > > > > >> >> as suggested by the IETF LMAP information model. >> > > > > >> >> >> > > > > >> >> During the review of the timers we had addition >> > > > > >> >> questions regarding Trevors response to the Poisson >> > > > > >> >> distribution for the Randomness of the >> > > > > >Periodic Timer. >> > > > > >> >> >> > > > > >> >> Trevor responded: >> > > > > >> >> >> > > > > >> >> "Yes this does need to be clarified. I was assuming a >> > > > > >> >> distribution about the mean (i.e. the timing given is >> > > > > >> >> the mean). The spread would be the standard deviation >> > > > > >> >> (could use mean deviation or something else but I see no >> > > > > >> >> advantage as long as we all know what it refers to) and >> > > > > >> >> need to change to a float. The upper and lower cuts >> > > > > >> >> would be in seconds +/- the mean (also needs to change >> > > > > >> >to >> > > > > >> >> float) and are simply used to trim the function - >> > > > > >> >> obviously needed on a uniform distribution but useful to >> > > > > >> >> constrain other >functions. >> > > > > >> >> >> > > > > >> >> I will make all this clear in the next release. >> > > > > >> >> >> > > > > >> >> As for poisson I think there are 3 options: >> > > > > >> >> >> > > > > >> >> - Use a continuous form instead >> > > > > >> >> >> > > > > >> >> - Have the discrete interval implicit in the functi= on choice >> > > > > >> >e.g."poisson_1_sec" >> > > > > >> >> >> > > > > >> >> - Add an interval to the information model. >> > > > > >> >> >> > > > > >> >> I was really thinking about the first, but I don't see >> > > > > >> >> the problem with the second. However I wouldn't do the >> > > > > >> >> third unless they was a demonstrable value to supporting >> > > > > >> >> discrete functions (rather than continuous >> > > > > >versions of them). " >> > > > > >> >> >> > > > > >> >> But as people looked at Trevors response there were >> > > > > >> >> additional >questions: >> > > > > >> >> >> > > > > >> >> I don't understand what Trevor means about the Poisson >> > > > > >> >> distribution. As far as I know, it is a discrete >> > > > > >> >> distribution, so a "continuous form" would be a >> > > > > >> >> different distribution and not Poisson. And I believe >> > > > > >> >> that we do need a >continuous >> > distribution. >> > > > > >> >> But what matters is that the definition is clear, not >> > > > > >> >> the particular >> > > > distribution >> > > > > >(I don't have an opinion on that). >> > > > > >> >> >> > > > > >> >> Could some please clarify this for us - Are we planning >> > > > > >> >> something other than Poisson method; better yet is there >> > > > > >> >> a definition for the types of >> > > > > >> >> distribution: Poisson, Normal and Uniform. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Tim >> > > > > >> > >> > > > > >> > >> > > > > >> >-- >> > > > > >> >Open WebMail Project (http://openwebmail.org) >> > > > > >> >> > > > > >> _______________________________________________ >> > > > > >> lmap mailing list >> > > > > >> lmap@ietf.org >> > > > > >> https://www.ietf.org/mailman/listinfo/lmap >> > > > > > >> > > > > > >> > > > > >-- >> > > > > >Open WebMail Project (http://openwebmail.org) >> > > > > >> > > > > _______________________________________________ >> > > > > lmap mailing list >> > > > > lmap@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/lmap >> > > > >> > > > >> > > > -- >> > > > Open WebMail Project (http://openwebmail.org) >> > > > >> > > > _______________________________________________ >> > > > 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 >> > > >> > > _______________________________________________ >> > > 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 >> > >> > -- >> > Open WebMail Project (http://openwebmail.org) >> >> -- >> Open WebMail Project (http://openwebmail.org) > > >-- >Open WebMail Project (http://openwebmail.org) From nobody Wed May 14 03:11: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 205A71A0290 for ; Wed, 14 May 2014 03:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.651] 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 YZv49PZ6yVeu for ; Wed, 14 May 2014 03:11:04 -0700 (PDT) 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 99D4B1A027E for ; Wed, 14 May 2014 03:11:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUIAI9Ac1OHCzIm/2dsb2JhbABZgmUhT1EHgmioYAYFkkIbhzsBGYEEFnSCJQEBAQEDAQEBDxEROgQFDgYBCA0EAQMBAQMCBh0DAgQlCxQBAgUBCQEEAQkJCAEZiB8BBwWhNYpHpQwXgSqEKogjAyM+gm82gRUElViFNoVVjAGDNoFvQQ X-IronPort-AV: E=Sophos;i="4.97,1051,1389762000"; d="scan'208";a="63381470" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 May 2014 06:10:57 -0400 X-OutboundMail_SMTP: 1 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; 14 May 2014 06:09:19 -0400 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; Wed, 14 May 2014 12:10:55 +0200 From: "Romascanu, Dan (Dan)" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-05.txt Thread-Index: Ac9vXMg0t0CRoVQiROGPMIwRnQAM2w== Date: Wed, 14 May 2014 10:10:54 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7E5C84@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/C9eoLMWcldv_yWTsc8jhzkf5m3Y Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-05.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: Wed, 14 May 2014 10:11:10 -0000 VGhhbmtzIHRvIGF1dGhvcnMgYW5kIGFsbCB0aGUgY29udHJpYnV0b3JzIGZvciB0aGUgZ29vZCB3 b3JrLiANCg0KV2UgaGFkIHR3byBXR0xDcyBmb3IgdGhpcyBkb2N1bWVudC4gQWxsIGZvbGtzIHdo byBtYWRlIGNvbW1lbnRzIGFyZSBraW5kbHkgaW52aXRlZCB0aGF0IGFsbCB0aGVpciBjb21tZW50 cyB3ZXJlIGFkZHJlc3NlZC4gSSBkbyBub3QgYmVsaWV2ZSB0aGF0IHdlIG5lZWQgYSB0aGlyZCBX R0xDLiBJIHdpbGwgbGVhdmUgYSBmZXcgZGF5cyBmb3IgZm9sa3MgdG8gcmVhZCB0aGlzIHZlcnNp b24gYW5kIG1ha2Ugc3VyZSB0aGF0IGl0IGlzIGdvb2QgZW5vdWdoIHRvIGJlIHN1Ym1pdHRlZCB0 byB0aGUgSUVTRy4gSWYgYW55Ym9keSBoYXMgY29uY2VybnMgYWJvdXQgdGhpcyBwcm9jZXNzLCBu ZWVkcyBtb3JlIHRpbWUgdG8gcmVhZCBhbmQgcmV2aWV3LCBvciBoYXMgbmV3IHN1YnN0YW50aWFs IGNvbW1lbnRzIC0gcGxlYXNlIHNwZWFrIHVwIGluIHRoZSBuZXh0IGZldyBkYXlzLiANCg0KVGhh bmtzIGFuZCBSZWdhcmRzLA0KDQpEYW4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP Zg0KPiBwaGlsaXAuZWFyZGxleUBidC5jb20NCj4gU2VudDogVHVlc2RheSwgTWF5IDEzLCAyMDE0 IDg6NTMgUE0NCj4gVG86IGxtYXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2xtYXBdIEZXOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstDQo+IDA1 LnR4dA0KPiANCj4gSGksDQo+IA0KPiBXZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9m IHRoZSBmcmFtZXdvcmsuIFRoYW5rcyB2ZXJ5IG11Y2ggZm9yDQo+IHRoZSBjb21tZW50cyBhbmQg ZGlzY3Vzc2lvbiBkdXJpbmcgdGhlIDJuZCBXR0xDLCB0aGluayB0aGV5J3JlIGFsbA0KPiByZXNv bHZlZC4gU29ycnkgaWYgd2UgbWlzc2VkIGFueSwgcGxlYXNlIGxldCB1cyBrbm93IGlmIG5vdCAo b2ZmLWxpc3QgaWYgYSBuaXQpLg0KPiANCj4gSGVyZSBhcmUgdGhlIG1haW4gY2hhbmdlczoNCj4g DQo+IDEyLjUuICBGcm9tIC0wNCB0byAtMDUNCj4gDQo+ICAgIG8gIGNsYXJpZmllZCB2YXJpb3Vz IHNjb3BpbmcgY29tbWVudHMgYnkgdXNpbmcgdGhlIHBocmFzZSAic2NvcGUgb2YNCj4gICAgICAg aW5pdGlhbCBMTUFQIHdvcmsiIChhdm9pZGluZyAic2NvcGUgb2YgTE1BUCBXRyIgc2luY2UgdGhp cyBtYXkNCj4gICAgICAgY2hhbmdlIGluIHRoZSBmdXR1cmUpDQo+IA0KPiAgICBvICBhZGRlZCBh IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgLSBhbGxvd3MgdGhlIENvbnRyb2xsZXIgdG8gdXBkYXRl DQo+ICAgICAgIHRoZSBNQSBhYm91dCBpbmZvcm1hdGlvbiB0aGF0IGl0IG9idGFpbmVkIGR1cmlu ZyB0aGUgYm9vdHN0cmFwcGluZw0KPiAgICAgICBwcm9jZXNzIChmb3IgY29uc2lzdGVuY3kgd2l0 aCBJbmZvcm1hdGlvbiBNb2RlbCkNCj4gDQo+ICAgIG8gIFJlbW92ZWQgb3Zlci1kZXRhaWxlZCBp bmZvcm1hdGlvbiBhYm91dCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4NCj4gICAgICAgdGhlIGRp ZmZlcmVudCBpdGVtcyBpbiBJbnN0cnVjdGlvbiwgYXMgdGhpcyBzZWVtcyBtb3JlIGFwcHJvcHJp YXRlDQo+ICAgICAgIGZvciB0aGUgaW5mb3JtYXRpb24gbW9kZWwuICBDbGFyaWZpZWQgdGhhdCB0 aGUgbGlzdHMgZ2l2ZW4gYXJlDQo+ICAgICAgIGFib3V0IHRoZSBhaW1zIGFuZCBub3QgYSBsaXN0 IG9mIGluZm9ybWF0aW9uIGVsZW1lbnRzICh0aGVzZSB3aWxsDQo+ICAgICAgIGJlIGRlZmluZWQg aW4gZHJhZnQtaWV0Zi1pbmZvcm1hdGlvbi1tb2RlbCkuDQo+IA0KPiAgICBvICB0aGUgTWVhc3Vy ZW1lbnQgTWV0aG9kLCBzcGVjaWZpZWQgYXMgYSBVUkkgdG8gYSByZWdpc3RyeSBlbnRyeSAtDQo+ ICAgICAgIHJhdGhlciB0aGFuIGEgVVJODQo+IA0KPiAgICBvICBNQSBjb25maWd1cmVkIHdpdGgg dGltZSBsaW1pdCBhZnRlciB3aGljaCwgaWYgaXQgaGFzbid0IGhlYXJkIGZyb20NCj4gICAgICAg Q29udHJvbGxlciwgdGhlbiBpdCBzdG9wcyBydW5uaW5nIE1lYXN1cmVtZW50IFRhc2tzIChyYXRo ZXIgdGhhbg0KPiAgICAgICB0aGlzIGJlaW5nIHBhcnQgb2YgYSBTY2hlZHVsZSkNCj4gDQo+ICAg IG8gIGNsYXJpZmllZCB0aGVyZSBpcyBubyBkaXN0aW5jdGlvbiBiZXR3ZWVuIGhvdyBjYXBhYmls aXRpZXMsDQo+ICAgICAgIGZhaWx1cmUgYW5kIGxvZ2dpbmcgaW5mb3JtYXRpb24gYXJlIHRyYW5z ZmVycmVkIChhbGwgY2FuIGJlIHdoZW4NCj4gICAgICAgcmVxdWVzdGVkIGJ5IENvbnRyb2xsZXIg b3IgYnkgTUEgb24gaXRzIG93biBpbml0aWF0aXZlKS4NCj4gDQo+ICAgIG8gIHJlbW92ZWQgbWVu dGlvbiBvZiBEYXRhIFRyYW5zZmVyIFRhc2tzLiAgVGhpcyBhYnN0cmFjdGlvbiBpcyBsZWZ0DQo+ ICAgICAgIHRvIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBpLWQNCj4gDQo+ICAgIG8gIGFkZGVkIERl cGxveW1lbnQgc3ViLXNlY3Rpb24gYWJvdXQgTWVhc3VyZW1lbnQgQWdlbnQgZW1iZWRkZWQgaW4N Cj4gICAgICAgSVNQIE5ldHdvcmsNCj4gDQo+ICAgIG8gIHZhcmlvdXMgb3RoZXIgc21hbGxlciBp bXByb3ZlbWVudHMsIGFyaXNpbmcgZnJvbSB0aGUgMm5kIFdHTEMNCj4gDQo+IA0KPiBTdXBwcmVz c2lvbjotDQo+IFRoZSByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBzdXBwcmVzc2lvbiBkb2VzbuKA mXQgc2VlbSB0byBoYXZlIGJlZW4NCj4gY29uY2x1c2l2ZS4gSW4gb3JkZXIgdG8gbWFrZSBwcm9n cmVzcywgYW5kIGFzIHRoZSAtMDQgdGV4dCByZWZsZWN0ZWQgdGhlDQo+IGRpc2N1c3Npb25zIC9h Z3JlZW1lbnQgZHVyaW5nIHRoZSBMb25kb24gSUVURiwgb3VyIHN1Z2dlc3Rpb24gaXMgbm90IHRv DQo+IG1ha2UgY2hhbmdlcyB0byB0aGlzIHNlY3Rpb24uIFdlIGNoZWNrZWQgd2l0aCBhIGZldyBu b24tYXV0aG9ycyAoQmFyYmFyYSwNCj4gS2VuLCBKdWVyZ2VuKSB3aG8nZCBiZWVuIG1vc3QgYWN0 aXZlIG9uIHRoaXMgdG9waWMgYW5kIHRoZXkncmUgT0sgd2l0aCB0aGlzDQo+IGFwcHJvYWNoLg0K PiANCj4gDQo+IFRoYW5rcw0KPiBQaGlsIGFuZCBmcmllbmRzDQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IDEzIE1heSAyMDE0IDE4OjIyDQo+IFRv OiBBYW1lciBBa2h0ZXI7IEFsIEMuIE1vcnRvbjsgQWwgTW9ydG9uOyBFYXJkbGV5LFBMLFBoaWxp cCxUVUI4IFI7IFBhdWwNCj4gQWl0a2VuOyBQYXVsIEFpdGtlbjsgTWFyY2VsbyBCYWdudWxvOyBF YXJkbGV5LFBMLFBoaWxpcCxUVUI4IFI7IE1hcmNlbG8NCj4gQmFnbnVsbzsgQnVyYnJpZGdlLFQs VHJldm9yLFRVQjggUjsgQWFtZXIgQWtodGVyOyBCdXJicmlkZ2UsVCxUcmV2b3IsVFVCOA0KPiBS DQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1sbWFw LWZyYW1ld29yay0wNS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt aWV0Zi1sbWFwLWZyYW1ld29yay0wNS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBQaGlsaXAgRWFyZGxleSBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRv cnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yaw0KPiBSZXZpc2lvbjoJ MDUNCj4gVGl0bGU6CQlBIGZyYW1ld29yayBmb3IgbGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnQgcGxh dGZvcm1zIChMTUFQKQ0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTA1LTEzDQo+IEdyb3VwOgkJbG1h cA0KPiBQYWdlczoJCTU0DQo+IFVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLQ0KPiAwNS50eHQNCj4gU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt bG1hcC1mcmFtZXdvcmsvDQo+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA1DQo+IERpZmY6ICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA1 DQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgTWVhc3VyaW5nIGJyb2FkYmFuZCBzZXJ2aWNlIG9uIGEg bGFyZ2Ugc2NhbGUgcmVxdWlyZXMgYSBkZXNjcmlwdGlvbg0KPiAgICBvZiB0aGUgbG9naWNhbCBh cmNoaXRlY3R1cmUgYW5kIHN0YW5kYXJkaXNhdGlvbiBvZiB0aGUga2V5IHByb3RvY29scw0KPiAg ICB0aGF0IGNvb3JkaW5hdGUgaW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlIGNvbXBvbmVudHMuICBU aGUgZG9jdW1lbnQNCj4gICAgcHJlc2VudHMgYW4gb3ZlcmFsbCBmcmFtZXdvcmsgZm9yIGxhcmdl LXNjYWxlIG1lYXN1cmVtZW50cy4gIEl0IGFsc28NCj4gICAgZGVmaW5lcyB0ZXJtaW5vbG9neSBm b3IgTE1BUCAobGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnQgcGxhdGZvcm1zKS4NCj4gDQo+IA0KPiAN Cj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRG IFNlY3JldGFyaWF0DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBsbWFwIG1haWxpbmcgbGlzdA0KPiBsbWFwQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcA0K From nobody Wed May 14 04:28: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 966E31A0059 for ; Wed, 14 May 2014 04:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-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 FXzL5nONmauH for ; Wed, 14 May 2014 04:27:52 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C67EE1A005B for ; Wed, 14 May 2014 04:27:52 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s4EBRaBC010371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 06:27:37 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s4EBRYOr018596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 07:27:34 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 14 May 2014 07:27:34 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "marc.ibrahim@usj.edu.lb" , "KEN.KO@adtran.com" , "sharam.hakimi@exfo.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAMH2AAABWvrAAAELs4AAIod6AAAAj6gAAAZ1bAAAAx60AAAFrJIAAAEmdgAAIBF/A///+ooCAAEZwgIAA3ImA/+awS0CAMvsTgIAAPebw///PCgCABY49gIAAKQeQ Date: Wed, 14 May 2014 11:27:33 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719542AB7@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> <20140423145224.M63656@usj.edu.lb> <20140423151059.GE1056@elstar.local> <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> <20140423221748.M2036@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcate l-lucent.com> <20140510193741.M70435@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954016F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140510205713.M39371@usj.edu.lb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] 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/7LGcThoi2AiXUlTuYFWyuf8c0pk Cc: "lmap@ietf.org" Subject: Re: [lmap] Timer: Poisson distribution question 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, 14 May 2014 11:27:58 -0000 Trevor, I think we said, because we wanted negative offsets, that we would need the= LowerLimit (offset) and spread. Thanks, Tim -----Original Message----- From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]=20 Sent: Wednesday, May 14, 2014 4:54 AM To: marc.ibrahim@usj.edu.lb; Carey, Timothy (Timothy); KEN.KO@adtran.com; s= haram.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Just to acknowledge that this (just having spread as a positive from Ti) is= what I'll implement in the next revision of the Information Model unless t= here are further discussions. Trevor Burbridge >-----Original Message----- >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >Sent: 10 May 2014 22:03 >To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen Schoenwaelder >Cc: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org >Subject: RE: [lmap] Timer: Poisson distribution question > >The simplest to do, is to spread starting from Ti. So, all you need is to = specify only >one parameter: the spread. random values will be picked from between Ti an= d >Ti+spread. > >If you want to control spread position, then yes, you need an offset param= eter. >Random values will then be picked between Ti+offset and Ti+offset + spread= . > >BR, > >Marc. > > >On Sat, 10 May 2014 20:43:54 +0000, Carey, Timothy (Timothy) wrote >> Marc, >> >> So we can do Xmin + spread or Xmax - spread or Xmax-Xmin but you need >> the offset from Ti to allow for a negative spread from Ti, right? >> >> BR, >> Tim >> >> -----Original Message----- >> From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> Sent: Saturday, May 10, 2014 3:17 PM >> To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen >> Schoenwaelder >> Cc: trevor.burbridge@bt.com; lmap@ietf.org >> Subject: RE: [lmap] Timer: Poisson distribution question >> >> Tim, >> >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> >> I agree with Ken that Xmin is superfluous. The essential parameter is >> the spread. I suggested Xmin just to be able to control the spread >> around Ti, but this is not really important. We can just say that the >> time values will be chosen between Ti and Ti+spread. >> >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. >> >> As the draft says, the goal of randomness is to spread the load by >> preventing multiple events from occurring simultaneously. Given the >> spread interval, the uniform distribution is mathematically the best >> to achieve it. I don't see why we should use normal distribution, >> which will tend to concentrate values around some mean. >> >> >If so is this the Uniform-Discrete distribution? >> >> I suggested to express the randomness as an integer number of >> milliseconds. So the answer is yes. >> >> Finally, I would like to add a comment about the Poisson distribution >> that was the initial cause of this discussion about timer. I think >> that there was a confusion with the Poisson process used to randomize >> the instants of packets transmission in active measurements. In fact, >> Poisson in measurement context is a process describing the occurrence >> of events and not a probability distribution for a time interval (the >> related distribution is exponential as explained below). So, if a >> Poisson process is to be used in lmap context, it applies in my opinion = only to >periodic schedules as follows: >> >> - The period specified in the timing object is in fact an average pe= riod. >> For example, if an MA event occurs at Ti, the next event will occur in >> average at Ti+period >> >> - After an event occurs at Ti, the MA will choose a real number X >> according to an exponential distribution of mean =3D period. Next event >> will then occur at Ti+X. >> >> - When the inter-event time is exponential, the whole process is >> known as a Poisson process of rate =3D 1/period. >> >> - In this approach, we do not specify a spread around predefined >> instants Tis. We rather randomize the whole interval separating two >consecutive Tis. >> >> This could be another viable (but may be more complicated??) approach >> for periodic events. >> >> BR, >> >> Marc. >> >> On Sat, 10 May 2014 18:52:50 +0000, Carey, Timothy (Timothy) wrote >> > Ken, >> > >> > I am in the process of commenting on the BBF model TR-181i2a8 for >StrawBallot. >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> > >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. - If so is this the Uniform-Dis= crete >distribution? >> > >> > Thanks, >> > Tim >> > >> > -----Original Message----- >> > From: KEN KO [mailto:KEN.KO@adtran.com] >> > Sent: Thursday, April 24, 2014 7:17 AM >> > To: marc.ibrahim; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org >> > Subject: RE: [lmap] Timer: Poisson distribution question >> > >> > Since Ti+Xmin is non-random, Xmin is not really needed as a separate >> > parameter. Just offset Ti to the desired minimum time and let the >> > spread range from Ti to Ti+Xmax. >> > >> > Other than that nit, +1 >> > >> > -----Original Message----- >> > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > Sent: Wednesday, April 23, 2014 7:08 PM >> > To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > lmap@ietf.org >> > Subject: Re: [lmap] Timer: Poisson distribution question >> > >> > Based on what has been exchanged, I suggest the following: >> > >> > 1- Exact randomness definition and operation >> > -------------------------------------------- >> > IMHO, we need to define how exactly the randomness is applied. >> > >> > For a given event E (e.g. running a measurement task, start >> > reporting,...), let Ti be the predefined (scheduled) instant of the i= th >occurrence of E. >> > Adding randomness means that the event E will happen at time Ti + X >> > instead of Ti, where X is a random variable. If Xmin and Xmax denote >> > the minimum and maximum possible values of X repectively, then the >> > event E will take place at an instant randomly chosen between >> > Ti+Xmin and Ti+Xmax. The spread is equal to Xmax-Xmin >> > >> > Ti+Xmin Ti Ti+Xmax >> > ---------|-----------------|-------------------|----------- >> > >> > <-------------------------------------> >> > Spread >> > >> > Note that Xmin could be negative if E can occur before Ti like in the = figure. >> > I think that the most common values of Xmin would be 0 or (-spread/2). >> > >> > 2- Random generation of X >> > --------------------------- >> > To make it simple as stated by many, X could an integer number of >> > milliseconds uniformly chosen in the interval [Xmin, Xmax]. Xmin, >> > Xmax, and hence spread, are all integers (milliseconds). >> > >> > Then the MA has to define a function UNIF(Xmin, Xmax) or >> > equivalently UNIF(Xmin, spread) that generates a random number of >> > milliseconds from [Xmin, Xmax] interval. The controller has just to >> > send two integer variables (Xmin, >> > Xmax) or (Xmin, spread) to the MA in the timing object. >> > >> > In this minimalist approach, no need to specify the nature of >> > distribution in the timing object since it is assumed to be the unifor= m one. >> > >> > BR, >> > >> > Marc. >> > >> > On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote >> > > This example confuses resolution of the measurement result with >> > > resolution and accuracy of the time at which the measurement is >> > > initiated. Measuring round trip latencies on a Gigabit LAN may >> > > well require microsecond resolution, which could be within the >> > > capabilities of a higher end MA. But that doesn't require >> > > microsecond resolution of the time at which the measurement is >> > > initiated. In addition, for microsecond resolution on the Timer to b= e >meaningful would require synchronization to that resolution across differe= nt MAs >in the network. >> > > >> > > I'm in favor of keeping things simple and specifying Timer >> > > resolution in >> milliseconds. >> > > >> > > -----Original Message----- >> > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam >> > > Hakimi >> > > Sent: Wednesday, April 23, 2014 11:33 AM >> > > To: Juergen Schoenwaelder; marc.ibrahim >> > > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > It depends what the performance goal of the measurement is. A ping >> > > packet in a Gigabit network is just under 1 microseconds and with >> > > fast processors a packet can be sent and received at the same time i= f >granularity is milliseconds. >> > > >> > > This does not even take into account 10Gig networks, not that they >> > > would be at consumer sites, but they would sure exist inside a ISP n= etwork. >> > > >> > > Sharam >> > > >> > > -----Original Message----- >> > > From: Juergen Schoenwaelder >> > > [mailto:j.schoenwaelder@jacobs-university.de] >> > > Sent: Wednesday, April 23, 2014 11:11 AM >> > > To: marc.ibrahim >> > > Cc: trevor.burbridge@bt.com; Sharam Hakimi; >> > > timothy.carey@alcatel-lucent.com; >> > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > I believe randomization with a granularity of milliseconds is good e= nough. >> > > Within an implementation of a measurement task, one may use more >> > > precise timers. But for the randomization of the start of >> > > measurement tasks or the sending of reports, milliseconds seem to >> > > be sufficient (since there will be likely other delays introduced >> > > by the operating system that may get into the some order for startin= g a >measurement task or triggering a report). >> > > >> > > /js >> > > >> > > On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote: >> > > > I would say that choosing the millisecond as atomic time >> > > > alleviates constraints on both timer granularity and generator cap= acity. >> > > > >> > > > I still don't see a real measurement example where few >> > > > microseconds would really >> > matter. >> > > > >> > > > Practically, can a program deal with microseconds timers in >> > > > computers and >> > smartphones? >> > > > This is the scale of the OS, no? >> > > > >> > > > Marc. >> > > > >> > > > On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote >> > > > > So the question is really do we want to design for extremely >> > > > > constrained devices? I'd argue that if this is a problem for >> > > > > them then they are really going to struggle with the >> > > > > Instruction information or >> > measurement results. >> > > > > >> > > > > Trevor. >> > > > > >> > > > > >-----Original Message----- >> > > > > >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >Sent: 23 April 2014 15:00 >> > > > > >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > > >> > > > > >Here is how I see the problem. >> > > > > > >> > > > > >First we have to separate time granularity and random generatio= n. >> > > > > > >> > > > > >Time granularity depends on the timer running on the MA. e.g >> > > > > >microseconds scale means that the MA timer increment each >microsecond. >> > > > > > >> > > > > >When MA wants to generate a random time, he has to choose an >> > > > > >integer number of microseconds to count. So the problem is >> > > > > >always an integer (discrete) number generation. >> > > > > > >> > > > > >Now, if the random generator can attain the maximum integer >> > > > > >(so the maximum possible random time), then, as Trevor says, >> > > > > >no need for the timeStep I talked about, since all possible >> > > > > >durations will be expressed >as >> > multiple of microseconds. >> > > > > > >> > > > > > >> > > > > >For example, a 32 bits random generator could generate up to >> > > > > >a maximum value of 4 billions. In microseconds, this is equal >> > > > > >to less than 2 >> hours. >> > > > > > >> > > > > >It all depends on the capacity of the generator. >> > > > > >Marc. >> > > > > > >> > > > > > >> > > > > >On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote >> > > > > >> So what is the argument for the latter (discrete) option? >> > > > > >> >> > > > > >> Trevor. >> > > > > >> >> > > > > >> >-----Original Message----- >> > > > > >> >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >> >Sent: 23 April 2014 14:10 >> > > > > >> >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >> >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >> >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> > >> > > > > >> >Trevor, you're right. >> > > > > >> >it is just about whether we want a discrete or continuous ge= nerator. >> > > > > >> >If we use a continuous uniform generator, than it is >> > > > > >> >enough to specify the maximum time. >> > > > > >> >With a discrete random generator, you need to specify an >> > > > > >> >additional time granularity. >> > > > > >> > >> > > > > >> >BR, >> > > > > >> > >> > > > > >> >Marc. >> > > > > >> > >> > > > > >> > >> > > > > >> >On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote >> > > > > >> >> I'm not sure I get the point of allowing coarser >> > > > > >> >> granularity that the MA is capable of. If I want the MA >> > > > > >> >> to test/report sometime within a minute window, why not >> > > > > >> >> allow that to happen with the maximum resolution the MA >> > > > > >> >> is capable >> > > > > >> >of? >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Sharam Hakimi >> > > > > >> >> Sent: 23 April 2014 13:58 >> > > > > >> >> To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R; >> > > > > >> >> lmap@ietf.org >> > > > > >> >> Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Marc's suggestion works for me. That allows better >> > > > > >> >> interoperability in my >> > > > > >> >opinion. >> > > > > >> >> >> > > > > >> >> I do agree that we need a common "structure" and "names". >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:47 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> No - I am using the variable of your Information Model >> > > > > >> >> (LowerLimit, >> > > > > >> >UpperLimit, >> > > > > >> >> Spread) - works so far. Marc suggested a TimeStep >> > > > > >> >> parameter so we don't lockin on a specific microsecond, >> > > > > >> >> millisecond, second thing - I am open >> > > > > >to that. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:41 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Agree we need to have well defined function names. I >> > > > > >> >> thought you were also suggesting different functions >> > > > > >> >> needed different input >> > parameters. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 23 April 2014 13:36 >> > > > > >> >> To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Its not that the Measurement controller has to configure >> > > > > >> >> the timer for the >> > > > > >MA. >> > > > > >> >> >> > > > > >> >> If we do not specify the functions and variable names, >> > > > > >> >> the measurement controller doesn't have a standard way >> > > > > >> >> of configuring a >timer. >> > > > > >> >> >> > > > > >> >> For example - If I specify for a Uniform distribution >> > > > > >> >> function called "Uniform" you have a variable called >> > > > > >> >> "UpperLimit", the MA will implement the specification; >> > > > > >> >> the controller will implement the >> > > > > >specification and things work. >> > > > > >> >> >> > > > > >> >> If I do not specify anything for the Uniform >> > > > > >> >> distribution function >> > > > > >> >> - MA vendor >> > > > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" >> > > > > >> >> and maybe an >> > > > > >"Enable" >> > > > > >> >> parameter for good measure; MA vendor 2 can call it "U" >> > > > > >> >> and have an attribute "X that is an integer". >> > > > > >> >> >> > > > > >> >> Now put that variation on steroids based on the number >> > > > > >> >> of MA vendors - That is why we specify things, right? >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:24 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The measurement controller has to communicate what tests >> > > > > >> >> have to be run on >> > > > > >> >an >> > > > > >> >> MA, for how long, when to run them, what test results >> > > > > >> >> are generated, etc. Why would configuring this parameter >> > > > > >> >> be any different. Maybe I am missing >> > > > > >> >something. >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:16 AM >> > > > > >> >> To: Sharam Hakimi; >> > > > > >> >trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> So the burden is on the Measurement controller to know >> > > > > >> >> the functions and inputs specifications for each >> > > > > >> >> possible MA vendor; not something I would want to have >> > > > > >> >> to do as a Measurement controller >> > > > > >vendor. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:14 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> I do not see why vendor A or B or C matters. They would >> > > > > >> >> all be under the control of one Measurement Controller >> > > > > >> >> which would specify what inputs to use for all MAs in a gr= oup. >> > > > > >> >> >> > > > > >> >> As Trevor also mentioned this timer can be used for both >> > > > > >> >> testing and reporting and I would strongly suggest to >> > > > > >> >> have microsecond granularity. For reporting one could >> > > > > >> >> choose seconds in terms of >> > > > > >microseconds. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:04 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> If we don't define the inputs for each function (leaving >> > > > > >> >> the inputs >> > > > > >> >> opaque) you will have interop problems. MA vendor 1 >> > > > > >> >> uses these 2 inputs >> > > > > >named "A" >> > > > > >> >and >> > > > > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" >> > > > > >> >> for the same >> > > > > >function. >> > > > > >> >> >> > > > > >> >> I think we need to avoid that if we realistically want >> > > > > >> >> the Randomness function to be used efficiently. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 2:55 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The random timing can be used for both specifying when a >> > > > > >> >> test runs, or when a report is sent (or any other task >> > > > > >> >> such as contacting the Controller). It doesn't have to be = used, but >it can be. >> > > > > >> >> >> > > > > >> >> I don't really want different input variable for >> > > > > >> >> different functions. I don't see we need to. Also if we >> > > > > >> >> do, then we would have to have schema for each function >> > > > > >> >> to specify which inputs are expected (like the >> > > > > >> >> measurement task registry). I'd like to >> avoid >> > that. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 22 April 2014 22:07 >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >> Burbridge,T,Trevor, >> > > > > >> >> TUB8 R Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Sharam, >> > > > > >> >> >> > > > > >> >> We are talking about offsets for when to report; in the >> > > > > >> >> world we live in milliseconds is sufficient - IMHO. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:59 PM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the min/max should have microseconds granularity. >> > > > > >> >> Milliseconds would not be accurate enough. >> > > > > >> >> >> > > > > >> >> Personally, I would not trust my periodic tests in a >> > > > > >> >> large scale deployment to a random number generator and >> > > > > >> >> would want to know exactly how and when >> > > > > >> >tests >> > > > > >> >> would be run. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:16 PM >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> The data model is extensible by vendors so we can add >> > > > > >> >> functions and input variables as we need. >> > > > > >> >> >> > > > > >> >> However we have to decide on which small subset we >> > > > > >> >> actually want to >> > > > > >> >standardize. >> > > > > >> >> >> > > > > >> >> You suggested the Uniform and Normal which is fine but >> > > > > >> >> for the model we need to go farther by defining the >> > > > > >> >> specific function along with which inputs are used by >> > > > > >> >> the function to derive what random number. Otherwise we >> > > > > >> >> will have 2 implementers of the same standard algorithm >implement different variations. - Not good. >> > > > > >> >> >> > > > > >> >> So I suggest we keep this simple. >> > > > > >> >> >> > > > > >> >> Uniform Discrete - input variables - maximum [positive >> > > > > >> >> integer] Gaussian -input variables - mean of min/max, >> > > > > >> >> spread =3D standard deviation >> > > > > >> >> >> > > > > >> >> The min/max would be milliseconds - Spread would be an int= eger. >> > > > > >> >> >> > > > > >> >> This sound OK? >> > > > > >> >> >> > > > > >> >> BR >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 8:23 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the Periodic Timer distribution needs to have >> > > > > >> >> closer configuration control by the user and I think >> > > > > >> >> your 2nd choice attempts to provide it but having a >> > > > > >> >> discrete interval definition is a better way >> > > > > >to go. >> > > > > >> >> >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Sent: Tuesday, April 22, 2014 4:35 AM >> > > > > >> >> To: >> > > > > >> >> timothy.carey@alcatel-lucent.com> > > > > >> >> catel- >> > > > > >> >lucent.com>; >> > > > > >> >> lmap@ietf.org Subject: Re: [lmap] Ti= mer: >> > > > > >> >> Poisson distribution question >> > > > > >> >> >> > > > > >> >> On continuous counterparts of Poisson I'm far from any >> > > > > >> >> expert and it would certainly be up to the user to >> > > > > >> >> decide if such functions were suitable replacements for >> > > > > >> >> the discrete Poisson function. Yes it would be a >> > > > > >> >> different function even if there was perfect fit (which >> > > > > >> >> they are not) as one is continuous and one is >> > discrete: >> > > > > >> >> http://cmscience.blogspot.co.uk/2008/04/mt- >> > > > > >> >6- >> > > > > >> >> poisson-and-gamma-distribution.html >> > > > > >> >> http://arxiv.org/abs/1303.5990 >> > > > > >> >> >> > > > > >> >> As I tried to say the current Information Model can take >> > > > > >> >> either discrete or continuous functions - only that >> > > > > >> >> there is currently no explicit support for specifying >> > > > > >> >> the interval used for a discrete function. I was questioni= ng the >need to add this. >> > > > > >> >> >> > > > > >> >> Personally I'd think that Normal and Uniform >> > > > > >> >> distributions would cover most needs, but the framework >> > > > > >> >> should be flexible in this >> regard. >> > > > > >> >> >> > > > > >> >> Trevor. >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Carey, Timothy >> > > > > >> >(Timothy) >> > > > > >> >> Sent: 19 April 2014 20:24 >> > > > > >> >> To: lmap@ietf.org >> > > > > >> >> Subject: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Team, >> > > > > >> >> >> > > > > >> >> The BBF is looking at standardizing the model for Timers >> > > > > >> >> as suggested by the IETF LMAP information model. >> > > > > >> >> >> > > > > >> >> During the review of the timers we had addition >> > > > > >> >> questions regarding Trevors response to the Poisson >> > > > > >> >> distribution for the Randomness of the >> > > > > >Periodic Timer. >> > > > > >> >> >> > > > > >> >> Trevor responded: >> > > > > >> >> >> > > > > >> >> "Yes this does need to be clarified. I was assuming a >> > > > > >> >> distribution about the mean (i.e. the timing given is >> > > > > >> >> the mean). The spread would be the standard deviation >> > > > > >> >> (could use mean deviation or something else but I see no >> > > > > >> >> advantage as long as we all know what it refers to) and >> > > > > >> >> need to change to a float. The upper and lower cuts >> > > > > >> >> would be in seconds +/- the mean (also needs to change >> > > > > >> >to >> > > > > >> >> float) and are simply used to trim the function - >> > > > > >> >> obviously needed on a uniform distribution but useful to >> > > > > >> >> constrain other >functions. >> > > > > >> >> >> > > > > >> >> I will make all this clear in the next release. >> > > > > >> >> >> > > > > >> >> As for poisson I think there are 3 options: >> > > > > >> >> >> > > > > >> >> - Use a continuous form instead >> > > > > >> >> >> > > > > >> >> - Have the discrete interval implicit in the functi= on choice >> > > > > >> >e.g."poisson_1_sec" >> > > > > >> >> >> > > > > >> >> - Add an interval to the information model. >> > > > > >> >> >> > > > > >> >> I was really thinking about the first, but I don't see >> > > > > >> >> the problem with the second. However I wouldn't do the >> > > > > >> >> third unless they was a demonstrable value to supporting >> > > > > >> >> discrete functions (rather than continuous >> > > > > >versions of them). " >> > > > > >> >> >> > > > > >> >> But as people looked at Trevors response there were >> > > > > >> >> additional >questions: >> > > > > >> >> >> > > > > >> >> I don't understand what Trevor means about the Poisson >> > > > > >> >> distribution. As far as I know, it is a discrete >> > > > > >> >> distribution, so a "continuous form" would be a >> > > > > >> >> different distribution and not Poisson. And I believe >> > > > > >> >> that we do need a >continuous >> > distribution. >> > > > > >> >> But what matters is that the definition is clear, not >> > > > > >> >> the particular >> > > > distribution >> > > > > >(I don't have an opinion on that). >> > > > > >> >> >> > > > > >> >> Could some please clarify this for us - Are we planning >> > > > > >> >> something other than Poisson method; better yet is there >> > > > > >> >> a definition for the types of >> > > > > >> >> distribution: Poisson, Normal and Uniform. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Tim >> > > > > >> > >> > > > > >> > >> > > > > >> >-- >> > > > > >> >Open WebMail Project (http://openwebmail.org) >> > > > > >> >> > > > > >> _______________________________________________ >> > > > > >> lmap mailing list >> > > > > >> lmap@ietf.org >> > > > > >> https://www.ietf.org/mailman/listinfo/lmap >> > > > > > >> > > > > > >> > > > > >-- >> > > > > >Open WebMail Project (http://openwebmail.org) >> > > > > >> > > > > _______________________________________________ >> > > > > lmap mailing list >> > > > > lmap@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/lmap >> > > > >> > > > >> > > > -- >> > > > Open WebMail Project (http://openwebmail.org) >> > > > >> > > > _______________________________________________ >> > > > 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 >> > > >> > > _______________________________________________ >> > > 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 >> > >> > -- >> > Open WebMail Project (http://openwebmail.org) >> >> -- >> Open WebMail Project (http://openwebmail.org) > > >-- >Open WebMail Project (http://openwebmail.org) From nobody Wed May 14 04:33: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 EDA691A0015 for ; Wed, 14 May 2014 04:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 vu5t3x689aCB for ; Wed, 14 May 2014 04:33:39 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 53E501A0063 for ; Wed, 14 May 2014 04:33:38 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4EBXTrs008129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 06:33:29 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s4EBXRYT017957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 07:33:27 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 14 May 2014 07:33:27 -0400 From: "Carey, Timothy (Timothy)" To: "philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" , "marc.ibrahim@usj.edu.lb" Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFAAOul4AAAFBuIAAD7DoAAACWpoAAAFXBgAAAu1hgAADOgJA Date: Wed, 14 May 2014 11:33:26 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719542AF2@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <20140514064545.M74784@usj.edu.lb> <20140514073758.GA91397@elstar.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] 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/nOXcmQLBtGvYd4O9_TdlVZfc2aM Cc: "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 14 May 2014 11:33:41 -0000 I am open to any of the approaches for this combination; just need an answe= r as I am updating the BBF data model...:-) -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Wednesday, May 14, 2014 4:02 AM To: j.schoenwaelder@jacobs-university.de; marc.ibrahim@usj.edu.lb Cc: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: [lmap] Question on information model - Suppression I also would not over engineer suppression. I'd either interpret as the Uni= on, or else not allow both a task and schedule list in a suppression. > > Union means: Tasks T1 to Tn are all suppressed (from all MA > schedules, > > isn't it JS?) and all tasks started by S1 to Sm should be suppressed > too. > > > > Pairing: m=3Dn. Ti suppressed from Si. > > > > I see the intersection (or another term) definition is as clear as > > union IMO. If I understood you well JS, I see that union cannot > perform all suppression possibilities. > > For example, how to suppress only a subset from a given schedule? > > Intersection can do it with one or more suppression objects. > > Pairing solution needs only one object to do any suppression > combination. > > >=20 > I do not like pairing. I am fine with intersection or alternatively to > remove the capability to have both a task list and a schedule list in > a suppression. I think we should not over engineer suppression. >=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 nobody Wed May 14 04:38: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 472ED1A0063 for ; Wed, 14 May 2014 04:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 rFotUsIVkBVr for ; Wed, 14 May 2014 04:37:57 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id F37861A0015 for ; Wed, 14 May 2014 04:37:56 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4EBbnEZ011185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 06:37:50 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s4EBbn5K010363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 07:37:49 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 14 May 2014 07:37:49 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder , "marc. ibrahim" Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFAAOul4AAAFBuIAAD7DoAAADqTSA Date: Wed, 14 May 2014 11:37:47 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> In-Reply-To: <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] 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/HgzdQeqcM5XunZh22von54vn2yo Cc: "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 14 May 2014 11:37:59 -0000 Juergen, You cannot as I read the text have multiple suppression objects. Did I miss= something. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, May 14, 2014 12:52 AM To: marc. ibrahim Cc: Carey, Timothy (Timothy); lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: >=20 > ma-suppression-task-names<0..*> and > ma-suppression-schedule-names<0..*> are strings containing names of > tasks and schedules. If we just allow to have the same name multiple > times, a pairing association could be done between tasks without > changing the information model. > > For example, ma-suppression-task-names =3D [T1 T1 T2 T2 T3 *] and > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1 > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all > schedules, and schedule S4 will be suppressed. Does this change the > information model Tim? I do not think this is needed since you can have multiple suppression objects. But defining the intersection of ma-suppression-task-names =3D [T1 T2] ma-suppression-schedule-names =3D [S1 S2] may not be that clear. The union is clear, suppress tasks T1 and T2 and anything started by S1 and S2. Is the intersection interpretation suppress any T1 started by S1, any T2 started by S1, any T1 started by S2, any T2 started by S2? This is not really an intersection - a strict intersection interpretation would likely lead to an empty set. /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 Wed May 14 04:51: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 8D4941A0015 for ; Wed, 14 May 2014 04:51:45 -0700 (PDT) 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_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 TiV9CgG0BJpT for ; Wed, 14 May 2014 04:51:38 -0700 (PDT) Received: from p01c12o148.mxlogic.net (p01c12o148.mxlogic.net [208.65.145.71]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3671A0012 for ; Wed, 14 May 2014 04:51:37 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO p01c12o148.mxlogic.net) by p01c12o148.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 3c853735.2b229ca42940.37726.00-527.85793.p01c12o148.mxlogic.net (envelope-from ); Wed, 14 May 2014 05:51:31 -0600 (MDT) X-MXL-Hash: 537358c35165e67c-5a5f4e074288eb0a73e8c48b87e97b2ce1ae7925 Received: from unknown [76.164.174.81] by p01c12o148.mxlogic.net(mxl_mta-8.0.0-1) with SMTP id 6b853735.0.37508.00-289.85542.p01c12o148.mxlogic.net (envelope-from ); Wed, 14 May 2014 05:51:30 -0600 (MDT) X-MXL-Hash: 537358c2526ee4cf-87e6f55a2d005453bc6e774583a9cfd6fe99151d 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, 14 May 2014 06:51:11 -0500 From: KEN KO To: "Carey, Timothy (Timothy)" , "trevor.burbridge@bt.com" , "marc.ibrahim@usj.edu.lb" , "sharam.hakimi@exfo.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgAAGpuQAMg7ywAAAMetAAABaySAAABJnYAAAMjegAAEULewAAuNC4AAEP0W4AM9EAoAAALvw4AAAPFAAAAArNsAALHHk4AAA0fUgAAKAlGg Date: Wed, 14 May 2014 11:51:11 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> <20140423145224.M63656@usj.edu.lb> <20140423151059.GE1056@elstar.local> <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> <20140423221748.M2036@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcate l-lucent.com> <20140510193741.M70435@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954016F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140510205713.M39371@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F7719542AB7@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719542AB7@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=WpGlMLvv c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=7JF6gnM3VwMA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=y1pov1uI18EA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=gxZvrgisAAAA:8 a=e9qsufxtAAAA:8 a=pTHmISxBAAAA:8 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=Rg5jOeRUAAAA:8 a=QZam-5MpAAAA:8 a=EWPDJS0nA] X-AnalysisOut: [AAA:8 a=NMdtWtFZAAAA:8 a=j3Z76cjpAAAA:8 a=TgcDCLPAUmUDRB05] X-AnalysisOut: [RSgA:9 a=eB5MAlW3GsZCYA_T:21 a=OoOXlckL7V5FAsvk:21 a=CjuIK] X-AnalysisOut: [1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=3FZX-ydVl] X-AnalysisOut: [cEA:10 a=W1qU_X6G3J8A:10 a=DAs2C8GDBtAA:10 a=zeshHG33Dl4A:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=DvnSUQUdWHYA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014051405); S=0.200(2014050601)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/BOeznh-qIJTbHznfLIlhvsp3QO0 Cc: "lmap@ietf.org" Subject: Re: [lmap] Timer: Poisson distribution question 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, 14 May 2014 11:51:45 -0000 Tim, I'm still not sure *why* you want negative offsets. Several people have com= mented that having a uniform spread from Ti to Ti+Xmax (or equivalently, Tm= in to Tmax) is sufficient to assure randomness. I think there needs to be a= good reason to add an additional parameter. Thanks, Ken -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]=20 Sent: Wednesday, May 14, 2014 7:28 AM To: trevor.burbridge@bt.com; marc.ibrahim@usj.edu.lb; KEN KO; sharam.hakimi= @exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Trevor, I think we said, because we wanted negative offsets, that we would need the= LowerLimit (offset) and spread. Thanks, Tim -----Original Message----- From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]=20 Sent: Wednesday, May 14, 2014 4:54 AM To: marc.ibrahim@usj.edu.lb; Carey, Timothy (Timothy); KEN.KO@adtran.com; s= haram.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Just to acknowledge that this (just having spread as a positive from Ti) is= what I'll implement in the next revision of the Information Model unless t= here are further discussions. Trevor Burbridge >-----Original Message----- >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >Sent: 10 May 2014 22:03 >To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen Schoenwaelder >Cc: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org >Subject: RE: [lmap] Timer: Poisson distribution question > >The simplest to do, is to spread starting from Ti. So, all you need is to = specify only >one parameter: the spread. random values will be picked from between Ti an= d >Ti+spread. > >If you want to control spread position, then yes, you need an offset param= eter. >Random values will then be picked between Ti+offset and Ti+offset + spread= . > >BR, > >Marc. > > >On Sat, 10 May 2014 20:43:54 +0000, Carey, Timothy (Timothy) wrote >> Marc, >> >> So we can do Xmin + spread or Xmax - spread or Xmax-Xmin but you need >> the offset from Ti to allow for a negative spread from Ti, right? >> >> BR, >> Tim >> >> -----Original Message----- >> From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> Sent: Saturday, May 10, 2014 3:17 PM >> To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen >> Schoenwaelder >> Cc: trevor.burbridge@bt.com; lmap@ietf.org >> Subject: RE: [lmap] Timer: Poisson distribution question >> >> Tim, >> >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> >> I agree with Ken that Xmin is superfluous. The essential parameter is >> the spread. I suggested Xmin just to be able to control the spread >> around Ti, but this is not really important. We can just say that the >> time values will be chosen between Ti and Ti+spread. >> >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. >> >> As the draft says, the goal of randomness is to spread the load by >> preventing multiple events from occurring simultaneously. Given the >> spread interval, the uniform distribution is mathematically the best >> to achieve it. I don't see why we should use normal distribution, >> which will tend to concentrate values around some mean. >> >> >If so is this the Uniform-Discrete distribution? >> >> I suggested to express the randomness as an integer number of >> milliseconds. So the answer is yes. >> >> Finally, I would like to add a comment about the Poisson distribution >> that was the initial cause of this discussion about timer. I think >> that there was a confusion with the Poisson process used to randomize >> the instants of packets transmission in active measurements. In fact, >> Poisson in measurement context is a process describing the occurrence >> of events and not a probability distribution for a time interval (the >> related distribution is exponential as explained below). So, if a >> Poisson process is to be used in lmap context, it applies in my opinion = only to >periodic schedules as follows: >> >> - The period specified in the timing object is in fact an average pe= riod. >> For example, if an MA event occurs at Ti, the next event will occur in >> average at Ti+period >> >> - After an event occurs at Ti, the MA will choose a real number X >> according to an exponential distribution of mean =3D period. Next event >> will then occur at Ti+X. >> >> - When the inter-event time is exponential, the whole process is >> known as a Poisson process of rate =3D 1/period. >> >> - In this approach, we do not specify a spread around predefined >> instants Tis. We rather randomize the whole interval separating two >consecutive Tis. >> >> This could be another viable (but may be more complicated??) approach >> for periodic events. >> >> BR, >> >> Marc. >> >> On Sat, 10 May 2014 18:52:50 +0000, Carey, Timothy (Timothy) wrote >> > Ken, >> > >> > I am in the process of commenting on the BBF model TR-181i2a8 for >StrawBallot. >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> > >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. - If so is this the Uniform-Dis= crete >distribution? >> > >> > Thanks, >> > Tim >> > >> > -----Original Message----- >> > From: KEN KO [mailto:KEN.KO@adtran.com] >> > Sent: Thursday, April 24, 2014 7:17 AM >> > To: marc.ibrahim; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org >> > Subject: RE: [lmap] Timer: Poisson distribution question >> > >> > Since Ti+Xmin is non-random, Xmin is not really needed as a separate >> > parameter. Just offset Ti to the desired minimum time and let the >> > spread range from Ti to Ti+Xmax. >> > >> > Other than that nit, +1 >> > >> > -----Original Message----- >> > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > Sent: Wednesday, April 23, 2014 7:08 PM >> > To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > lmap@ietf.org >> > Subject: Re: [lmap] Timer: Poisson distribution question >> > >> > Based on what has been exchanged, I suggest the following: >> > >> > 1- Exact randomness definition and operation >> > -------------------------------------------- >> > IMHO, we need to define how exactly the randomness is applied. >> > >> > For a given event E (e.g. running a measurement task, start >> > reporting,...), let Ti be the predefined (scheduled) instant of the i= th >occurrence of E. >> > Adding randomness means that the event E will happen at time Ti + X >> > instead of Ti, where X is a random variable. If Xmin and Xmax denote >> > the minimum and maximum possible values of X repectively, then the >> > event E will take place at an instant randomly chosen between >> > Ti+Xmin and Ti+Xmax. The spread is equal to Xmax-Xmin >> > >> > Ti+Xmin Ti Ti+Xmax >> > ---------|-----------------|-------------------|----------- >> > >> > <-------------------------------------> >> > Spread >> > >> > Note that Xmin could be negative if E can occur before Ti like in the = figure. >> > I think that the most common values of Xmin would be 0 or (-spread/2). >> > >> > 2- Random generation of X >> > --------------------------- >> > To make it simple as stated by many, X could an integer number of >> > milliseconds uniformly chosen in the interval [Xmin, Xmax]. Xmin, >> > Xmax, and hence spread, are all integers (milliseconds). >> > >> > Then the MA has to define a function UNIF(Xmin, Xmax) or >> > equivalently UNIF(Xmin, spread) that generates a random number of >> > milliseconds from [Xmin, Xmax] interval. The controller has just to >> > send two integer variables (Xmin, >> > Xmax) or (Xmin, spread) to the MA in the timing object. >> > >> > In this minimalist approach, no need to specify the nature of >> > distribution in the timing object since it is assumed to be the unifor= m one. >> > >> > BR, >> > >> > Marc. >> > >> > On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote >> > > This example confuses resolution of the measurement result with >> > > resolution and accuracy of the time at which the measurement is >> > > initiated. Measuring round trip latencies on a Gigabit LAN may >> > > well require microsecond resolution, which could be within the >> > > capabilities of a higher end MA. But that doesn't require >> > > microsecond resolution of the time at which the measurement is >> > > initiated. In addition, for microsecond resolution on the Timer to b= e >meaningful would require synchronization to that resolution across differe= nt MAs >in the network. >> > > >> > > I'm in favor of keeping things simple and specifying Timer >> > > resolution in >> milliseconds. >> > > >> > > -----Original Message----- >> > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam >> > > Hakimi >> > > Sent: Wednesday, April 23, 2014 11:33 AM >> > > To: Juergen Schoenwaelder; marc.ibrahim >> > > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > It depends what the performance goal of the measurement is. A ping >> > > packet in a Gigabit network is just under 1 microseconds and with >> > > fast processors a packet can be sent and received at the same time i= f >granularity is milliseconds. >> > > >> > > This does not even take into account 10Gig networks, not that they >> > > would be at consumer sites, but they would sure exist inside a ISP n= etwork. >> > > >> > > Sharam >> > > >> > > -----Original Message----- >> > > From: Juergen Schoenwaelder >> > > [mailto:j.schoenwaelder@jacobs-university.de] >> > > Sent: Wednesday, April 23, 2014 11:11 AM >> > > To: marc.ibrahim >> > > Cc: trevor.burbridge@bt.com; Sharam Hakimi; >> > > timothy.carey@alcatel-lucent.com; >> > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > I believe randomization with a granularity of milliseconds is good e= nough. >> > > Within an implementation of a measurement task, one may use more >> > > precise timers. But for the randomization of the start of >> > > measurement tasks or the sending of reports, milliseconds seem to >> > > be sufficient (since there will be likely other delays introduced >> > > by the operating system that may get into the some order for startin= g a >measurement task or triggering a report). >> > > >> > > /js >> > > >> > > On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote: >> > > > I would say that choosing the millisecond as atomic time >> > > > alleviates constraints on both timer granularity and generator cap= acity. >> > > > >> > > > I still don't see a real measurement example where few >> > > > microseconds would really >> > matter. >> > > > >> > > > Practically, can a program deal with microseconds timers in >> > > > computers and >> > smartphones? >> > > > This is the scale of the OS, no? >> > > > >> > > > Marc. >> > > > >> > > > On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote >> > > > > So the question is really do we want to design for extremely >> > > > > constrained devices? I'd argue that if this is a problem for >> > > > > them then they are really going to struggle with the >> > > > > Instruction information or >> > measurement results. >> > > > > >> > > > > Trevor. >> > > > > >> > > > > >-----Original Message----- >> > > > > >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >Sent: 23 April 2014 15:00 >> > > > > >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > > >> > > > > >Here is how I see the problem. >> > > > > > >> > > > > >First we have to separate time granularity and random generatio= n. >> > > > > > >> > > > > >Time granularity depends on the timer running on the MA. e.g >> > > > > >microseconds scale means that the MA timer increment each >microsecond. >> > > > > > >> > > > > >When MA wants to generate a random time, he has to choose an >> > > > > >integer number of microseconds to count. So the problem is >> > > > > >always an integer (discrete) number generation. >> > > > > > >> > > > > >Now, if the random generator can attain the maximum integer >> > > > > >(so the maximum possible random time), then, as Trevor says, >> > > > > >no need for the timeStep I talked about, since all possible >> > > > > >durations will be expressed >as >> > multiple of microseconds. >> > > > > > >> > > > > > >> > > > > >For example, a 32 bits random generator could generate up to >> > > > > >a maximum value of 4 billions. In microseconds, this is equal >> > > > > >to less than 2 >> hours. >> > > > > > >> > > > > >It all depends on the capacity of the generator. >> > > > > >Marc. >> > > > > > >> > > > > > >> > > > > >On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote >> > > > > >> So what is the argument for the latter (discrete) option? >> > > > > >> >> > > > > >> Trevor. >> > > > > >> >> > > > > >> >-----Original Message----- >> > > > > >> >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >> >Sent: 23 April 2014 14:10 >> > > > > >> >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >> >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >> >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> > >> > > > > >> >Trevor, you're right. >> > > > > >> >it is just about whether we want a discrete or continuous ge= nerator. >> > > > > >> >If we use a continuous uniform generator, than it is >> > > > > >> >enough to specify the maximum time. >> > > > > >> >With a discrete random generator, you need to specify an >> > > > > >> >additional time granularity. >> > > > > >> > >> > > > > >> >BR, >> > > > > >> > >> > > > > >> >Marc. >> > > > > >> > >> > > > > >> > >> > > > > >> >On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote >> > > > > >> >> I'm not sure I get the point of allowing coarser >> > > > > >> >> granularity that the MA is capable of. If I want the MA >> > > > > >> >> to test/report sometime within a minute window, why not >> > > > > >> >> allow that to happen with the maximum resolution the MA >> > > > > >> >> is capable >> > > > > >> >of? >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Sharam Hakimi >> > > > > >> >> Sent: 23 April 2014 13:58 >> > > > > >> >> To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R; >> > > > > >> >> lmap@ietf.org >> > > > > >> >> Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Marc's suggestion works for me. That allows better >> > > > > >> >> interoperability in my >> > > > > >> >opinion. >> > > > > >> >> >> > > > > >> >> I do agree that we need a common "structure" and "names". >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:47 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> No - I am using the variable of your Information Model >> > > > > >> >> (LowerLimit, >> > > > > >> >UpperLimit, >> > > > > >> >> Spread) - works so far. Marc suggested a TimeStep >> > > > > >> >> parameter so we don't lockin on a specific microsecond, >> > > > > >> >> millisecond, second thing - I am open >> > > > > >to that. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:41 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Agree we need to have well defined function names. I >> > > > > >> >> thought you were also suggesting different functions >> > > > > >> >> needed different input >> > parameters. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 23 April 2014 13:36 >> > > > > >> >> To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Its not that the Measurement controller has to configure >> > > > > >> >> the timer for the >> > > > > >MA. >> > > > > >> >> >> > > > > >> >> If we do not specify the functions and variable names, >> > > > > >> >> the measurement controller doesn't have a standard way >> > > > > >> >> of configuring a >timer. >> > > > > >> >> >> > > > > >> >> For example - If I specify for a Uniform distribution >> > > > > >> >> function called "Uniform" you have a variable called >> > > > > >> >> "UpperLimit", the MA will implement the specification; >> > > > > >> >> the controller will implement the >> > > > > >specification and things work. >> > > > > >> >> >> > > > > >> >> If I do not specify anything for the Uniform >> > > > > >> >> distribution function >> > > > > >> >> - MA vendor >> > > > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" >> > > > > >> >> and maybe an >> > > > > >"Enable" >> > > > > >> >> parameter for good measure; MA vendor 2 can call it "U" >> > > > > >> >> and have an attribute "X that is an integer". >> > > > > >> >> >> > > > > >> >> Now put that variation on steroids based on the number >> > > > > >> >> of MA vendors - That is why we specify things, right? >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:24 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The measurement controller has to communicate what tests >> > > > > >> >> have to be run on >> > > > > >> >an >> > > > > >> >> MA, for how long, when to run them, what test results >> > > > > >> >> are generated, etc. Why would configuring this parameter >> > > > > >> >> be any different. Maybe I am missing >> > > > > >> >something. >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:16 AM >> > > > > >> >> To: Sharam Hakimi; >> > > > > >> >trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> So the burden is on the Measurement controller to know >> > > > > >> >> the functions and inputs specifications for each >> > > > > >> >> possible MA vendor; not something I would want to have >> > > > > >> >> to do as a Measurement controller >> > > > > >vendor. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:14 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> I do not see why vendor A or B or C matters. They would >> > > > > >> >> all be under the control of one Measurement Controller >> > > > > >> >> which would specify what inputs to use for all MAs in a gr= oup. >> > > > > >> >> >> > > > > >> >> As Trevor also mentioned this timer can be used for both >> > > > > >> >> testing and reporting and I would strongly suggest to >> > > > > >> >> have microsecond granularity. For reporting one could >> > > > > >> >> choose seconds in terms of >> > > > > >microseconds. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:04 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> If we don't define the inputs for each function (leaving >> > > > > >> >> the inputs >> > > > > >> >> opaque) you will have interop problems. MA vendor 1 >> > > > > >> >> uses these 2 inputs >> > > > > >named "A" >> > > > > >> >and >> > > > > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" >> > > > > >> >> for the same >> > > > > >function. >> > > > > >> >> >> > > > > >> >> I think we need to avoid that if we realistically want >> > > > > >> >> the Randomness function to be used efficiently. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 2:55 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The random timing can be used for both specifying when a >> > > > > >> >> test runs, or when a report is sent (or any other task >> > > > > >> >> such as contacting the Controller). It doesn't have to be = used, but >it can be. >> > > > > >> >> >> > > > > >> >> I don't really want different input variable for >> > > > > >> >> different functions. I don't see we need to. Also if we >> > > > > >> >> do, then we would have to have schema for each function >> > > > > >> >> to specify which inputs are expected (like the >> > > > > >> >> measurement task registry). I'd like to >> avoid >> > that. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 22 April 2014 22:07 >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >> Burbridge,T,Trevor, >> > > > > >> >> TUB8 R Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Sharam, >> > > > > >> >> >> > > > > >> >> We are talking about offsets for when to report; in the >> > > > > >> >> world we live in milliseconds is sufficient - IMHO. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:59 PM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the min/max should have microseconds granularity. >> > > > > >> >> Milliseconds would not be accurate enough. >> > > > > >> >> >> > > > > >> >> Personally, I would not trust my periodic tests in a >> > > > > >> >> large scale deployment to a random number generator and >> > > > > >> >> would want to know exactly how and when >> > > > > >> >tests >> > > > > >> >> would be run. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:16 PM >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> The data model is extensible by vendors so we can add >> > > > > >> >> functions and input variables as we need. >> > > > > >> >> >> > > > > >> >> However we have to decide on which small subset we >> > > > > >> >> actually want to >> > > > > >> >standardize. >> > > > > >> >> >> > > > > >> >> You suggested the Uniform and Normal which is fine but >> > > > > >> >> for the model we need to go farther by defining the >> > > > > >> >> specific function along with which inputs are used by >> > > > > >> >> the function to derive what random number. Otherwise we >> > > > > >> >> will have 2 implementers of the same standard algorithm >implement different variations. - Not good. >> > > > > >> >> >> > > > > >> >> So I suggest we keep this simple. >> > > > > >> >> >> > > > > >> >> Uniform Discrete - input variables - maximum [positive >> > > > > >> >> integer] Gaussian -input variables - mean of min/max, >> > > > > >> >> spread =3D standard deviation >> > > > > >> >> >> > > > > >> >> The min/max would be milliseconds - Spread would be an int= eger. >> > > > > >> >> >> > > > > >> >> This sound OK? >> > > > > >> >> >> > > > > >> >> BR >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 8:23 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the Periodic Timer distribution needs to have >> > > > > >> >> closer configuration control by the user and I think >> > > > > >> >> your 2nd choice attempts to provide it but having a >> > > > > >> >> discrete interval definition is a better way >> > > > > >to go. >> > > > > >> >> >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Sent: Tuesday, April 22, 2014 4:35 AM >> > > > > >> >> To: >> > > > > >> >> timothy.carey@alcatel-lucent.com> > > > > >> >> catel- >> > > > > >> >lucent.com>; >> > > > > >> >> lmap@ietf.org Subject: Re: [lmap] Ti= mer: >> > > > > >> >> Poisson distribution question >> > > > > >> >> >> > > > > >> >> On continuous counterparts of Poisson I'm far from any >> > > > > >> >> expert and it would certainly be up to the user to >> > > > > >> >> decide if such functions were suitable replacements for >> > > > > >> >> the discrete Poisson function. Yes it would be a >> > > > > >> >> different function even if there was perfect fit (which >> > > > > >> >> they are not) as one is continuous and one is >> > discrete: >> > > > > >> >> http://cmscience.blogspot.co.uk/2008/04/mt- >> > > > > >> >6- >> > > > > >> >> poisson-and-gamma-distribution.html >> > > > > >> >> http://arxiv.org/abs/1303.5990 >> > > > > >> >> >> > > > > >> >> As I tried to say the current Information Model can take >> > > > > >> >> either discrete or continuous functions - only that >> > > > > >> >> there is currently no explicit support for specifying >> > > > > >> >> the interval used for a discrete function. I was questioni= ng the >need to add this. >> > > > > >> >> >> > > > > >> >> Personally I'd think that Normal and Uniform >> > > > > >> >> distributions would cover most needs, but the framework >> > > > > >> >> should be flexible in this >> regard. >> > > > > >> >> >> > > > > >> >> Trevor. >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Carey, Timothy >> > > > > >> >(Timothy) >> > > > > >> >> Sent: 19 April 2014 20:24 >> > > > > >> >> To: lmap@ietf.org >> > > > > >> >> Subject: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Team, >> > > > > >> >> >> > > > > >> >> The BBF is looking at standardizing the model for Timers >> > > > > >> >> as suggested by the IETF LMAP information model. >> > > > > >> >> >> > > > > >> >> During the review of the timers we had addition >> > > > > >> >> questions regarding Trevors response to the Poisson >> > > > > >> >> distribution for the Randomness of the >> > > > > >Periodic Timer. >> > > > > >> >> >> > > > > >> >> Trevor responded: >> > > > > >> >> >> > > > > >> >> "Yes this does need to be clarified. I was assuming a >> > > > > >> >> distribution about the mean (i.e. the timing given is >> > > > > >> >> the mean). The spread would be the standard deviation >> > > > > >> >> (could use mean deviation or something else but I see no >> > > > > >> >> advantage as long as we all know what it refers to) and >> > > > > >> >> need to change to a float. The upper and lower cuts >> > > > > >> >> would be in seconds +/- the mean (also needs to change >> > > > > >> >to >> > > > > >> >> float) and are simply used to trim the function - >> > > > > >> >> obviously needed on a uniform distribution but useful to >> > > > > >> >> constrain other >functions. >> > > > > >> >> >> > > > > >> >> I will make all this clear in the next release. >> > > > > >> >> >> > > > > >> >> As for poisson I think there are 3 options: >> > > > > >> >> >> > > > > >> >> - Use a continuous form instead >> > > > > >> >> >> > > > > >> >> - Have the discrete interval implicit in the functi= on choice >> > > > > >> >e.g."poisson_1_sec" >> > > > > >> >> >> > > > > >> >> - Add an interval to the information model. >> > > > > >> >> >> > > > > >> >> I was really thinking about the first, but I don't see >> > > > > >> >> the problem with the second. However I wouldn't do the >> > > > > >> >> third unless they was a demonstrable value to supporting >> > > > > >> >> discrete functions (rather than continuous >> > > > > >versions of them). " >> > > > > >> >> >> > > > > >> >> But as people looked at Trevors response there were >> > > > > >> >> additional >questions: >> > > > > >> >> >> > > > > >> >> I don't understand what Trevor means about the Poisson >> > > > > >> >> distribution. As far as I know, it is a discrete >> > > > > >> >> distribution, so a "continuous form" would be a >> > > > > >> >> different distribution and not Poisson. And I believe >> > > > > >> >> that we do need a >continuous >> > distribution. >> > > > > >> >> But what matters is that the definition is clear, not >> > > > > >> >> the particular >> > > > distribution >> > > > > >(I don't have an opinion on that). >> > > > > >> >> >> > > > > >> >> Could some please clarify this for us - Are we planning >> > > > > >> >> something other than Poisson method; better yet is there >> > > > > >> >> a definition for the types of >> > > > > >> >> distribution: Poisson, Normal and Uniform. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Tim >> > > > > >> > >> > > > > >> > >> > > > > >> >-- >> > > > > >> >Open WebMail Project (http://openwebmail.org) >> > > > > >> >> > > > > >> _______________________________________________ >> > > > > >> lmap mailing list >> > > > > >> lmap@ietf.org >> > > > > >> https://www.ietf.org/mailman/listinfo/lmap >> > > > > > >> > > > > > >> > > > > >-- >> > > > > >Open WebMail Project (http://openwebmail.org) >> > > > > >> > > > > _______________________________________________ >> > > > > lmap mailing list >> > > > > lmap@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/lmap >> > > > >> > > > >> > > > -- >> > > > Open WebMail Project (http://openwebmail.org) >> > > > >> > > > _______________________________________________ >> > > > 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 >> > > >> > > _______________________________________________ >> > > 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 >> > >> > -- >> > Open WebMail Project (http://openwebmail.org) >> >> -- >> Open WebMail Project (http://openwebmail.org) > > >-- >Open WebMail Project (http://openwebmail.org) From nobody Wed May 14 04:54: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 447241A0064 for ; Wed, 14 May 2014 04:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-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 gKZ2KQnzolBE for ; Wed, 14 May 2014 04:54:49 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id AF4841A0052 for ; Wed, 14 May 2014 04:54:48 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4EBsYqK021967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 06:54:34 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s4EBsXJ7025041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 07:54:33 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 14 May 2014 07:54:33 -0400 From: "Carey, Timothy (Timothy)" To: KEN KO , "trevor.burbridge@bt.com" , "marc.ibrahim@usj.edu.lb" , "sharam.hakimi@exfo.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAMH2AAABWvrAAAELs4AAIod6AAAAj6gAAAZ1bAAAAx60AAAFrJIAAAEmdgAAIBF/A///+ooCAAEZwgIAA3ImA/+awS0CAMvsTgIAAPebw///PCgCABY49gIAAKQeQ///30oAACFTNIA== Date: Wed, 14 May 2014 11:54:32 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719542C3C@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> <20140423145224.M63656@usj.edu.lb> <20140423151059.GE1056@elstar.local> <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> <20140423221748.M2036@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcate l-lucent.com> <20140510193741.M70435@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954016F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140510205713.M39371@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F7719542AB7@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] 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/pjjabyJCsN2e-UvDJaqUkzfqXBw Cc: "lmap@ietf.org" Subject: Re: [lmap] Timer: Poisson distribution question 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, 14 May 2014 11:54:54 -0000 Ken, I personally do not care; I thought we left it at offset+spread; just tryin= g to capture the result. BR, Tim -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com]=20 Sent: Wednesday, May 14, 2014 6:51 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; marc.ibrahim@usj.edu= .lb; sharam.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Tim, I'm still not sure *why* you want negative offsets. Several people have com= mented that having a uniform spread from Ti to Ti+Xmax (or equivalently, Tm= in to Tmax) is sufficient to assure randomness. I think there needs to be a= good reason to add an additional parameter. Thanks, Ken -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]=20 Sent: Wednesday, May 14, 2014 7:28 AM To: trevor.burbridge@bt.com; marc.ibrahim@usj.edu.lb; KEN KO; sharam.hakimi= @exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Trevor, I think we said, because we wanted negative offsets, that we would need the= LowerLimit (offset) and spread. Thanks, Tim -----Original Message----- From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]=20 Sent: Wednesday, May 14, 2014 4:54 AM To: marc.ibrahim@usj.edu.lb; Carey, Timothy (Timothy); KEN.KO@adtran.com; s= haram.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Just to acknowledge that this (just having spread as a positive from Ti) is= what I'll implement in the next revision of the Information Model unless t= here are further discussions. Trevor Burbridge >-----Original Message----- >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >Sent: 10 May 2014 22:03 >To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen Schoenwaelder >Cc: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org >Subject: RE: [lmap] Timer: Poisson distribution question > >The simplest to do, is to spread starting from Ti. So, all you need is to = specify only >one parameter: the spread. random values will be picked from between Ti an= d >Ti+spread. > >If you want to control spread position, then yes, you need an offset param= eter. >Random values will then be picked between Ti+offset and Ti+offset + spread= . > >BR, > >Marc. > > >On Sat, 10 May 2014 20:43:54 +0000, Carey, Timothy (Timothy) wrote >> Marc, >> >> So we can do Xmin + spread or Xmax - spread or Xmax-Xmin but you need >> the offset from Ti to allow for a negative spread from Ti, right? >> >> BR, >> Tim >> >> -----Original Message----- >> From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> Sent: Saturday, May 10, 2014 3:17 PM >> To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen >> Schoenwaelder >> Cc: trevor.burbridge@bt.com; lmap@ietf.org >> Subject: RE: [lmap] Timer: Poisson distribution question >> >> Tim, >> >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> >> I agree with Ken that Xmin is superfluous. The essential parameter is >> the spread. I suggested Xmin just to be able to control the spread >> around Ti, but this is not really important. We can just say that the >> time values will be chosen between Ti and Ti+spread. >> >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. >> >> As the draft says, the goal of randomness is to spread the load by >> preventing multiple events from occurring simultaneously. Given the >> spread interval, the uniform distribution is mathematically the best >> to achieve it. I don't see why we should use normal distribution, >> which will tend to concentrate values around some mean. >> >> >If so is this the Uniform-Discrete distribution? >> >> I suggested to express the randomness as an integer number of >> milliseconds. So the answer is yes. >> >> Finally, I would like to add a comment about the Poisson distribution >> that was the initial cause of this discussion about timer. I think >> that there was a confusion with the Poisson process used to randomize >> the instants of packets transmission in active measurements. In fact, >> Poisson in measurement context is a process describing the occurrence >> of events and not a probability distribution for a time interval (the >> related distribution is exponential as explained below). So, if a >> Poisson process is to be used in lmap context, it applies in my opinion = only to >periodic schedules as follows: >> >> - The period specified in the timing object is in fact an average pe= riod. >> For example, if an MA event occurs at Ti, the next event will occur in >> average at Ti+period >> >> - After an event occurs at Ti, the MA will choose a real number X >> according to an exponential distribution of mean =3D period. Next event >> will then occur at Ti+X. >> >> - When the inter-event time is exponential, the whole process is >> known as a Poisson process of rate =3D 1/period. >> >> - In this approach, we do not specify a spread around predefined >> instants Tis. We rather randomize the whole interval separating two >consecutive Tis. >> >> This could be another viable (but may be more complicated??) approach >> for periodic events. >> >> BR, >> >> Marc. >> >> On Sat, 10 May 2014 18:52:50 +0000, Carey, Timothy (Timothy) wrote >> > Ken, >> > >> > I am in the process of commenting on the BBF model TR-181i2a8 for >StrawBallot. >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> > >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. - If so is this the Uniform-Dis= crete >distribution? >> > >> > Thanks, >> > Tim >> > >> > -----Original Message----- >> > From: KEN KO [mailto:KEN.KO@adtran.com] >> > Sent: Thursday, April 24, 2014 7:17 AM >> > To: marc.ibrahim; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org >> > Subject: RE: [lmap] Timer: Poisson distribution question >> > >> > Since Ti+Xmin is non-random, Xmin is not really needed as a separate >> > parameter. Just offset Ti to the desired minimum time and let the >> > spread range from Ti to Ti+Xmax. >> > >> > Other than that nit, +1 >> > >> > -----Original Message----- >> > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > Sent: Wednesday, April 23, 2014 7:08 PM >> > To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > lmap@ietf.org >> > Subject: Re: [lmap] Timer: Poisson distribution question >> > >> > Based on what has been exchanged, I suggest the following: >> > >> > 1- Exact randomness definition and operation >> > -------------------------------------------- >> > IMHO, we need to define how exactly the randomness is applied. >> > >> > For a given event E (e.g. running a measurement task, start >> > reporting,...), let Ti be the predefined (scheduled) instant of the i= th >occurrence of E. >> > Adding randomness means that the event E will happen at time Ti + X >> > instead of Ti, where X is a random variable. If Xmin and Xmax denote >> > the minimum and maximum possible values of X repectively, then the >> > event E will take place at an instant randomly chosen between >> > Ti+Xmin and Ti+Xmax. The spread is equal to Xmax-Xmin >> > >> > Ti+Xmin Ti Ti+Xmax >> > ---------|-----------------|-------------------|----------- >> > >> > <-------------------------------------> >> > Spread >> > >> > Note that Xmin could be negative if E can occur before Ti like in the = figure. >> > I think that the most common values of Xmin would be 0 or (-spread/2). >> > >> > 2- Random generation of X >> > --------------------------- >> > To make it simple as stated by many, X could an integer number of >> > milliseconds uniformly chosen in the interval [Xmin, Xmax]. Xmin, >> > Xmax, and hence spread, are all integers (milliseconds). >> > >> > Then the MA has to define a function UNIF(Xmin, Xmax) or >> > equivalently UNIF(Xmin, spread) that generates a random number of >> > milliseconds from [Xmin, Xmax] interval. The controller has just to >> > send two integer variables (Xmin, >> > Xmax) or (Xmin, spread) to the MA in the timing object. >> > >> > In this minimalist approach, no need to specify the nature of >> > distribution in the timing object since it is assumed to be the unifor= m one. >> > >> > BR, >> > >> > Marc. >> > >> > On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote >> > > This example confuses resolution of the measurement result with >> > > resolution and accuracy of the time at which the measurement is >> > > initiated. Measuring round trip latencies on a Gigabit LAN may >> > > well require microsecond resolution, which could be within the >> > > capabilities of a higher end MA. But that doesn't require >> > > microsecond resolution of the time at which the measurement is >> > > initiated. In addition, for microsecond resolution on the Timer to b= e >meaningful would require synchronization to that resolution across differe= nt MAs >in the network. >> > > >> > > I'm in favor of keeping things simple and specifying Timer >> > > resolution in >> milliseconds. >> > > >> > > -----Original Message----- >> > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam >> > > Hakimi >> > > Sent: Wednesday, April 23, 2014 11:33 AM >> > > To: Juergen Schoenwaelder; marc.ibrahim >> > > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > It depends what the performance goal of the measurement is. A ping >> > > packet in a Gigabit network is just under 1 microseconds and with >> > > fast processors a packet can be sent and received at the same time i= f >granularity is milliseconds. >> > > >> > > This does not even take into account 10Gig networks, not that they >> > > would be at consumer sites, but they would sure exist inside a ISP n= etwork. >> > > >> > > Sharam >> > > >> > > -----Original Message----- >> > > From: Juergen Schoenwaelder >> > > [mailto:j.schoenwaelder@jacobs-university.de] >> > > Sent: Wednesday, April 23, 2014 11:11 AM >> > > To: marc.ibrahim >> > > Cc: trevor.burbridge@bt.com; Sharam Hakimi; >> > > timothy.carey@alcatel-lucent.com; >> > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > I believe randomization with a granularity of milliseconds is good e= nough. >> > > Within an implementation of a measurement task, one may use more >> > > precise timers. But for the randomization of the start of >> > > measurement tasks or the sending of reports, milliseconds seem to >> > > be sufficient (since there will be likely other delays introduced >> > > by the operating system that may get into the some order for startin= g a >measurement task or triggering a report). >> > > >> > > /js >> > > >> > > On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote: >> > > > I would say that choosing the millisecond as atomic time >> > > > alleviates constraints on both timer granularity and generator cap= acity. >> > > > >> > > > I still don't see a real measurement example where few >> > > > microseconds would really >> > matter. >> > > > >> > > > Practically, can a program deal with microseconds timers in >> > > > computers and >> > smartphones? >> > > > This is the scale of the OS, no? >> > > > >> > > > Marc. >> > > > >> > > > On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote >> > > > > So the question is really do we want to design for extremely >> > > > > constrained devices? I'd argue that if this is a problem for >> > > > > them then they are really going to struggle with the >> > > > > Instruction information or >> > measurement results. >> > > > > >> > > > > Trevor. >> > > > > >> > > > > >-----Original Message----- >> > > > > >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >Sent: 23 April 2014 15:00 >> > > > > >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > > >> > > > > >Here is how I see the problem. >> > > > > > >> > > > > >First we have to separate time granularity and random generatio= n. >> > > > > > >> > > > > >Time granularity depends on the timer running on the MA. e.g >> > > > > >microseconds scale means that the MA timer increment each >microsecond. >> > > > > > >> > > > > >When MA wants to generate a random time, he has to choose an >> > > > > >integer number of microseconds to count. So the problem is >> > > > > >always an integer (discrete) number generation. >> > > > > > >> > > > > >Now, if the random generator can attain the maximum integer >> > > > > >(so the maximum possible random time), then, as Trevor says, >> > > > > >no need for the timeStep I talked about, since all possible >> > > > > >durations will be expressed >as >> > multiple of microseconds. >> > > > > > >> > > > > > >> > > > > >For example, a 32 bits random generator could generate up to >> > > > > >a maximum value of 4 billions. In microseconds, this is equal >> > > > > >to less than 2 >> hours. >> > > > > > >> > > > > >It all depends on the capacity of the generator. >> > > > > >Marc. >> > > > > > >> > > > > > >> > > > > >On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote >> > > > > >> So what is the argument for the latter (discrete) option? >> > > > > >> >> > > > > >> Trevor. >> > > > > >> >> > > > > >> >-----Original Message----- >> > > > > >> >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >> >Sent: 23 April 2014 14:10 >> > > > > >> >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >> >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >> >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> > >> > > > > >> >Trevor, you're right. >> > > > > >> >it is just about whether we want a discrete or continuous ge= nerator. >> > > > > >> >If we use a continuous uniform generator, than it is >> > > > > >> >enough to specify the maximum time. >> > > > > >> >With a discrete random generator, you need to specify an >> > > > > >> >additional time granularity. >> > > > > >> > >> > > > > >> >BR, >> > > > > >> > >> > > > > >> >Marc. >> > > > > >> > >> > > > > >> > >> > > > > >> >On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote >> > > > > >> >> I'm not sure I get the point of allowing coarser >> > > > > >> >> granularity that the MA is capable of. If I want the MA >> > > > > >> >> to test/report sometime within a minute window, why not >> > > > > >> >> allow that to happen with the maximum resolution the MA >> > > > > >> >> is capable >> > > > > >> >of? >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Sharam Hakimi >> > > > > >> >> Sent: 23 April 2014 13:58 >> > > > > >> >> To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R; >> > > > > >> >> lmap@ietf.org >> > > > > >> >> Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Marc's suggestion works for me. That allows better >> > > > > >> >> interoperability in my >> > > > > >> >opinion. >> > > > > >> >> >> > > > > >> >> I do agree that we need a common "structure" and "names". >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:47 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> No - I am using the variable of your Information Model >> > > > > >> >> (LowerLimit, >> > > > > >> >UpperLimit, >> > > > > >> >> Spread) - works so far. Marc suggested a TimeStep >> > > > > >> >> parameter so we don't lockin on a specific microsecond, >> > > > > >> >> millisecond, second thing - I am open >> > > > > >to that. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:41 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Agree we need to have well defined function names. I >> > > > > >> >> thought you were also suggesting different functions >> > > > > >> >> needed different input >> > parameters. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 23 April 2014 13:36 >> > > > > >> >> To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Its not that the Measurement controller has to configure >> > > > > >> >> the timer for the >> > > > > >MA. >> > > > > >> >> >> > > > > >> >> If we do not specify the functions and variable names, >> > > > > >> >> the measurement controller doesn't have a standard way >> > > > > >> >> of configuring a >timer. >> > > > > >> >> >> > > > > >> >> For example - If I specify for a Uniform distribution >> > > > > >> >> function called "Uniform" you have a variable called >> > > > > >> >> "UpperLimit", the MA will implement the specification; >> > > > > >> >> the controller will implement the >> > > > > >specification and things work. >> > > > > >> >> >> > > > > >> >> If I do not specify anything for the Uniform >> > > > > >> >> distribution function >> > > > > >> >> - MA vendor >> > > > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" >> > > > > >> >> and maybe an >> > > > > >"Enable" >> > > > > >> >> parameter for good measure; MA vendor 2 can call it "U" >> > > > > >> >> and have an attribute "X that is an integer". >> > > > > >> >> >> > > > > >> >> Now put that variation on steroids based on the number >> > > > > >> >> of MA vendors - That is why we specify things, right? >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:24 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The measurement controller has to communicate what tests >> > > > > >> >> have to be run on >> > > > > >> >an >> > > > > >> >> MA, for how long, when to run them, what test results >> > > > > >> >> are generated, etc. Why would configuring this parameter >> > > > > >> >> be any different. Maybe I am missing >> > > > > >> >something. >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:16 AM >> > > > > >> >> To: Sharam Hakimi; >> > > > > >> >trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> So the burden is on the Measurement controller to know >> > > > > >> >> the functions and inputs specifications for each >> > > > > >> >> possible MA vendor; not something I would want to have >> > > > > >> >> to do as a Measurement controller >> > > > > >vendor. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:14 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> I do not see why vendor A or B or C matters. They would >> > > > > >> >> all be under the control of one Measurement Controller >> > > > > >> >> which would specify what inputs to use for all MAs in a gr= oup. >> > > > > >> >> >> > > > > >> >> As Trevor also mentioned this timer can be used for both >> > > > > >> >> testing and reporting and I would strongly suggest to >> > > > > >> >> have microsecond granularity. For reporting one could >> > > > > >> >> choose seconds in terms of >> > > > > >microseconds. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:04 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> If we don't define the inputs for each function (leaving >> > > > > >> >> the inputs >> > > > > >> >> opaque) you will have interop problems. MA vendor 1 >> > > > > >> >> uses these 2 inputs >> > > > > >named "A" >> > > > > >> >and >> > > > > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" >> > > > > >> >> for the same >> > > > > >function. >> > > > > >> >> >> > > > > >> >> I think we need to avoid that if we realistically want >> > > > > >> >> the Randomness function to be used efficiently. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 2:55 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The random timing can be used for both specifying when a >> > > > > >> >> test runs, or when a report is sent (or any other task >> > > > > >> >> such as contacting the Controller). It doesn't have to be = used, but >it can be. >> > > > > >> >> >> > > > > >> >> I don't really want different input variable for >> > > > > >> >> different functions. I don't see we need to. Also if we >> > > > > >> >> do, then we would have to have schema for each function >> > > > > >> >> to specify which inputs are expected (like the >> > > > > >> >> measurement task registry). I'd like to >> avoid >> > that. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 22 April 2014 22:07 >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >> Burbridge,T,Trevor, >> > > > > >> >> TUB8 R Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Sharam, >> > > > > >> >> >> > > > > >> >> We are talking about offsets for when to report; in the >> > > > > >> >> world we live in milliseconds is sufficient - IMHO. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:59 PM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the min/max should have microseconds granularity. >> > > > > >> >> Milliseconds would not be accurate enough. >> > > > > >> >> >> > > > > >> >> Personally, I would not trust my periodic tests in a >> > > > > >> >> large scale deployment to a random number generator and >> > > > > >> >> would want to know exactly how and when >> > > > > >> >tests >> > > > > >> >> would be run. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:16 PM >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> The data model is extensible by vendors so we can add >> > > > > >> >> functions and input variables as we need. >> > > > > >> >> >> > > > > >> >> However we have to decide on which small subset we >> > > > > >> >> actually want to >> > > > > >> >standardize. >> > > > > >> >> >> > > > > >> >> You suggested the Uniform and Normal which is fine but >> > > > > >> >> for the model we need to go farther by defining the >> > > > > >> >> specific function along with which inputs are used by >> > > > > >> >> the function to derive what random number. Otherwise we >> > > > > >> >> will have 2 implementers of the same standard algorithm >implement different variations. - Not good. >> > > > > >> >> >> > > > > >> >> So I suggest we keep this simple. >> > > > > >> >> >> > > > > >> >> Uniform Discrete - input variables - maximum [positive >> > > > > >> >> integer] Gaussian -input variables - mean of min/max, >> > > > > >> >> spread =3D standard deviation >> > > > > >> >> >> > > > > >> >> The min/max would be milliseconds - Spread would be an int= eger. >> > > > > >> >> >> > > > > >> >> This sound OK? >> > > > > >> >> >> > > > > >> >> BR >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 8:23 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the Periodic Timer distribution needs to have >> > > > > >> >> closer configuration control by the user and I think >> > > > > >> >> your 2nd choice attempts to provide it but having a >> > > > > >> >> discrete interval definition is a better way >> > > > > >to go. >> > > > > >> >> >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Sent: Tuesday, April 22, 2014 4:35 AM >> > > > > >> >> To: >> > > > > >> >> timothy.carey@alcatel-lucent.com> > > > > >> >> catel- >> > > > > >> >lucent.com>; >> > > > > >> >> lmap@ietf.org Subject: Re: [lmap] Ti= mer: >> > > > > >> >> Poisson distribution question >> > > > > >> >> >> > > > > >> >> On continuous counterparts of Poisson I'm far from any >> > > > > >> >> expert and it would certainly be up to the user to >> > > > > >> >> decide if such functions were suitable replacements for >> > > > > >> >> the discrete Poisson function. Yes it would be a >> > > > > >> >> different function even if there was perfect fit (which >> > > > > >> >> they are not) as one is continuous and one is >> > discrete: >> > > > > >> >> http://cmscience.blogspot.co.uk/2008/04/mt- >> > > > > >> >6- >> > > > > >> >> poisson-and-gamma-distribution.html >> > > > > >> >> http://arxiv.org/abs/1303.5990 >> > > > > >> >> >> > > > > >> >> As I tried to say the current Information Model can take >> > > > > >> >> either discrete or continuous functions - only that >> > > > > >> >> there is currently no explicit support for specifying >> > > > > >> >> the interval used for a discrete function. I was questioni= ng the >need to add this. >> > > > > >> >> >> > > > > >> >> Personally I'd think that Normal and Uniform >> > > > > >> >> distributions would cover most needs, but the framework >> > > > > >> >> should be flexible in this >> regard. >> > > > > >> >> >> > > > > >> >> Trevor. >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Carey, Timothy >> > > > > >> >(Timothy) >> > > > > >> >> Sent: 19 April 2014 20:24 >> > > > > >> >> To: lmap@ietf.org >> > > > > >> >> Subject: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Team, >> > > > > >> >> >> > > > > >> >> The BBF is looking at standardizing the model for Timers >> > > > > >> >> as suggested by the IETF LMAP information model. >> > > > > >> >> >> > > > > >> >> During the review of the timers we had addition >> > > > > >> >> questions regarding Trevors response to the Poisson >> > > > > >> >> distribution for the Randomness of the >> > > > > >Periodic Timer. >> > > > > >> >> >> > > > > >> >> Trevor responded: >> > > > > >> >> >> > > > > >> >> "Yes this does need to be clarified. I was assuming a >> > > > > >> >> distribution about the mean (i.e. the timing given is >> > > > > >> >> the mean). The spread would be the standard deviation >> > > > > >> >> (could use mean deviation or something else but I see no >> > > > > >> >> advantage as long as we all know what it refers to) and >> > > > > >> >> need to change to a float. The upper and lower cuts >> > > > > >> >> would be in seconds +/- the mean (also needs to change >> > > > > >> >to >> > > > > >> >> float) and are simply used to trim the function - >> > > > > >> >> obviously needed on a uniform distribution but useful to >> > > > > >> >> constrain other >functions. >> > > > > >> >> >> > > > > >> >> I will make all this clear in the next release. >> > > > > >> >> >> > > > > >> >> As for poisson I think there are 3 options: >> > > > > >> >> >> > > > > >> >> - Use a continuous form instead >> > > > > >> >> >> > > > > >> >> - Have the discrete interval implicit in the functi= on choice >> > > > > >> >e.g."poisson_1_sec" >> > > > > >> >> >> > > > > >> >> - Add an interval to the information model. >> > > > > >> >> >> > > > > >> >> I was really thinking about the first, but I don't see >> > > > > >> >> the problem with the second. However I wouldn't do the >> > > > > >> >> third unless they was a demonstrable value to supporting >> > > > > >> >> discrete functions (rather than continuous >> > > > > >versions of them). " >> > > > > >> >> >> > > > > >> >> But as people looked at Trevors response there were >> > > > > >> >> additional >questions: >> > > > > >> >> >> > > > > >> >> I don't understand what Trevor means about the Poisson >> > > > > >> >> distribution. As far as I know, it is a discrete >> > > > > >> >> distribution, so a "continuous form" would be a >> > > > > >> >> different distribution and not Poisson. And I believe >> > > > > >> >> that we do need a >continuous >> > distribution. >> > > > > >> >> But what matters is that the definition is clear, not >> > > > > >> >> the particular >> > > > distribution >> > > > > >(I don't have an opinion on that). >> > > > > >> >> >> > > > > >> >> Could some please clarify this for us - Are we planning >> > > > > >> >> something other than Poisson method; better yet is there >> > > > > >> >> a definition for the types of >> > > > > >> >> distribution: Poisson, Normal and Uniform. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Tim >> > > > > >> > >> > > > > >> > >> > > > > >> >-- >> > > > > >> >Open WebMail Project (http://openwebmail.org) >> > > > > >> >> > > > > >> _______________________________________________ >> > > > > >> lmap mailing list >> > > > > >> lmap@ietf.org >> > > > > >> https://www.ietf.org/mailman/listinfo/lmap >> > > > > > >> > > > > > >> > > > > >-- >> > > > > >Open WebMail Project (http://openwebmail.org) >> > > > > >> > > > > _______________________________________________ >> > > > > lmap mailing list >> > > > > lmap@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/lmap >> > > > >> > > > >> > > > -- >> > > > Open WebMail Project (http://openwebmail.org) >> > > > >> > > > _______________________________________________ >> > > > 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 >> > > >> > > _______________________________________________ >> > > 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 >> > >> > -- >> > Open WebMail Project (http://openwebmail.org) >> >> -- >> Open WebMail Project (http://openwebmail.org) > > >-- >Open WebMail Project (http://openwebmail.org) From nobody Wed May 14 05:10: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 96FC31A0062 for ; Wed, 14 May 2014 05:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 nHteNPbFI1d5 for ; Wed, 14 May 2014 05:10:11 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED2C1A006D for ; Wed, 14 May 2014 05:09:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6CF281084; Wed, 14 May 2014 14:09:25 +0200 (CEST) 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 N1NontEDBU8f; Wed, 14 May 2014 14:09:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 14 May 2014 14:09:24 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 995B920013; Wed, 14 May 2014 14:09:24 +0200 (CEST) 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 A6SAHeRBrVAU; Wed, 14 May 2014 14:09:23 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF3AA2002C; Wed, 14 May 2014 14:09:22 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 1EF6C2CD1A8B; Wed, 14 May 2014 14:09:20 +0200 (CEST) Date: Wed, 14 May 2014 14:09:20 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> Mail-Followup-To: "Carey, Timothy (Timothy)" , "marc. ibrahim" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/EnbGFTtE6fBkPouPwaiR-hqONiw Cc: "marc. ibrahim" , "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 14 May 2014 12:10:13 -0000 Yes, I stand corrected. I think I am personally leaning towards allowing multiple suppression objects in order to keep the complexity of each suppression object down to a basic minimum. /js On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > You cannot as I read the text have multiple suppression objects. Did I miss something. > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, May 14, 2014 12:52 AM > To: marc. ibrahim > Cc: Carey, Timothy (Timothy); lmap@ietf.org > Subject: Re: [lmap] Question on information model - Suppression > > On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: > > > > ma-suppression-task-names<0..*> and > > ma-suppression-schedule-names<0..*> are strings containing names of > > tasks and schedules. If we just allow to have the same name multiple > > times, a pairing association could be done between tasks without > > changing the information model. > > > > For example, ma-suppression-task-names = [T1 T1 T2 T2 T3 *] and > > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1 > > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all > > schedules, and schedule S4 will be suppressed. Does this change the > > information model Tim? > > I do not think this is needed since you can have multiple suppression > objects. But defining the intersection of > > ma-suppression-task-names = [T1 T2] > ma-suppression-schedule-names = [S1 S2] > > may not be that clear. The union is clear, suppress tasks T1 and T2 > and anything started by S1 and S2. Is the intersection interpretation > suppress any T1 started by S1, any T2 started by S1, any T1 started by > S2, any T2 started by S2? This is not really an intersection - a > strict intersection interpretation would likely lead to an empty set. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- 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 May 14 05:24: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 9D2A81A0068 for ; Wed, 14 May 2014 05:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-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 qavdOiEszcqv for ; Wed, 14 May 2014 05:24:21 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2741A005F for ; Wed, 14 May 2014 05:24:21 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4ECO8fx018767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 07:24:08 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s4ECO34q027300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 08:24:04 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 14 May 2014 08:24:03 -0400 From: "Carey, Timothy (Timothy)" To: KEN KO , "trevor.burbridge@bt.com" , "marc.ibrahim@usj.edu.lb" , "sharam.hakimi@exfo.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAMH2AAABWvrAAAELs4AAIod6AAAAj6gAAAZ1bAAAAx60AAAFrJIAAAEmdgAAIBF/A///+ooCAAEZwgIAA3ImA/+awS0CAMvsTgIAAPebw///PCgCABY49gIAAKQeQ///30oAACFTNIAAHPhOAABbQUHA= Date: Wed, 14 May 2014 12:24:02 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719542D6F@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> <20140423145224.M63656@usj.edu.lb> <20140423151059.GE1056@elstar.local> <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> <20140423221748.M2036@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcate l-lucent.com> <20140510193741.M70435@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954016F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140510205713.M39371@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F7719542AB7@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719542C3C@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] 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/sqL8s-7PgQhGHYTssfen0M0GmPY Cc: "lmap@ietf.org" Subject: Re: [lmap] Timer: Poisson distribution question 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, 14 May 2014 12:24:27 -0000 I am good with this. -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com]=20 Sent: Wednesday, May 14, 2014 7:22 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; marc.ibrahim@usj.edu= .lb; sharam.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Tim, thanks for the clarification.=20 On rereading this extended thread I see a number of views expressed. But in= the more recent comments, I *think* I see support from multiple people, an= d perhaps the beginnings of consensus, for: - One distribution (Discrete Uniform) - One time increment (milliseconds) - One parameter (spread) That is a simplification from the existing text in the information model bu= t it seems sufficient to me. Is it something to which others can agree? Best regards, Ken -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]=20 Sent: Wednesday, May 14, 2014 7:55 AM To: KEN KO; trevor.burbridge@bt.com; marc.ibrahim@usj.edu.lb; sharam.hakimi= @exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Ken, I personally do not care; I thought we left it at offset+spread; just tryin= g to capture the result. BR, Tim -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com]=20 Sent: Wednesday, May 14, 2014 6:51 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; marc.ibrahim@usj.edu= .lb; sharam.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Tim, I'm still not sure *why* you want negative offsets. Several people have com= mented that having a uniform spread from Ti to Ti+Xmax (or equivalently, Tm= in to Tmax) is sufficient to assure randomness. I think there needs to be a= good reason to add an additional parameter. Thanks, Ken -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]=20 Sent: Wednesday, May 14, 2014 7:28 AM To: trevor.burbridge@bt.com; marc.ibrahim@usj.edu.lb; KEN KO; sharam.hakimi= @exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Trevor, I think we said, because we wanted negative offsets, that we would need the= LowerLimit (offset) and spread. Thanks, Tim -----Original Message----- From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]=20 Sent: Wednesday, May 14, 2014 4:54 AM To: marc.ibrahim@usj.edu.lb; Carey, Timothy (Timothy); KEN.KO@adtran.com; s= haram.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Just to acknowledge that this (just having spread as a positive from Ti) is= what I'll implement in the next revision of the Information Model unless t= here are further discussions. Trevor Burbridge >-----Original Message----- >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >Sent: 10 May 2014 22:03 >To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen Schoenwaelder >Cc: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org >Subject: RE: [lmap] Timer: Poisson distribution question > >The simplest to do, is to spread starting from Ti. So, all you need is to = specify only >one parameter: the spread. random values will be picked from between Ti an= d >Ti+spread. > >If you want to control spread position, then yes, you need an offset param= eter. >Random values will then be picked between Ti+offset and Ti+offset + spread= . > >BR, > >Marc. > > >On Sat, 10 May 2014 20:43:54 +0000, Carey, Timothy (Timothy) wrote >> Marc, >> >> So we can do Xmin + spread or Xmax - spread or Xmax-Xmin but you need >> the offset from Ti to allow for a negative spread from Ti, right? >> >> BR, >> Tim >> >> -----Original Message----- >> From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> Sent: Saturday, May 10, 2014 3:17 PM >> To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen >> Schoenwaelder >> Cc: trevor.burbridge@bt.com; lmap@ietf.org >> Subject: RE: [lmap] Timer: Poisson distribution question >> >> Tim, >> >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> >> I agree with Ken that Xmin is superfluous. The essential parameter is >> the spread. I suggested Xmin just to be able to control the spread >> around Ti, but this is not really important. We can just say that the >> time values will be chosen between Ti and Ti+spread. >> >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. >> >> As the draft says, the goal of randomness is to spread the load by >> preventing multiple events from occurring simultaneously. Given the >> spread interval, the uniform distribution is mathematically the best >> to achieve it. I don't see why we should use normal distribution, >> which will tend to concentrate values around some mean. >> >> >If so is this the Uniform-Discrete distribution? >> >> I suggested to express the randomness as an integer number of >> milliseconds. So the answer is yes. >> >> Finally, I would like to add a comment about the Poisson distribution >> that was the initial cause of this discussion about timer. I think >> that there was a confusion with the Poisson process used to randomize >> the instants of packets transmission in active measurements. In fact, >> Poisson in measurement context is a process describing the occurrence >> of events and not a probability distribution for a time interval (the >> related distribution is exponential as explained below). So, if a >> Poisson process is to be used in lmap context, it applies in my opinion = only to >periodic schedules as follows: >> >> - The period specified in the timing object is in fact an average pe= riod. >> For example, if an MA event occurs at Ti, the next event will occur in >> average at Ti+period >> >> - After an event occurs at Ti, the MA will choose a real number X >> according to an exponential distribution of mean =3D period. Next event >> will then occur at Ti+X. >> >> - When the inter-event time is exponential, the whole process is >> known as a Poisson process of rate =3D 1/period. >> >> - In this approach, we do not specify a spread around predefined >> instants Tis. We rather randomize the whole interval separating two >consecutive Tis. >> >> This could be another viable (but may be more complicated??) approach >> for periodic events. >> >> BR, >> >> Marc. >> >> On Sat, 10 May 2014 18:52:50 +0000, Carey, Timothy (Timothy) wrote >> > Ken, >> > >> > I am in the process of commenting on the BBF model TR-181i2a8 for >StrawBallot. >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> > >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. - If so is this the Uniform-Dis= crete >distribution? >> > >> > Thanks, >> > Tim >> > >> > -----Original Message----- >> > From: KEN KO [mailto:KEN.KO@adtran.com] >> > Sent: Thursday, April 24, 2014 7:17 AM >> > To: marc.ibrahim; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org >> > Subject: RE: [lmap] Timer: Poisson distribution question >> > >> > Since Ti+Xmin is non-random, Xmin is not really needed as a separate >> > parameter. Just offset Ti to the desired minimum time and let the >> > spread range from Ti to Ti+Xmax. >> > >> > Other than that nit, +1 >> > >> > -----Original Message----- >> > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > Sent: Wednesday, April 23, 2014 7:08 PM >> > To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > lmap@ietf.org >> > Subject: Re: [lmap] Timer: Poisson distribution question >> > >> > Based on what has been exchanged, I suggest the following: >> > >> > 1- Exact randomness definition and operation >> > -------------------------------------------- >> > IMHO, we need to define how exactly the randomness is applied. >> > >> > For a given event E (e.g. running a measurement task, start >> > reporting,...), let Ti be the predefined (scheduled) instant of the i= th >occurrence of E. >> > Adding randomness means that the event E will happen at time Ti + X >> > instead of Ti, where X is a random variable. If Xmin and Xmax denote >> > the minimum and maximum possible values of X repectively, then the >> > event E will take place at an instant randomly chosen between >> > Ti+Xmin and Ti+Xmax. The spread is equal to Xmax-Xmin >> > >> > Ti+Xmin Ti Ti+Xmax >> > ---------|-----------------|-------------------|----------- >> > >> > <-------------------------------------> >> > Spread >> > >> > Note that Xmin could be negative if E can occur before Ti like in the = figure. >> > I think that the most common values of Xmin would be 0 or (-spread/2). >> > >> > 2- Random generation of X >> > --------------------------- >> > To make it simple as stated by many, X could an integer number of >> > milliseconds uniformly chosen in the interval [Xmin, Xmax]. Xmin, >> > Xmax, and hence spread, are all integers (milliseconds). >> > >> > Then the MA has to define a function UNIF(Xmin, Xmax) or >> > equivalently UNIF(Xmin, spread) that generates a random number of >> > milliseconds from [Xmin, Xmax] interval. The controller has just to >> > send two integer variables (Xmin, >> > Xmax) or (Xmin, spread) to the MA in the timing object. >> > >> > In this minimalist approach, no need to specify the nature of >> > distribution in the timing object since it is assumed to be the unifor= m one. >> > >> > BR, >> > >> > Marc. >> > >> > On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote >> > > This example confuses resolution of the measurement result with >> > > resolution and accuracy of the time at which the measurement is >> > > initiated. Measuring round trip latencies on a Gigabit LAN may >> > > well require microsecond resolution, which could be within the >> > > capabilities of a higher end MA. But that doesn't require >> > > microsecond resolution of the time at which the measurement is >> > > initiated. In addition, for microsecond resolution on the Timer to b= e >meaningful would require synchronization to that resolution across differe= nt MAs >in the network. >> > > >> > > I'm in favor of keeping things simple and specifying Timer >> > > resolution in >> milliseconds. >> > > >> > > -----Original Message----- >> > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam >> > > Hakimi >> > > Sent: Wednesday, April 23, 2014 11:33 AM >> > > To: Juergen Schoenwaelder; marc.ibrahim >> > > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > It depends what the performance goal of the measurement is. A ping >> > > packet in a Gigabit network is just under 1 microseconds and with >> > > fast processors a packet can be sent and received at the same time i= f >granularity is milliseconds. >> > > >> > > This does not even take into account 10Gig networks, not that they >> > > would be at consumer sites, but they would sure exist inside a ISP n= etwork. >> > > >> > > Sharam >> > > >> > > -----Original Message----- >> > > From: Juergen Schoenwaelder >> > > [mailto:j.schoenwaelder@jacobs-university.de] >> > > Sent: Wednesday, April 23, 2014 11:11 AM >> > > To: marc.ibrahim >> > > Cc: trevor.burbridge@bt.com; Sharam Hakimi; >> > > timothy.carey@alcatel-lucent.com; >> > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > I believe randomization with a granularity of milliseconds is good e= nough. >> > > Within an implementation of a measurement task, one may use more >> > > precise timers. But for the randomization of the start of >> > > measurement tasks or the sending of reports, milliseconds seem to >> > > be sufficient (since there will be likely other delays introduced >> > > by the operating system that may get into the some order for startin= g a >measurement task or triggering a report). >> > > >> > > /js >> > > >> > > On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote: >> > > > I would say that choosing the millisecond as atomic time >> > > > alleviates constraints on both timer granularity and generator cap= acity. >> > > > >> > > > I still don't see a real measurement example where few >> > > > microseconds would really >> > matter. >> > > > >> > > > Practically, can a program deal with microseconds timers in >> > > > computers and >> > smartphones? >> > > > This is the scale of the OS, no? >> > > > >> > > > Marc. >> > > > >> > > > On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote >> > > > > So the question is really do we want to design for extremely >> > > > > constrained devices? I'd argue that if this is a problem for >> > > > > them then they are really going to struggle with the >> > > > > Instruction information or >> > measurement results. >> > > > > >> > > > > Trevor. >> > > > > >> > > > > >-----Original Message----- >> > > > > >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >Sent: 23 April 2014 15:00 >> > > > > >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > > >> > > > > >Here is how I see the problem. >> > > > > > >> > > > > >First we have to separate time granularity and random generatio= n. >> > > > > > >> > > > > >Time granularity depends on the timer running on the MA. e.g >> > > > > >microseconds scale means that the MA timer increment each >microsecond. >> > > > > > >> > > > > >When MA wants to generate a random time, he has to choose an >> > > > > >integer number of microseconds to count. So the problem is >> > > > > >always an integer (discrete) number generation. >> > > > > > >> > > > > >Now, if the random generator can attain the maximum integer >> > > > > >(so the maximum possible random time), then, as Trevor says, >> > > > > >no need for the timeStep I talked about, since all possible >> > > > > >durations will be expressed >as >> > multiple of microseconds. >> > > > > > >> > > > > > >> > > > > >For example, a 32 bits random generator could generate up to >> > > > > >a maximum value of 4 billions. In microseconds, this is equal >> > > > > >to less than 2 >> hours. >> > > > > > >> > > > > >It all depends on the capacity of the generator. >> > > > > >Marc. >> > > > > > >> > > > > > >> > > > > >On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote >> > > > > >> So what is the argument for the latter (discrete) option? >> > > > > >> >> > > > > >> Trevor. >> > > > > >> >> > > > > >> >-----Original Message----- >> > > > > >> >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >> >Sent: 23 April 2014 14:10 >> > > > > >> >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >> >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >> >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> > >> > > > > >> >Trevor, you're right. >> > > > > >> >it is just about whether we want a discrete or continuous ge= nerator. >> > > > > >> >If we use a continuous uniform generator, than it is >> > > > > >> >enough to specify the maximum time. >> > > > > >> >With a discrete random generator, you need to specify an >> > > > > >> >additional time granularity. >> > > > > >> > >> > > > > >> >BR, >> > > > > >> > >> > > > > >> >Marc. >> > > > > >> > >> > > > > >> > >> > > > > >> >On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote >> > > > > >> >> I'm not sure I get the point of allowing coarser >> > > > > >> >> granularity that the MA is capable of. If I want the MA >> > > > > >> >> to test/report sometime within a minute window, why not >> > > > > >> >> allow that to happen with the maximum resolution the MA >> > > > > >> >> is capable >> > > > > >> >of? >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Sharam Hakimi >> > > > > >> >> Sent: 23 April 2014 13:58 >> > > > > >> >> To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R; >> > > > > >> >> lmap@ietf.org >> > > > > >> >> Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Marc's suggestion works for me. That allows better >> > > > > >> >> interoperability in my >> > > > > >> >opinion. >> > > > > >> >> >> > > > > >> >> I do agree that we need a common "structure" and "names". >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:47 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> No - I am using the variable of your Information Model >> > > > > >> >> (LowerLimit, >> > > > > >> >UpperLimit, >> > > > > >> >> Spread) - works so far. Marc suggested a TimeStep >> > > > > >> >> parameter so we don't lockin on a specific microsecond, >> > > > > >> >> millisecond, second thing - I am open >> > > > > >to that. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:41 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Agree we need to have well defined function names. I >> > > > > >> >> thought you were also suggesting different functions >> > > > > >> >> needed different input >> > parameters. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 23 April 2014 13:36 >> > > > > >> >> To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Its not that the Measurement controller has to configure >> > > > > >> >> the timer for the >> > > > > >MA. >> > > > > >> >> >> > > > > >> >> If we do not specify the functions and variable names, >> > > > > >> >> the measurement controller doesn't have a standard way >> > > > > >> >> of configuring a >timer. >> > > > > >> >> >> > > > > >> >> For example - If I specify for a Uniform distribution >> > > > > >> >> function called "Uniform" you have a variable called >> > > > > >> >> "UpperLimit", the MA will implement the specification; >> > > > > >> >> the controller will implement the >> > > > > >specification and things work. >> > > > > >> >> >> > > > > >> >> If I do not specify anything for the Uniform >> > > > > >> >> distribution function >> > > > > >> >> - MA vendor >> > > > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" >> > > > > >> >> and maybe an >> > > > > >"Enable" >> > > > > >> >> parameter for good measure; MA vendor 2 can call it "U" >> > > > > >> >> and have an attribute "X that is an integer". >> > > > > >> >> >> > > > > >> >> Now put that variation on steroids based on the number >> > > > > >> >> of MA vendors - That is why we specify things, right? >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:24 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The measurement controller has to communicate what tests >> > > > > >> >> have to be run on >> > > > > >> >an >> > > > > >> >> MA, for how long, when to run them, what test results >> > > > > >> >> are generated, etc. Why would configuring this parameter >> > > > > >> >> be any different. Maybe I am missing >> > > > > >> >something. >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:16 AM >> > > > > >> >> To: Sharam Hakimi; >> > > > > >> >trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> So the burden is on the Measurement controller to know >> > > > > >> >> the functions and inputs specifications for each >> > > > > >> >> possible MA vendor; not something I would want to have >> > > > > >> >> to do as a Measurement controller >> > > > > >vendor. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:14 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> I do not see why vendor A or B or C matters. They would >> > > > > >> >> all be under the control of one Measurement Controller >> > > > > >> >> which would specify what inputs to use for all MAs in a gr= oup. >> > > > > >> >> >> > > > > >> >> As Trevor also mentioned this timer can be used for both >> > > > > >> >> testing and reporting and I would strongly suggest to >> > > > > >> >> have microsecond granularity. For reporting one could >> > > > > >> >> choose seconds in terms of >> > > > > >microseconds. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:04 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> If we don't define the inputs for each function (leaving >> > > > > >> >> the inputs >> > > > > >> >> opaque) you will have interop problems. MA vendor 1 >> > > > > >> >> uses these 2 inputs >> > > > > >named "A" >> > > > > >> >and >> > > > > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" >> > > > > >> >> for the same >> > > > > >function. >> > > > > >> >> >> > > > > >> >> I think we need to avoid that if we realistically want >> > > > > >> >> the Randomness function to be used efficiently. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 2:55 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The random timing can be used for both specifying when a >> > > > > >> >> test runs, or when a report is sent (or any other task >> > > > > >> >> such as contacting the Controller). It doesn't have to be = used, but >it can be. >> > > > > >> >> >> > > > > >> >> I don't really want different input variable for >> > > > > >> >> different functions. I don't see we need to. Also if we >> > > > > >> >> do, then we would have to have schema for each function >> > > > > >> >> to specify which inputs are expected (like the >> > > > > >> >> measurement task registry). I'd like to >> avoid >> > that. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 22 April 2014 22:07 >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >> Burbridge,T,Trevor, >> > > > > >> >> TUB8 R Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Sharam, >> > > > > >> >> >> > > > > >> >> We are talking about offsets for when to report; in the >> > > > > >> >> world we live in milliseconds is sufficient - IMHO. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:59 PM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the min/max should have microseconds granularity. >> > > > > >> >> Milliseconds would not be accurate enough. >> > > > > >> >> >> > > > > >> >> Personally, I would not trust my periodic tests in a >> > > > > >> >> large scale deployment to a random number generator and >> > > > > >> >> would want to know exactly how and when >> > > > > >> >tests >> > > > > >> >> would be run. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:16 PM >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> The data model is extensible by vendors so we can add >> > > > > >> >> functions and input variables as we need. >> > > > > >> >> >> > > > > >> >> However we have to decide on which small subset we >> > > > > >> >> actually want to >> > > > > >> >standardize. >> > > > > >> >> >> > > > > >> >> You suggested the Uniform and Normal which is fine but >> > > > > >> >> for the model we need to go farther by defining the >> > > > > >> >> specific function along with which inputs are used by >> > > > > >> >> the function to derive what random number. Otherwise we >> > > > > >> >> will have 2 implementers of the same standard algorithm >implement different variations. - Not good. >> > > > > >> >> >> > > > > >> >> So I suggest we keep this simple. >> > > > > >> >> >> > > > > >> >> Uniform Discrete - input variables - maximum [positive >> > > > > >> >> integer] Gaussian -input variables - mean of min/max, >> > > > > >> >> spread =3D standard deviation >> > > > > >> >> >> > > > > >> >> The min/max would be milliseconds - Spread would be an int= eger. >> > > > > >> >> >> > > > > >> >> This sound OK? >> > > > > >> >> >> > > > > >> >> BR >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 8:23 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the Periodic Timer distribution needs to have >> > > > > >> >> closer configuration control by the user and I think >> > > > > >> >> your 2nd choice attempts to provide it but having a >> > > > > >> >> discrete interval definition is a better way >> > > > > >to go. >> > > > > >> >> >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Sent: Tuesday, April 22, 2014 4:35 AM >> > > > > >> >> To: >> > > > > >> >> timothy.carey@alcatel-lucent.com> > > > > >> >> catel- >> > > > > >> >lucent.com>; >> > > > > >> >> lmap@ietf.org Subject: Re: [lmap] Ti= mer: >> > > > > >> >> Poisson distribution question >> > > > > >> >> >> > > > > >> >> On continuous counterparts of Poisson I'm far from any >> > > > > >> >> expert and it would certainly be up to the user to >> > > > > >> >> decide if such functions were suitable replacements for >> > > > > >> >> the discrete Poisson function. Yes it would be a >> > > > > >> >> different function even if there was perfect fit (which >> > > > > >> >> they are not) as one is continuous and one is >> > discrete: >> > > > > >> >> http://cmscience.blogspot.co.uk/2008/04/mt- >> > > > > >> >6- >> > > > > >> >> poisson-and-gamma-distribution.html >> > > > > >> >> http://arxiv.org/abs/1303.5990 >> > > > > >> >> >> > > > > >> >> As I tried to say the current Information Model can take >> > > > > >> >> either discrete or continuous functions - only that >> > > > > >> >> there is currently no explicit support for specifying >> > > > > >> >> the interval used for a discrete function. I was questioni= ng the >need to add this. >> > > > > >> >> >> > > > > >> >> Personally I'd think that Normal and Uniform >> > > > > >> >> distributions would cover most needs, but the framework >> > > > > >> >> should be flexible in this >> regard. >> > > > > >> >> >> > > > > >> >> Trevor. >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Carey, Timothy >> > > > > >> >(Timothy) >> > > > > >> >> Sent: 19 April 2014 20:24 >> > > > > >> >> To: lmap@ietf.org >> > > > > >> >> Subject: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Team, >> > > > > >> >> >> > > > > >> >> The BBF is looking at standardizing the model for Timers >> > > > > >> >> as suggested by the IETF LMAP information model. >> > > > > >> >> >> > > > > >> >> During the review of the timers we had addition >> > > > > >> >> questions regarding Trevors response to the Poisson >> > > > > >> >> distribution for the Randomness of the >> > > > > >Periodic Timer. >> > > > > >> >> >> > > > > >> >> Trevor responded: >> > > > > >> >> >> > > > > >> >> "Yes this does need to be clarified. I was assuming a >> > > > > >> >> distribution about the mean (i.e. the timing given is >> > > > > >> >> the mean). The spread would be the standard deviation >> > > > > >> >> (could use mean deviation or something else but I see no >> > > > > >> >> advantage as long as we all know what it refers to) and >> > > > > >> >> need to change to a float. The upper and lower cuts >> > > > > >> >> would be in seconds +/- the mean (also needs to change >> > > > > >> >to >> > > > > >> >> float) and are simply used to trim the function - >> > > > > >> >> obviously needed on a uniform distribution but useful to >> > > > > >> >> constrain other >functions. >> > > > > >> >> >> > > > > >> >> I will make all this clear in the next release. >> > > > > >> >> >> > > > > >> >> As for poisson I think there are 3 options: >> > > > > >> >> >> > > > > >> >> - Use a continuous form instead >> > > > > >> >> >> > > > > >> >> - Have the discrete interval implicit in the functi= on choice >> > > > > >> >e.g."poisson_1_sec" >> > > > > >> >> >> > > > > >> >> - Add an interval to the information model. >> > > > > >> >> >> > > > > >> >> I was really thinking about the first, but I don't see >> > > > > >> >> the problem with the second. However I wouldn't do the >> > > > > >> >> third unless they was a demonstrable value to supporting >> > > > > >> >> discrete functions (rather than continuous >> > > > > >versions of them). " >> > > > > >> >> >> > > > > >> >> But as people looked at Trevors response there were >> > > > > >> >> additional >questions: >> > > > > >> >> >> > > > > >> >> I don't understand what Trevor means about the Poisson >> > > > > >> >> distribution. As far as I know, it is a discrete >> > > > > >> >> distribution, so a "continuous form" would be a >> > > > > >> >> different distribution and not Poisson. And I believe >> > > > > >> >> that we do need a >continuous >> > distribution. >> > > > > >> >> But what matters is that the definition is clear, not >> > > > > >> >> the particular >> > > > distribution >> > > > > >(I don't have an opinion on that). >> > > > > >> >> >> > > > > >> >> Could some please clarify this for us - Are we planning >> > > > > >> >> something other than Poisson method; better yet is there >> > > > > >> >> a definition for the types of >> > > > > >> >> distribution: Poisson, Normal and Uniform. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Tim >> > > > > >> > >> > > > > >> > >> > > > > >> >-- >> > > > > >> >Open WebMail Project (http://openwebmail.org) >> > > > > >> >> > > > > >> _______________________________________________ >> > > > > >> lmap mailing list >> > > > > >> lmap@ietf.org >> > > > > >> https://www.ietf.org/mailman/listinfo/lmap >> > > > > > >> > > > > > >> > > > > >-- >> > > > > >Open WebMail Project (http://openwebmail.org) >> > > > > >> > > > > _______________________________________________ >> > > > > lmap mailing list >> > > > > lmap@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/lmap >> > > > >> > > > >> > > > -- >> > > > Open WebMail Project (http://openwebmail.org) >> > > > >> > > > _______________________________________________ >> > > > 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 >> > > >> > > _______________________________________________ >> > > 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 >> > >> > -- >> > Open WebMail Project (http://openwebmail.org) >> >> -- >> Open WebMail Project (http://openwebmail.org) > > >-- >Open WebMail Project (http://openwebmail.org) From nobody Wed May 14 05:32: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 BCD8F1A0068 for ; Wed, 14 May 2014 05:32:26 -0700 (PDT) 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_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 L4z9rwNSknMs for ; Wed, 14 May 2014 05:32:17 -0700 (PDT) Received: from p02c11o147.mxlogic.net (p02c11o147.mxlogic.net [208.65.144.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECCC1A005F for ; Wed, 14 May 2014 05:32:14 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO p02c11o147.mxlogic.net) by p02c11o147.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 84263735.2ab85b945940.35785.00-572.88669.p02c11o147.mxlogic.net (envelope-from ); Wed, 14 May 2014 06:32:08 -0600 (MDT) X-MXL-Hash: 537362487bc15b8a-a9ec4fcf757e9cd6d568320c6441ebeb575ffc02 Received: from unknown [76.164.174.83] by p02c11o147.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with SMTP id 60063735.0.29620.00-387.73026.p02c11o147.mxlogic.net (envelope-from ); Wed, 14 May 2014 06:22:37 -0600 (MDT) X-MXL-Hash: 5373600d210e4674-b733aaddbcbcb9161847f210273943c655085ede 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, 14 May 2014 07:22:22 -0500 From: KEN KO To: "Carey, Timothy (Timothy)" , "trevor.burbridge@bt.com" , "marc.ibrahim@usj.edu.lb" , "sharam.hakimi@exfo.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgAAGpuQAMg7ywAAAMetAAABaySAAABJnYAAAMjegAAEULewAAuNC4AAEP0W4AM9EAoAAALvw4AAAPFAAAAArNsAALHHk4AAA0fUgAAKAlGg//+3dwCAAFOAYA== Date: Wed, 14 May 2014 12:22:21 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> <20140423145224.M63656@usj.edu.lb> <20140423151059.GE1056@elstar.local> <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> <20140423221748.M2036@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcate l-lucent.com> <20140510193741.M70435@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954016F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140510205713.M39371@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F7719542AB7@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719542C3C@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719542C3C@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=BIo9rTgG c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=7JF6gnM3VwMA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=y1pov1uI18EA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=gxZvrgisAAAA:8 a=e9qsufxtAAAA:8 a=pTHmISxBAAAA:8 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=Rg5jOeRUAAAA:8 a=QZam-5MpAAAA:8 a=EWPDJS0nA] X-AnalysisOut: [AAA:8 a=NMdtWtFZAAAA:8 a=j3Z76cjpAAAA:8 a=5WA63G5WGDI7O49k] X-AnalysisOut: [pwYA:9 a=8Jb5UE2YEuCTbn4q:21 a=IS62FEPUuyMAoXZF:21 a=CjuIK] X-AnalysisOut: [1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=3FZX-ydVl] X-AnalysisOut: [cEA:10 a=W1qU_X6G3J8A:10 a=DAs2C8GDBtAA:10 a=zeshHG33Dl4A:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=DvnSUQUdWHYA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014051406); S=0.200(2014050601)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/MeTUhP8FbA00y6jmgIaJketqnow Cc: "lmap@ietf.org" Subject: Re: [lmap] Timer: Poisson distribution question 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, 14 May 2014 12:32:26 -0000 Tim, thanks for the clarification.=20 On rereading this extended thread I see a number of views expressed. But in= the more recent comments, I *think* I see support from multiple people, an= d perhaps the beginnings of consensus, for: - One distribution (Discrete Uniform) - One time increment (milliseconds) - One parameter (spread) That is a simplification from the existing text in the information model bu= t it seems sufficient to me. Is it something to which others can agree? Best regards, Ken -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]=20 Sent: Wednesday, May 14, 2014 7:55 AM To: KEN KO; trevor.burbridge@bt.com; marc.ibrahim@usj.edu.lb; sharam.hakimi= @exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Ken, I personally do not care; I thought we left it at offset+spread; just tryin= g to capture the result. BR, Tim -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com]=20 Sent: Wednesday, May 14, 2014 6:51 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; marc.ibrahim@usj.edu= .lb; sharam.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Tim, I'm still not sure *why* you want negative offsets. Several people have com= mented that having a uniform spread from Ti to Ti+Xmax (or equivalently, Tm= in to Tmax) is sufficient to assure randomness. I think there needs to be a= good reason to add an additional parameter. Thanks, Ken -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]=20 Sent: Wednesday, May 14, 2014 7:28 AM To: trevor.burbridge@bt.com; marc.ibrahim@usj.edu.lb; KEN KO; sharam.hakimi= @exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Trevor, I think we said, because we wanted negative offsets, that we would need the= LowerLimit (offset) and spread. Thanks, Tim -----Original Message----- From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]=20 Sent: Wednesday, May 14, 2014 4:54 AM To: marc.ibrahim@usj.edu.lb; Carey, Timothy (Timothy); KEN.KO@adtran.com; s= haram.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Just to acknowledge that this (just having spread as a positive from Ti) is= what I'll implement in the next revision of the Information Model unless t= here are further discussions. Trevor Burbridge >-----Original Message----- >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >Sent: 10 May 2014 22:03 >To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen Schoenwaelder >Cc: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org >Subject: RE: [lmap] Timer: Poisson distribution question > >The simplest to do, is to spread starting from Ti. So, all you need is to = specify only >one parameter: the spread. random values will be picked from between Ti an= d >Ti+spread. > >If you want to control spread position, then yes, you need an offset param= eter. >Random values will then be picked between Ti+offset and Ti+offset + spread= . > >BR, > >Marc. > > >On Sat, 10 May 2014 20:43:54 +0000, Carey, Timothy (Timothy) wrote >> Marc, >> >> So we can do Xmin + spread or Xmax - spread or Xmax-Xmin but you need >> the offset from Ti to allow for a negative spread from Ti, right? >> >> BR, >> Tim >> >> -----Original Message----- >> From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> Sent: Saturday, May 10, 2014 3:17 PM >> To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen >> Schoenwaelder >> Cc: trevor.burbridge@bt.com; lmap@ietf.org >> Subject: RE: [lmap] Timer: Poisson distribution question >> >> Tim, >> >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> >> I agree with Ken that Xmin is superfluous. The essential parameter is >> the spread. I suggested Xmin just to be able to control the spread >> around Ti, but this is not really important. We can just say that the >> time values will be chosen between Ti and Ti+spread. >> >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. >> >> As the draft says, the goal of randomness is to spread the load by >> preventing multiple events from occurring simultaneously. Given the >> spread interval, the uniform distribution is mathematically the best >> to achieve it. I don't see why we should use normal distribution, >> which will tend to concentrate values around some mean. >> >> >If so is this the Uniform-Discrete distribution? >> >> I suggested to express the randomness as an integer number of >> milliseconds. So the answer is yes. >> >> Finally, I would like to add a comment about the Poisson distribution >> that was the initial cause of this discussion about timer. I think >> that there was a confusion with the Poisson process used to randomize >> the instants of packets transmission in active measurements. In fact, >> Poisson in measurement context is a process describing the occurrence >> of events and not a probability distribution for a time interval (the >> related distribution is exponential as explained below). So, if a >> Poisson process is to be used in lmap context, it applies in my opinion = only to >periodic schedules as follows: >> >> - The period specified in the timing object is in fact an average pe= riod. >> For example, if an MA event occurs at Ti, the next event will occur in >> average at Ti+period >> >> - After an event occurs at Ti, the MA will choose a real number X >> according to an exponential distribution of mean =3D period. Next event >> will then occur at Ti+X. >> >> - When the inter-event time is exponential, the whole process is >> known as a Poisson process of rate =3D 1/period. >> >> - In this approach, we do not specify a spread around predefined >> instants Tis. We rather randomize the whole interval separating two >consecutive Tis. >> >> This could be another viable (but may be more complicated??) approach >> for periodic events. >> >> BR, >> >> Marc. >> >> On Sat, 10 May 2014 18:52:50 +0000, Carey, Timothy (Timothy) wrote >> > Ken, >> > >> > I am in the process of commenting on the BBF model TR-181i2a8 for >StrawBallot. >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> > >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. - If so is this the Uniform-Dis= crete >distribution? >> > >> > Thanks, >> > Tim >> > >> > -----Original Message----- >> > From: KEN KO [mailto:KEN.KO@adtran.com] >> > Sent: Thursday, April 24, 2014 7:17 AM >> > To: marc.ibrahim; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org >> > Subject: RE: [lmap] Timer: Poisson distribution question >> > >> > Since Ti+Xmin is non-random, Xmin is not really needed as a separate >> > parameter. Just offset Ti to the desired minimum time and let the >> > spread range from Ti to Ti+Xmax. >> > >> > Other than that nit, +1 >> > >> > -----Original Message----- >> > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > Sent: Wednesday, April 23, 2014 7:08 PM >> > To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > lmap@ietf.org >> > Subject: Re: [lmap] Timer: Poisson distribution question >> > >> > Based on what has been exchanged, I suggest the following: >> > >> > 1- Exact randomness definition and operation >> > -------------------------------------------- >> > IMHO, we need to define how exactly the randomness is applied. >> > >> > For a given event E (e.g. running a measurement task, start >> > reporting,...), let Ti be the predefined (scheduled) instant of the i= th >occurrence of E. >> > Adding randomness means that the event E will happen at time Ti + X >> > instead of Ti, where X is a random variable. If Xmin and Xmax denote >> > the minimum and maximum possible values of X repectively, then the >> > event E will take place at an instant randomly chosen between >> > Ti+Xmin and Ti+Xmax. The spread is equal to Xmax-Xmin >> > >> > Ti+Xmin Ti Ti+Xmax >> > ---------|-----------------|-------------------|----------- >> > >> > <-------------------------------------> >> > Spread >> > >> > Note that Xmin could be negative if E can occur before Ti like in the = figure. >> > I think that the most common values of Xmin would be 0 or (-spread/2). >> > >> > 2- Random generation of X >> > --------------------------- >> > To make it simple as stated by many, X could an integer number of >> > milliseconds uniformly chosen in the interval [Xmin, Xmax]. Xmin, >> > Xmax, and hence spread, are all integers (milliseconds). >> > >> > Then the MA has to define a function UNIF(Xmin, Xmax) or >> > equivalently UNIF(Xmin, spread) that generates a random number of >> > milliseconds from [Xmin, Xmax] interval. The controller has just to >> > send two integer variables (Xmin, >> > Xmax) or (Xmin, spread) to the MA in the timing object. >> > >> > In this minimalist approach, no need to specify the nature of >> > distribution in the timing object since it is assumed to be the unifor= m one. >> > >> > BR, >> > >> > Marc. >> > >> > On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote >> > > This example confuses resolution of the measurement result with >> > > resolution and accuracy of the time at which the measurement is >> > > initiated. Measuring round trip latencies on a Gigabit LAN may >> > > well require microsecond resolution, which could be within the >> > > capabilities of a higher end MA. But that doesn't require >> > > microsecond resolution of the time at which the measurement is >> > > initiated. In addition, for microsecond resolution on the Timer to b= e >meaningful would require synchronization to that resolution across differe= nt MAs >in the network. >> > > >> > > I'm in favor of keeping things simple and specifying Timer >> > > resolution in >> milliseconds. >> > > >> > > -----Original Message----- >> > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam >> > > Hakimi >> > > Sent: Wednesday, April 23, 2014 11:33 AM >> > > To: Juergen Schoenwaelder; marc.ibrahim >> > > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > It depends what the performance goal of the measurement is. A ping >> > > packet in a Gigabit network is just under 1 microseconds and with >> > > fast processors a packet can be sent and received at the same time i= f >granularity is milliseconds. >> > > >> > > This does not even take into account 10Gig networks, not that they >> > > would be at consumer sites, but they would sure exist inside a ISP n= etwork. >> > > >> > > Sharam >> > > >> > > -----Original Message----- >> > > From: Juergen Schoenwaelder >> > > [mailto:j.schoenwaelder@jacobs-university.de] >> > > Sent: Wednesday, April 23, 2014 11:11 AM >> > > To: marc.ibrahim >> > > Cc: trevor.burbridge@bt.com; Sharam Hakimi; >> > > timothy.carey@alcatel-lucent.com; >> > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > I believe randomization with a granularity of milliseconds is good e= nough. >> > > Within an implementation of a measurement task, one may use more >> > > precise timers. But for the randomization of the start of >> > > measurement tasks or the sending of reports, milliseconds seem to >> > > be sufficient (since there will be likely other delays introduced >> > > by the operating system that may get into the some order for startin= g a >measurement task or triggering a report). >> > > >> > > /js >> > > >> > > On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote: >> > > > I would say that choosing the millisecond as atomic time >> > > > alleviates constraints on both timer granularity and generator cap= acity. >> > > > >> > > > I still don't see a real measurement example where few >> > > > microseconds would really >> > matter. >> > > > >> > > > Practically, can a program deal with microseconds timers in >> > > > computers and >> > smartphones? >> > > > This is the scale of the OS, no? >> > > > >> > > > Marc. >> > > > >> > > > On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote >> > > > > So the question is really do we want to design for extremely >> > > > > constrained devices? I'd argue that if this is a problem for >> > > > > them then they are really going to struggle with the >> > > > > Instruction information or >> > measurement results. >> > > > > >> > > > > Trevor. >> > > > > >> > > > > >-----Original Message----- >> > > > > >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >Sent: 23 April 2014 15:00 >> > > > > >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > > >> > > > > >Here is how I see the problem. >> > > > > > >> > > > > >First we have to separate time granularity and random generatio= n. >> > > > > > >> > > > > >Time granularity depends on the timer running on the MA. e.g >> > > > > >microseconds scale means that the MA timer increment each >microsecond. >> > > > > > >> > > > > >When MA wants to generate a random time, he has to choose an >> > > > > >integer number of microseconds to count. So the problem is >> > > > > >always an integer (discrete) number generation. >> > > > > > >> > > > > >Now, if the random generator can attain the maximum integer >> > > > > >(so the maximum possible random time), then, as Trevor says, >> > > > > >no need for the timeStep I talked about, since all possible >> > > > > >durations will be expressed >as >> > multiple of microseconds. >> > > > > > >> > > > > > >> > > > > >For example, a 32 bits random generator could generate up to >> > > > > >a maximum value of 4 billions. In microseconds, this is equal >> > > > > >to less than 2 >> hours. >> > > > > > >> > > > > >It all depends on the capacity of the generator. >> > > > > >Marc. >> > > > > > >> > > > > > >> > > > > >On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote >> > > > > >> So what is the argument for the latter (discrete) option? >> > > > > >> >> > > > > >> Trevor. >> > > > > >> >> > > > > >> >-----Original Message----- >> > > > > >> >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >> >Sent: 23 April 2014 14:10 >> > > > > >> >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >> >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >> >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> > >> > > > > >> >Trevor, you're right. >> > > > > >> >it is just about whether we want a discrete or continuous ge= nerator. >> > > > > >> >If we use a continuous uniform generator, than it is >> > > > > >> >enough to specify the maximum time. >> > > > > >> >With a discrete random generator, you need to specify an >> > > > > >> >additional time granularity. >> > > > > >> > >> > > > > >> >BR, >> > > > > >> > >> > > > > >> >Marc. >> > > > > >> > >> > > > > >> > >> > > > > >> >On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote >> > > > > >> >> I'm not sure I get the point of allowing coarser >> > > > > >> >> granularity that the MA is capable of. If I want the MA >> > > > > >> >> to test/report sometime within a minute window, why not >> > > > > >> >> allow that to happen with the maximum resolution the MA >> > > > > >> >> is capable >> > > > > >> >of? >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Sharam Hakimi >> > > > > >> >> Sent: 23 April 2014 13:58 >> > > > > >> >> To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R; >> > > > > >> >> lmap@ietf.org >> > > > > >> >> Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Marc's suggestion works for me. That allows better >> > > > > >> >> interoperability in my >> > > > > >> >opinion. >> > > > > >> >> >> > > > > >> >> I do agree that we need a common "structure" and "names". >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:47 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> No - I am using the variable of your Information Model >> > > > > >> >> (LowerLimit, >> > > > > >> >UpperLimit, >> > > > > >> >> Spread) - works so far. Marc suggested a TimeStep >> > > > > >> >> parameter so we don't lockin on a specific microsecond, >> > > > > >> >> millisecond, second thing - I am open >> > > > > >to that. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:41 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Agree we need to have well defined function names. I >> > > > > >> >> thought you were also suggesting different functions >> > > > > >> >> needed different input >> > parameters. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 23 April 2014 13:36 >> > > > > >> >> To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Its not that the Measurement controller has to configure >> > > > > >> >> the timer for the >> > > > > >MA. >> > > > > >> >> >> > > > > >> >> If we do not specify the functions and variable names, >> > > > > >> >> the measurement controller doesn't have a standard way >> > > > > >> >> of configuring a >timer. >> > > > > >> >> >> > > > > >> >> For example - If I specify for a Uniform distribution >> > > > > >> >> function called "Uniform" you have a variable called >> > > > > >> >> "UpperLimit", the MA will implement the specification; >> > > > > >> >> the controller will implement the >> > > > > >specification and things work. >> > > > > >> >> >> > > > > >> >> If I do not specify anything for the Uniform >> > > > > >> >> distribution function >> > > > > >> >> - MA vendor >> > > > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" >> > > > > >> >> and maybe an >> > > > > >"Enable" >> > > > > >> >> parameter for good measure; MA vendor 2 can call it "U" >> > > > > >> >> and have an attribute "X that is an integer". >> > > > > >> >> >> > > > > >> >> Now put that variation on steroids based on the number >> > > > > >> >> of MA vendors - That is why we specify things, right? >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:24 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The measurement controller has to communicate what tests >> > > > > >> >> have to be run on >> > > > > >> >an >> > > > > >> >> MA, for how long, when to run them, what test results >> > > > > >> >> are generated, etc. Why would configuring this parameter >> > > > > >> >> be any different. Maybe I am missing >> > > > > >> >something. >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:16 AM >> > > > > >> >> To: Sharam Hakimi; >> > > > > >> >trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> So the burden is on the Measurement controller to know >> > > > > >> >> the functions and inputs specifications for each >> > > > > >> >> possible MA vendor; not something I would want to have >> > > > > >> >> to do as a Measurement controller >> > > > > >vendor. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:14 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> I do not see why vendor A or B or C matters. They would >> > > > > >> >> all be under the control of one Measurement Controller >> > > > > >> >> which would specify what inputs to use for all MAs in a gr= oup. >> > > > > >> >> >> > > > > >> >> As Trevor also mentioned this timer can be used for both >> > > > > >> >> testing and reporting and I would strongly suggest to >> > > > > >> >> have microsecond granularity. For reporting one could >> > > > > >> >> choose seconds in terms of >> > > > > >microseconds. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:04 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> If we don't define the inputs for each function (leaving >> > > > > >> >> the inputs >> > > > > >> >> opaque) you will have interop problems. MA vendor 1 >> > > > > >> >> uses these 2 inputs >> > > > > >named "A" >> > > > > >> >and >> > > > > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" >> > > > > >> >> for the same >> > > > > >function. >> > > > > >> >> >> > > > > >> >> I think we need to avoid that if we realistically want >> > > > > >> >> the Randomness function to be used efficiently. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 2:55 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The random timing can be used for both specifying when a >> > > > > >> >> test runs, or when a report is sent (or any other task >> > > > > >> >> such as contacting the Controller). It doesn't have to be = used, but >it can be. >> > > > > >> >> >> > > > > >> >> I don't really want different input variable for >> > > > > >> >> different functions. I don't see we need to. Also if we >> > > > > >> >> do, then we would have to have schema for each function >> > > > > >> >> to specify which inputs are expected (like the >> > > > > >> >> measurement task registry). I'd like to >> avoid >> > that. >> > > > > >> >> >> > > > > >> >> 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 abov= e. >> > > > > >> >> If you're not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using this informatio= n 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 22 April 2014 22:07 >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >> Burbridge,T,Trevor, >> > > > > >> >> TUB8 R Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Sharam, >> > > > > >> >> >> > > > > >> >> We are talking about offsets for when to report; in the >> > > > > >> >> world we live in milliseconds is sufficient - IMHO. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:59 PM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the min/max should have microseconds granularity. >> > > > > >> >> Milliseconds would not be accurate enough. >> > > > > >> >> >> > > > > >> >> Personally, I would not trust my periodic tests in a >> > > > > >> >> large scale deployment to a random number generator and >> > > > > >> >> would want to know exactly how and when >> > > > > >> >tests >> > > > > >> >> would be run. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:16 PM >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> The data model is extensible by vendors so we can add >> > > > > >> >> functions and input variables as we need. >> > > > > >> >> >> > > > > >> >> However we have to decide on which small subset we >> > > > > >> >> actually want to >> > > > > >> >standardize. >> > > > > >> >> >> > > > > >> >> You suggested the Uniform and Normal which is fine but >> > > > > >> >> for the model we need to go farther by defining the >> > > > > >> >> specific function along with which inputs are used by >> > > > > >> >> the function to derive what random number. Otherwise we >> > > > > >> >> will have 2 implementers of the same standard algorithm >implement different variations. - Not good. >> > > > > >> >> >> > > > > >> >> So I suggest we keep this simple. >> > > > > >> >> >> > > > > >> >> Uniform Discrete - input variables - maximum [positive >> > > > > >> >> integer] Gaussian -input variables - mean of min/max, >> > > > > >> >> spread =3D standard deviation >> > > > > >> >> >> > > > > >> >> The min/max would be milliseconds - Spread would be an int= eger. >> > > > > >> >> >> > > > > >> >> This sound OK? >> > > > > >> >> >> > > > > >> >> BR >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 8:23 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the Periodic Timer distribution needs to have >> > > > > >> >> closer configuration control by the user and I think >> > > > > >> >> your 2nd choice attempts to provide it but having a >> > > > > >> >> discrete interval definition is a better way >> > > > > >to go. >> > > > > >> >> >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Sent: Tuesday, April 22, 2014 4:35 AM >> > > > > >> >> To: >> > > > > >> >> timothy.carey@alcatel-lucent.com> > > > > >> >> catel- >> > > > > >> >lucent.com>; >> > > > > >> >> lmap@ietf.org Subject: Re: [lmap] Ti= mer: >> > > > > >> >> Poisson distribution question >> > > > > >> >> >> > > > > >> >> On continuous counterparts of Poisson I'm far from any >> > > > > >> >> expert and it would certainly be up to the user to >> > > > > >> >> decide if such functions were suitable replacements for >> > > > > >> >> the discrete Poisson function. Yes it would be a >> > > > > >> >> different function even if there was perfect fit (which >> > > > > >> >> they are not) as one is continuous and one is >> > discrete: >> > > > > >> >> http://cmscience.blogspot.co.uk/2008/04/mt- >> > > > > >> >6- >> > > > > >> >> poisson-and-gamma-distribution.html >> > > > > >> >> http://arxiv.org/abs/1303.5990 >> > > > > >> >> >> > > > > >> >> As I tried to say the current Information Model can take >> > > > > >> >> either discrete or continuous functions - only that >> > > > > >> >> there is currently no explicit support for specifying >> > > > > >> >> the interval used for a discrete function. I was questioni= ng the >need to add this. >> > > > > >> >> >> > > > > >> >> Personally I'd think that Normal and Uniform >> > > > > >> >> distributions would cover most needs, but the framework >> > > > > >> >> should be flexible in this >> regard. >> > > > > >> >> >> > > > > >> >> Trevor. >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Carey, Timothy >> > > > > >> >(Timothy) >> > > > > >> >> Sent: 19 April 2014 20:24 >> > > > > >> >> To: lmap@ietf.org >> > > > > >> >> Subject: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Team, >> > > > > >> >> >> > > > > >> >> The BBF is looking at standardizing the model for Timers >> > > > > >> >> as suggested by the IETF LMAP information model. >> > > > > >> >> >> > > > > >> >> During the review of the timers we had addition >> > > > > >> >> questions regarding Trevors response to the Poisson >> > > > > >> >> distribution for the Randomness of the >> > > > > >Periodic Timer. >> > > > > >> >> >> > > > > >> >> Trevor responded: >> > > > > >> >> >> > > > > >> >> "Yes this does need to be clarified. I was assuming a >> > > > > >> >> distribution about the mean (i.e. the timing given is >> > > > > >> >> the mean). The spread would be the standard deviation >> > > > > >> >> (could use mean deviation or something else but I see no >> > > > > >> >> advantage as long as we all know what it refers to) and >> > > > > >> >> need to change to a float. The upper and lower cuts >> > > > > >> >> would be in seconds +/- the mean (also needs to change >> > > > > >> >to >> > > > > >> >> float) and are simply used to trim the function - >> > > > > >> >> obviously needed on a uniform distribution but useful to >> > > > > >> >> constrain other >functions. >> > > > > >> >> >> > > > > >> >> I will make all this clear in the next release. >> > > > > >> >> >> > > > > >> >> As for poisson I think there are 3 options: >> > > > > >> >> >> > > > > >> >> - Use a continuous form instead >> > > > > >> >> >> > > > > >> >> - Have the discrete interval implicit in the functi= on choice >> > > > > >> >e.g."poisson_1_sec" >> > > > > >> >> >> > > > > >> >> - Add an interval to the information model. >> > > > > >> >> >> > > > > >> >> I was really thinking about the first, but I don't see >> > > > > >> >> the problem with the second. However I wouldn't do the >> > > > > >> >> third unless they was a demonstrable value to supporting >> > > > > >> >> discrete functions (rather than continuous >> > > > > >versions of them). " >> > > > > >> >> >> > > > > >> >> But as people looked at Trevors response there were >> > > > > >> >> additional >questions: >> > > > > >> >> >> > > > > >> >> I don't understand what Trevor means about the Poisson >> > > > > >> >> distribution. As far as I know, it is a discrete >> > > > > >> >> distribution, so a "continuous form" would be a >> > > > > >> >> different distribution and not Poisson. And I believe >> > > > > >> >> that we do need a >continuous >> > distribution. >> > > > > >> >> But what matters is that the definition is clear, not >> > > > > >> >> the particular >> > > > distribution >> > > > > >(I don't have an opinion on that). >> > > > > >> >> >> > > > > >> >> Could some please clarify this for us - Are we planning >> > > > > >> >> something other than Poisson method; better yet is there >> > > > > >> >> a definition for the types of >> > > > > >> >> distribution: Poisson, Normal and Uniform. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Tim >> > > > > >> > >> > > > > >> > >> > > > > >> >-- >> > > > > >> >Open WebMail Project (http://openwebmail.org) >> > > > > >> >> > > > > >> _______________________________________________ >> > > > > >> lmap mailing list >> > > > > >> lmap@ietf.org >> > > > > >> https://www.ietf.org/mailman/listinfo/lmap >> > > > > > >> > > > > > >> > > > > >-- >> > > > > >Open WebMail Project (http://openwebmail.org) >> > > > > >> > > > > _______________________________________________ >> > > > > lmap mailing list >> > > > > lmap@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/lmap >> > > > >> > > > >> > > > -- >> > > > Open WebMail Project (http://openwebmail.org) >> > > > >> > > > _______________________________________________ >> > > > 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 >> > > >> > > _______________________________________________ >> > > 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 >> > >> > -- >> > Open WebMail Project (http://openwebmail.org) >> >> -- >> Open WebMail Project (http://openwebmail.org) > > >-- >Open WebMail Project (http://openwebmail.org) From nobody Wed May 14 05:38: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 B8F821A006B for ; Wed, 14 May 2014 05:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.048 X-Spam-Level: * X-Spam-Status: No, score=1.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.651, 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 jC-vqjdNhD-T for ; Wed, 14 May 2014 05:37:51 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0641A0068 for ; Wed, 14 May 2014 05:37:50 -0700 (PDT) X-ASG-Debug-ID: 1400071209-05fac103c4a9930001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id 9rdeR1F1yyDQN795; Wed, 14 May 2014 15:40:09 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from marcHP ([10.80.0.99]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4ECbRlH007222; Wed, 14 May 2014 15:37:29 +0300 From: "Marc Ibrahim" To: "'KEN KO'" , "'Carey, Timothy \(Timothy\)'" , , , References: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> <20140423145224.M63656@usj.edu.lb> <20140423151059.GE1056@elstar.local> <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> <20140423221748.M2036@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F77195400EF@US70UWXCHMBA05.zam.alcate l-lucent.com> <201405 10193741.M70435@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954016F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140510205713.M39371@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F7719542AB7@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719542C3C@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Date: Wed, 14 May 2014 15:37:25 +0300 X-ASG-Orig-Subj: RE: [lmap] Timer: Poisson distribution question Message-ID: <06b301cf6f71$457aff70$d070fe50$@usj.edu.lb> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKx2uVvqwD2okcQ1AtOcKigbzcmkgKdiF72Ag5MNf4B9ofW/AF1B8pwAap9aOsBKNXhcQMuTPtCAfluB84B9+253AIAExvjAs/Nwf0CoFc6gwILEyH+AhXh/x0BWcln8gIpHLO/AfzNVU4CIqUdngIlO4CDAWTM1oMCGgXmTwEYxn5+Agqki4eYCwGu0A== Content-Language: en-us X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1400071209 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.5801 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/0zJQFHlEXm8AyyDw-39C1zQrj-4 Cc: lmap@ietf.org Subject: Re: [lmap] Timer: Poisson distribution question 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, 14 May 2014 12:37:58 -0000 Ok for me. Marc. -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of KEN KO Sent: Wednesday, May 14, 2014 3:22 PM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; marc.ibrahim@usj.edu.lb; sharam.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: Re: [lmap] Timer: Poisson distribution question Tim, thanks for the clarification. On rereading this extended thread I see a number of views expressed. But in the more recent comments, I *think* I see support from multiple people, and perhaps the beginnings of consensus, for: - One distribution (Discrete Uniform) - One time increment (milliseconds) - One parameter (spread) That is a simplification from the existing text in the information model but it seems sufficient to me. Is it something to which others can agree? Best regards, Ken -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Wednesday, May 14, 2014 7:55 AM To: KEN KO; trevor.burbridge@bt.com; marc.ibrahim@usj.edu.lb; sharam.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Ken, I personally do not care; I thought we left it at offset+spread; just trying to capture the result. BR, Tim -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com] Sent: Wednesday, May 14, 2014 6:51 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; marc.ibrahim@usj.edu.lb; sharam.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Tim, I'm still not sure *why* you want negative offsets. Several people have commented that having a uniform spread from Ti to Ti+Xmax (or equivalently, Tmin to Tmax) is sufficient to assure randomness. I think there needs to be a good reason to add an additional parameter. Thanks, Ken -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Wednesday, May 14, 2014 7:28 AM To: trevor.burbridge@bt.com; marc.ibrahim@usj.edu.lb; KEN KO; sharam.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Trevor, I think we said, because we wanted negative offsets, that we would need the LowerLimit (offset) and spread. Thanks, Tim -----Original Message----- From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Wednesday, May 14, 2014 4:54 AM To: marc.ibrahim@usj.edu.lb; Carey, Timothy (Timothy); KEN.KO@adtran.com; sharam.hakimi@exfo.com; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Timer: Poisson distribution question Just to acknowledge that this (just having spread as a positive from Ti) is what I'll implement in the next revision of the Information Model unless there are further discussions. Trevor Burbridge >-----Original Message----- >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >Sent: 10 May 2014 22:03 >To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen Schoenwaelder >Cc: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org >Subject: RE: [lmap] Timer: Poisson distribution question > >The simplest to do, is to spread starting from Ti. So, all you need is to specify only >one parameter: the spread. random values will be picked from between Ti and >Ti+spread. > >If you want to control spread position, then yes, you need an offset parameter. >Random values will then be picked between Ti+offset and Ti+offset + spread. > >BR, > >Marc. > > >On Sat, 10 May 2014 20:43:54 +0000, Carey, Timothy (Timothy) wrote >> Marc, >> >> So we can do Xmin + spread or Xmax - spread or Xmax-Xmin but you need >> the offset from Ti to allow for a negative spread from Ti, right? >> >> BR, >> Tim >> >> -----Original Message----- >> From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> Sent: Saturday, May 10, 2014 3:17 PM >> To: Carey, Timothy (Timothy); KEN KO; Sharam Hakimi; Juergen >> Schoenwaelder >> Cc: trevor.burbridge@bt.com; lmap@ietf.org >> Subject: RE: [lmap] Timer: Poisson distribution question >> >> Tim, >> >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> >> I agree with Ken that Xmin is superfluous. The essential parameter is >> the spread. I suggested Xmin just to be able to control the spread >> around Ti, but this is not really important. We can just say that the >> time values will be chosen between Ti and Ti+spread. >> >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. >> >> As the draft says, the goal of randomness is to spread the load by >> preventing multiple events from occurring simultaneously. Given the >> spread interval, the uniform distribution is mathematically the best >> to achieve it. I don't see why we should use normal distribution, >> which will tend to concentrate values around some mean. >> >> >If so is this the Uniform-Discrete distribution? >> >> I suggested to express the randomness as an integer number of >> milliseconds. So the answer is yes. >> >> Finally, I would like to add a comment about the Poisson distribution >> that was the initial cause of this discussion about timer. I think >> that there was a confusion with the Poisson process used to randomize >> the instants of packets transmission in active measurements. In fact, >> Poisson in measurement context is a process describing the occurrence >> of events and not a probability distribution for a time interval (the >> related distribution is exponential as explained below). So, if a >> Poisson process is to be used in lmap context, it applies in my opinion only to >periodic schedules as follows: >> >> - The period specified in the timing object is in fact an average period. >> For example, if an MA event occurs at Ti, the next event will occur in >> average at Ti+period >> >> - After an event occurs at Ti, the MA will choose a real number X >> according to an exponential distribution of mean = period. Next event >> will then occur at Ti+X. >> >> - When the inter-event time is exponential, the whole process is >> known as a Poisson process of rate = 1/period. >> >> - In this approach, we do not specify a spread around predefined >> instants Tis. We rather randomize the whole interval separating two >consecutive Tis. >> >> This could be another viable (but may be more complicated??) approach >> for periodic events. >> >> BR, >> >> Marc. >> >> On Sat, 10 May 2014 18:52:50 +0000, Carey, Timothy (Timothy) wrote >> > Ken, >> > >> > I am in the process of commenting on the BBF model TR-181i2a8 for >StrawBallot. >> > While you are correct in your assumption the Ti isn't really known >> > when you setup the timer (which also could be used for multiple >> > Tis). So I plan to keep what Marc was saying. >> > >> > My question to the group is should we limit the Randomness to just >> > the distribution to what Marc suggested or should we keep the >> > capability for multiple distributions. - If so is this the Uniform-Discrete >distribution? >> > >> > Thanks, >> > Tim >> > >> > -----Original Message----- >> > From: KEN KO [mailto:KEN.KO@adtran.com] >> > Sent: Thursday, April 24, 2014 7:17 AM >> > To: marc.ibrahim; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org >> > Subject: RE: [lmap] Timer: Poisson distribution question >> > >> > Since Ti+Xmin is non-random, Xmin is not really needed as a separate >> > parameter. Just offset Ti to the desired minimum time and let the >> > spread range from Ti to Ti+Xmax. >> > >> > Other than that nit, +1 >> > >> > -----Original Message----- >> > From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > Sent: Wednesday, April 23, 2014 7:08 PM >> > To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder >> > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > lmap@ietf.org >> > Subject: Re: [lmap] Timer: Poisson distribution question >> > >> > Based on what has been exchanged, I suggest the following: >> > >> > 1- Exact randomness definition and operation >> > -------------------------------------------- >> > IMHO, we need to define how exactly the randomness is applied. >> > >> > For a given event E (e.g. running a measurement task, start >> > reporting,...), let Ti be the predefined (scheduled) instant of the ith >occurrence of E. >> > Adding randomness means that the event E will happen at time Ti + X >> > instead of Ti, where X is a random variable. If Xmin and Xmax denote >> > the minimum and maximum possible values of X repectively, then the >> > event E will take place at an instant randomly chosen between >> > Ti+Xmin and Ti+Xmax. The spread is equal to Xmax-Xmin >> > >> > Ti+Xmin Ti Ti+Xmax >> > ---------|-----------------|-------------------|----------- >> > >> > <-------------------------------------> >> > Spread >> > >> > Note that Xmin could be negative if E can occur before Ti like in the figure. >> > I think that the most common values of Xmin would be 0 or (-spread/2). >> > >> > 2- Random generation of X >> > --------------------------- >> > To make it simple as stated by many, X could an integer number of >> > milliseconds uniformly chosen in the interval [Xmin, Xmax]. Xmin, >> > Xmax, and hence spread, are all integers (milliseconds). >> > >> > Then the MA has to define a function UNIF(Xmin, Xmax) or >> > equivalently UNIF(Xmin, spread) that generates a random number of >> > milliseconds from [Xmin, Xmax] interval. The controller has just to >> > send two integer variables (Xmin, >> > Xmax) or (Xmin, spread) to the MA in the timing object. >> > >> > In this minimalist approach, no need to specify the nature of >> > distribution in the timing object since it is assumed to be the uniform one. >> > >> > BR, >> > >> > Marc. >> > >> > On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote >> > > This example confuses resolution of the measurement result with >> > > resolution and accuracy of the time at which the measurement is >> > > initiated. Measuring round trip latencies on a Gigabit LAN may >> > > well require microsecond resolution, which could be within the >> > > capabilities of a higher end MA. But that doesn't require >> > > microsecond resolution of the time at which the measurement is >> > > initiated. In addition, for microsecond resolution on the Timer to be >meaningful would require synchronization to that resolution across different MAs >in the network. >> > > >> > > I'm in favor of keeping things simple and specifying Timer >> > > resolution in >> milliseconds. >> > > >> > > -----Original Message----- >> > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam >> > > Hakimi >> > > Sent: Wednesday, April 23, 2014 11:33 AM >> > > To: Juergen Schoenwaelder; marc.ibrahim >> > > Cc: timothy.carey@alcatel-lucent.com; trevor.burbridge@bt.com; >> > > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > It depends what the performance goal of the measurement is. A ping >> > > packet in a Gigabit network is just under 1 microseconds and with >> > > fast processors a packet can be sent and received at the same time if >granularity is milliseconds. >> > > >> > > This does not even take into account 10Gig networks, not that they >> > > would be at consumer sites, but they would sure exist inside a ISP network. >> > > >> > > Sharam >> > > >> > > -----Original Message----- >> > > From: Juergen Schoenwaelder >> > > [mailto:j.schoenwaelder@jacobs-university.de] >> > > Sent: Wednesday, April 23, 2014 11:11 AM >> > > To: marc.ibrahim >> > > Cc: trevor.burbridge@bt.com; Sharam Hakimi; >> > > timothy.carey@alcatel-lucent.com; >> > lmap@ietf.org >> > > Subject: Re: [lmap] Timer: Poisson distribution question >> > > >> > > I believe randomization with a granularity of milliseconds is good enough. >> > > Within an implementation of a measurement task, one may use more >> > > precise timers. But for the randomization of the start of >> > > measurement tasks or the sending of reports, milliseconds seem to >> > > be sufficient (since there will be likely other delays introduced >> > > by the operating system that may get into the some order for starting a >measurement task or triggering a report). >> > > >> > > /js >> > > >> > > On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote: >> > > > I would say that choosing the millisecond as atomic time >> > > > alleviates constraints on both timer granularity and generator capacity. >> > > > >> > > > I still don't see a real measurement example where few >> > > > microseconds would really >> > matter. >> > > > >> > > > Practically, can a program deal with microseconds timers in >> > > > computers and >> > smartphones? >> > > > This is the scale of the OS, no? >> > > > >> > > > Marc. >> > > > >> > > > On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote >> > > > > So the question is really do we want to design for extremely >> > > > > constrained devices? I'd argue that if this is a problem for >> > > > > them then they are really going to struggle with the >> > > > > Instruction information or >> > measurement results. >> > > > > >> > > > > Trevor. >> > > > > >> > > > > >-----Original Message----- >> > > > > >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >Sent: 23 April 2014 15:00 >> > > > > >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > > >> > > > > >Here is how I see the problem. >> > > > > > >> > > > > >First we have to separate time granularity and random generation. >> > > > > > >> > > > > >Time granularity depends on the timer running on the MA. e.g >> > > > > >microseconds scale means that the MA timer increment each >microsecond. >> > > > > > >> > > > > >When MA wants to generate a random time, he has to choose an >> > > > > >integer number of microseconds to count. So the problem is >> > > > > >always an integer (discrete) number generation. >> > > > > > >> > > > > >Now, if the random generator can attain the maximum integer >> > > > > >(so the maximum possible random time), then, as Trevor says, >> > > > > >no need for the timeStep I talked about, since all possible >> > > > > >durations will be expressed >as >> > multiple of microseconds. >> > > > > > >> > > > > > >> > > > > >For example, a 32 bits random generator could generate up to >> > > > > >a maximum value of 4 billions. In microseconds, this is equal >> > > > > >to less than 2 >> hours. >> > > > > > >> > > > > >It all depends on the capacity of the generator. >> > > > > >Marc. >> > > > > > >> > > > > > >> > > > > >On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote >> > > > > >> So what is the argument for the latter (discrete) option? >> > > > > >> >> > > > > >> Trevor. >> > > > > >> >> > > > > >> >-----Original Message----- >> > > > > >> >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> > > > > >> >Sent: 23 April 2014 14:10 >> > > > > >> >To: Burbridge,T,Trevor,TUB8 R; sharam.hakimi@exfo.com; >> > > > > >> >timothy.carey@alcatel-lucent.com; lmap@ietf.org >> > > > > >> >Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> > >> > > > > >> >Trevor, you're right. >> > > > > >> >it is just about whether we want a discrete or continuous generator. >> > > > > >> >If we use a continuous uniform generator, than it is >> > > > > >> >enough to specify the maximum time. >> > > > > >> >With a discrete random generator, you need to specify an >> > > > > >> >additional time granularity. >> > > > > >> > >> > > > > >> >BR, >> > > > > >> > >> > > > > >> >Marc. >> > > > > >> > >> > > > > >> > >> > > > > >> >On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote >> > > > > >> >> I'm not sure I get the point of allowing coarser >> > > > > >> >> granularity that the MA is capable of. If I want the MA >> > > > > >> >> to test/report sometime within a minute window, why not >> > > > > >> >> allow that to happen with the maximum resolution the MA >> > > > > >> >> is capable >> > > > > >> >of? >> > > > > >> >> >> > > > > >> >> 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 not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Sharam Hakimi >> > > > > >> >> Sent: 23 April 2014 13:58 >> > > > > >> >> To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R; >> > > > > >> >> lmap@ietf.org >> > > > > >> >> Subject: Re: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Marc's suggestion works for me. That allows better >> > > > > >> >> interoperability in my >> > > > > >> >opinion. >> > > > > >> >> >> > > > > >> >> I do agree that we need a common "structure" and "names". >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:47 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> No - I am using the variable of your Information Model >> > > > > >> >> (LowerLimit, >> > > > > >> >UpperLimit, >> > > > > >> >> Spread) - works so far. Marc suggested a TimeStep >> > > > > >> >> parameter so we don't lockin on a specific microsecond, >> > > > > >> >> millisecond, second thing - I am open >> > > > > >to that. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:41 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Agree we need to have well defined function names. I >> > > > > >> >> thought you were also suggesting different functions >> > > > > >> >> needed different input >> > parameters. >> > > > > >> >> >> > > > > >> >> 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 not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 23 April 2014 13:36 >> > > > > >> >> To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Its not that the Measurement controller has to configure >> > > > > >> >> the timer for the >> > > > > >MA. >> > > > > >> >> >> > > > > >> >> If we do not specify the functions and variable names, >> > > > > >> >> the measurement controller doesn't have a standard way >> > > > > >> >> of configuring a >timer. >> > > > > >> >> >> > > > > >> >> For example - If I specify for a Uniform distribution >> > > > > >> >> function called "Uniform" you have a variable called >> > > > > >> >> "UpperLimit", the MA will implement the specification; >> > > > > >> >> the controller will implement the >> > > > > >specification and things work. >> > > > > >> >> >> > > > > >> >> If I do not specify anything for the Uniform >> > > > > >> >> distribution function >> > > > > >> >> - MA vendor >> > > > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" >> > > > > >> >> and maybe an >> > > > > >"Enable" >> > > > > >> >> parameter for good measure; MA vendor 2 can call it "U" >> > > > > >> >> and have an attribute "X that is an integer". >> > > > > >> >> >> > > > > >> >> Now put that variation on steroids based on the number >> > > > > >> >> of MA vendors - That is why we specify things, right? >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:24 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The measurement controller has to communicate what tests >> > > > > >> >> have to be run on >> > > > > >> >an >> > > > > >> >> MA, for how long, when to run them, what test results >> > > > > >> >> are generated, etc. Why would configuring this parameter >> > > > > >> >> be any different. Maybe I am missing >> > > > > >> >something. >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:16 AM >> > > > > >> >> To: Sharam Hakimi; >> > > > > >> >trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> So the burden is on the Measurement controller to know >> > > > > >> >> the functions and inputs specifications for each >> > > > > >> >> possible MA vendor; not something I would want to have >> > > > > >> >> to do as a Measurement controller >> > > > > >vendor. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 7:14 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> I do not see why vendor A or B or C matters. They would >> > > > > >> >> all be under the control of one Measurement Controller >> > > > > >> >> which would specify what inputs to use for all MAs in a group. >> > > > > >> >> >> > > > > >> >> As Trevor also mentioned this timer can be used for both >> > > > > >> >> testing and reporting and I would strongly suggest to >> > > > > >> >> have microsecond granularity. For reporting one could >> > > > > >> >> choose seconds in terms of >> > > > > >microseconds. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 8:04 AM >> > > > > >> >> To: >> > > > > >> >> trevor.burbridge@bt.com; >> > > > > >> >> Sharam >> > > > > >> >Hakimi; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> If we don't define the inputs for each function (leaving >> > > > > >> >> the inputs >> > > > > >> >> opaque) you will have interop problems. MA vendor 1 >> > > > > >> >> uses these 2 inputs >> > > > > >named "A" >> > > > > >> >and >> > > > > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" >> > > > > >> >> for the same >> > > > > >function. >> > > > > >> >> >> > > > > >> >> I think we need to avoid that if we realistically want >> > > > > >> >> the Randomness function to be used efficiently. >> > > > > >> >> >> > > > > >> >> BR, >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: >> > > > > >> >> trevor.burbridge@bt.com >> > > > > >> >[mailto:trevor.burbridge@bt.com] >> > > > > >> >> Sent: Wednesday, April 23, 2014 2:55 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> sharam.hakimi@exfo.com; >> > > > > >> >lmap@ietf.org >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> The random timing can be used for both specifying when a >> > > > > >> >> test runs, or when a report is sent (or any other task >> > > > > >> >> such as contacting the Controller). It doesn't have to be used, but >it can be. >> > > > > >> >> >> > > > > >> >> I don't really want different input variable for >> > > > > >> >> different functions. I don't see we need to. Also if we >> > > > > >> >> do, then we would have to have schema for each function >> > > > > >> >> to specify which inputs are expected (like the >> > > > > >> >> measurement task registry). I'd like to >> avoid >> > that. >> > > > > >> >> >> > > > > >> >> 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 not the intended recipient, note that >> > > > > >> >> disclosing, copying, distributing or using 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. >> > > > > >> >> British Telecommunications plc Registered >> > > > > >> >> office: 81 Newgate Street London EC1A 7AJ Registered in >> > > > > >> >> England >> > > > > >> >no: >> > > > > >> >> 1800000 >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: 22 April 2014 22:07 >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >> Burbridge,T,Trevor, >> > > > > >> >> TUB8 R Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Sharam, >> > > > > >> >> >> > > > > >> >> We are talking about offsets for when to report; in the >> > > > > >> >> world we live in milliseconds is sufficient - IMHO. >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:59 PM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the min/max should have microseconds granularity. >> > > > > >> >> Milliseconds would not be accurate enough. >> > > > > >> >> >> > > > > >> >> Personally, I would not trust my periodic tests in a >> > > > > >> >> large scale deployment to a random number generator and >> > > > > >> >> would want to know exactly how and when >> > > > > >> >tests >> > > > > >> >> would be run. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: Carey, Timothy (Timothy) >> > > > > >> >> [mailto:timothy.carey@alcatel-lucent.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 3:16 PM >> > > > > >> >> To: Sharam Hakimi; lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Trevor, >> > > > > >> >> >> > > > > >> >> The data model is extensible by vendors so we can add >> > > > > >> >> functions and input variables as we need. >> > > > > >> >> >> > > > > >> >> However we have to decide on which small subset we >> > > > > >> >> actually want to >> > > > > >> >standardize. >> > > > > >> >> >> > > > > >> >> You suggested the Uniform and Normal which is fine but >> > > > > >> >> for the model we need to go farther by defining the >> > > > > >> >> specific function along with which inputs are used by >> > > > > >> >> the function to derive what random number. Otherwise we >> > > > > >> >> will have 2 implementers of the same standard algorithm >implement different variations. - Not good. >> > > > > >> >> >> > > > > >> >> So I suggest we keep this simple. >> > > > > >> >> >> > > > > >> >> Uniform Discrete - input variables - maximum [positive >> > > > > >> >> integer] Gaussian -input variables - mean of min/max, >> > > > > >> >> spread = standard deviation >> > > > > >> >> >> > > > > >> >> The min/max would be milliseconds - Spread would be an integer. >> > > > > >> >> >> > > > > >> >> This sound OK? >> > > > > >> >> >> > > > > >> >> BR >> > > > > >> >> Tim >> > > > > >> >> >> > > > > >> >> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >> > > > > >> >> Sent: Tuesday, April 22, 2014 8:23 AM >> > > > > >> >> To: Carey, Timothy (Timothy); >> > > > > >> >> lmap@ietf.org; >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Subject: RE: Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Tim, >> > > > > >> >> I think the Periodic Timer distribution needs to have >> > > > > >> >> closer configuration control by the user and I think >> > > > > >> >> your 2nd choice attempts to provide it but having a >> > > > > >> >> discrete interval definition is a better way >> > > > > >to go. >> > > > > >> >> >> > > > > >> >> Sharam >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >trevor.burbridge@bt.com >> > > > > >> >> Sent: Tuesday, April 22, 2014 4:35 AM >> > > > > >> >> To: >> > > > > >> >> timothy.carey@alcatel-lucent.com> > > > > >> >> catel- >> > > > > >> >lucent.com>; >> > > > > >> >> lmap@ietf.org Subject: Re: [lmap] Timer: >> > > > > >> >> Poisson distribution question >> > > > > >> >> >> > > > > >> >> On continuous counterparts of Poisson I'm far from any >> > > > > >> >> expert and it would certainly be up to the user to >> > > > > >> >> decide if such functions were suitable replacements for >> > > > > >> >> the discrete Poisson function. Yes it would be a >> > > > > >> >> different function even if there was perfect fit (which >> > > > > >> >> they are not) as one is continuous and one is >> > discrete: >> > > > > >> >> http://cmscience.blogspot.co.uk/2008/04/mt- >> > > > > >> >6- >> > > > > >> >> poisson-and-gamma-distribution.html >> > > > > >> >> http://arxiv.org/abs/1303.5990 >> > > > > >> >> >> > > > > >> >> As I tried to say the current Information Model can take >> > > > > >> >> either discrete or continuous functions - only that >> > > > > >> >> there is currently no explicit support for specifying >> > > > > >> >> the interval used for a discrete function. I was questioning the >need to add this. >> > > > > >> >> >> > > > > >> >> Personally I'd think that Normal and Uniform >> > > > > >> >> distributions would cover most needs, but the framework >> > > > > >> >> should be flexible in this >> regard. >> > > > > >> >> >> > > > > >> >> Trevor. >> > > > > >> >> >> > > > > >> >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >> > > > > >> >> Carey, Timothy >> > > > > >> >(Timothy) >> > > > > >> >> Sent: 19 April 2014 20:24 >> > > > > >> >> To: lmap@ietf.org >> > > > > >> >> Subject: [lmap] Timer: Poisson distribution question >> > > > > >> >> >> > > > > >> >> Team, >> > > > > >> >> >> > > > > >> >> The BBF is looking at standardizing the model for Timers >> > > > > >> >> as suggested by the IETF LMAP information model. >> > > > > >> >> >> > > > > >> >> During the review of the timers we had addition >> > > > > >> >> questions regarding Trevors response to the Poisson >> > > > > >> >> distribution for the Randomness of the >> > > > > >Periodic Timer. >> > > > > >> >> >> > > > > >> >> Trevor responded: >> > > > > >> >> >> > > > > >> >> "Yes this does need to be clarified. I was assuming a >> > > > > >> >> distribution about the mean (i.e. the timing given is >> > > > > >> >> the mean). The spread would be the standard deviation >> > > > > >> >> (could use mean deviation or something else but I see no >> > > > > >> >> advantage as long as we all know what it refers to) and >> > > > > >> >> need to change to a float. The upper and lower cuts >> > > > > >> >> would be in seconds +/- the mean (also needs to change >> > > > > >> >to >> > > > > >> >> float) and are simply used to trim the function - >> > > > > >> >> obviously needed on a uniform distribution but useful to >> > > > > >> >> constrain other >functions. >> > > > > >> >> >> > > > > >> >> I will make all this clear in the next release. >> > > > > >> >> >> > > > > >> >> As for poisson I think there are 3 options: >> > > > > >> >> >> > > > > >> >> - Use a continuous form instead >> > > > > >> >> >> > > > > >> >> - Have the discrete interval implicit in the function choice >> > > > > >> >e.g."poisson_1_sec" >> > > > > >> >> >> > > > > >> >> - Add an interval to the information model. >> > > > > >> >> >> > > > > >> >> I was really thinking about the first, but I don't see >> > > > > >> >> the problem with the second. However I wouldn't do the >> > > > > >> >> third unless they was a demonstrable value to supporting >> > > > > >> >> discrete functions (rather than continuous >> > > > > >versions of them). " >> > > > > >> >> >> > > > > >> >> But as people looked at Trevors response there were >> > > > > >> >> additional >questions: >> > > > > >> >> >> > > > > >> >> I don't understand what Trevor means about the Poisson >> > > > > >> >> distribution. As far as I know, it is a discrete >> > > > > >> >> distribution, so a "continuous form" would be a >> > > > > >> >> different distribution and not Poisson. And I believe >> > > > > >> >> that we do need a >continuous >> > distribution. >> > > > > >> >> But what matters is that the definition is clear, not >> > > > > >> >> the particular >> > > > distribution >> > > > > >(I don't have an opinion on that). >> > > > > >> >> >> > > > > >> >> Could some please clarify this for us - Are we planning >> > > > > >> >> something other than Poisson method; better yet is there >> > > > > >> >> a definition for the types of >> > > > > >> >> distribution: Poisson, Normal and Uniform. >> > > > > >> >> >> > > > > >> >> Thanks, >> > > > > >> >> Tim >> > > > > >> > >> > > > > >> > >> > > > > >> >-- >> > > > > >> >Open WebMail Project (http://openwebmail.org) >> > > > > >> >> > > > > >> _______________________________________________ >> > > > > >> lmap mailing list >> > > > > >> lmap@ietf.org >> > > > > >> https://www.ietf.org/mailman/listinfo/lmap >> > > > > > >> > > > > > >> > > > > >-- >> > > > > >Open WebMail Project (http://openwebmail.org) >> > > > > >> > > > > _______________________________________________ >> > > > > lmap mailing list >> > > > > lmap@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/lmap >> > > > >> > > > >> > > > -- >> > > > Open WebMail Project (http://openwebmail.org) >> > > > >> > > > _______________________________________________ >> > > > 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 >> > > >> > > _______________________________________________ >> > > 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 >> > >> > -- >> > Open WebMail Project (http://openwebmail.org) >> >> -- >> Open WebMail Project (http://openwebmail.org) > > >-- >Open WebMail Project (http://openwebmail.org) _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Wed May 14 06:08: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 164FA1A0084 for ; Wed, 14 May 2014 06:08:30 -0700 (PDT) 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 UiRHERJXPWFw for ; Wed, 14 May 2014 06:08:28 -0700 (PDT) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by ietfa.amsl.com (Postfix) with ESMTP id 05EB01A007B for ; Wed, 14 May 2014 06:08:27 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c12o144.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 5ca63735.2ad8c9007940.4390.00-548.11527.p01c12o144.mxlogic.net (envelope-from ); Wed, 14 May 2014 07:08:21 -0600 (MDT) X-MXL-Hash: 53736ac5729de79a-604eea3d29374befb49800f7fc54b3ef4b8b8026 Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c12o144.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id e4a63735.0.3051.00-398.7892.p01c12o144.mxlogic.net (envelope-from ); Wed, 14 May 2014 07:06:29 -0600 (MDT) X-MXL-Hash: 53736a5513c1a0e2-58b34994258197ccff9d9909d68d46f6d87efa28 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; Wed, 14 May 2014 08:06:22 -0500 From: KEN KO To: Juergen Schoenwaelder , "Carey, Timothy (Timothy)" Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFAAQ0s8AAAZ592MAFopqgAABGhQAAAm/hQA= Date: Wed, 14 May 2014 13:06:21 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> In-Reply-To: <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=P9m0h0wu c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=8U0ojwJlBgkA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=y1pov1uI18EA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=rpYzwg7CVfGy4jv3uUQ] X-AnalysisOut: [A:9 a=dtVlGviVT4DXQnx2:21 a=OLHOd_jzgEPJCzB2:21 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=zeshHG33Dl4A:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014051408); S=0.200(2014050601)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/e8qqwpms0N3xpxnXwUj-JWfJwNw Cc: "marc. ibrahim" , "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 14 May 2014 13:08:30 -0000 Adding +1 to the comments cautioning us to avoid over-engineering suppressi= on. Per the framework, suppression is "used if the measurement system wants to = eliminate inessential traffic, because there is some unexpected network iss= ue for example." It provides a means of doing so without updating the exist= ing measurement schedules, as a temporary relief measure in which measureme= nts are disrupted by definition. There is no need for complete flexibility in the suppression mechanism (e.g= ., pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve this pur= pose, because you can always modify the schedules to get that level of cont= rol. When you consider that every option adds complexity to the MA, there i= s a case to be made for simplifying rather than complicating suppression.=20 WRT the existing ambiguity: I prefer barring the two fields from being used= together as that will be simplest for the MA. Union or Intersection are al= so acceptable as fixed definitions (not options). I think adding pairing or= multiple suppression objects would be a mistake. Best regards, Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: Wednesday, May 14, 2014 8:09 AM To: Carey, Timothy (Timothy) Cc: marc. ibrahim; lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression Yes, I stand corrected. I think I am personally leaning towards allowing multiple suppression objec= ts in order to keep the complexity of each suppression object down to a bas= ic minimum. /js On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > You cannot as I read the text have multiple suppression objects. Did I mi= ss something. >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, May 14, 2014 12:52 AM > To: marc. ibrahim > Cc: Carey, Timothy (Timothy); lmap@ietf.org > Subject: Re: [lmap] Question on information model - Suppression >=20 > On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: > >=20 > > ma-suppression-task-names<0..*> and > > ma-suppression-schedule-names<0..*> are strings containing names of=20 > > tasks and schedules. If we just allow to have the same name multiple=20 > > times, a pairing association could be done between tasks without=20 > > changing the information model. > > > > For example, ma-suppression-task-names =3D [T1 T1 T2 T2 T3 *] and > > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1=20 > > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all=20 > > schedules, and schedule S4 will be suppressed. Does this change the=20 > > information model Tim? >=20 > I do not think this is needed since you can have multiple suppression=20 > objects. But defining the intersection of >=20 > ma-suppression-task-names =3D [T1 T2] > ma-suppression-schedule-names =3D [S1 S2] >=20 > may not be that clear. The union is clear, suppress tasks T1 and T2=20 > and anything started by S1 and S2. Is the intersection interpretation=20 > suppress any T1 started by S1, any T2 started by S1, any T1 started by=20 > S2, any T2 started by S2? This is not really an intersection - a=20 > strict intersection interpretation would likely lead to an empty set. >=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 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 May 15 02:15: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 18F5A1A0448 for ; Thu, 15 May 2014 02:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 sGVZ1JoAy4bE for ; Thu, 15 May 2014 02:15:44 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131B61A0440 for ; Thu, 15 May 2014 02:15:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EB852750; Thu, 15 May 2014 11:15:35 +0200 (CEST) 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 oAB6rxeb0Smo; Thu, 15 May 2014 11:15:35 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 15 May 2014 11:15:35 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6AB552002F; Thu, 15 May 2014 11:15:35 +0200 (CEST) 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 ymDVvvgrE0-Y; Thu, 15 May 2014 11:15:34 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E89C20013; Thu, 15 May 2014 11:15:34 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id DCC192CD277F; Thu, 15 May 2014 11:15:33 +0200 (CEST) Date: Thu, 15 May 2014 11:15:33 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20140515091533.GA94481@elstar.jacobs.jacobs-university.de> Mail-Followup-To: "Romascanu, Dan (Dan)" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA5C7E5C84@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C7E5C84@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/G8a3LJS8zl6sC7AuqrsPyGoMWsc Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-05.txt 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, 15 May 2014 09:15:46 -0000 On Wed, May 14, 2014 at 10:10:54AM +0000, Romascanu, Dan (Dan) wrote: > Thanks to authors and all the contributors for the good work. > > We had two WGLCs for this document. All folks who made comments are kindly invited that all their comments were addressed. I do not believe that we need a third WGLC. I will leave a few days for folks to read this version and make sure that it is good enough to be submitted to the IESG. If anybody has concerns about this process, needs more time to read and review, or has new substantial comments - please speak up in the next few days. > I looked over the diff and the changes looked good to me. /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 May 15 07:21: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 E64071A00B9 for ; Thu, 15 May 2014 07:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 D56ZDHGeGBWf for ; Thu, 15 May 2014 07:21:11 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C2F1A00BD for ; Thu, 15 May 2014 07:21:10 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s4FEKwJ7000263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 09:20:58 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s4FEKpBr029249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 May 2014 10:20:56 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 15 May 2014 10:20:55 -0400 From: "Carey, Timothy (Timothy)" To: KEN KO , Juergen Schoenwaelder Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFAAOul4AAAFBuIAAD7DoAAADqTSAAAmCoQAAAf3FgAAsTaIg Date: Thu, 15 May 2014 14:20:54 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] 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/bM8bktB3qAKvm3In2OYjpo3kxB0 Cc: "marc. ibrahim" , "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 15 May 2014 14:21:14 -0000 So I would like close on a consensus. I added the union as the first option= which seemed to have the most consensus. Do we have consensus on this? What are the rules: 1) If Tasks is non-empty and Schedules is non-empty: suppress the listed ta= sks and the listed schedules as an union of the tasks and schedules 2) If Tasks is empty and Schedules is non-empty - suppress all tasks for th= e listed=20 Schedules 3) If Tasks is non-empty and Schedules is empty: suppress listed tasks for = all schedules=20 of the task 4) If Tasks and Schedules are empty: suppress all tasks regardless of sched= ule Thanks, Tim -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com]=20 Sent: Wednesday, May 14, 2014 8:06 AM To: Juergen Schoenwaelder; Carey, Timothy (Timothy) Cc: marc. ibrahim; lmap@ietf.org Subject: RE: [lmap] Question on information model - Suppression Adding +1 to the comments cautioning us to avoid over-engineering suppressi= on. Per the framework, suppression is "used if the measurement system wants to = eliminate inessential traffic, because there is some unexpected network iss= ue for example." It provides a means of doing so without updating the exist= ing measurement schedules, as a temporary relief measure in which measureme= nts are disrupted by definition. There is no need for complete flexibility in the suppression mechanism (e.g= ., pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve this pur= pose, because you can always modify the schedules to get that level of cont= rol. When you consider that every option adds complexity to the MA, there i= s a case to be made for simplifying rather than complicating suppression.=20 WRT the existing ambiguity: I prefer barring the two fields from being used= together as that will be simplest for the MA. Union or Intersection are al= so acceptable as fixed definitions (not options). I think adding pairing or= multiple suppression objects would be a mistake. Best regards, Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: Wednesday, May 14, 2014 8:09 AM To: Carey, Timothy (Timothy) Cc: marc. ibrahim; lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression Yes, I stand corrected. I think I am personally leaning towards allowing multiple suppression objec= ts in order to keep the complexity of each suppression object down to a bas= ic minimum. /js On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > You cannot as I read the text have multiple suppression objects. Did I mi= ss something. >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, May 14, 2014 12:52 AM > To: marc. ibrahim > Cc: Carey, Timothy (Timothy); lmap@ietf.org > Subject: Re: [lmap] Question on information model - Suppression >=20 > On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: > >=20 > > ma-suppression-task-names<0..*> and > > ma-suppression-schedule-names<0..*> are strings containing names of=20 > > tasks and schedules. If we just allow to have the same name multiple=20 > > times, a pairing association could be done between tasks without=20 > > changing the information model. > > > > For example, ma-suppression-task-names =3D [T1 T1 T2 T2 T3 *] and > > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1=20 > > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all=20 > > schedules, and schedule S4 will be suppressed. Does this change the=20 > > information model Tim? >=20 > I do not think this is needed since you can have multiple suppression=20 > objects. But defining the intersection of >=20 > ma-suppression-task-names =3D [T1 T2] > ma-suppression-schedule-names =3D [S1 S2] >=20 > may not be that clear. The union is clear, suppress tasks T1 and T2=20 > and anything started by S1 and S2. Is the intersection interpretation=20 > suppress any T1 started by S1, any T2 started by S1, any T1 started by=20 > S2, any T2 started by S2? This is not really an intersection - a=20 > strict intersection interpretation would likely lead to an empty set. >=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 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 May 15 07:26: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 AC8F91A00BE for ; Thu, 15 May 2014 07:26:44 -0700 (PDT) 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 zJPnv2H2l0gi for ; Thu, 15 May 2014 07:26:42 -0700 (PDT) Received: from p02c12o145.mxlogic.net (p02c12o145.mxlogic.net [208.65.145.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544851A028A for ; Thu, 15 May 2014 07:26:42 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c12o145.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id b9ec4735.2aad3d254940.16054.00-548.43562.p02c12o145.mxlogic.net (envelope-from ); Thu, 15 May 2014 08:26:35 -0600 (MDT) X-MXL-Hash: 5374ce9b70597975-e9d337827ee18be9620945c89a63ad63db9ab471 Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c12o145.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id 3fdc4735.0.14378.00-209.38920.p02c12o145.mxlogic.net (envelope-from ); Thu, 15 May 2014 08:24:29 -0600 (MDT) X-MXL-Hash: 5374ce1d485e33c9-6e6b914bdd82bacfb932bed081de959deaeeec00 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, 15 May 2014 09:23:47 -0500 From: KEN KO To: "Carey, Timothy (Timothy)" , "Juergen Schoenwaelder" Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFAAQ0s8AAAZ592MAFopqgAABGhQAAAm/hQAALSNiAAAKZqMA Date: Thu, 15 May 2014 14:23:46 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=LMboQfm9 c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=8U0ojwJlBgkA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=y1pov1uI18EA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=gxZvrgisAAAA:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=_o] X-AnalysisOut: [wRRpBJWxu2AkzkXfwA:9 a=8wJmIl3GF520ny8F:21 a=RDsb43mS3_rlZ] X-AnalysisOut: [11T:21 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:] X-AnalysisOut: [10 a=3FZX-ydVlcEA:10 a=lZB815dzVvQA:10 a=DvnSUQUdWHYA:10 a] X-AnalysisOut: [=zeshHG33Dl4A:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014051509); S=0.200(2014050601)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9yUzPNcE3tJNdjd-n-lydy_wb7A Cc: "marc. ibrahim" , "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 15 May 2014 14:26:44 -0000 That looks good to me.=20 Ken -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]=20 Sent: Thursday, May 15, 2014 10:21 AM To: KEN KO; Juergen Schoenwaelder Cc: marc. ibrahim; lmap@ietf.org Subject: RE: [lmap] Question on information model - Suppression So I would like close on a consensus. I added the union as the first option= which seemed to have the most consensus. Do we have consensus on this? What are the rules: 1) If Tasks is non-empty and Schedules is non-empty: suppress the listed ta= sks and the listed schedules as an union of the tasks and schedules 2) If Tasks is empty and Schedules is non-empty - suppress all tasks for th= e listed Schedules 3) If Tasks is non-empty and Schedules is empty: suppress listed tasks for = all schedules of the task 4) If Tasks and Schedules are empty: suppress all tasks regardless of sched= ule Thanks, Tim -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com] Sent: Wednesday, May 14, 2014 8:06 AM To: Juergen Schoenwaelder; Carey, Timothy (Timothy) Cc: marc. ibrahim; lmap@ietf.org Subject: RE: [lmap] Question on information model - Suppression Adding +1 to the comments cautioning us to avoid over-engineering suppressi= on. Per the framework, suppression is "used if the measurement system wants to = eliminate inessential traffic, because there is some unexpected network iss= ue for example." It provides a means of doing so without updating the exist= ing measurement schedules, as a temporary relief measure in which measureme= nts are disrupted by definition. There is no need for complete flexibility in the suppression mechanism (e.g= ., pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve this pur= pose, because you can always modify the schedules to get that level of cont= rol. When you consider that every option adds complexity to the MA, there i= s a case to be made for simplifying rather than complicating suppression.=20 WRT the existing ambiguity: I prefer barring the two fields from being used= together as that will be simplest for the MA. Union or Intersection are al= so acceptable as fixed definitions (not options). I think adding pairing or= multiple suppression objects would be a mistake. Best regards, Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: Wednesday, May 14, 2014 8:09 AM To: Carey, Timothy (Timothy) Cc: marc. ibrahim; lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression Yes, I stand corrected. I think I am personally leaning towards allowing multiple suppression objec= ts in order to keep the complexity of each suppression object down to a bas= ic minimum. /js On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > You cannot as I read the text have multiple suppression objects. Did I mi= ss something. >=20 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, May 14, 2014 12:52 AM > To: marc. ibrahim > Cc: Carey, Timothy (Timothy); lmap@ietf.org > Subject: Re: [lmap] Question on information model - Suppression >=20 > On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: > >=20 > > ma-suppression-task-names<0..*> and > > ma-suppression-schedule-names<0..*> are strings containing names of=20 > > tasks and schedules. If we just allow to have the same name multiple=20 > > times, a pairing association could be done between tasks without=20 > > changing the information model. > > > > For example, ma-suppression-task-names =3D [T1 T1 T2 T2 T3 *] and > > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1=20 > > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all=20 > > schedules, and schedule S4 will be suppressed. Does this change the=20 > > information model Tim? >=20 > I do not think this is needed since you can have multiple suppression=20 > objects. But defining the intersection of >=20 > ma-suppression-task-names =3D [T1 T2] > ma-suppression-schedule-names =3D [S1 S2] >=20 > may not be that clear. The union is clear, suppress tasks T1 and T2=20 > and anything started by S1 and S2. Is the intersection interpretation=20 > suppress any T1 started by S1, any T2 started by S1, any T1 started by=20 > S2, any T2 started by S2? This is not really an intersection - a=20 > strict intersection interpretation would likely lead to an empty set. >=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 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 May 15 07:33: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 C37A91A02AD for ; Thu, 15 May 2014 07:33:09 -0700 (PDT) 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: ...43B25@US70UWXCHMBA05.zam.alcatel-lucent.com>\n 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 DzdwDByWPYq3 for ; Thu, 15 May 2014 07:33:03 -0700 (PDT) Received: from p01c11o141.mxlogic.net (p01c11o141.mxlogic.net [208.65.144.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D001A02A5 for ; Thu, 15 May 2014 07:32:52 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p01c11o141.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id e00d4735.2aca18806940.54113.00-538.143385.p01c11o141.mxlogic.net (envelope-from ); Thu, 15 May 2014 08:32:46 -0600 (MDT) X-MXL-Hash: 5374d00e728f55c1-e9906f6d62aafbd0879d094a9d952d7f1acb4e6a Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p01c11o141.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id c9fc4735.0.52572.00-171.139298.p01c11o141.mxlogic.net (envelope-from ); Thu, 15 May 2014 08:31:09 -0600 (MDT) X-MXL-Hash: 5374cfad55efb277-65c0968b1ad4d560bc28e28eca3c9d7556fbb792 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, 15 May 2014 09:30:51 -0500 From: KEN KO To: "Carey, Timothy (Timothy)" , "Juergen Schoenwaelder" Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFAAQ0s8AAAZ592MAFopqgAABGhQAAAm/hQAALSNiAAAKZqMAABS/l/A= Date: Thu, 15 May 2014 14:30:51 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=Eb9GQZWC c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=8U0ojwJlBgkA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=y1pov1uI18EA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=j3Z76cjpAAAA:8 a=rL] X-AnalysisOut: [zdAje6OGcl90fGdP0A:9 a=QZRiF7j5rXjA7EOI:21 a=ZttHQ--hge_TC] X-AnalysisOut: [SuE:21 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=3FZX-ydVlcEA:10 a=DvnSUQUdWHYA:10 a] X-AnalysisOut: [=zeshHG33Dl4A:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014051509); S=0.200(2014050601)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/T0mCAIq-yN5Fdr0xKzh2u-w1aeY Cc: "marc. ibrahim" , "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 15 May 2014 14:33:09 -0000 Modifying my own reply. #4, if Tasks and Schedules are both empty, isn't th= e default action applied to Active measurement tasks, with the effect on Pa= ssive tasks undefined? That is what the framework draft says but the inform= ation model omits the word "active." The two documents need to be consisten= t. -----Original Message----- From: KEN KO=20 Sent: Thursday, May 15, 2014 10:24 AM To: 'Carey, Timothy (Timothy)'; Juergen Schoenwaelder Cc: marc. ibrahim; lmap@ietf.org Subject: RE: [lmap] Question on information model - Suppression That looks good to me.=20 Ken -----Original Message----- From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Thursday, May 15, 2014 10:21 AM To: KEN KO; Juergen Schoenwaelder Cc: marc. ibrahim; lmap@ietf.org Subject: RE: [lmap] Question on information model - Suppression So I would like close on a consensus. I added the union as the first option= which seemed to have the most consensus. Do we have consensus on this? What are the rules: 1) If Tasks is non-empty and Schedules is non-empty: suppress the listed ta= sks and the listed schedules as an union of the tasks and schedules 2) If Tasks is empty and Schedules is non-empty - suppress all tasks for th= e listed Schedules 3) If Tasks is non-empty and Schedules is empty: suppress listed tasks for = all schedules of the task 4) If Tasks and Schedules are empty: suppress all tasks regardless of sched= ule Thanks, Tim -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com] Sent: Wednesday, May 14, 2014 8:06 AM To: Juergen Schoenwaelder; Carey, Timothy (Timothy) Cc: marc. ibrahim; lmap@ietf.org Subject: RE: [lmap] Question on information model - Suppression Adding +1 to the comments cautioning us to avoid over-engineering suppressi= on. Per the framework, suppression is "used if the measurement system wants to = eliminate inessential traffic, because there is some unexpected network iss= ue for example." It provides a means of doing so without updating the exist= ing measurement schedules, as a temporary relief measure in which measureme= nts are disrupted by definition. There is no need for complete flexibility in the suppression mechanism (e.g= ., pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve this pur= pose, because you can always modify the schedules to get that level of cont= rol. When you consider that every option adds complexity to the MA, there i= s a case to be made for simplifying rather than complicating suppression.=20 WRT the existing ambiguity: I prefer barring the two fields from being used= together as that will be simplest for the MA. Union or Intersection are al= so acceptable as fixed definitions (not options). I think adding pairing or= multiple suppression objects would be a mistake. Best regards, Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: Wednesday, May 14, 2014 8:09 AM To: Carey, Timothy (Timothy) Cc: marc. ibrahim; lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression Yes, I stand corrected. I think I am personally leaning towards allowing multiple suppression objec= ts in order to keep the complexity of each suppression object down to a bas= ic minimum. /js On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > You cannot as I read the text have multiple suppression objects. Did I mi= ss something. >=20 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, May 14, 2014 12:52 AM > To: marc. ibrahim > Cc: Carey, Timothy (Timothy); lmap@ietf.org > Subject: Re: [lmap] Question on information model - Suppression >=20 > On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: > >=20 > > ma-suppression-task-names<0..*> and > > ma-suppression-schedule-names<0..*> are strings containing names of=20 > > tasks and schedules. If we just allow to have the same name multiple=20 > > times, a pairing association could be done between tasks without=20 > > changing the information model. > > > > For example, ma-suppression-task-names =3D [T1 T1 T2 T2 T3 *] and > > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1=20 > > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all=20 > > schedules, and schedule S4 will be suppressed. Does this change the=20 > > information model Tim? >=20 > I do not think this is needed since you can have multiple suppression=20 > objects. But defining the intersection of >=20 > ma-suppression-task-names =3D [T1 T2] > ma-suppression-schedule-names =3D [S1 S2] >=20 > may not be that clear. The union is clear, suppress tasks T1 and T2=20 > and anything started by S1 and S2. Is the intersection interpretation=20 > suppress any T1 started by S1, any T2 started by S1, any T1 started by=20 > S2, any T2 started by S2? This is not really an intersection - a=20 > strict intersection interpretation would likely lead to an empty set. >=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 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 May 15 07: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 4EDBF1A04FA for ; Thu, 15 May 2014 07:35:28 -0700 (PDT) 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 cbxq3oAOBCks for ; Thu, 15 May 2014 07:35:26 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2901A04E9 for ; Thu, 15 May 2014 07:35:26 -0700 (PDT) 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 s4FEZ26b008292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 09:35:02 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 1C3891E0063; Thu, 15 May 2014 08:34:57 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id C66D21E007F; Thu, 15 May 2014 08:34:56 -0600 (MDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s4FEYuTC012334; Thu, 15 May 2014 09:34:56 -0500 (CDT) 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 s4FEYt8R012293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 May 2014 09:34:55 -0500 (CDT) 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, 15 May 2014 09:34:55 -0500 From: "Bugenhagen, Michael K" To: "'KEN KO'" , "Cook, Charles" , "'Juergen Schoenwaelder'" , "'MORTON, ALFRED C (AL)'" , "'philip.eardley@bt.com'" , "'trevor.burbridge@bt.com'" Thread-Topic: polling for any pref. / Thoughts on how to incorporate test environment methods into the testing framework Thread-Index: AQHPcErUcXl4ES3zBUSm1gj9pHmRnA== Date: Thu, 15 May 2014 14:34:54 +0000 Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.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.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/La3-6CzmrjlA9RTmOJ7_Q7j7hHo Cc: 'Brian Trammell' , "'marc. ibrahim'" , "'lmap@ietf.org'" Subject: [lmap] polling for any pref. / Thoughts on how to incorporate test environment methods into the testing framework 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, 15 May 2014 14:35:28 -0000 A month or so ago we identified that the Test registry wouldn't include a s= et of test method descriptors for handling test behaviors with things like = Cross traffic. Do we as a group, or any individuals here have suggestions on how to add = that "behavior per test" for including test method / behavior strings outsi= de of the test attributes themselves? I this is a fairly significant gap so before I started pondering ways I th= ought I'd ask if I missed a group direction on this one=20 Thanks, Mike From nobody Thu May 15 07:52: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 8A4171A0371 for ; Thu, 15 May 2014 07:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 Q4VIaT0eDP3A for ; Thu, 15 May 2014 07:52:31 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id 074A31A02A7 for ; Thu, 15 May 2014 07:52:31 -0700 (PDT) X-ASG-Debug-ID: 1400165700-05fac103c4dab00001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id NmNxMEH5wlZEbqLr; Thu, 15 May 2014 17:55:00 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from marcHP ([172.17.20.201]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4FEqETU017746; Thu, 15 May 2014 17:52:16 +0300 From: "Marc Ibrahim" To: "'Carey, Timothy \(Timothy\)'" , "'KEN KO'" , "'Juergen Schoenwaelder'" References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Thu, 15 May 2014 17:52:11 +0300 X-ASG-Orig-Subj: RE: [lmap] Question on information model - Suppression Message-ID: <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJnpqsRiBe7K8T7Oelf4UivjElc9gJIlRyoAnAmWq4Cwji7JwEPlUA6Abq3ikwBmE50PAIEdYvKmaI7H+A= Content-Language: en-us X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1400165700 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.5832 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/AOCJT0nlZldU0Sh8GfYGulZ6z7A Cc: lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 15 May 2014 14:52:34 -0000 Ok for union interpretation. The section (5.3.1.1) of the framework states that a suppression can optionally include a demand to stop on-going active measurements. I don't see this option in the suppression object. BR, Marc. -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: Thursday, May 15, 2014 5:21 PM To: KEN KO; Juergen Schoenwaelder Cc: marc. ibrahim; lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression So I would like close on a consensus. I added the union as the first option which seemed to have the most consensus. Do we have consensus on this? What are the rules: 1) If Tasks is non-empty and Schedules is non-empty: suppress the listed tasks and the listed schedules as an union of the tasks and schedules 2) If Tasks is empty and Schedules is non-empty - suppress all tasks for the listed Schedules 3) If Tasks is non-empty and Schedules is empty: suppress listed tasks for all schedules of the task 4) If Tasks and Schedules are empty: suppress all tasks regardless of schedule Thanks, Tim -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com] Sent: Wednesday, May 14, 2014 8:06 AM To: Juergen Schoenwaelder; Carey, Timothy (Timothy) Cc: marc. ibrahim; lmap@ietf.org Subject: RE: [lmap] Question on information model - Suppression Adding +1 to the comments cautioning us to avoid over-engineering suppression. Per the framework, suppression is "used if the measurement system wants to eliminate inessential traffic, because there is some unexpected network issue for example." It provides a means of doing so without updating the existing measurement schedules, as a temporary relief measure in which measurements are disrupted by definition. There is no need for complete flexibility in the suppression mechanism (e.g., pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve this purpose, because you can always modify the schedules to get that level of control. When you consider that every option adds complexity to the MA, there is a case to be made for simplifying rather than complicating suppression. WRT the existing ambiguity: I prefer barring the two fields from being used together as that will be simplest for the MA. Union or Intersection are also acceptable as fixed definitions (not options). I think adding pairing or multiple suppression objects would be a mistake. Best regards, Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, May 14, 2014 8:09 AM To: Carey, Timothy (Timothy) Cc: marc. ibrahim; lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression Yes, I stand corrected. I think I am personally leaning towards allowing multiple suppression objects in order to keep the complexity of each suppression object down to a basic minimum. /js On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > You cannot as I read the text have multiple suppression objects. Did I miss something. > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, May 14, 2014 12:52 AM > To: marc. ibrahim > Cc: Carey, Timothy (Timothy); lmap@ietf.org > Subject: Re: [lmap] Question on information model - Suppression > > On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: > > > > ma-suppression-task-names<0..*> and > > ma-suppression-schedule-names<0..*> are strings containing names of > > tasks and schedules. If we just allow to have the same name multiple > > times, a pairing association could be done between tasks without > > changing the information model. > > > > For example, ma-suppression-task-names = [T1 T1 T2 T2 T3 *] and > > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1 > > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all > > schedules, and schedule S4 will be suppressed. Does this change the > > information model Tim? > > I do not think this is needed since you can have multiple suppression > objects. But defining the intersection of > > ma-suppression-task-names = [T1 T2] > ma-suppression-schedule-names = [S1 S2] > > may not be that clear. The union is clear, suppress tasks T1 and T2 > and anything started by S1 and S2. Is the intersection interpretation > suppress any T1 started by S1, any T2 started by S1, any T1 started by > S2, any T2 started by S2? This is not really an intersection - a > strict intersection interpretation would likely lead to an empty set. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- 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 Thu May 15 08:10: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 340EB1A00E4 for ; Thu, 15 May 2014 08:10:50 -0700 (PDT) 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 itWah16o3h0T for ; Thu, 15 May 2014 08:10:47 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC381A0584 for ; Thu, 15 May 2014 08:10:46 -0700 (PDT) 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; Thu, 15 May 2014 16:08:01 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 15 May 2014 16:09:28 +0100 From: To: , , , Date: Thu, 15 May 2014 16:09:28 +0100 Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: AQJnpqsRiBe7K8T7Oelf4UivjElc9gJIlRyoAnAmWq4Cwji7JwEPlUA6Abq3ikwBmE50PAIEdYvKmaI7H+CAAAZsgA== Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> In-Reply-To: <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> 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/-g-M0jOF3YpreDNC7pf_WqETUWA Cc: lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 15 May 2014 15:10:50 -0000 Currently ma-suppression-obj contains the Boolean ma-suppression-stop-ongoi= ng-tasks. 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 Marc Ibrahim >Sent: 15 May 2014 15:52 >To: 'Carey, Timothy (Timothy)'; 'KEN KO'; 'Juergen Schoenwaelder' >Cc: lmap@ietf.org >Subject: Re: [lmap] Question on information model - Suppression > >Ok for union interpretation. > > >The section (5.3.1.1) of the framework states that a suppression can optio= nally >include a demand to stop on-going active measurements. I don't see this op= tion >in the suppression object. > >BR, > >Marc. > > > >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy >(Timothy) >Sent: Thursday, May 15, 2014 5:21 PM >To: KEN KO; Juergen Schoenwaelder >Cc: marc. ibrahim; lmap@ietf.org >Subject: Re: [lmap] Question on information model - Suppression > >So I would like close on a consensus. I added the union as the first optio= n which >seemed to have the most consensus. Do we have consensus on this? > > >What are the rules: >1) If Tasks is non-empty and Schedules is non-empty: suppress the listed t= asks and >the listed schedules as an union of the tasks and schedules > >2) If Tasks is empty and Schedules is non-empty - suppress all tasks for t= he listed >Schedules > >3) If Tasks is non-empty and Schedules is empty: suppress listed tasks for= all >schedules of the task > >4) If Tasks and Schedules are empty: suppress all tasks regardless of sche= dule > >Thanks, >Tim > >-----Original Message----- >From: KEN KO [mailto:KEN.KO@adtran.com] >Sent: Wednesday, May 14, 2014 8:06 AM >To: Juergen Schoenwaelder; Carey, Timothy (Timothy) >Cc: marc. ibrahim; lmap@ietf.org >Subject: RE: [lmap] Question on information model - Suppression > >Adding +1 to the comments cautioning us to avoid over-engineering suppress= ion. > >Per the framework, suppression is "used if the measurement system wants to >eliminate inessential traffic, because there is some unexpected network is= sue for >example." It provides a means of doing so without updating the existing >measurement schedules, as a temporary relief measure in which measurements >are disrupted by definition. > >There is no need for complete flexibility in the suppression mechanism (e.= g., >pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve this purpo= se, >because you can always modify the schedules to get that level of control. = When >you consider that every option adds complexity to the MA, there is a case = to be >made for simplifying rather than complicating suppression. > >WRT the existing ambiguity: I prefer barring the two fields from being use= d >together as that will be simplest for the MA. Union or Intersection are al= so >acceptable as fixed definitions (not options). I think adding pairing or m= ultiple >suppression objects would be a mistake. > >Best regards, >Ken > >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen >Schoenwaelder >Sent: Wednesday, May 14, 2014 8:09 AM >To: Carey, Timothy (Timothy) >Cc: marc. ibrahim; lmap@ietf.org >Subject: Re: [lmap] Question on information model - Suppression > >Yes, I stand corrected. > >I think I am personally leaning towards allowing multiple suppression obje= cts in >order to keep the complexity of each suppression object down to a basic >minimum. > >/js > >On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote: >> Juergen, >> >> You cannot as I read the text have multiple suppression objects. Did I >miss something. >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Wednesday, May 14, 2014 12:52 AM >> To: marc. ibrahim >> Cc: Carey, Timothy (Timothy); lmap@ietf.org >> Subject: Re: [lmap] Question on information model - Suppression >> >> On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: >> > >> > ma-suppression-task-names<0..*> and >> > ma-suppression-schedule-names<0..*> are strings containing names of >> > tasks and schedules. If we just allow to have the same name multiple >> > times, a pairing association could be done between tasks without >> > changing the information model. >> > >> > For example, ma-suppression-task-names =3D [T1 T1 T2 T2 T3 *] and >> > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1 >> > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all >> > schedules, and schedule S4 will be suppressed. Does this change the >> > information model Tim? >> >> I do not think this is needed since you can have multiple suppression >> objects. But defining the intersection of >> >> ma-suppression-task-names =3D [T1 T2] >> ma-suppression-schedule-names =3D [S1 S2] >> >> may not be that clear. The union is clear, suppress tasks T1 and T2 >> and anything started by S1 and S2. Is the intersection interpretation >> suppress any T1 started by S1, any T2 started by S1, any T1 started by >> S2, any T2 started by S2? This is not really an intersection - a >> strict intersection interpretation would likely lead to an empty set. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > >-- >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 > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From nobody Thu May 15 10:02: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 D30AD1A067D for ; Thu, 15 May 2014 10:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-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 4_pZ6xrJCwwH for ; Thu, 15 May 2014 10:02:31 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1654D1A0416 for ; Thu, 15 May 2014 10:02:30 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4FH1wiV007812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 12:01:58 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s4FH1teT011386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 May 2014 13:01:55 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 15 May 2014 13:01:55 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "marc.ibrahim@usj.edu.lb" , "KEN.KO@adtran.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFAAOul4AAAFBuIAAD7DoAAADqTSAAAmCoQAAAf3FgAAsTaIgAAmvMoAAAJqGAAAEmCew Date: Thu, 15 May 2014 17:01:53 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] 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/uvHbA954-3IIxUmmJXjLZj7XCUo Cc: "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 15 May 2014 17:02:34 -0000 Trevor, The latest published draft (draft-ietf-lmap-information-model-00) has object { boolean ma-suppression-enabled; [datetime ma-suppression-start;] // default: immediate [datetime ma-suppression-end;] // default: indefinite [string ma-suppression-task-names<0..*>;] // default: all tasks if // ma-suppression-task-names is empty [string ma-suppression-schedule-names<0..*>;] // default: all schedules if // ma-suppression-schedule-names is empty } ma-suppression-obj; BR, Tim -----Original Message----- From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]=20 Sent: Thursday, May 15, 2014 10:09 AM To: marc.ibrahim@usj.edu.lb; Carey, Timothy (Timothy); KEN.KO@adtran.com; j= .schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Question on information model - Suppression Currently ma-suppression-obj contains the Boolean ma-suppression-stop-ongoi= ng-tasks. 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 Marc Ibrahim >Sent: 15 May 2014 15:52 >To: 'Carey, Timothy (Timothy)'; 'KEN KO'; 'Juergen Schoenwaelder' >Cc: lmap@ietf.org >Subject: Re: [lmap] Question on information model - Suppression > >Ok for union interpretation. > > >The section (5.3.1.1) of the framework states that a suppression can optio= nally >include a demand to stop on-going active measurements. I don't see this op= tion >in the suppression object. > >BR, > >Marc. > > > >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy >(Timothy) >Sent: Thursday, May 15, 2014 5:21 PM >To: KEN KO; Juergen Schoenwaelder >Cc: marc. ibrahim; lmap@ietf.org >Subject: Re: [lmap] Question on information model - Suppression > >So I would like close on a consensus. I added the union as the first optio= n which >seemed to have the most consensus. Do we have consensus on this? > > >What are the rules: >1) If Tasks is non-empty and Schedules is non-empty: suppress the listed t= asks and >the listed schedules as an union of the tasks and schedules > >2) If Tasks is empty and Schedules is non-empty - suppress all tasks for t= he listed >Schedules > >3) If Tasks is non-empty and Schedules is empty: suppress listed tasks for= all >schedules of the task > >4) If Tasks and Schedules are empty: suppress all tasks regardless of sche= dule > >Thanks, >Tim > >-----Original Message----- >From: KEN KO [mailto:KEN.KO@adtran.com] >Sent: Wednesday, May 14, 2014 8:06 AM >To: Juergen Schoenwaelder; Carey, Timothy (Timothy) >Cc: marc. ibrahim; lmap@ietf.org >Subject: RE: [lmap] Question on information model - Suppression > >Adding +1 to the comments cautioning us to avoid over-engineering suppress= ion. > >Per the framework, suppression is "used if the measurement system wants to >eliminate inessential traffic, because there is some unexpected network is= sue for >example." It provides a means of doing so without updating the existing >measurement schedules, as a temporary relief measure in which measurements >are disrupted by definition. > >There is no need for complete flexibility in the suppression mechanism (e.= g., >pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve this purpo= se, >because you can always modify the schedules to get that level of control. = When >you consider that every option adds complexity to the MA, there is a case = to be >made for simplifying rather than complicating suppression. > >WRT the existing ambiguity: I prefer barring the two fields from being use= d >together as that will be simplest for the MA. Union or Intersection are al= so >acceptable as fixed definitions (not options). I think adding pairing or m= ultiple >suppression objects would be a mistake. > >Best regards, >Ken > >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen >Schoenwaelder >Sent: Wednesday, May 14, 2014 8:09 AM >To: Carey, Timothy (Timothy) >Cc: marc. ibrahim; lmap@ietf.org >Subject: Re: [lmap] Question on information model - Suppression > >Yes, I stand corrected. > >I think I am personally leaning towards allowing multiple suppression obje= cts in >order to keep the complexity of each suppression object down to a basic >minimum. > >/js > >On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote: >> Juergen, >> >> You cannot as I read the text have multiple suppression objects. Did I >miss something. >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Wednesday, May 14, 2014 12:52 AM >> To: marc. ibrahim >> Cc: Carey, Timothy (Timothy); lmap@ietf.org >> Subject: Re: [lmap] Question on information model - Suppression >> >> On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: >> > >> > ma-suppression-task-names<0..*> and >> > ma-suppression-schedule-names<0..*> are strings containing names of >> > tasks and schedules. If we just allow to have the same name multiple >> > times, a pairing association could be done between tasks without >> > changing the information model. >> > >> > For example, ma-suppression-task-names =3D [T1 T1 T2 T2 T3 *] and >> > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1 >> > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all >> > schedules, and schedule S4 will be suppressed. Does this change the >> > information model Tim? >> >> I do not think this is needed since you can have multiple suppression >> objects. But defining the intersection of >> >> ma-suppression-task-names =3D [T1 T2] >> ma-suppression-schedule-names =3D [S1 S2] >> >> may not be that clear. The union is clear, suppress tasks T1 and T2 >> and anything started by S1 and S2. Is the intersection interpretation >> suppress any T1 started by S1, any T2 started by S1, any T1 started by >> S2, any T2 started by S2? This is not really an intersection - a >> strict intersection interpretation would likely lead to an empty set. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > >-- >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 > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From nobody Thu May 15 17:16: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 6485B1A02E4 for ; Thu, 15 May 2014 17:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 IF8MAIQdWLDg for ; Thu, 15 May 2014 17:16:40 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C99A1A01C2 for ; Thu, 15 May 2014 17:16:40 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id jx11so2317497veb.28 for ; Thu, 15 May 2014 17:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5CmZR9hQNq87r87kA4P0m/A7GF6qYpCIMHGqcAn2TqU=; b=eJ2iwsCe5StMUlzTdVP9csNOokijFAFqpfK/VWd/XK/lu0OvkCzx49f1OZfNm7rMRI 79h0NoDBPrPva1d4VYONsEqh0a5LVjoL4eiNmcmg6Ic0bEIVQJLaLDy1dOVEM3v6lD59 Uw/N9/tl4VkBBX4zNvGgEmW8MUW3GGD1DiIO6qR8TEh7d/TYJa2IjzpvACcrUAogulxq OIVjutuYLvhXoaYAm3jCpvOlPCw8DwHBtcsc8h56yk1HkF3nG9PcMNdU4bJLAOYakMzf 4zbvtn8bDp8Fp9WJc0jSQpnahKdR8kp+ZaULEWB8P691qql1LgOQUKr4nE4kgsKVrvTz GQyQ== MIME-Version: 1.0 X-Received: by 10.52.99.168 with SMTP id er8mr9353799vdb.26.1400199392693; Thu, 15 May 2014 17:16:32 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 15 May 2014 17:16:32 -0700 (PDT) In-Reply-To: <20140513172159.14622.51471.idtracker@ietfa.amsl.com> References: <20140513172159.14622.51471.idtracker@ietfa.amsl.com> Date: Thu, 15 May 2014 17:16:32 -0700 Message-ID: From: Greg Mirsky To: "lmap@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Content-Type: multipart/alternative; boundary=20cf3071cab06a92c504f9795314 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/eX_Fn2jMnudKGqec3Xl-XHj_EYI Subject: Re: [lmap] I-D Action: draft-ietf-lmap-framework-05.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, 16 May 2014 00:16:44 -0000 --20cf3071cab06a92c504f9795314 Content-Type: text/plain; charset=UTF-8 Dear Authors, et. al, please find my comments to the latest updates of the LMAP Framework document below: - Use of RFC 2119. Even though the Framework document is on Informational track RFC 2119 may be used. Hence my question: Do we want to turn 'must' into MUST and so on in the document? - Section 3. I think that definition of an Active Measurement Method only as "A generalization of an Active Measurement Task" is not sufficiently clear. Perhaps the following may be used instead by re-using or referring to explanation of Measurement Method: Active Measurement Method - The process of measuring some performance or reliability parameter associated with the transfer of Traffic by generating and/or receiving Active Measurement Traffic. - If definition of the Active Measurement Method references use of Active Measurement Traffic, then the current definition can be updated to explain that Active Measurement Task is realization of Active Measurement Method among participating Measurement Agents and Measurement Peers with specific parameters, e.g. profile of the Active Measurement Traffic. And I believe that coordination of Active Measurement Task among participating MAs and/or MPs is optional. The current definition reads as it is mandatory. I suggest to change it by splitting the sentence and making it to say "Coordination of an Active Measurement Task among participating Measurement Agents and/or Measurement Peers may be achieved by using protocols. Definition of such protocols by LMAP WG is for further study." - I don't see much difference between Configuration Protocol and Control Protocol. I think that the former supports subset of functionality of the latter. Besides, it is not clear whether Configuration Protocol uses Control Channel between Controller and a MA or not. I think this differentiation between Configuration and Control is unnecessary. - Reference to "initial LMAP work" may be too vague as charter of the LMAP WG will likely to change with time. Can it be changed to "NNN is for future study"? - Section 5.2 been introduced in this version. Firstly, I don't recall that the WG discussed Configuration Protocol and agreed that it is essential part of the LMAP Framework. Adding new concepts, IMO, doesn't help to pass WG LC. Regards, Greg On Tue, May 13, 2014 at 10:21 AM, wrote: > > 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 : A framework for large-scale measurement > platforms (LMAP) > Authors : Philip Eardley > Al Morton > Marcelo Bagnulo > Trevor Burbridge > Paul Aitken > Aamer Akhter > Filename : draft-ietf-lmap-framework-05.txt > Pages : 54 > Date : 2014-05-13 > > Abstract: > Measuring broadband service on a large scale requires a description > of the logical architecture and standardisation of the key protocols > that coordinate interactions between the components. The document > presents an overall framework for large-scale measurements. It also > defines terminology for LMAP (large-scale measurement platforms). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lmap-framework-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-05 > > > 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/ > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > --20cf3071cab06a92c504f9795314 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors, et. al,
please find = my comments to the latest updates of the LMAP Framework document below:
=
  • Use of RFC 2119. Even though the Framework document is on Informati= onal track RFC 2119 may be used. Hence my question: Do we want to turn '= ;must' into MUST and so on in the document?
  • Section 3. I think that definition of an Active Measurement Method= only as "A generalization of an Active Measurement Task" is not = sufficiently clear. Perhaps the following may be used instead by re-using o= r referring to explanation of Measurement Method:
Active Measurement Method - The = process of measuring some performance or reliability parameter associated w= ith the transfer of Traffic by generating and/or receiving Active Measureme= nt Traffic.
  • If definition of the Active Measurement Method references use= of Active Measurement Traffic, then the current definition can be updated = to explain that Active Measurement Task is realization of Active Measuremen= t Method among participating Measurement Agents and Measurement Peers with = specific parameters, e.g. profile of the Active Measurement Traffic.
And I believe that coordination = of Active Measurement Task among participating MAs and/or MPs is optional. = The current definition reads as it is mandatory. I suggest to change it by = splitting the sentence and making it to say "Coordination of an Active= Measurement Task among participating Measurement Agents and/or Measurement= Peers may be achieved by using protocols. Definition of such protocols by = LMAP WG is for further study."

  • I don't see much difference between Configuratio= n Protocol and Control Protocol. I think that the former supports subset of= functionality of the latter. Besides, it is not clear whether Configuratio= n Protocol uses Control Channel between Controller and a MA or not. I think= this differentiation between Configuration and Control is unnecessary.
  • Reference to "initial LMAP work" may be too vague as charter = of the LMAP WG will likely to change with time. Can it be changed to "= NNN is for future study"?
  • Section 5.2 been introduced in this = version. Firstly, I don't recall that the WG discussed Configuration Pr= otocol and agreed that it is essential part of the LMAP Framework. Adding n= ew concepts, IMO, doesn't help to pass WG LC.

Regards,
Greg
<= div class=3D"gmail_extra">

On Tue, May 13= , 2014 at 10:21 AM, <internet-drafts@ietf.org> wrote= :

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Large-Scale Measurement of Broadband= Performance Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : A fr= amework for large-scale measurement platforms (LMAP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Philip Ea= rdley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Al Morton
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Marcelo Bagnulo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Trevor Burbridge
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Paul Aitken
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Aamer Akhter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-lmap-framework-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 54 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-05-13

Abstract:
=C2=A0 =C2=A0Measuring broadband service on a large scale requires a descri= ption
=C2=A0 =C2=A0of the logical architecture and standardisation of the key pro= tocols
=C2=A0 =C2=A0that coordinate interactions between the components. =C2=A0The= document
=C2=A0 =C2=A0presents an overall framework for large-scale measurements. = =C2=A0It also
=C2=A0 =C2=A0defines terminology for LMAP (large-scale measurement platform= s).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/<= /a>

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-lmap-framework-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-frame= work-05


Please note that it may take a couple of minutes from the time of submissio= n
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/

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

--20cf3071cab06a92c504f9795314-- From nobody Fri May 16 10:16: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 4BD111A0273; Fri, 16 May 2014 10:16:10 -0700 (PDT) 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 wnTQKdp7qqrN; Fri, 16 May 2014 10:16:09 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id D21311A00FF; Fri, 16 May 2014 10:16:08 -0700 (PDT) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id EF9AF1A02D9; Fri, 16 May 2014 19:15:30 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_6F9AD479-BDD7-45CE-868D-F2586A0D22BA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Trammell In-Reply-To: Date: Fri, 16 May 2014 19:15:30 +0200 Message-Id: <3FF5006E-6158-4214-AAB6-BE680FF49367@trammell.ch> References: To: ippm@ietf.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/kZIgehr7xaqrQaB9bI88vuWiQa0 Cc: lmap@ietf.org Subject: Re: [lmap] [ippm] WGLC on draft-ietf-ippm-lmap-path 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, 16 May 2014 17:16:10 -0000 --Apple-Mail=_6F9AD479-BDD7-45CE-868D-F2586A0D22BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, WGLC on draft-ietf-ippm-lmap-path-02 is now complete; authors, please = address the comments received and posted to the list, as well as any you = may have received privately during the call. Thanks, cheers, Brian On 24 Apr 2014, at 16:56, Brian Trammell wrote: > Greetings, all, >=20 > This begins a Working Group Last Call on draft-ietf-ippm-lmap-path-02, = "A Reference Path and Measurement Points for LMAP". (I'm cross-posting = this to LMAP, so that the LMAP WG can have a chance to review as well, = given that this document is applicable to both WGs.) >=20 > WGLC will run until Thursday 15 May 2014. Please review the document = and provide comments to ippm@ietf.org. >=20 > Many thanks, best regards, >=20 > Brian Trammell > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_6F9AD479-BDD7-45CE-868D-F2586A0D22BA 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 iQEcBAEBCgAGBQJTdkeyAAoJENt3nsOmbNJcsuwH/2R+fQHdLh3d+kZQQyvRLch2 qJsosTZPd7QcJNQC9MP+WZgFlJumbrYgwaY1aX0lpdY8bSFmUZWENYVh5s1Yycez g2COMLD9J7r66sJv4PDqz0VI9KpXQLqZo6+zftbqtobKde3BVVPO+DXtsDYFB8gW NG+UdIa/+lHKMMC0cvH2lbujVi2BMjrURP+gtz/fzt8/xFMhBS/ArBL7jq1d97tC UDdGtGJVK4xUsSguXC7WfgHbcXsTS3uNqKfMUgGGKkL03mbQ1JZnaewesRq/tSXD XkK0FqMhRu0bMJAioarY7bwOhzMx2pwhFuJLXJdFCakOCLFkFJj5FYFcLN/u86U= =7aZ6 -----END PGP SIGNATURE----- --Apple-Mail=_6F9AD479-BDD7-45CE-868D-F2586A0D22BA-- From nobody Fri May 16 11:28: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 C29B41A02EF; Fri, 16 May 2014 11:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 4Rm_QZ8cNCqi; Fri, 16 May 2014 11:14:41 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id E4E771A02E2; Fri, 16 May 2014 11:14:40 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id B439B120BF0; Fri, 16 May 2014 14:16:08 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-azure.research.att.com (Postfix) with ESMTP id 530C9E2379; Fri, 16 May 2014 14:14:33 -0400 (EDT) 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, 16 May 2014 14:14:32 -0400 From: "MORTON, ALFRED C (AL)" To: Brian Trammell , "ippm@ietf.org" Date: Fri, 16 May 2014 14:11:33 -0400 Thread-Topic: [lmap] [ippm] WGLC on draft-ietf-ippm-lmap-path Thread-Index: Ac9xKo1Oj3Q1e4IVS/ea6gXiKsynYAAB7erk Message-ID: <2845723087023D4CB5114223779FA9C80178E0CD7B@njfpsrvexg8.research.att.com> References: , <3FF5006E-6158-4214-AAB6-BE680FF49367@trammell.ch> In-Reply-To: <3FF5006E-6158-4214-AAB6-BE680FF49367@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/BxK7maNE4rkQWqdStR7vDyDsAv8 Cc: "lmap@ietf.org" Subject: Re: [lmap] [ippm] WGLC on draft-ietf-ippm-lmap-path 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, 16 May 2014 18:14:45 -0000 We have a version addressing most comments, but there are a few details to finalize. Should be able to finish this up and submit next week. Al (for co-authors) ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Brian Trammell [ietf@tramme= ll.ch] Sent: Friday, May 16, 2014 1:15 PM To: ippm@ietf.org Cc: lmap@ietf.org Subject: Re: [lmap] [ippm] WGLC on draft-ietf-ippm-lmap-path Greetings, all, WGLC on draft-ietf-ippm-lmap-path-02 is now complete; authors, please addre= ss the comments received and posted to the list, as well as any you may hav= e received privately during the call. Thanks, cheers, Brian On 24 Apr 2014, at 16:56, Brian Trammell wrote: > Greetings, all, > > This begins a Working Group Last Call on draft-ietf-ippm-lmap-path-02, "A= Reference Path and Measurement Points for LMAP". (I'm cross-posting this t= o LMAP, so that the LMAP WG can have a chance to review as well, given that= this document is applicable to both WGs.) > > WGLC will run until Thursday 15 May 2014. Please review the document and = provide comments to ippm@ietf.org. > > Many thanks, best regards, > > Brian Trammell > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Sun May 18 10:53: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 87C1C1A01E8 for ; Sun, 18 May 2014 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 xK49pq1_X-yf for ; Sun, 18 May 2014 10:53:44 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8821A01DF for ; Sun, 18 May 2014 10:53:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FACrzeFOHCzIm/2dsb2JhbABZgmUhT1ipUgEBAQEBB5orAYELFnSCJQEBAQEDEgtLHQQCAQgNBAQBAQsdBwIwFAcBAQUDAgQTCAYGCAaIHwEMokGpRYULEwSFVYNcghEBgisOAwEfBjICAgKDJYEVBJE6gTqNeYwHgzeBdzk X-IronPort-AV: E=Sophos;i="4.98,862,1392181200"; d="dat'?scan'208";a="63427643" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 May 2014 13:53:43 -0400 X-OutboundMail_SMTP: 1 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; 18 May 2014 13:51:56 -0400 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, 18 May 2014 19:53:42 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: NomCom 2014-2015 Call for Volunteers Thread-Index: AQHPcRXSEKVybB6Dr0mPzdiT1genj5tGoXbw Date: Sun, 18 May 2014 17:53:41 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7EAA9F@AZ-FFEXMB04.global.avaya.com> References: <8770.1400250056@sandelman.ca> In-Reply-To: <8770.1400250056@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/mixed; boundary="_002_9904FB1B0159DA42B0B887B7FA8119CA5C7EAA9FAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/XTjYvzVcdy7QY5UnYUX5O1LKs1o Subject: [lmap] FW: NomCom 2014-2015 Call for Volunteers 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, 18 May 2014 17:53:46 -0000 --_002_9904FB1B0159DA42B0B887B7FA8119CA5C7EAA9FAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please consider volunteering for NomCom - this activity is highly important= for the IETF.=20 Regards, Dan > -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: Friday, May 16, 2014 5:21 PM > To: ietf@ietf.org > Subject: NomCom 2014-2015 Call for Volunteers >=20 >=20 > The IETF nominating committee (nomcom) process for 2014-15 has begun. > The IETF nomcom appoints folks to fill the open slots on the IAOC, the IA= B, > and the IESG (including IETF Chair). >=20 > Ten voting members for the nomcom are selected in a verifiably random way > from a pool of volunteers. The more volunteers, the better chance we have > of choosing a random yet representative cross section of the IETF populat= ion. >=20 > Let's break the 200 volunteer mark again this year! >=20 > The details of the operation of the nomcom can be found in RFC 3777, and > BCP10/RFC3797 details the selection algorithm. >=20 > Volunteers must have attended 3 of the past 5 IETF meetings. As specifie= d in > RFC 3777, that means three out of the five past meetings up to the time t= his > email announcement goes out to start the solicitation of volunteers. > The five meetings out of which you must have attended *three* > are IETF 85(Atlanta), \ > 86(Orlando), \ > 87(Berlin), *** ANY THREE! > 88(Vancouver), / > 89(London) / >=20 > If you qualify, please volunteer. However, much as we want this, before > you > decide to volunteer, please be sure you are willing to forgo appointment = to > any of the positions for which this nomcom is responsible. >=20 > The list of people and posts whose terms end with the March 2015 IETF > meeting, and thus the positions for which this nomcom is responsible, are >=20 > IAOC: > To be confirmed >=20 > IAB: > Joel Halpern > Russ Housley > Eliot Lear > Xing Li > Andrew Sullivan > Dave Thaler >=20 > IESG: > Pete Resnick (Applications) > Ted Lemon (Internet) > Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian > Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) = Jari > Arkko (Gen) >=20 > (names with * have publically indicated they will not serve another term) >=20 > The primary activity for this nomcom will begin in July 2014 and should b= e > completed in January 2015. The nomcom will have regularly scheduled > conference calls to ensure progress. (We might dogfood WebRTC) There will > be activities to collect requirements from the community, review candidat= e > questionnaires, review feedback from community members about > candidates, and talk to candidates. >=20 > Thus, being a nomcom member does require some time commitment; but it > is also a very rewarding experience. >=20 > It is very important that you be able to attend IETF91 to conduct intervi= ews. > Being at IETF90 is useful for training. Being at IETF92 is not essential= . >=20 > Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours= ) > June 22, 2013, as follows: >=20 > To: nomcom-chair-2014@ietf.org > Subject: Nomcom 2014-15 Volunteer >=20 > Please include the following information in the email body: >=20 > > // First/Given Name followed by Last/Family Name > // matching how you enter it in the IETF Registration Form) >=20 > > // Typically what goes in the Company field > // in the IETF Registration Form > [] > > // For confirmation if selected >=20 > You should expect an email response from me within 3 business days statin= g > whether or not you are qualified. If you don't receive this response, pl= ease > re-send your email with the tag "RESEND"" added to the subject line. >=20 > If you are not yet sure if you would like to volunteer, please consider t= hat > nomcom members play a very important role in shaping the leadership of th= e > IETF. Questions by email or voice are welcome. > Volunteering for the nomcom is a great way to contribute to the IETF! >=20 > You can find a detailed timeline on the nomcom web site at: > https://datatracker.ietf.org/nomcom/2014/ >=20 > I will be publishing a more detailed target timetable, as well as details= of the > randomness seeds to be used for the RFC 3797 selection process, within th= e > next couple weeks. >=20 > Thank you! > Michael Richardson > mcr+nomcom@sandelman.ca > nomcom-chair-2014@ietf.org --_002_9904FB1B0159DA42B0B887B7FA8119CA5C7EAA9FAZFFEXMB04globa_ Content-Type: application/pgp-signature; name="Untitled attachment 00009.dat" Content-Description: Untitled attachment 00009.dat Content-Disposition: attachment; filename="Untitled attachment 00009.dat"; size=491; creation-date="Sun, 18 May 2014 17:53:40 GMT"; modification-date="Sun, 18 May 2014 17:53:40 GMT" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTIgKEdO VS9MaW51eCkNCg0KaVFFVkF3VUJVM1lleDRDTGNQdmQwTjFsQVFMYVVRZ0FwbUt6elh4Tk55aFhv cDY1VkxaVnFjL3dKL1BBY0xvcw0KWTBlY1lneFY5SHJ3UGF6QkdaMDU0M0NPTGkvZm15M3dIMVhq Y1QwK3VqSnRkcmZGMTZxODNMSStucEVvclV1MA0KS3lYclAwOVM2bWhlRkF6Q3VkUk1tQ1UzektI UzdqK3FxNEFHMGhFeUo0Q0pUVnhiMEl5MEpDMzVTaDcxRW5kVA0Kb0R2T29oRXVUbHAwdnFrZUg3 LzNPVnRDekxmcnZoRXFKMDNNWERYZ1BGaE8vb2JDTk9EM3cxdC9uTWZBOGhjcg0KUGxQOVBGQVl0 dEdWMWtBLzEvTllhM1NYUDljdUo3NjJMb2NGNDFoaUhsMU5YdkVYdXZjYVZIV3dtWUlqQ05aVw0K YzR5SkV3bkhkcWUreFVKTFlZUHhvY0ZwT0dWTENuOE4wdjExaGt1bmVFS0QvdWVkMEV0ZzV3PT0N Cj1CZlY5DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0= --_002_9904FB1B0159DA42B0B887B7FA8119CA5C7EAA9FAZFFEXMB04globa_-- From nobody Mon May 19 01: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 3DC7A1A02F3 for ; Mon, 19 May 2014 01:02:36 -0700 (PDT) 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_91=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 2NHEMB9ofBNx for ; Mon, 19 May 2014 01:02:33 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82971A030F for ; Mon, 19 May 2014 01:02:32 -0700 (PDT) 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, 19 May 2014 09:02:22 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 19 May 2014 09:01:59 +0100 From: To: , , , Date: Mon, 19 May 2014 09:01:58 +0100 Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFAAOul4AAAFBuIAAD7DoAAADqTSAAAmCoQAAAf3FgAAsTaIgAAmvMoAAAJqGAAAEmCewAK066XA= Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.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/BVYu4qt2JWDuAgxs9wVRyIzYki0 Cc: lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 19 May 2014 08:02:36 -0000 Sorry, my mistake - the additional parameter was agreed to be added in Lond= on, so will appear in revision 01. 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: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] >Sent: 15 May 2014 18:02 >To: Burbridge,T,Trevor,TUB8 R; marc.ibrahim@usj.edu.lb; KEN.KO@adtran.com; >j.schoenwaelder@jacobs-university.de >Cc: lmap@ietf.org >Subject: RE: [lmap] Question on information model - Suppression > >Trevor, > >The latest published draft (draft-ietf-lmap-information-model-00) has > object { > boolean ma-suppression-enabled; > [datetime ma-suppression-start;] // default: immediate > [datetime ma-suppression-end;] // default: indefinite > [string ma-suppression-task-names<0..*>;] > // default: all tasks if > // ma-suppression-task-names is empty > [string ma-suppression-schedule-names<0..*>;] > // default: all schedules if > // ma-suppression-schedule-names is empty > } ma-suppression-obj; > >BR, >Tim >-----Original Message----- >From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] >Sent: Thursday, May 15, 2014 10:09 AM >To: marc.ibrahim@usj.edu.lb; Carey, Timothy (Timothy); KEN.KO@adtran.com; >j.schoenwaelder@jacobs-university.de >Cc: lmap@ietf.org >Subject: RE: [lmap] Question on information model - Suppression > >Currently ma-suppression-obj contains the Boolean ma-suppression-stop- >ongoing-tasks. > >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 confidentia= l. It's >meant only for the individual(s) or entity named above. If you're not the = intended >recipient, note that disclosing, copying, distributing or using this infor= mation is >prohibited. If you've received this email in error, please let me know imm= ediately >on the email address above. Thank you. >We monitor our email system, and may record your emails. >British Telecommunications plc >Registered office: 81 Newgate Street London EC1A 7AJ >Registered in England no: 1800000 > > >>-----Original Message----- >>From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Marc Ibrahim >>Sent: 15 May 2014 15:52 >>To: 'Carey, Timothy (Timothy)'; 'KEN KO'; 'Juergen Schoenwaelder' >>Cc: lmap@ietf.org >>Subject: Re: [lmap] Question on information model - Suppression >> >>Ok for union interpretation. >> >> >>The section (5.3.1.1) of the framework states that a suppression can opti= onally >>include a demand to stop on-going active measurements. I don't see this o= ption >>in the suppression object. >> >>BR, >> >>Marc. >> >> >> >>-----Original Message----- >>From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy >>(Timothy) >>Sent: Thursday, May 15, 2014 5:21 PM >>To: KEN KO; Juergen Schoenwaelder >>Cc: marc. ibrahim; lmap@ietf.org >>Subject: Re: [lmap] Question on information model - Suppression >> >>So I would like close on a consensus. I added the union as the first opti= on which >>seemed to have the most consensus. Do we have consensus on this? >> >> >>What are the rules: >>1) If Tasks is non-empty and Schedules is non-empty: suppress the listed = tasks >and >>the listed schedules as an union of the tasks and schedules >> >>2) If Tasks is empty and Schedules is non-empty - suppress all tasks for = the listed >>Schedules >> >>3) If Tasks is non-empty and Schedules is empty: suppress listed tasks fo= r all >>schedules of the task >> >>4) If Tasks and Schedules are empty: suppress all tasks regardless of sch= edule >> >>Thanks, >>Tim >> >>-----Original Message----- >>From: KEN KO [mailto:KEN.KO@adtran.com] >>Sent: Wednesday, May 14, 2014 8:06 AM >>To: Juergen Schoenwaelder; Carey, Timothy (Timothy) >>Cc: marc. ibrahim; lmap@ietf.org >>Subject: RE: [lmap] Question on information model - Suppression >> >>Adding +1 to the comments cautioning us to avoid over-engineering >suppression. >> >>Per the framework, suppression is "used if the measurement system wants t= o >>eliminate inessential traffic, because there is some unexpected network i= ssue >for >>example." It provides a means of doing so without updating the existing >>measurement schedules, as a temporary relief measure in which measurement= s >>are disrupted by definition. >> >>There is no need for complete flexibility in the suppression mechanism (e= .g., >>pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve this purp= ose, >>because you can always modify the schedules to get that level of control.= When >>you consider that every option adds complexity to the MA, there is a case= to be >>made for simplifying rather than complicating suppression. >> >>WRT the existing ambiguity: I prefer barring the two fields from being us= ed >>together as that will be simplest for the MA. Union or Intersection are a= lso >>acceptable as fixed definitions (not options). I think adding pairing or = multiple >>suppression objects would be a mistake. >> >>Best regards, >>Ken >> >>-----Original Message----- >>From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen >>Schoenwaelder >>Sent: Wednesday, May 14, 2014 8:09 AM >>To: Carey, Timothy (Timothy) >>Cc: marc. ibrahim; lmap@ietf.org >>Subject: Re: [lmap] Question on information model - Suppression >> >>Yes, I stand corrected. >> >>I think I am personally leaning towards allowing multiple suppression obj= ects in >>order to keep the complexity of each suppression object down to a basic >>minimum. >> >>/js >> >>On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote: >>> Juergen, >>> >>> You cannot as I read the text have multiple suppression objects. Did I >>miss something. >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Wednesday, May 14, 2014 12:52 AM >>> To: marc. ibrahim >>> Cc: Carey, Timothy (Timothy); lmap@ietf.org >>> Subject: Re: [lmap] Question on information model - Suppression >>> >>> On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: >>> > >>> > ma-suppression-task-names<0..*> and >>> > ma-suppression-schedule-names<0..*> are strings containing names of >>> > tasks and schedules. If we just allow to have the same name multiple >>> > times, a pairing association could be done between tasks without >>> > changing the information model. >>> > >>> > For example, ma-suppression-task-names =3D [T1 T1 T2 T2 T3 *] and >>> > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1 >>> > will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all >>> > schedules, and schedule S4 will be suppressed. Does this change the >>> > information model Tim? >>> >>> I do not think this is needed since you can have multiple suppression >>> objects. But defining the intersection of >>> >>> ma-suppression-task-names =3D [T1 T2] >>> ma-suppression-schedule-names =3D [S1 S2] >>> >>> may not be that clear. The union is clear, suppress tasks T1 and T2 >>> and anything started by S1 and S2. Is the intersection interpretation >>> suppress any T1 started by S1, any T2 started by S1, any T1 started by >>> S2, any T2 started by S2? This is not really an intersection - a >>> strict intersection interpretation would likely lead to an empty set. >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >> >>-- >>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 >> >>_______________________________________________ >>lmap mailing list >>lmap@ietf.org >>https://www.ietf.org/mailman/listinfo/lmap From nobody Mon May 19 05:13: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 3B42A1A0249; Mon, 19 May 2014 05:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 gkM0Aw7k-fTK; Mon, 19 May 2014 05:12:55 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F51A1A0015; Mon, 19 May 2014 05:12:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIFAO7zeVPGmAcV/2dsb2JhbABZgmUhUVipTwEBAQEBAQaSUxuHPQGBExZ0giUBAQEBAgEBAQEPKDQLBQcEAgEIDQEDBAEBAQoUCQcnCxQJCAIEAQkEBQgRCYgXCAEMolKuexMEhVWIIycxBwaDJYEVBKBtjAeDN4FuQg X-IronPort-AV: E=Sophos;i="4.98,866,1392181200"; d="scan'208";a="64031306" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 May 2014 08:12:53 -0400 X-OutboundMail_SMTP: 1 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; 19 May 2014 07:55:51 -0400 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, 19 May 2014 14:12:52 +0200 From: "Romascanu, Dan (Dan)" To: Brian Trammell , "ippm@ietf.org" Thread-Topic: [lmap] [ippm] WGLC on draft-ietf-ippm-lmap-path Thread-Index: AQHPcSqH19Civdayy0Ou9ytWjsoIW5tH0EqQ Date: Mon, 19 May 2014 12:12:52 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7EB660@AZ-FFEXMB04.global.avaya.com> References: <3FF5006E-6158-4214-AAB6-BE680FF49367@trammell.ch> In-Reply-To: <3FF5006E-6158-4214-AAB6-BE680FF49367@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ZewxtB0EO44H1esvIHSe75WWjLc Cc: "lmap@ietf.org" Subject: Re: [lmap] [ippm] WGLC on draft-ietf-ippm-lmap-path 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, 19 May 2014 12:12:57 -0000 Hi, I apologize for the delay, but I missed the original WGLC announcement.=20 Here are my comments:=20 1. The Purpose and Scope section is very crisp in defining the reference pa= th 'for LMAP'. Am I mistaken that it can be used for any framework that req= uires a determination of the location of the measurement points without amb= iguity, but it is not necessarily limited to LMAP?=20 2. same section: ' The bridge between the reference path and specific netwo= rk technologies ... ' - I am confused by the usage of the term 'bridge' he= re - not sure what it means 3. same section:=20 > This should serve many measurement uses, including diagnostic (where the same metric may be measured over many different path scopes) and comparative (where the same metric may be measured on different network infrastructures). comparative ... what? - something seems to be missing 4. section 4:=20 > Access (Service) Demarcation point - this varies by technology but is usually defined as the Ethernet interface on a residential gateway or modem where the scope of access packet transfer service begins and ends. In the case of a WiFi Service, this would be an Air Interface within the intended service boundary (e.g., walls of the coffee shop). The Demarcation point may be within an integrated endpoint using an Air Interface (e.g., LTE UE). I am uncomfortable with this definition (or description) by example. I beli= eve that what is meant here is to describe a local area interface to an acc= ess service. I would re-formulate this in a generic manner, and use Etherne= t, WiFi, etc. as examples 5. In Section 5:=20 > The networking technology used at all measurement points must be indicated, especially the interface standard and configured speed. None of the path descriptions that follow show the configured speed. The in= terface standard is also described in very general terms ('Wi-Fi') - in rea= l-life more exact information is needed I assume. One more detailed example= would be useful=20 6. Editorial comment - I suggest to number the different path diagrams 7. Nit - the following sentence in section 7 seems to be broken or has some= thing missing=20 > We believe is becoming a fairly common configuration in parts of the world. Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Friday, May 16, 2014 8:16 PM > To: ippm@ietf.org > Cc: lmap@ietf.org > Subject: Re: [lmap] [ippm] WGLC on draft-ietf-ippm-lmap-path >=20 > Greetings, all, >=20 > WGLC on draft-ietf-ippm-lmap-path-02 is now complete; authors, please > address the comments received and posted to the list, as well as any you > may have received privately during the call. >=20 > Thanks, cheers, >=20 > Brian >=20 >=20 > On 24 Apr 2014, at 16:56, Brian Trammell wrote: >=20 > > Greetings, all, > > > > This begins a Working Group Last Call on draft-ietf-ippm-lmap-path-02, = "A > Reference Path and Measurement Points for LMAP". (I'm cross-posting this > to LMAP, so that the LMAP WG can have a chance to review as well, given > that this document is applicable to both WGs.) > > > > WGLC will run until Thursday 15 May 2014. Please review the document an= d > provide comments to ippm@ietf.org. > > > > Many thanks, best regards, > > > > Brian Trammell > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm From nobody Mon May 19 05:15: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 D760A1A035A for ; Mon, 19 May 2014 05:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-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 7IMb7k6D_3dd for ; Mon, 19 May 2014 05:15:15 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F0E1A0352 for ; Mon, 19 May 2014 05:15:14 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s4JCF8Sh023501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 May 2014 07:15:08 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s4JCF5I1016734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 May 2014 08:15:05 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.157]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 19 May 2014 08:15:05 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "marc.ibrahim@usj.edu.lb" , "KEN.KO@adtran.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFAAOul4AAAFBuIAAD7DoAAADqTSAAAmCoQAAAf3FgAAsTaIgAAmvMoAAAJqGAAAEmCewAK066XAACHJKAA== Date: Mon, 19 May 2014 12:15:06 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] 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/wxE_SQ2fmweScRDqmwViAd36GyA Cc: "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 19 May 2014 12:15:18 -0000 Ok - no worries; So then stop ongoing tasks (ma-suppression-stop-ongoing-tasks) will stop al= l active and passive measurements, correct while the schedule and tasks ent= ities only work on active measurements, correct? If so - I will document that as well as the union approach when schedules a= nd tasks are non-empty.=20 BR, Tim -----Original Message----- From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]=20 Sent: Monday, May 19, 2014 3:02 AM To: Carey, Timothy (Timothy); marc.ibrahim@usj.edu.lb; KEN.KO@adtran.com; j= .schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: RE: [lmap] Question on information model - Suppression Sorry, my mistake - the additional parameter was agreed to be added in Lond= on, so will appear in revision 01. 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: Carey, Timothy (Timothy)=20 >[mailto:timothy.carey@alcatel-lucent.com] >Sent: 15 May 2014 18:02 >To: Burbridge,T,Trevor,TUB8 R; marc.ibrahim@usj.edu.lb;=20 >KEN.KO@adtran.com; j.schoenwaelder@jacobs-university.de >Cc: lmap@ietf.org >Subject: RE: [lmap] Question on information model - Suppression > >Trevor, > >The latest published draft (draft-ietf-lmap-information-model-00) has > object { > boolean ma-suppression-enabled; > [datetime ma-suppression-start;] // default: immediate > [datetime ma-suppression-end;] // default: indefinite > [string ma-suppression-task-names<0..*>;] > // default: all tasks if > // ma-suppression-task-names is empty > [string ma-suppression-schedule-names<0..*>;] > // default: all schedules if > // ma-suppression-schedule-names is empty > } ma-suppression-obj; > >BR, >Tim >-----Original Message----- >From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] >Sent: Thursday, May 15, 2014 10:09 AM >To: marc.ibrahim@usj.edu.lb; Carey, Timothy (Timothy);=20 >KEN.KO@adtran.com; j.schoenwaelder@jacobs-university.de >Cc: lmap@ietf.org >Subject: RE: [lmap] Question on information model - Suppression > >Currently ma-suppression-obj contains the Boolean ma-suppression-stop-=20 >ongoing-tasks. > >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=20 >confidential. It's meant only for the individual(s) or entity named=20 >above. If you're not the intended recipient, note that disclosing,=20 >copying, distributing or using this information is prohibited. If=20 >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. >British Telecommunications plc >Registered office: 81 Newgate Street London EC1A 7AJ Registered in=20 >England no: 1800000 > > >>-----Original Message----- >>From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Marc Ibrahim >>Sent: 15 May 2014 15:52 >>To: 'Carey, Timothy (Timothy)'; 'KEN KO'; 'Juergen Schoenwaelder' >>Cc: lmap@ietf.org >>Subject: Re: [lmap] Question on information model - Suppression >> >>Ok for union interpretation. >> >> >>The section (5.3.1.1) of the framework states that a suppression can=20 >>optionally include a demand to stop on-going active measurements. I=20 >>don't see this option in the suppression object. >> >>BR, >> >>Marc. >> >> >> >>-----Original Message----- >>From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy >>(Timothy) >>Sent: Thursday, May 15, 2014 5:21 PM >>To: KEN KO; Juergen Schoenwaelder >>Cc: marc. ibrahim; lmap@ietf.org >>Subject: Re: [lmap] Question on information model - Suppression >> >>So I would like close on a consensus. I added the union as the first=20 >>option which seemed to have the most consensus. Do we have consensus on t= his? >> >> >>What are the rules: >>1) If Tasks is non-empty and Schedules is non-empty: suppress the=20 >>listed tasks >and >>the listed schedules as an union of the tasks and schedules >> >>2) If Tasks is empty and Schedules is non-empty - suppress all tasks=20 >>for the listed Schedules >> >>3) If Tasks is non-empty and Schedules is empty: suppress listed tasks=20 >>for all schedules of the task >> >>4) If Tasks and Schedules are empty: suppress all tasks regardless of=20 >>schedule >> >>Thanks, >>Tim >> >>-----Original Message----- >>From: KEN KO [mailto:KEN.KO@adtran.com] >>Sent: Wednesday, May 14, 2014 8:06 AM >>To: Juergen Schoenwaelder; Carey, Timothy (Timothy) >>Cc: marc. ibrahim; lmap@ietf.org >>Subject: RE: [lmap] Question on information model - Suppression >> >>Adding +1 to the comments cautioning us to avoid over-engineering >suppression. >> >>Per the framework, suppression is "used if the measurement system=20 >>wants to eliminate inessential traffic, because there is some=20 >>unexpected network issue >for >>example." It provides a means of doing so without updating the=20 >>existing measurement schedules, as a temporary relief measure in which=20 >>measurements are disrupted by definition. >> >>There is no need for complete flexibility in the suppression mechanism=20 >>(e.g., pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve=20 >>this purpose, because you can always modify the schedules to get that=20 >>level of control. When you consider that every option adds complexity=20 >>to the MA, there is a case to be made for simplifying rather than complic= ating suppression. >> >>WRT the existing ambiguity: I prefer barring the two fields from being=20 >>used together as that will be simplest for the MA. Union or=20 >>Intersection are also acceptable as fixed definitions (not options). I=20 >>think adding pairing or multiple suppression objects would be a mistake. >> >>Best regards, >>Ken >> >>-----Original Message----- >>From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen=20 >>Schoenwaelder >>Sent: Wednesday, May 14, 2014 8:09 AM >>To: Carey, Timothy (Timothy) >>Cc: marc. ibrahim; lmap@ietf.org >>Subject: Re: [lmap] Question on information model - Suppression >> >>Yes, I stand corrected. >> >>I think I am personally leaning towards allowing multiple suppression=20 >>objects in order to keep the complexity of each suppression object=20 >>down to a basic minimum. >> >>/js >> >>On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote: >>> Juergen, >>> >>> You cannot as I read the text have multiple suppression objects. Did=20 >>> I >>miss something. >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Wednesday, May 14, 2014 12:52 AM >>> To: marc. ibrahim >>> Cc: Carey, Timothy (Timothy); lmap@ietf.org >>> Subject: Re: [lmap] Question on information model - Suppression >>> >>> On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: >>> > >>> > ma-suppression-task-names<0..*> and=20 >>> > ma-suppression-schedule-names<0..*> are strings containing names=20 >>> > of tasks and schedules. If we just allow to have the same name=20 >>> > multiple times, a pairing association could be done between tasks=20 >>> > without changing the information model. >>> > >>> > For example, ma-suppression-task-names =3D [T1 T1 T2 T2 T3 *] and >>> > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that=20 >>> > T1 will be suppressed from S1 and S2, T2 from S1 and S2, T3 from=20 >>> > all schedules, and schedule S4 will be suppressed. Does this=20 >>> > change the information model Tim? >>> >>> I do not think this is needed since you can have multiple=20 >>> suppression objects. But defining the intersection of >>> >>> ma-suppression-task-names =3D [T1 T2] >>> ma-suppression-schedule-names =3D [S1 S2] >>> >>> may not be that clear. The union is clear, suppress tasks T1 and T2=20 >>> and anything started by S1 and S2. Is the intersection=20 >>> interpretation suppress any T1 started by S1, any T2 started by S1,=20 >>> any T1 started by S2, any T2 started by S2? This is not really an=20 >>> intersection - a strict intersection interpretation would likely lead t= o an empty set. >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >> >>-- >>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 >> >>_______________________________________________ >>lmap mailing list >>lmap@ietf.org >>https://www.ietf.org/mailman/listinfo/lmap From nobody Mon May 19 05:18: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 9769E1A0336 for ; Mon, 19 May 2014 05:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 QznsFP0p5_Jx for ; Mon, 19 May 2014 05:18:35 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772AD1A0249 for ; Mon, 19 May 2014 05:18:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F22CFABA; Mon, 19 May 2014 14:18:33 +0200 (CEST) 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 V56mhrGVhEgz; Mon, 19 May 2014 14:18:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 May 2014 14:18:33 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 617D220017; Mon, 19 May 2014 14:18:33 +0200 (CEST) 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 2svr42ZDrrck; Mon, 19 May 2014 14:18:33 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1811B20013; Mon, 19 May 2014 14:18:31 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 34CF62CE922A; Mon, 19 May 2014 14:18:30 +0200 (CEST) Date: Mon, 19 May 2014 14:18:29 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20140519121829.GA79818@elstar.jacobs.jacobs-university.de> Mail-Followup-To: "Carey, Timothy (Timothy)" , "trevor.burbridge@bt.com" , "marc.ibrahim@usj.edu.lb" , "KEN.KO@adtran.com" , "lmap@ietf.org" References: <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/87QFneqIpq9uE_ZKb62iole5hkA Cc: "trevor.burbridge@bt.com" , "marc.ibrahim@usj.edu.lb" , "KEN.KO@adtran.com" , "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 19 May 2014 12:18:37 -0000 On Mon, May 19, 2014 at 12:15:06PM +0000, Carey, Timothy (Timothy) wrote: > Ok - no worries; > > So then stop ongoing tasks (ma-suppression-stop-ongoing-tasks) will stop all active and passive measurements, correct while the schedule and tasks entities only work on active measurements, correct? > Why? What is the value of restricting this? I think we already discussed some weeks ago that there may be hybrid things as well. What is wrong with simply suppressing tasks irrespective of their nature? /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 May 19 05:29: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 CE8911A0249 for ; Mon, 19 May 2014 05:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_91=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 6EIcQylOX4qN for ; Mon, 19 May 2014 05:29:02 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA221A004C for ; Mon, 19 May 2014 05:29:01 -0700 (PDT) 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; Mon, 19 May 2014 13:25:27 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 19 May 2014 13:28:47 +0100 From: To: , , , Date: Mon, 19 May 2014 13:28:47 +0100 Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9u23mkIGCze/cYSYq4/GSTku1dFAAOul4AAAFBuIAAD7DoAAADqTSAAAmCoQAAAf3FgAAsTaIgAAmvMoAAAJqGAAAEmCewAK066XAACHJKAAAAdJ0A Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771954227D@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140513214656.GA87889@elstar.jacobs.jacobs-university.de> <20140513220810.M26751@mail.usj.edu.lb> <20140514055212.GA91064@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.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/fy7VVGbFJGhSw7gSnU2T3xNAfhI Cc: lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 19 May 2014 12:29:05 -0000 It is just meant to be an extension of suppression to encompass currently e= xecuting tasks as well as those scheduled to operate in future. It doesn't at the moment make a judgement on whether that should be active/= passive/non-measurement tasks or whether the suppression should stop the ta= sk running or block network traffic. We still need to agree these points. My opinion would definitely favour stopping the task running rather than si= mply blocking network traffic. Seems simpler to implement and stops any pos= sible interaction problems between tasks. On the long-standing discussion on whether only to suppress active tasks, p= ersonally I'd rather not make an active vs passive semantic distinction. Ho= wever, in the task configuration I am leaning towards having an arbitrary "= suppressible" flag which would serve the same purpose (but be more flexible= ). One reason I'm leaning in this direction is that now everything is a tas= k - we don't necessarily want suppression to take down the tasks that repor= t errors or status, report to the Collector or communicate with the Control= ler etc. If we did this though we'd also need to say whether this can be ov= er-ridden by actually specifying the task name in the task list to be suppr= essed. Trevor Burbridge >-----Original Message----- >From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] >Sent: 19 May 2014 13:15 >To: Burbridge,T,Trevor,TUB8 R; marc.ibrahim@usj.edu.lb; KEN.KO@adtran.com; >j.schoenwaelder@jacobs-university.de >Cc: lmap@ietf.org >Subject: RE: [lmap] Question on information model - Suppression > >Ok - no worries; > >So then stop ongoing tasks (ma-suppression-stop-ongoing-tasks) will stop a= ll >active and passive measurements, correct while the schedule and tasks enti= ties >only work on active measurements, correct? > >If so - I will document that as well as the union approach when schedules = and >tasks are non-empty. > >BR, >Tim > >-----Original Message----- >From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] >Sent: Monday, May 19, 2014 3:02 AM >To: Carey, Timothy (Timothy); marc.ibrahim@usj.edu.lb; KEN.KO@adtran.com; >j.schoenwaelder@jacobs-university.de >Cc: lmap@ietf.org >Subject: RE: [lmap] Question on information model - Suppression > >Sorry, my mistake - the additional parameter was agreed to be added in Lon= don, >so will appear in revision 01. > >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 confidentia= l. It's >meant only for the individual(s) or entity named above. If you're not the = intended >recipient, note that disclosing, copying, distributing or using this infor= mation is >prohibited. If you've received this email in error, please let me know imm= ediately >on the email address above. Thank you. >We monitor our email system, and may record your emails. >British Telecommunications plc >Registered office: 81 Newgate Street London EC1A 7AJ Registered in England= no: >1800000 > >>-----Original Message----- >>From: Carey, Timothy (Timothy) >>[mailto:timothy.carey@alcatel-lucent.com] >>Sent: 15 May 2014 18:02 >>To: Burbridge,T,Trevor,TUB8 R; marc.ibrahim@usj.edu.lb; >>KEN.KO@adtran.com; j.schoenwaelder@jacobs-university.de >>Cc: lmap@ietf.org >>Subject: RE: [lmap] Question on information model - Suppression >> >>Trevor, >> >>The latest published draft (draft-ietf-lmap-information-model-00) has >> object { >> boolean ma-suppression-enabled; >> [datetime ma-suppression-start;] // default: immediate >> [datetime ma-suppression-end;] // default: indefinite >> [string ma-suppression-task-names<0..*>;] >> // default: all tasks if >> // ma-suppression-task-names is empty >> [string ma-suppression-schedule-names<0..*>;] >> // default: all schedules if >> // ma-suppression-schedule-names is empty >> } ma-suppression-obj; >> >>BR, >>Tim >>-----Original Message----- >>From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] >>Sent: Thursday, May 15, 2014 10:09 AM >>To: marc.ibrahim@usj.edu.lb; Carey, Timothy (Timothy); >>KEN.KO@adtran.com; j.schoenwaelder@jacobs-university.de >>Cc: lmap@ietf.org >>Subject: RE: [lmap] Question on information model - Suppression >> >>Currently ma-suppression-obj contains the Boolean ma-suppression-stop- >>ongoing-tasks. >> >>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 not the intended recipient, note that disclosing, >>copying, distributing or using this information is prohibited. If >>you've received this email in error, please let me know immediately on th= e email >address above. Thank you. >>We monitor our email system, and may record your emails. >>British Telecommunications plc >>Registered office: 81 Newgate Street London EC1A 7AJ Registered in >>England no: 1800000 >> >> >>>-----Original Message----- >>>From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Marc Ibrahim >>>Sent: 15 May 2014 15:52 >>>To: 'Carey, Timothy (Timothy)'; 'KEN KO'; 'Juergen Schoenwaelder' >>>Cc: lmap@ietf.org >>>Subject: Re: [lmap] Question on information model - Suppression >>> >>>Ok for union interpretation. >>> >>> >>>The section (5.3.1.1) of the framework states that a suppression can >>>optionally include a demand to stop on-going active measurements. I >>>don't see this option in the suppression object. >>> >>>BR, >>> >>>Marc. >>> >>> >>> >>>-----Original Message----- >>>From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy >>>(Timothy) >>>Sent: Thursday, May 15, 2014 5:21 PM >>>To: KEN KO; Juergen Schoenwaelder >>>Cc: marc. ibrahim; lmap@ietf.org >>>Subject: Re: [lmap] Question on information model - Suppression >>> >>>So I would like close on a consensus. I added the union as the first >>>option which seemed to have the most consensus. Do we have consensus on >this? >>> >>> >>>What are the rules: >>>1) If Tasks is non-empty and Schedules is non-empty: suppress the >>>listed tasks >>and >>>the listed schedules as an union of the tasks and schedules >>> >>>2) If Tasks is empty and Schedules is non-empty - suppress all tasks >>>for the listed Schedules >>> >>>3) If Tasks is non-empty and Schedules is empty: suppress listed tasks >>>for all schedules of the task >>> >>>4) If Tasks and Schedules are empty: suppress all tasks regardless of >>>schedule >>> >>>Thanks, >>>Tim >>> >>>-----Original Message----- >>>From: KEN KO [mailto:KEN.KO@adtran.com] >>>Sent: Wednesday, May 14, 2014 8:06 AM >>>To: Juergen Schoenwaelder; Carey, Timothy (Timothy) >>>Cc: marc. ibrahim; lmap@ietf.org >>>Subject: RE: [lmap] Question on information model - Suppression >>> >>>Adding +1 to the comments cautioning us to avoid over-engineering >>suppression. >>> >>>Per the framework, suppression is "used if the measurement system >>>wants to eliminate inessential traffic, because there is some >>>unexpected network issue >>for >>>example." It provides a means of doing so without updating the >>>existing measurement schedules, as a temporary relief measure in which >>>measurements are disrupted by definition. >>> >>>There is no need for complete flexibility in the suppression mechanism >>>(e.g., pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve >>>this purpose, because you can always modify the schedules to get that >>>level of control. When you consider that every option adds complexity >>>to the MA, there is a case to be made for simplifying rather than compli= cating >suppression. >>> >>>WRT the existing ambiguity: I prefer barring the two fields from being >>>used together as that will be simplest for the MA. Union or >>>Intersection are also acceptable as fixed definitions (not options). I >>>think adding pairing or multiple suppression objects would be a mistake. >>> >>>Best regards, >>>Ken >>> >>>-----Original Message----- >>>From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen >>>Schoenwaelder >>>Sent: Wednesday, May 14, 2014 8:09 AM >>>To: Carey, Timothy (Timothy) >>>Cc: marc. ibrahim; lmap@ietf.org >>>Subject: Re: [lmap] Question on information model - Suppression >>> >>>Yes, I stand corrected. >>> >>>I think I am personally leaning towards allowing multiple suppression >>>objects in order to keep the complexity of each suppression object >>>down to a basic minimum. >>> >>>/js >>> >>>On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote= : >>>> Juergen, >>>> >>>> You cannot as I read the text have multiple suppression objects. Did >>>> I >>>miss something. >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Wednesday, May 14, 2014 12:52 AM >>>> To: marc. ibrahim >>>> Cc: Carey, Timothy (Timothy); lmap@ietf.org >>>> Subject: Re: [lmap] Question on information model - Suppression >>>> >>>> On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote: >>>> > >>>> > ma-suppression-task-names<0..*> and >>>> > ma-suppression-schedule-names<0..*> are strings containing names >>>> > of tasks and schedules. If we just allow to have the same name >>>> > multiple times, a pairing association could be done between tasks >>>> > without changing the information model. >>>> > >>>> > For example, ma-suppression-task-names =3D [T1 T1 T2 T2 T3 *] and >>>> > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that >>>> > T1 will be suppressed from S1 and S2, T2 from S1 and S2, T3 from >>>> > all schedules, and schedule S4 will be suppressed. Does this >>>> > change the information model Tim? >>>> >>>> I do not think this is needed since you can have multiple >>>> suppression objects. But defining the intersection of >>>> >>>> ma-suppression-task-names =3D [T1 T2] >>>> ma-suppression-schedule-names =3D [S1 S2] >>>> >>>> may not be that clear. The union is clear, suppress tasks T1 and T2 >>>> and anything started by S1 and S2. Is the intersection >>>> interpretation suppress any T1 started by S1, any T2 started by S1, >>>> any T1 started by S2, any T2 started by S2? This is not really an >>>> intersection - a strict intersection interpretation would likely lead = to an empty >set. >>>> >>>> /js >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>>> Fax: +49 421 200 3103 >>> >>>-- >>>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 >>> >>>_______________________________________________ >>>lmap mailing list >>>lmap@ietf.org >>>https://www.ietf.org/mailman/listinfo/lmap From nobody Mon May 19 11: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 54C651A03C8 for ; Mon, 19 May 2014 11:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 SEY-Xp9SSVKC for ; Mon, 19 May 2014 11:24:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0F61A00D7 for ; Mon, 19 May 2014 11:23:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 677594DA; Mon, 19 May 2014 20:23:44 +0200 (CEST) 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 08_AOZb6f8yM; Mon, 19 May 2014 20:23:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 May 2014 20:23:43 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92CD720013; Mon, 19 May 2014 20:23:43 +0200 (CEST) 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 Uoe3ODXpq7Fz; Mon, 19 May 2014 20:23:42 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 76A4120017; Mon, 19 May 2014 20:23:41 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 2A1D32CE9A2B; Mon, 19 May 2014 20:23:41 +0200 (CEST) Date: Mon, 19 May 2014 20:23:41 +0200 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20140519182341.GB80752@elstar.jacobs.jacobs-university.de> Mail-Followup-To: trevor.burbridge@bt.com, timothy.carey@alcatel-lucent.com, marc.ibrahim@usj.edu.lb, KEN.KO@adtran.com, lmap@ietf.org References: <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/JAqYbhbjvzj9OFlpio8M66WgAJg Cc: timothy.carey@alcatel-lucent.com, marc.ibrahim@usj.edu.lb, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 19 May 2014 18:24:10 -0000 On Mon, May 19, 2014 at 01:28:47PM +0100, trevor.burbridge@bt.com wrote: > It is just meant to be an extension of suppression to encompass currently executing tasks as well as those scheduled to operate in future. > > It doesn't at the moment make a judgement on whether that should be active/passive/non-measurement tasks or whether the suppression should stop the task running or block network traffic. We still need to agree these points. > > My opinion would definitely favour stopping the task running rather than simply blocking network traffic. Seems simpler to implement and stops any possible interaction problems between tasks. > > On the long-standing discussion on whether only to suppress active tasks, personally I'd rather not make an active vs passive semantic distinction. However, in the task configuration I am leaning towards having an arbitrary "suppressible" flag which would serve the same purpose (but be more flexible). One reason I'm leaning in this direction is that now everything is a task - we don't necessarily want suppression to take down the tasks that report errors or status, report to the Collector or communicate with the Controller etc. If we did this though we'd also need to say whether this can be over-ridden by actually specifying the task name in the task list to be suppressed. > Would it not make more sense to state that tasks not involved in measurements are always not suppressible? Adding more flags and special cases all adds complexity. Does every implementation have to support the 'suppressible' flag on all tasks? Or is that something an implementation can hardwire (even to the extreme where nothing is suppressible)? How do I learn whether a certain task can be suppressable for a given implementation - by trial and error? It is all these little details that increase complexity for something that ought to be simple and used only in rare 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 May 19 12:11: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 BB5681A03B9 for ; Mon, 19 May 2014 12:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 uqF5hknJiJ7z for ; Mon, 19 May 2014 12:10:52 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id 72FE41A022A for ; Mon, 19 May 2014 12:10:52 -0700 (PDT) X-ASG-Debug-ID: 1400526832-05fac105a334af0001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id KxeVJChWHfLtPDh2; Mon, 19 May 2014 22:13:52 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from usj.edu.lb (localhost.localdomain [127.0.0.1]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4JJAi38022009; Mon, 19 May 2014 22:10:46 +0300 From: "marc.ibrahim" To: Juergen Schoenwaelder , trevor.burbridge@bt.com Date: Mon, 19 May 2014 22:10:44 +0300 X-ASG-Orig-Subj: Re: [lmap] Question on information model - Suppression Message-Id: <20140519185107.M36304@usj.edu.lb> In-Reply-To: <20140519182341.GB80752@elstar.jacobs.jacobs-university.de> References: <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140519182341.GB80752@elstar.jacobs.jacobs-university.de> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 37.209.253.182 (marc.ibrahim) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1400526832 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.5940 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/M0Vdfxd_aAyeNPrA5u61kcg64XM Cc: timothy.carey@alcatel-lucent.com, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 19 May 2014 19:10:59 -0000 I join Trevor in considering that no distinction should be made between active and passive tasks. For tasks suppression (Tasks array in suppression object), the controller is free to specify any kind of tasks it wishes to suppress. If it wants to suppress only active measurements, then it just lists them. I don't see that "Trevor flag" is useful here since the flag and the Tasks array are both under the Controller control. For schedule suppression (Schedules array), the flag would mean the following: being able to suppress a schedule S while keeping a "non suppressible" subset of tasks running according to S. In my opinion, it will complicate things as JS stated, especially that previous decisions privileged simplicity. I see that if the controller wants to define a subset of "non suppressible tasks, it can simply create a dedicated schedule for these tasks and not mix them with other suppressible tasks. BR, Marc. On Mon, 19 May 2014 20:23:41 +0200, Juergen Schoenwaelder wrote > On Mon, May 19, 2014 at 01:28:47PM +0100, trevor.burbridge@bt.com wrote: > > It is just meant to be an extension of suppression to encompass currently executing tasks as well as those scheduled to operate in future. > > > > It doesn't at the moment make a judgement on whether that should be active/passive/non-measurement tasks or whether the suppression should stop the task running or block network traffic. We still need to agree these points. > > > > My opinion would definitely favour stopping the task running rather than simply blocking network traffic. Seems simpler to implement and stops any possible interaction problems between tasks. > > > > On the long-standing discussion on whether only to suppress active tasks, personally I'd rather not make an active vs passive semantic distinction. However, in the task configuration I am leaning towards having an arbitrary "suppressible" flag which would serve the same purpose (but be more flexible). One reason I'm leaning in this direction is that now everything is a task - we don't necessarily want suppression to take down the tasks that report errors or status, report to the Collector or communicate with the Controller etc. If we did this though we'd also need to say whether this can be over- ridden by actually specifying the task name in the task list to be suppressed. > > > > Would it not make more sense to state that tasks not involved in > measurements are always not suppressible? Adding more flags and > special cases all adds complexity. Does every implementation have to > support the 'suppressible' flag on all tasks? Or is that something an > implementation can hardwire (even to the extreme where nothing is > suppressible)? How do I learn whether a certain task can be > suppressable for a given implementation - by trial and error? It is > all these little details that increase complexity for something that > ought to be simple and used only in rare situations... > > /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 -- Open WebMail Project (http://openwebmail.org) From nobody Tue May 20 01:07: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 A306C1A049F for ; Tue, 20 May 2014 01:07:20 -0700 (PDT) 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_91=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 fL8uYNHXYmj4 for ; Tue, 20 May 2014 01:07:18 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9F31A0499 for ; Tue, 20 May 2014 01:07:18 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 20 May 2014 09:07:22 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Tue, 20 May 2014 09:07:05 +0100 From: To: Date: Tue, 20 May 2014 09:07:04 +0100 Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9zj3k77H40uQudQZO4H9/xdNZwpgAcpXXQ Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140519182341.GB80752@elstar.jacobs.jacobs-university.de> In-Reply-To: <20140519182341.GB80752@elstar.jacobs.jacobs-university.de> 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/4lOyfFtKV8-Scwl2DxC-tnffeCI Cc: timothy.carey@alcatel-lucent.com, marc.ibrahim@usj.edu.lb, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 20 May 2014 08:07:20 -0000 >-----Original Message----- >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >Sent: 19 May 2014 19:24 >To: Burbridge,T,Trevor,TUB8 R >Cc: timothy.carey@alcatel-lucent.com; marc.ibrahim@usj.edu.lb; >KEN.KO@adtran.com; lmap@ietf.org >Subject: Re: [lmap] Question on information model - Suppression > [...] >Would it not make more sense to state that tasks not involved in >measurements are always not suppressible? Adding more flags and >special cases all adds complexity. Does every implementation have to >support the 'suppressible' flag on all tasks? Or is that something an >implementation can hardwire (even to the extreme where nothing is >suppressible)? How do I learn whether a certain task can be >suppressable for a given implementation - by trial and error? It is >all these little details that increase complexity for something that >ought to be simple and used only in rare situations... To do what you suggest (tasks not involved in measurements are always not s= uppressible) would need some sort of flag or classification. The MA needs s= ome way to decide whether it is a measurement task. The only question real= ly is whether it is it the registry entry (not changeable for different dep= loyments) or in the task configuration. Trevor. From nobody Tue May 20 01:14: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 A28C81A0450 for ; Tue, 20 May 2014 01:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=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 uK3PKE42ohu2 for ; Tue, 20 May 2014 01:14:20 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47EB1A03F4 for ; Tue, 20 May 2014 01:14:19 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 20 May 2014 09:14:24 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 20 May 2014 09:14:17 +0100 From: To: , Date: Tue, 20 May 2014 09:14:16 +0100 Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac9zlg89n6A/zWIITzKbs/vmnVWMGwAbJcCQ Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140519182341.GB80752@elstar.jacobs.jacobs-university.de> <20140519185107.M36304@usj.edu.lb> In-Reply-To: <20140519185107.M36304@usj.edu.lb> 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/0YOjr1n6jQlgmFes58pOSbSZ530 Cc: timothy.carey@alcatel-lucent.com, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 20 May 2014 08:14:21 -0000 This is where I was until we have everything as a task. Measurement tasks, = reporting tasks, alarm collection tasks, Instruction fetching tasks). Witho= ut some sort of tweak a single "suppress" message could put the MA out of c= ommunication. A single suppress message without an endtime would put the MA= out of communication permanently. The controller communication tasks at least need some sort of protection. Let me try an alternative that I think is close to Marc and Juergen: - as Marc suggests below (i.e. all tasks can be suppressed without distinct= ion) - BUT the tasks run in the controller communication schedule are exempt fro= m suppression. i.e. suppression only affects the Instruction schedules. Trevor. Trevor Burbridge >-----Original Message----- >From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >Sent: 19 May 2014 20:11 >To: Juergen Schoenwaelder; Burbridge,T,Trevor,TUB8 R >Cc: timothy.carey@alcatel-lucent.com; KEN.KO@adtran.com; lmap@ietf.org >Subject: Re: [lmap] Question on information model - Suppression > >I join Trevor in considering that no distinction should be made between ac= tive and >passive tasks. > >For tasks suppression (Tasks array in suppression object), the controller = is free to >specify any kind of tasks it wishes to suppress. If it wants to suppress o= nly active >measurements, then it just lists them. I don't see that "Trevor flag" is u= seful here >since the flag and the Tasks array are both under the Controller control. > >For schedule suppression (Schedules array), the flag would mean the follow= ing: >being able to suppress a schedule S while keeping a "non suppressible" sub= set of >tasks running according to S. In my opinion, it will complicate things as = JS stated, >especially that previous decisions privileged simplicity. >I see that if the controller wants to define a subset of "non suppressible= tasks, it >can simply create a dedicated schedule for these tasks and not mix them wi= th >other suppressible tasks. > >BR, > >Marc. > > > >On Mon, 19 May 2014 20:23:41 +0200, Juergen Schoenwaelder wrote >> On Mon, May 19, 2014 at 01:28:47PM +0100, trevor.burbridge@bt.com wrote: >> > It is just meant to be an extension of suppression to encompass curren= tly >executing >tasks as well as those scheduled to operate in future. >> > >> > It doesn't at the moment make a judgement on whether that should be >active/passive/non-measurement tasks or whether the suppression should sto= p >the task >running or block network traffic. We still need to agree these points. >> > >> > My opinion would definitely favour stopping the task running rather th= an >simply >blocking network traffic. Seems simpler to implement and stops any possibl= e >interaction >problems between tasks. >> > >> > On the long-standing discussion on whether only to suppress active tas= ks, >personally >I'd rather not make an active vs passive semantic distinction. However, in= the task >configuration I am leaning towards having an arbitrary "suppressible" flag= which >would >serve the same purpose (but be more flexible). One reason I'm leaning in t= his >direction >is that now everything is a task - we don't necessarily want suppression t= o take >down >the tasks that report errors or status, report to the Collector or communi= cate >with the >Controller etc. If we did this though we'd also need to say whether this c= an be >over- >ridden by actually specifying the task name in the task list to be suppres= sed. >> > >> >> Would it not make more sense to state that tasks not involved in >> measurements are always not suppressible? Adding more flags and >> special cases all adds complexity. Does every implementation have to >> support the 'suppressible' flag on all tasks? Or is that something an >> implementation can hardwire (even to the extreme where nothing is >> suppressible)? How do I learn whether a certain task can be >> suppressable for a given implementation - by trial and error? It is >> all these little details that increase complexity for something that >> ought to be simple and used only in rare situations... >> >> /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 > > >-- >Open WebMail Project (http://openwebmail.org) From nobody Tue May 20 07:59: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 D19311A0346 for ; Tue, 20 May 2014 07:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=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 MoSmlW8F0vcA for ; Tue, 20 May 2014 07:59:11 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBDE1A0153 for ; Tue, 20 May 2014 07:59:11 -0700 (PDT) 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 s4KEwPgP019972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 May 2014 09:58:25 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 446F11E0084; Tue, 20 May 2014 09:58:20 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 0507C1E0069; Tue, 20 May 2014 09:58:20 -0500 (CDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s4KEwJ9U019468; Tue, 20 May 2014 08:58:19 -0600 (MDT) Received: from [10.188.200.201] (x1069818.dhcp.intranet [10.188.200.201]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s4KEwHdl019411; Tue, 20 May 2014 08:58:18 -0600 (MDT) Message-ID: <537B6D89.9090505@centurylink.com> Date: Tue, 20 May 2014 08:58:17 -0600 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: trevor.burbridge@bt.com References: <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140519182341.GB80752@elstar.jacobs.jacobs-university.de> <20140519185107.M36304@usj.edu.lb> In-Reply-To: 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/V1jgsmGYKzY1rsF6MsAwUmyWNwg Cc: j.schoenwaelder@jacobs-university.de, lmap@ietf.org, marc.ibrahim@usj.edu.lb, KEN.KO@adtran.com, timothy.carey@alcatel-lucent.com Subject: Re: [lmap] Question on information model - Suppression 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: Tue, 20 May 2014 14:59:13 -0000 Trevor, I'm not sure what the second dash item means - particularly the first half of the item regarding the controller communication schedule. Perhaps you can elaborate. Charles On 5/20/2014 2:14 AM, trevor.burbridge@bt.com wrote: > This is where I was until we have everything as a task. Measurement tasks, reporting tasks, alarm collection tasks, Instruction fetching tasks). Without some sort of tweak a single "suppress" message could put the MA out of communication. A single suppress message without an endtime would put the MA out of communication permanently. > > The controller communication tasks at least need some sort of protection. > > Let me try an alternative that I think is close to Marc and Juergen: > > - as Marc suggests below (i.e. all tasks can be suppressed without distinction) > - BUT the tasks run in the controller communication schedule are exempt from suppression. i.e. suppression only affects the Instruction schedules. > > Trevor. > > Trevor Burbridge > >> -----Original Message----- >> From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >> Sent: 19 May 2014 20:11 >> To: Juergen Schoenwaelder; Burbridge,T,Trevor,TUB8 R >> Cc: timothy.carey@alcatel-lucent.com; KEN.KO@adtran.com; lmap@ietf.org >> Subject: Re: [lmap] Question on information model - Suppression >> >> I join Trevor in considering that no distinction should be made between active and >> passive tasks. >> >> For tasks suppression (Tasks array in suppression object), the controller is free to >> specify any kind of tasks it wishes to suppress. If it wants to suppress only active >> measurements, then it just lists them. I don't see that "Trevor flag" is useful here >> since the flag and the Tasks array are both under the Controller control. >> >> For schedule suppression (Schedules array), the flag would mean the following: >> being able to suppress a schedule S while keeping a "non suppressible" subset of >> tasks running according to S. In my opinion, it will complicate things as JS stated, >> especially that previous decisions privileged simplicity. >> I see that if the controller wants to define a subset of "non suppressible tasks, it >> can simply create a dedicated schedule for these tasks and not mix them with >> other suppressible tasks. >> >> BR, >> >> Marc. >> >> >> >> On Mon, 19 May 2014 20:23:41 +0200, Juergen Schoenwaelder wrote >>> On Mon, May 19, 2014 at 01:28:47PM +0100, trevor.burbridge@bt.com wrote: >>>> It is just meant to be an extension of suppression to encompass currently >> executing >> tasks as well as those scheduled to operate in future. >>>> It doesn't at the moment make a judgement on whether that should be >> active/passive/non-measurement tasks or whether the suppression should stop >> the task >> running or block network traffic. We still need to agree these points. >>>> My opinion would definitely favour stopping the task running rather than >> simply >> blocking network traffic. Seems simpler to implement and stops any possible >> interaction >> problems between tasks. >>>> On the long-standing discussion on whether only to suppress active tasks, >> personally >> I'd rather not make an active vs passive semantic distinction. However, in the task >> configuration I am leaning towards having an arbitrary "suppressible" flag which >> would >> serve the same purpose (but be more flexible). One reason I'm leaning in this >> direction >> is that now everything is a task - we don't necessarily want suppression to take >> down >> the tasks that report errors or status, report to the Collector or communicate >> with the >> Controller etc. If we did this though we'd also need to say whether this can be >> over- >> ridden by actually specifying the task name in the task list to be suppressed. >>> Would it not make more sense to state that tasks not involved in >>> measurements are always not suppressible? Adding more flags and >>> special cases all adds complexity. Does every implementation have to >>> support the 'suppressible' flag on all tasks? Or is that something an >>> implementation can hardwire (even to the extreme where nothing is >>> suppressible)? How do I learn whether a certain task can be >>> suppressable for a given implementation - by trial and error? It is >>> all these little details that increase complexity for something that >>> ought to be simple and used only in rare situations... >>> >>> /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 >> >> -- >> Open WebMail Project (http://openwebmail.org) > _______________________________________________ > 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 Tue May 20 08:52: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 EB2B41A0774 for ; Tue, 20 May 2014 08:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=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 1tEcEFMEnltw for ; Tue, 20 May 2014 08:52:42 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7249E1A036B for ; Tue, 20 May 2014 08:52:41 -0700 (PDT) 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; Tue, 20 May 2014 16:49:08 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Tue, 20 May 2014 16:52:09 +0100 From: To: Date: Tue, 20 May 2014 16:52:09 +0100 Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac90PBPsebMIRHu7SpOsByZG92YPzwABmowQ Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140514120920.GA92001@elstar.jacobs.jacobs-university.de> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140519182341.GB80752@elstar.jacobs.jacobs-university.de> <20140519185107.M36304@usj.edu.lb> <537B6D89.9090505@centurylink.com> In-Reply-To: <537B6D89.9090505@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/I8mj3F3YT1uk8_VGEkZn8xZRlrA Cc: j.schoenwaelder@jacobs-university.de, lmap@ietf.org, marc.ibrahim@usj.edu.lb, KEN.KO@adtran.com, timothy.carey@alcatel-lucent.com Subject: Re: [lmap] Question on information model - Suppression 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, 20 May 2014 15:52:45 -0000 The change that was agreed in London was that everything would be treated a= s a Task - meaning also that everything is run from a Schedule. The consequ= ences of this is that we have a Control Schedule that executes the Control = Tasks (that implement the Control Protocol). This is set in pre-configurati= on and can be updated in configuration. We then have separate Instruction Schedules containing all other Tasks (e.g= . measurement and reporting tasks). These are set as part of the Instructio= n. The separation of these two sets of information (necessary since we need to= communicate initially with a Controller before receiving Instruction) mean= s we can exploit this in the effect of Suppression. This is what I was sugg= esting - anything in the 'control' information would not be suppressed. i.e= . you can't suppress the MA talking with the Controller. Sorry some of this is not very clear as it is agreed but unpublished work (= forthcoming in revision 01). Trevor Burbridge >-----Original Message----- >From: Charles Cook [mailto:charles.cook2@centurylink.com] >Sent: 20 May 2014 15:58 >To: Burbridge,T,Trevor,TUB8 R >Cc: marc.ibrahim@usj.edu.lb; j.schoenwaelder@jacobs-university.de; >timothy.carey@alcatel-lucent.com; KEN.KO@adtran.com; lmap@ietf.org >Subject: Re: [lmap] Question on information model - Suppression > >Trevor, > >I'm not sure what the second dash item means - particularly the first >half of the item regarding the controller communication schedule. >Perhaps you can elaborate. > >Charles > >On 5/20/2014 2:14 AM, trevor.burbridge@bt.com wrote: >> This is where I was until we have everything as a task. Measurement task= s, >reporting tasks, alarm collection tasks, Instruction fetching tasks). With= out some >sort of tweak a single "suppress" message could put the MA out of >communication. A single suppress message without an endtime would put the = MA >out of communication permanently. >> >> The controller communication tasks at least need some sort of protection= . >> >> Let me try an alternative that I think is close to Marc and Juergen: >> >> - as Marc suggests below (i.e. all tasks can be suppressed without disti= nction) >> - BUT the tasks run in the controller communication schedule are exempt = from >suppression. i.e. suppression only affects the Instruction schedules. >> >> Trevor. >> >> Trevor Burbridge >> >>> -----Original Message----- >>> From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >>> Sent: 19 May 2014 20:11 >>> To: Juergen Schoenwaelder; Burbridge,T,Trevor,TUB8 R >>> Cc: timothy.carey@alcatel-lucent.com; KEN.KO@adtran.com; lmap@ietf.org >>> Subject: Re: [lmap] Question on information model - Suppression >>> >>> I join Trevor in considering that no distinction should be made between= active >and >>> passive tasks. >>> >>> For tasks suppression (Tasks array in suppression object), the controll= er is free >to >>> specify any kind of tasks it wishes to suppress. If it wants to suppres= s only >active >>> measurements, then it just lists them. I don't see that "Trevor flag" i= s useful >here >>> since the flag and the Tasks array are both under the Controller contro= l. >>> >>> For schedule suppression (Schedules array), the flag would mean the >following: >>> being able to suppress a schedule S while keeping a "non suppressible" = subset >of >>> tasks running according to S. In my opinion, it will complicate things = as JS >stated, >>> especially that previous decisions privileged simplicity. >>> I see that if the controller wants to define a subset of "non suppressi= ble tasks, >it >>> can simply create a dedicated schedule for these tasks and not mix them= with >>> other suppressible tasks. >>> >>> BR, >>> >>> Marc. >>> >>> >>> >>> On Mon, 19 May 2014 20:23:41 +0200, Juergen Schoenwaelder wrote >>>> On Mon, May 19, 2014 at 01:28:47PM +0100, trevor.burbridge@bt.com >wrote: >>>>> It is just meant to be an extension of suppression to encompass curre= ntly >>> executing >>> tasks as well as those scheduled to operate in future. >>>>> It doesn't at the moment make a judgement on whether that should be >>> active/passive/non-measurement tasks or whether the suppression should >stop >>> the task >>> running or block network traffic. We still need to agree these points. >>>>> My opinion would definitely favour stopping the task running rather t= han >>> simply >>> blocking network traffic. Seems simpler to implement and stops any poss= ible >>> interaction >>> problems between tasks. >>>>> On the long-standing discussion on whether only to suppress active ta= sks, >>> personally >>> I'd rather not make an active vs passive semantic distinction. However,= in the >task >>> configuration I am leaning towards having an arbitrary "suppressible" f= lag >which >>> would >>> serve the same purpose (but be more flexible). One reason I'm leaning i= n this >>> direction >>> is that now everything is a task - we don't necessarily want suppressio= n to take >>> down >>> the tasks that report errors or status, report to the Collector or comm= unicate >>> with the >>> Controller etc. If we did this though we'd also need to say whether thi= s can be >>> over- >>> ridden by actually specifying the task name in the task list to be supp= ressed. >>>> Would it not make more sense to state that tasks not involved in >>>> measurements are always not suppressible? Adding more flags and >>>> special cases all adds complexity. Does every implementation have to >>>> support the 'suppressible' flag on all tasks? Or is that something an >>>> implementation can hardwire (even to the extreme where nothing is >>>> suppressible)? How do I learn whether a certain task can be >>>> suppressable for a given implementation - by trial and error? It is >>>> all these little details that increase complexity for something that >>>> ought to be simple and used only in rare situations... >>>> >>>> /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 >>> >>> -- >>> Open WebMail Project (http://openwebmail.org) >> _______________________________________________ >> 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 Tue May 20 09:27: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 5C8AF1A079D for ; Tue, 20 May 2014 09:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.651, 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 60evDoP2snHk for ; Tue, 20 May 2014 09:26:59 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id 03EC81A079B for ; Tue, 20 May 2014 09:26:56 -0700 (PDT) X-ASG-Debug-ID: 1400603396-05fac105a262d50001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id 0XCjERcwkBoVpYRz; Tue, 20 May 2014 19:29:56 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from [10.80.0.59] ([10.80.0.59]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4KGQZvX031963; Tue, 20 May 2014 19:26:40 +0300 From: marc.ibrahim@usj.edu.lb To: , Date: Tue, 20 May 2014 19:26:55 +0300 X-ASG-Orig-Subj: RE: [lmap] Question on information model - Suppression Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1400603396 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.82 X-Barracuda-Spam-Status: No, SCORE=0.82 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.5964 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FzBMyJO4g5VVJmYSh5piCRhHJWc Cc: timothy.carey@alcatel-lucent.com, j.schoenwaelder@jacobs-university.de, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 20 May 2014 16:27:02 -0000 It is very clear now Trevor. Can't we imagine a scenario where the controller would tell the MA to stop = communicating with controller for a given period of time (maintenance or = other reason...)? =20 marc. -original message- Subject: RE: [lmap] Question on information model - Suppression From: Date: 20/05/2014 18:53 The change that was agreed in London was that everything would be treated = as a Task - meaning also that everything is run from a Schedule. The = consequences of this is that we have a Control Schedule that executes the = Control Tasks (that implement the Control Protocol). This is set in = pre-configuration and can be updated in configuration. We then have separate Instruction Schedules containing all other Tasks = (e.g. measurement and reporting tasks). These are set as part of the = Instruction. The separation of these two sets of information (necessary since we need to = communicate initially with a Controller before receiving Instruction) means = we can exploit this in the effect of Suppression. This is what I was = suggesting - anything in the 'control' information would not be suppressed. = i.e. you can't suppress the MA talking with the Controller. Sorry some of this is not very clear as it is agreed but unpublished work = (forthcoming in revision 01). Trevor Burbridge >-----Original Message----- >From: Charles Cook [mailto:charles.cook2@centurylink.com] >Sent: 20 May 2014 15:58 >To: Burbridge,T,Trevor,TUB8 R >Cc: marc.ibrahim@usj.edu.lb; j.schoenwaelder@jacobs-university.de; >timothy.carey@alcatel-lucent.com; KEN.KO@adtran.com; lmap@ietf.org >Subject: Re: [lmap] Question on information model - Suppression > >Trevor, > >I'm not sure what the second dash item means - particularly the = first >half of the item regarding the controller communication schedule. >Perhaps you can elaborate. > >Charles > >On 5/20/2014 2:14 AM, trevor.burbridge@bt.com wrote: >> This is where I was until we have everything as a task. Measurement = tasks, >reporting tasks, alarm collection tasks, Instruction fetching tasks). = Without some >sort of tweak a single "suppress" message could put the MA out of >communication. A single suppress message without an endtime would put the = MA >out of communication permanently. >> >> The controller communication tasks at least need some sort of = protection. >> >> Let me try an alternative that I think is close to Marc and = Juergen: >> >> - as Marc suggests below (i.e. all tasks can be suppressed without = distinction) >> - BUT the tasks run in the controller communication schedule are exempt = from >suppression. i.e. suppression only affects the Instruction = schedules. >> >> Trevor. >> >> Trevor Burbridge >> >>> -----Original Message----- >>> From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >>> Sent: 19 May 2014 20:11 >>> To: Juergen Schoenwaelder; Burbridge,T,Trevor,TUB8 R >>> Cc: timothy.carey@alcatel-lucent.com; KEN.KO@adtran.com; = lmap@ietf.org >>> Subject: Re: [lmap] Question on information model - Suppression >>> >>> I join Trevor in considering that no distinction should be made between = active >and >>> passive tasks. >>> >>> For tasks suppression (Tasks array in suppression object), the = controller is free >to >>> specify any kind of tasks it wishes to suppress. If it wants to = suppress only >active >>> measurements, then it just lists them. I don't see that "Trevor flag" = is useful >here >>> since the flag and the Tasks array are both under the Controller = control. >>> >>> For schedule suppression (Schedules array), the flag would mean = the >following: >>> being able to suppress a schedule S while keeping a "non suppressible" = subset >of >>> tasks running according to S. In my opinion, it will complicate things = as JS >stated, >>> especially that previous decisions privileged simplicity. >>> I see that if the controller wants to define a subset of "non = suppressible tasks, >it >>> can simply create a dedicated schedule for these tasks and not mix them = with >>> other suppressible tasks. >>> >>> BR, >>> >>> Marc. >>> >>> >>> >>> On Mon, 19 May 2014 20:23:41 +0200, Juergen Schoenwaelder wrote >>>> On Mon, May 19, 2014 at 01:28:47PM +0100, = trevor.burbridge@bt.com >wrote: >>>>> It is just meant to be an extension of suppression to encompass = currently >>> executing >>> tasks as well as those scheduled to operate in future. >>>>> It doesn't at the moment make a judgement on whether that should = be >>> active/passive/non-measurement tasks or whether the suppression = should >stop >>> the task >>> running or block network traffic. We still need to agree these = points. >>>>> My opinion would definitely favour stopping the task running rather = than >>> simply >>> blocking network traffic. Seems simpler to implement and stops any = possible >>> interaction >>> problems between tasks. >>>>> On the long-standing discussion on whether only to suppress active = tasks, >>> personally >>> I'd rather not make an active vs passive semantic distinction. However, = in the >task >>> configuration I am leaning towards having an arbitrary "suppressible" = flag >which >>> would >>> serve the same purpose (but be more flexible). One reason I'm leaning = in this >>> direction >>> is that now everything is a task - we don't necessarily want = suppression to take >>> down >>> the tasks that report errors or status, report to the Collector or = communicate >>> with the >>> Controller etc. If we did this though we'd also need to say whether = this can be >>> over- >>> ridden by actually specifying the task name in the task list to be = suppressed. >>>> Would it not make more sense to state that tasks not involved in >>>> measurements are always not suppressible? Adding more flags and >>>> special cases all adds complexity. Does every implementation have = to >>>> support the 'suppressible' flag on all tasks? Or is that something = an >>>> implementation can hardwire (even to the extreme where nothing = is >>>> suppressible)? How do I learn whether a certain task can be >>>> suppressable for a given implementation - by trial and error? It = is >>>> all these little details that increase complexity for something = that >>>> ought to be simple and used only in rare situations... >>>> >>>> /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 >>> >>> -- >>> Open WebMail Project (http://openwebmail.org) >> _______________________________________________ >> 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 Tue May 20 11:07: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 9FB331A0744 for ; Tue, 20 May 2014 11:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=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 EHVAMHP4gsGJ for ; Tue, 20 May 2014 11:06:56 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F901A038A for ; Tue, 20 May 2014 11:06:46 -0700 (PDT) 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 s4KI2EFE014599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 May 2014 13:02:14 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 218691E0080; Tue, 20 May 2014 12:02:09 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id F02641E007C; Tue, 20 May 2014 12:02:08 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s4KI28u7003926; Tue, 20 May 2014 12:02:08 -0600 (MDT) Received: from [10.188.200.201] (x1069818.dhcp.intranet [10.188.200.201]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s4KI27wt003894; Tue, 20 May 2014 12:02:07 -0600 (MDT) Message-ID: <537B989E.1070006@centurylink.com> Date: Tue, 20 May 2014 12:02:06 -0600 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: trevor.burbridge@bt.com References: <9966516C6EB5FC4381E05BF80AA55F7719542B73@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140519182341.GB80752@elstar.jacobs.jacobs-university.de> <20140519185107.M36304@usj.edu.lb> <537B6D89.9090505@centurylink.com> In-Reply-To: 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/pHvFXT60DjDjvA9RnOLr3j_zYiE Cc: j.schoenwaelder@jacobs-university.de, lmap@ietf.org, marc.ibrahim@usj.edu.lb, KEN.KO@adtran.com, timothy.carey@alcatel-lucent.com Subject: Re: [lmap] Question on information model - Suppression 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: Tue, 20 May 2014 18:06:58 -0000 Thanks. This helps. I can generally agree with this approach. I do, however, have one question... What would be the intended approach to deal with a DOS attack by a rogue MA(s) on a Controller? Or do we treat that as an exception case that is out of scope since a hacker could ignore a suppression and perform a DOS regardless of the protocol? I suppose the Controller needs to have a strategy on how to protect itself in such a situation. Charles On 5/20/2014 9:52 AM, trevor.burbridge@bt.com wrote: > The change that was agreed in London was that everything would be treated as a Task - meaning also that everything is run from a Schedule. The consequences of this is that we have a Control Schedule that executes the Control Tasks (that implement the Control Protocol). This is set in pre-configuration and can be updated in configuration. > > We then have separate Instruction Schedules containing all other Tasks (e.g. measurement and reporting tasks). These are set as part of the Instruction. > > The separation of these two sets of information (necessary since we need to communicate initially with a Controller before receiving Instruction) means we can exploit this in the effect of Suppression. This is what I was suggesting - anything in the 'control' information would not be suppressed. i.e. you can't suppress the MA talking with the Controller. > > Sorry some of this is not very clear as it is agreed but unpublished work (forthcoming in revision 01). > > Trevor Burbridge > >> -----Original Message----- >> From: Charles Cook [mailto:charles.cook2@centurylink.com] >> Sent: 20 May 2014 15:58 >> To: Burbridge,T,Trevor,TUB8 R >> Cc: marc.ibrahim@usj.edu.lb; j.schoenwaelder@jacobs-university.de; >> timothy.carey@alcatel-lucent.com; KEN.KO@adtran.com; lmap@ietf.org >> Subject: Re: [lmap] Question on information model - Suppression >> >> Trevor, >> >> I'm not sure what the second dash item means - particularly the first >> half of the item regarding the controller communication schedule. >> Perhaps you can elaborate. >> >> Charles >> >> On 5/20/2014 2:14 AM, trevor.burbridge@bt.com wrote: >>> This is where I was until we have everything as a task. Measurement tasks, >> reporting tasks, alarm collection tasks, Instruction fetching tasks). Without some >> sort of tweak a single "suppress" message could put the MA out of >> communication. A single suppress message without an endtime would put the MA >> out of communication permanently. >>> The controller communication tasks at least need some sort of protection. >>> >>> Let me try an alternative that I think is close to Marc and Juergen: >>> >>> - as Marc suggests below (i.e. all tasks can be suppressed without distinction) >>> - BUT the tasks run in the controller communication schedule are exempt from >> suppression. i.e. suppression only affects the Instruction schedules. >>> Trevor. >>> >>> Trevor Burbridge >>> >>>> -----Original Message----- >>>> From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb] >>>> Sent: 19 May 2014 20:11 >>>> To: Juergen Schoenwaelder; Burbridge,T,Trevor,TUB8 R >>>> Cc: timothy.carey@alcatel-lucent.com; KEN.KO@adtran.com; lmap@ietf.org >>>> Subject: Re: [lmap] Question on information model - Suppression >>>> >>>> I join Trevor in considering that no distinction should be made between active >> and >>>> passive tasks. >>>> >>>> For tasks suppression (Tasks array in suppression object), the controller is free >> to >>>> specify any kind of tasks it wishes to suppress. If it wants to suppress only >> active >>>> measurements, then it just lists them. I don't see that "Trevor flag" is useful >> here >>>> since the flag and the Tasks array are both under the Controller control. >>>> >>>> For schedule suppression (Schedules array), the flag would mean the >> following: >>>> being able to suppress a schedule S while keeping a "non suppressible" subset >> of >>>> tasks running according to S. In my opinion, it will complicate things as JS >> stated, >>>> especially that previous decisions privileged simplicity. >>>> I see that if the controller wants to define a subset of "non suppressible tasks, >> it >>>> can simply create a dedicated schedule for these tasks and not mix them with >>>> other suppressible tasks. >>>> >>>> BR, >>>> >>>> Marc. >>>> >>>> >>>> >>>> On Mon, 19 May 2014 20:23:41 +0200, Juergen Schoenwaelder wrote >>>>> On Mon, May 19, 2014 at 01:28:47PM +0100, trevor.burbridge@bt.com >> wrote: >>>>>> It is just meant to be an extension of suppression to encompass currently >>>> executing >>>> tasks as well as those scheduled to operate in future. >>>>>> It doesn't at the moment make a judgement on whether that should be >>>> active/passive/non-measurement tasks or whether the suppression should >> stop >>>> the task >>>> running or block network traffic. We still need to agree these points. >>>>>> My opinion would definitely favour stopping the task running rather than >>>> simply >>>> blocking network traffic. Seems simpler to implement and stops any possible >>>> interaction >>>> problems between tasks. >>>>>> On the long-standing discussion on whether only to suppress active tasks, >>>> personally >>>> I'd rather not make an active vs passive semantic distinction. However, in the >> task >>>> configuration I am leaning towards having an arbitrary "suppressible" flag >> which >>>> would >>>> serve the same purpose (but be more flexible). One reason I'm leaning in this >>>> direction >>>> is that now everything is a task - we don't necessarily want suppression to take >>>> down >>>> the tasks that report errors or status, report to the Collector or communicate >>>> with the >>>> Controller etc. If we did this though we'd also need to say whether this can be >>>> over- >>>> ridden by actually specifying the task name in the task list to be suppressed. >>>>> Would it not make more sense to state that tasks not involved in >>>>> measurements are always not suppressible? Adding more flags and >>>>> special cases all adds complexity. Does every implementation have to >>>>> support the 'suppressible' flag on all tasks? Or is that something an >>>>> implementation can hardwire (even to the extreme where nothing is >>>>> suppressible)? How do I learn whether a certain task can be >>>>> suppressable for a given implementation - by trial and error? It is >>>>> all these little details that increase complexity for something that >>>>> ought to be simple and used only in rare situations... >>>>> >>>>> /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 >>>> -- >>>> Open WebMail Project (http://openwebmail.org) >>> _______________________________________________ >>> 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 -- 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 Tue May 20 12:00: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 043C61A0838 for ; Tue, 20 May 2014 12:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 CxOFSZ0jcnDR for ; Tue, 20 May 2014 12:00:35 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0211A0816 for ; Tue, 20 May 2014 12:00:30 -0700 (PDT) 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 d46ab735.0.551309.00-2390.1434736.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 20 May 2014 19:00:30 +0000 (UTC) X-MXL-Hash: 537ba64e60418784-f2a73a2708be8497e7b99f89982a38160561b0d1 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 s4KJ0SvV006921 for ; Tue, 20 May 2014 15:00:29 -0400 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 s4KJ0O8N006898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 May 2014 15:00:24 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi131.aldc.att.com (RSA Interceptor) for ; Tue, 20 May 2014 19:00:04 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, 20 May 2014 15:00:03 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: framework comment on Configuration Protocol Thread-Index: Ac90XaqNn5JR2K7dTaqbtpxndb65Cw== Date: Tue, 20 May 2014 19:00:03 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130439717@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.158.40] 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=HL104PRv c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=BmS2ixebKigA:10 a=ofMgfj31e3cA:10 a=FVNa4LjnvJ0A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=_-walNG8AjDIyPpNl3UA:9 a=CjuIK1q_8ugA:10 a=jfyKu5] X-AnalysisOut: [mUg4Ke-vhW:21 a=MzkXejUjnBsOljjR:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/UvEe6G4uZ_NUfZj5liODlFOHcvc Subject: [lmap] framework comment on Configuration Protocol 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, 20 May 2014 19:00:37 -0000 I've been reading back over the framework document (all words, not just loo= king for where I had comments) and saw the introduction of a new protocol: = the Configuration Protocol. This is described as a protocol between the Con= troller and the MA that isn't the Control Protocol. Elsewhere in framework,= there's still just mention of Control and Report Protocols as being the pr= otocols LMAP is working on. e.g., Other LMAP specifications will define an information model, the associated data models, and select/extend one or more protocols for the secure communication: firstly, a Control Protocol, from a Controller to instruct Measurement Agents what performance metrics to measure, when to measure them, how/when to report the measurement results to a Collector; secondly, a Report Protocol, for a Measurement Agent to report the results to the Collector. I'm really confused about whether LMAP is now intending to define a 3rd pro= tocol (not in its charter) and don't think there's been a lot of discussion= on the list about this new protocol. Why can configuration not be supporte= d by the Control Protocol? Barbara From nobody Tue May 20 12:12: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 1AA211A0390 for ; Tue, 20 May 2014 12:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 7PuKNB6LsvMX for ; Tue, 20 May 2014 12:12:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2AF71A01BB for ; Tue, 20 May 2014 12:12:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 01D4D6D7; Tue, 20 May 2014 21:12:54 +0200 (CEST) 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 hHX7B5YFTtFg; Tue, 20 May 2014 21:12:53 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 20 May 2014 21:12:53 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F18D20017; Tue, 20 May 2014 21:12:53 +0200 (CEST) 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 sSuKKas_gz7T; Tue, 20 May 2014 21:12:52 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5F0D20013; Tue, 20 May 2014 21:12:51 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 977C82CEC09C; Tue, 20 May 2014 21:12:50 +0200 (CEST) Date: Tue, 20 May 2014 21:12:49 +0200 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20140520191248.GA83689@elstar.jacobs.jacobs-university.de> Mail-Followup-To: trevor.burbridge@bt.com, timothy.carey@alcatel-lucent.com, marc.ibrahim@usj.edu.lb, KEN.KO@adtran.com, lmap@ietf.org References: <9966516C6EB5FC4381E05BF80AA55F7719543B25@US70UWXCHMBA05.zam.alcatel-lucent.com> <075101cf704d$42e65de0$c8b319a0$@usj.edu.lb> <9966516C6EB5FC4381E05BF80AA55F771954418D@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77195468A7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140519182341.GB80752@elstar.jacobs.jacobs-university.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/YQLuuNXQG4pqNy0m4OET0RKlp88 Cc: timothy.carey@alcatel-lucent.com, marc.ibrahim@usj.edu.lb, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 20 May 2014 19:12:58 -0000 On Tue, May 20, 2014 at 09:07:04AM +0100, trevor.burbridge@bt.com wrote: > > To do what you suggest (tasks not involved in measurements are > always not suppressible) would need some sort of flag or > classification. The MA needs some way to decide whether it is a > measurement task. The only question really is whether it is it the > registry entry (not changeable for different deployments) or in the > task configuration. I assume an implementation knows the difference between measurement tasks and tasks organizing the information flow with the controller and collector. In other words, the distinction between measurement tasks and infrastructure tasks is kind of hard-wired and not something configurable via instructions. /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 Tue May 20 12:15: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 A7DAC1A032A for ; Tue, 20 May 2014 12:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 z14l8Ug7vHJv for ; Tue, 20 May 2014 12:15:51 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7820F1A01BB for ; Tue, 20 May 2014 12:15:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F2A078B8; Tue, 20 May 2014 21:15:49 +0200 (CEST) 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 cQfjY7P9McRO; Tue, 20 May 2014 21:15:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 20 May 2014 21:15:49 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5FA3B20013; Tue, 20 May 2014 21:15:49 +0200 (CEST) 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 cKuHtoAnCWBT; Tue, 20 May 2014 21:15:46 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E0362002F; Tue, 20 May 2014 21:15:45 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 7BD632CEC0D0; Tue, 20 May 2014 21:15:45 +0200 (CEST) Date: Tue, 20 May 2014 21:15:45 +0200 From: Juergen Schoenwaelder To: marc.ibrahim@usj.edu.lb Message-ID: <20140520191545.GB83689@elstar.jacobs.jacobs-university.de> Mail-Followup-To: marc.ibrahim@usj.edu.lb, trevor.burbridge@bt.com, charles.cook2@centurylink.com, timothy.carey@alcatel-lucent.com, KEN.KO@adtran.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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/bPe9nWJ-4in-sy8L2K7MsbXTRuw Cc: timothy.carey@alcatel-lucent.com, trevor.burbridge@bt.com, charles.cook2@centurylink.com, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 20 May 2014 19:15:52 -0000 On Tue, May 20, 2014 at 07:26:55PM +0300, marc.ibrahim@usj.edu.lb wrote: > Can't we imagine a scenario where the controller would tell the MA > to stop communicating with controller for a given period of time > (maintenance or other reason...)? The question is not whether we can imagine something but whether things are worth adding additional complexity. Do any of the real world systems out there have such a feature and was it found essential? If not, lets move on. /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 Tue May 20 13:39: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 30A211A00EA for ; Tue, 20 May 2014 13:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 FEq2-DUPDVlx for ; Tue, 20 May 2014 13:39:52 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id DC7821A079B for ; Tue, 20 May 2014 13:39:47 -0700 (PDT) X-ASG-Debug-ID: 1400618570-05fac105a36e500001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id P66r5wlZzr3o26Vz; Tue, 20 May 2014 23:42:50 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from usj.edu.lb (localhost.localdomain [127.0.0.1]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4KKda7o031267; Tue, 20 May 2014 23:39:38 +0300 From: "marc.ibrahim" To: Juergen Schoenwaelder Date: Tue, 20 May 2014 23:39:36 +0300 X-ASG-Orig-Subj: Re: [lmap] Question on information model - Suppression Message-Id: <20140520203941.M5703@usj.edu.lb> In-Reply-To: <20140520191545.GB83689@elstar.jacobs.jacobs-university.de> References: <20140520191545.GB83689@elstar.jacobs.jacobs-university.de> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 37.209.253.182 (marc.ibrahim) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1400618570 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.5969 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/BEiyjHogqspqqiP3nDsCy-AlTKE Cc: timothy.carey@alcatel-lucent.com, trevor.burbridge@bt.com, charles.cook2@centurylink.com, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 20 May 2014 20:39:54 -0000 I agree JS. In fact, I was not proposing to add anything. It was just a reply to what Trevor said about that "you can't suppress the MA talking with the Controller." So, to clarify my point, I am just saying that there is no need to have additional flags and that the controller can ask suppression of any task it wants. And as you said, this distinction could be hardwired in the MA. BR, Marc. On Tue, 20 May 2014 21:15:45 +0200, Juergen Schoenwaelder wrote > On Tue, May 20, 2014 at 07:26:55PM +0300, marc.ibrahim@usj.edu.lb wrote: > > > Can't we imagine a scenario where the controller would tell the MA > > to stop communicating with controller for a given period of time > > (maintenance or other reason...)? > > The question is not whether we can imagine something but whether > things are worth adding additional complexity. Do any of the real > world systems out there have such a feature and was it found > essential? If not, lets move on. > > /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 -- Open WebMail Project (http://openwebmail.org) From nobody Tue May 20 13:39: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 613771A079B for ; Tue, 20 May 2014 13:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 gk-b12qzz4rU for ; Tue, 20 May 2014 13:39:54 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id 87A001A079C for ; Tue, 20 May 2014 13:39:48 -0700 (PDT) X-ASG-Debug-ID: 1400618570-05fac105a26e4f0001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id 0EMe9Z61B2eJvvMs; Tue, 20 May 2014 23:42:50 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from usj.edu.lb (localhost.localdomain [127.0.0.1]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4KKdalm031269; Tue, 20 May 2014 23:39:38 +0300 From: "marc.ibrahim" To: Juergen Schoenwaelder Date: Tue, 20 May 2014 23:39:36 +0300 X-ASG-Orig-Subj: Re: [lmap] Question on information model - Suppression Message-Id: <20140520201612.M41925@usj.edu.lb> In-Reply-To: <20140520191545.GB83689@elstar.jacobs.jacobs-university.de> References: <20140520191545.GB83689@elstar.jacobs.jacobs-university.de> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 37.209.253.182 (marc.ibrahim) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1400618570 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.5969 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/bYObvpxb1wkHmpNTo4ChDWd7uAQ Cc: timothy.carey@alcatel-lucent.com, trevor.burbridge@bt.com, charles.cook2@centurylink.com, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 20 May 2014 20:39:55 -0000 I agree JS. In fact, I was not proposing to add anything. It was just a reply to what Trevor said about that "you can't suppress the MA talking with the Controller." So, to clarify my point, I am just saying that there is no need to have additional flags and that the controller can ask suppression of any task it wants. And as you said, this distinction could be hardwired in the MA. BR, Marc. On Tue, 20 May 2014 21:15:45 +0200, Juergen Schoenwaelder wrote > On Tue, May 20, 2014 at 07:26:55PM +0300, marc.ibrahim@usj.edu.lb wrote: > > > Can't we imagine a scenario where the controller would tell the MA > > to stop communicating with controller for a given period of time > > (maintenance or other reason...)? > > The question is not whether we can imagine something but whether > things are worth adding additional complexity. Do any of the real > world systems out there have such a feature and was it found > essential? If not, lets move on. > > /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 -- Open WebMail Project (http://openwebmail.org) From nobody Wed May 21 01:12: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 884BF1A0831 for ; Wed, 21 May 2014 01:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=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 A_v5qZMEQTwo for ; Wed, 21 May 2014 01:12:33 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706E41A0836 for ; Wed, 21 May 2014 01:12:18 -0700 (PDT) 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; Wed, 21 May 2014 09:08:45 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.113]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 21 May 2014 09:12:08 +0100 From: To: , Date: Wed, 21 May 2014 09:12:07 +0100 Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: Ac90SFKa2oAjjiIJQp2hs2CLvu75ZgAg5BRw 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/X0STqbIAM3SXWubjuSN5yD8cknA Cc: timothy.carey@alcatel-lucent.com, j.schoenwaelder@jacobs-university.de, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Question on information model - Suppression 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, 21 May 2014 08:12:35 -0000 TWF5YmUsIGJ1dCBsZXQncyByZW1lbWJlciB0aGF0IHRoZSBDb250cm9sbGVyIGlzIGFsd2F5cyBm cmVlIHRvIGNoYW5nZSB0aGUgQ29udHJvbCBTY2hlZHVsZSBpbiB0aGUgQ29uZmlndXJhdGlvbiBp bmZvcm1hdGlvbi4NCg0KQ2hhbmdpbmcgdGhlIFNjaGVkdWxlIGlzIGFsd2F5cyBhbiBvcHRpb24g d2hlcmUgdGhlcmUgaXMgbm90IGVub3VnaCBmbGV4aWJpbGl0eSBpbiB0aGUgU3VwcHJlc3Npb24g aW5mb3JtYXRpb24uDQoNClRyZXZvci4NCg0KVHJldm9yIEJ1cmJyaWRnZQ0KDQoNCj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IG1hcmMuaWJyYWhpbUB1c2ouZWR1LmxiIFttYWls dG86bWFyYy5pYnJhaGltQHVzai5lZHUubGJdDQo+U2VudDogMjAgTWF5IDIwMTQgMTc6MjcNCj5U bzogQnVyYnJpZGdlLFQsVHJldm9yLFRVQjggUjsgY2hhcmxlcy5jb29rMkBjZW50dXJ5bGluay5j b20NCj5DYzogai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlOyB0aW1vdGh5LmNh cmV5QGFsY2F0ZWwtbHVjZW50LmNvbTsNCj5LRU4uS09AYWR0cmFuLmNvbTsgbG1hcEBpZXRmLm9y Zw0KPlN1YmplY3Q6IFJFOiBbbG1hcF0gUXVlc3Rpb24gb24gaW5mb3JtYXRpb24gbW9kZWwgLSBT dXBwcmVzc2lvbg0KPg0KPkl0IGlzIHZlcnkgY2xlYXIgbm93IFRyZXZvci4NCj5DYW4ndCB3ZSBp bWFnaW5lIGEgc2NlbmFyaW8gd2hlcmUgdGhlIGNvbnRyb2xsZXIgd291bGQgIHRlbGwgdGhlIE1B IHRvIHN0b3ANCj5jb21tdW5pY2F0aW5nIHdpdGggY29udHJvbGxlciBmb3IgYSBnaXZlbiBwZXJp b2Qgb2YgdGltZSAobWFpbnRlbmFuY2Ugb3Igb3RoZXINCj5yZWFzb24uLi4pPw0KPg0KPm1hcmMu DQo+LW9yaWdpbmFsIG1lc3NhZ2UtDQo+U3ViamVjdDogUkU6IFtsbWFwXSBRdWVzdGlvbiBvbiBp bmZvcm1hdGlvbiBtb2RlbCAtIFN1cHByZXNzaW9uDQo+RnJvbTogPHRyZXZvci5idXJicmlkZ2VA YnQuY29tPg0KPkRhdGU6IDIwLzA1LzIwMTQgMTg6NTMNCj4NCj5UaGUgY2hhbmdlIHRoYXQgd2Fz IGFncmVlZCBpbiBMb25kb24gd2FzIHRoYXQgZXZlcnl0aGluZyB3b3VsZCBiZSB0cmVhdGVkIGFz IGENCj5UYXNrIC0gbWVhbmluZyBhbHNvIHRoYXQgZXZlcnl0aGluZyBpcyBydW4gZnJvbSBhIFNj aGVkdWxlLiBUaGUgY29uc2VxdWVuY2VzIG9mDQo+dGhpcyBpcyB0aGF0IHdlIGhhdmUgYSBDb250 cm9sIFNjaGVkdWxlIHRoYXQgZXhlY3V0ZXMgdGhlIENvbnRyb2wgVGFza3MgKHRoYXQNCj5pbXBs ZW1lbnQgdGhlIENvbnRyb2wgUHJvdG9jb2wpLiBUaGlzIGlzIHNldCBpbiBwcmUtY29uZmlndXJh dGlvbiBhbmQgY2FuIGJlDQo+dXBkYXRlZCBpbiBjb25maWd1cmF0aW9uLg0KPg0KPldlIHRoZW4g aGF2ZSBzZXBhcmF0ZSBJbnN0cnVjdGlvbiBTY2hlZHVsZXMgY29udGFpbmluZyBhbGwgb3RoZXIg VGFza3MgKGUuZy4NCj5tZWFzdXJlbWVudCBhbmQgcmVwb3J0aW5nIHRhc2tzKS4gVGhlc2UgYXJl IHNldCBhcyBwYXJ0IG9mIHRoZSBJbnN0cnVjdGlvbi4NCj4NCj5UaGUgc2VwYXJhdGlvbiBvZiB0 aGVzZSB0d28gc2V0cyBvZiBpbmZvcm1hdGlvbiAobmVjZXNzYXJ5IHNpbmNlIHdlIG5lZWQgdG8N Cj5jb21tdW5pY2F0ZSBpbml0aWFsbHkgd2l0aCBhIENvbnRyb2xsZXIgYmVmb3JlIHJlY2Vpdmlu ZyBJbnN0cnVjdGlvbikgbWVhbnMgd2UNCj5jYW4gZXhwbG9pdCB0aGlzIGluIHRoZSBlZmZlY3Qg b2YgU3VwcHJlc3Npb24uIFRoaXMgaXMgd2hhdCBJIHdhcyBzdWdnZXN0aW5nIC0NCj5hbnl0aGlu ZyBpbiB0aGUgJ2NvbnRyb2wnIGluZm9ybWF0aW9uIHdvdWxkIG5vdCBiZSBzdXBwcmVzc2VkLiBp LmUuIHlvdSBjYW4ndA0KPnN1cHByZXNzIHRoZSBNQSB0YWxraW5nIHdpdGggdGhlIENvbnRyb2xs ZXIuDQo+DQo+U29ycnkgc29tZSBvZiB0aGlzIGlzIG5vdCB2ZXJ5IGNsZWFyIGFzIGl0IGlzIGFn cmVlZCBidXQgdW5wdWJsaXNoZWQgd29yaw0KPihmb3J0aGNvbWluZyBpbiByZXZpc2lvbiAwMSku DQo+DQo+VHJldm9yIEJ1cmJyaWRnZQ0KPg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj5Gcm9tOiBDaGFybGVzIENvb2sgW21haWx0bzpjaGFybGVzLmNvb2syQGNlbnR1cnlsaW5rLmNv bV0NCj4+U2VudDogMjAgTWF5IDIwMTQgMTU6NTgNCj4+VG86IEJ1cmJyaWRnZSxULFRyZXZvcixU VUI4IFINCj4+Q2M6IG1hcmMuaWJyYWhpbUB1c2ouZWR1LmxiOyBqLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGU7DQo+PnRpbW90aHkuY2FyZXlAYWxjYXRlbC1sdWNlbnQuY29tOyBL RU4uS09AYWR0cmFuLmNvbTsgbG1hcEBpZXRmLm9yZw0KPj5TdWJqZWN0OiBSZTogW2xtYXBdIFF1 ZXN0aW9uIG9uIGluZm9ybWF0aW9uIG1vZGVsIC0gU3VwcHJlc3Npb24NCj4+DQo+PlRyZXZvciwN Cj4+DQo+PkknbSBub3Qgc3VyZSB3aGF0IHRoZSBzZWNvbmQgZGFzaCBpdGVtIG1lYW5zIC0gcGFy dGljdWxhcmx5IHRoZSBmaXJzdA0KPj5oYWxmIG9mIHRoZSBpdGVtIHJlZ2FyZGluZyB0aGUgY29u dHJvbGxlciBjb21tdW5pY2F0aW9uIHNjaGVkdWxlLg0KPj5QZXJoYXBzIHlvdSBjYW4gZWxhYm9y YXRlLg0KPj4NCj4+Q2hhcmxlcw0KPj4NCj4+T24gNS8yMC8yMDE0IDI6MTQgQU0sIHRyZXZvci5i dXJicmlkZ2VAYnQuY29tIHdyb3RlOg0KPj4+IFRoaXMgaXMgd2hlcmUgSSB3YXMgdW50aWwgd2Ug aGF2ZSBldmVyeXRoaW5nIGFzIGEgdGFzay4gTWVhc3VyZW1lbnQNCj4+PiB0YXNrcywNCj4+cmVw b3J0aW5nIHRhc2tzLCBhbGFybSBjb2xsZWN0aW9uIHRhc2tzLCBJbnN0cnVjdGlvbiBmZXRjaGlu ZyB0YXNrcykuDQo+PldpdGhvdXQgc29tZSBzb3J0IG9mIHR3ZWFrIGEgc2luZ2xlICJzdXBwcmVz cyIgbWVzc2FnZSBjb3VsZCBwdXQgdGhlIE1BDQo+Pm91dCBvZiBjb21tdW5pY2F0aW9uLiBBIHNp bmdsZSBzdXBwcmVzcyBtZXNzYWdlIHdpdGhvdXQgYW4gZW5kdGltZQ0KPj53b3VsZCBwdXQgdGhl IE1BIG91dCBvZiBjb21tdW5pY2F0aW9uIHBlcm1hbmVudGx5Lg0KPj4+DQo+Pj4gVGhlIGNvbnRy b2xsZXIgY29tbXVuaWNhdGlvbiB0YXNrcyBhdCBsZWFzdCBuZWVkIHNvbWUgc29ydCBvZiBwcm90 ZWN0aW9uLg0KPj4+DQo+Pj4gTGV0IG1lIHRyeSBhbiBhbHRlcm5hdGl2ZSB0aGF0IEkgdGhpbmsg aXMgY2xvc2UgdG8gTWFyYyBhbmQgSnVlcmdlbjoNCj4+Pg0KPj4+IC0gYXMgTWFyYyBzdWdnZXN0 cyBiZWxvdyAoaS5lLiBhbGwgdGFza3MgY2FuIGJlIHN1cHByZXNzZWQgd2l0aG91dA0KPj4+IGRp c3RpbmN0aW9uKQ0KPj4+IC0gQlVUIHRoZSB0YXNrcyBydW4gaW4gdGhlIGNvbnRyb2xsZXIgY29t bXVuaWNhdGlvbiBzY2hlZHVsZSBhcmUNCj4+PiBleGVtcHQgZnJvbQ0KPj5zdXBwcmVzc2lvbi4g aS5lLiBzdXBwcmVzc2lvbiBvbmx5IGFmZmVjdHMgdGhlIEluc3RydWN0aW9uIHNjaGVkdWxlcy4N Cj4+Pg0KPj4+IFRyZXZvci4NCj4+Pg0KPj4+IFRyZXZvciBCdXJicmlkZ2UNCj4+Pg0KPj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBtYXJjLmlicmFoaW0gW21haWx0 bzptYXJjLmlicmFoaW1AdXNqLmVkdS5sYl0NCj4+Pj4gU2VudDogMTkgTWF5IDIwMTQgMjA6MTEN Cj4+Pj4gVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgQnVyYnJpZGdlLFQsVHJldm9yLFRVQjgg Ug0KPj4+PiBDYzogdGltb3RoeS5jYXJleUBhbGNhdGVsLWx1Y2VudC5jb207IEtFTi5LT0BhZHRy YW4uY29tOw0KPj4+PiBsbWFwQGlldGYub3JnDQo+Pj4+IFN1YmplY3Q6IFJlOiBbbG1hcF0gUXVl c3Rpb24gb24gaW5mb3JtYXRpb24gbW9kZWwgLSBTdXBwcmVzc2lvbg0KPj4+Pg0KPj4+PiBJIGpv aW4gVHJldm9yIGluIGNvbnNpZGVyaW5nIHRoYXQgbm8gZGlzdGluY3Rpb24gc2hvdWxkIGJlIG1h ZGUNCj4+Pj4gYmV0d2VlbiBhY3RpdmUNCj4+YW5kDQo+Pj4+IHBhc3NpdmUgdGFza3MuDQo+Pj4+ DQo+Pj4+IEZvciB0YXNrcyBzdXBwcmVzc2lvbiAoVGFza3MgYXJyYXkgaW4gc3VwcHJlc3Npb24g b2JqZWN0KSwgdGhlDQo+Pj4+IGNvbnRyb2xsZXIgaXMgZnJlZQ0KPj50bw0KPj4+PiBzcGVjaWZ5 IGFueSBraW5kIG9mIHRhc2tzIGl0IHdpc2hlcyB0byBzdXBwcmVzcy4gSWYgaXQgd2FudHMgdG8N Cj4+Pj4gc3VwcHJlc3Mgb25seQ0KPj5hY3RpdmUNCj4+Pj4gbWVhc3VyZW1lbnRzLCB0aGVuIGl0 IGp1c3QgbGlzdHMgdGhlbS4gSSBkb24ndCBzZWUgdGhhdCAiVHJldm9yDQo+Pj4+IGZsYWciIGlz IHVzZWZ1bA0KPj5oZXJlDQo+Pj4+IHNpbmNlIHRoZSBmbGFnIGFuZCB0aGUgVGFza3MgYXJyYXkg YXJlIGJvdGggdW5kZXIgdGhlIENvbnRyb2xsZXIgY29udHJvbC4NCj4+Pj4NCj4+Pj4gRm9yIHNj aGVkdWxlIHN1cHByZXNzaW9uIChTY2hlZHVsZXMgYXJyYXkpLCB0aGUgZmxhZyB3b3VsZCBtZWFu IHRoZQ0KPj5mb2xsb3dpbmc6DQo+Pj4+IGJlaW5nIGFibGUgdG8gc3VwcHJlc3MgYSBzY2hlZHVs ZSBTIHdoaWxlIGtlZXBpbmcgYSAibm9uDQo+Pj4+IHN1cHByZXNzaWJsZSIgc3Vic2V0DQo+Pm9m DQo+Pj4+IHRhc2tzIHJ1bm5pbmcgYWNjb3JkaW5nIHRvIFMuIEluIG15IG9waW5pb24sIGl0IHdp bGwgY29tcGxpY2F0ZQ0KPj4+PiB0aGluZ3MgYXMgSlMNCj4+c3RhdGVkLA0KPj4+PiBlc3BlY2lh bGx5IHRoYXQgcHJldmlvdXMgZGVjaXNpb25zIHByaXZpbGVnZWQgc2ltcGxpY2l0eS4NCj4+Pj4g SSBzZWUgdGhhdCBpZiB0aGUgY29udHJvbGxlciB3YW50cyB0byBkZWZpbmUgYSBzdWJzZXQgb2Yg Im5vbg0KPj4+PiBzdXBwcmVzc2libGUgdGFza3MsDQo+Pml0DQo+Pj4+IGNhbiBzaW1wbHkgY3Jl YXRlIGEgZGVkaWNhdGVkIHNjaGVkdWxlIGZvciB0aGVzZSB0YXNrcyBhbmQgbm90IG1peA0KPj4+ PiB0aGVtIHdpdGggb3RoZXIgc3VwcHJlc3NpYmxlIHRhc2tzLg0KPj4+Pg0KPj4+PiBCUiwNCj4+ Pj4NCj4+Pj4gTWFyYy4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gTW9uLCAxOSBNYXkgMjAx NCAyMDoyMzo0MSArMDIwMCwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdyb3RlDQo+Pj4+PiBPbiBN b24sIE1heSAxOSwgMjAxNCBhdCAwMToyODo0N1BNICswMTAwLCB0cmV2b3IuYnVyYnJpZGdlQGJ0 LmNvbQ0KPj53cm90ZToNCj4+Pj4+PiBJdCBpcyBqdXN0IG1lYW50IHRvIGJlIGFuIGV4dGVuc2lv biBvZiBzdXBwcmVzc2lvbiB0byBlbmNvbXBhc3MNCj4+Pj4+PiBjdXJyZW50bHkNCj4+Pj4gZXhl Y3V0aW5nDQo+Pj4+IHRhc2tzIGFzIHdlbGwgYXMgdGhvc2Ugc2NoZWR1bGVkIHRvIG9wZXJhdGUg aW4gZnV0dXJlLg0KPj4+Pj4+IEl0IGRvZXNuJ3QgYXQgdGhlIG1vbWVudCBtYWtlIGEganVkZ2Vt ZW50IG9uIHdoZXRoZXIgdGhhdCBzaG91bGQNCj4+Pj4+PiBiZQ0KPj4+PiBhY3RpdmUvcGFzc2l2 ZS9ub24tbWVhc3VyZW1lbnQgdGFza3Mgb3Igd2hldGhlciB0aGUgc3VwcHJlc3Npb24NCj4+Pj4g c2hvdWxkDQo+PnN0b3ANCj4+Pj4gdGhlIHRhc2sNCj4+Pj4gcnVubmluZyBvciBibG9jayBuZXR3 b3JrIHRyYWZmaWMuIFdlIHN0aWxsIG5lZWQgdG8gYWdyZWUgdGhlc2UgcG9pbnRzLg0KPj4+Pj4+ IE15IG9waW5pb24gd291bGQgZGVmaW5pdGVseSBmYXZvdXIgc3RvcHBpbmcgdGhlIHRhc2sgcnVu bmluZw0KPj4+Pj4+IHJhdGhlciB0aGFuDQo+Pj4+IHNpbXBseQ0KPj4+PiBibG9ja2luZyBuZXR3 b3JrIHRyYWZmaWMuIFNlZW1zIHNpbXBsZXIgdG8gaW1wbGVtZW50IGFuZCBzdG9wcyBhbnkNCj4+ Pj4gcG9zc2libGUgaW50ZXJhY3Rpb24gcHJvYmxlbXMgYmV0d2VlbiB0YXNrcy4NCj4+Pj4+PiBP biB0aGUgbG9uZy1zdGFuZGluZyBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgb25seSB0byBzdXBwcmVz cyBhY3RpdmUNCj4+Pj4+PiB0YXNrcywNCj4+Pj4gcGVyc29uYWxseQ0KPj4+PiBJJ2QgcmF0aGVy IG5vdCBtYWtlIGFuIGFjdGl2ZSB2cyBwYXNzaXZlIHNlbWFudGljIGRpc3RpbmN0aW9uLg0KPj4+ PiBIb3dldmVyLCBpbiB0aGUNCj4+dGFzaw0KPj4+PiBjb25maWd1cmF0aW9uIEkgYW0gbGVhbmlu ZyB0b3dhcmRzIGhhdmluZyBhbiBhcmJpdHJhcnkNCj4+Pj4gInN1cHByZXNzaWJsZSIgZmxhZw0K Pj53aGljaA0KPj4+PiB3b3VsZA0KPj4+PiBzZXJ2ZSB0aGUgc2FtZSBwdXJwb3NlIChidXQgYmUg bW9yZSBmbGV4aWJsZSkuIE9uZSByZWFzb24gSSdtDQo+Pj4+IGxlYW5pbmcgaW4gdGhpcyBkaXJl Y3Rpb24gaXMgdGhhdCBub3cgZXZlcnl0aGluZyBpcyBhIHRhc2sgLSB3ZQ0KPj4+PiBkb24ndCBu ZWNlc3NhcmlseSB3YW50IHN1cHByZXNzaW9uIHRvIHRha2UgZG93biB0aGUgdGFza3MgdGhhdA0K Pj4+PiByZXBvcnQgZXJyb3JzIG9yIHN0YXR1cywgcmVwb3J0IHRvIHRoZSBDb2xsZWN0b3Igb3Ig Y29tbXVuaWNhdGUgd2l0aA0KPj4+PiB0aGUgQ29udHJvbGxlciBldGMuIElmIHdlIGRpZCB0aGlz IHRob3VnaCB3ZSdkIGFsc28gbmVlZCB0byBzYXkNCj4+Pj4gd2hldGhlciB0aGlzIGNhbiBiZQ0K Pj4+PiBvdmVyLQ0KPj4+PiByaWRkZW4gYnkgYWN0dWFsbHkgc3BlY2lmeWluZyB0aGUgdGFzayBu YW1lIGluIHRoZSB0YXNrIGxpc3QgdG8gYmUgc3VwcHJlc3NlZC4NCj4+Pj4+IFdvdWxkIGl0IG5v dCBtYWtlIG1vcmUgc2Vuc2UgdG8gc3RhdGUgdGhhdCB0YXNrcyBub3QgaW52b2x2ZWQgaW4NCj4+ Pj4+IG1lYXN1cmVtZW50cyBhcmUgYWx3YXlzIG5vdCBzdXBwcmVzc2libGU/IEFkZGluZyBtb3Jl IGZsYWdzIGFuZA0KPj4+Pj4gc3BlY2lhbCBjYXNlcyBhbGwgYWRkcyBjb21wbGV4aXR5LiBEb2Vz IGV2ZXJ5IGltcGxlbWVudGF0aW9uIGhhdmUNCj4+Pj4+IHRvIHN1cHBvcnQgdGhlICdzdXBwcmVz c2libGUnIGZsYWcgb24gYWxsIHRhc2tzPyBPciBpcyB0aGF0DQo+Pj4+PiBzb21ldGhpbmcgYW4g aW1wbGVtZW50YXRpb24gY2FuIGhhcmR3aXJlIChldmVuIHRvIHRoZSBleHRyZW1lIHdoZXJlDQo+ Pj4+PiBub3RoaW5nIGlzIHN1cHByZXNzaWJsZSk/IEhvdyBkbyBJIGxlYXJuIHdoZXRoZXIgYSBj ZXJ0YWluIHRhc2sgY2FuDQo+Pj4+PiBiZSBzdXBwcmVzc2FibGUgZm9yIGEgZ2l2ZW4gaW1wbGVt ZW50YXRpb24gLSBieSB0cmlhbCBhbmQgZXJyb3I/IEl0DQo+Pj4+PiBpcyBhbGwgdGhlc2UgbGl0 dGxlIGRldGFpbHMgdGhhdCBpbmNyZWFzZSBjb21wbGV4aXR5IGZvciBzb21ldGhpbmcNCj4+Pj4+ IHRoYXQgb3VnaHQgdG8gYmUgc2ltcGxlIGFuZCB1c2VkIG9ubHkgaW4gcmFyZSBzaXR1YXRpb25z Li4uDQo+Pj4+Pg0KPj4+Pj4gL2pzDQo+Pj4+Pg0KPj4+Pj4gLS0NCj4+Pj4+IEp1ZXJnZW4gU2No b2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+Pj4+ PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5IEJy ZW1lbiwgR2VybWFueQ0KPj4+Pj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0 cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IGxtYXAgbWFpbGluZyBs aXN0DQo+Pj4+PiBsbWFwQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xtYXANCj4+Pj4NCj4+Pj4gLS0NCj4+Pj4gT3BlbiBXZWJNYWlsIFByb2pl Y3QgKGh0dHA6Ly9vcGVud2VibWFpbC5vcmcpDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBsbWFwIG1haWxpbmcgbGlzdA0KPj4+IGxtYXBA aWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXAN Cj4+DQo+Pi0tDQo+Pg0KPj5DaGFybGVzIENvb2sNCj4+UHJpbmNpcGFsIEFyY2hpdGVjdA0KPj5O ZXR3b3JrDQo+PjUzMjUgWnVuaSBTdHJlZXQ7IFN1aXRlIDIyNA0KPj5EZW52ZXIsIENPICA4MDIy MQ0KPj5UZWw6ICAzMDMuOTkyLjg5NTIgIEZheDogIDkyNS4yODEuMDY2Mg0KPj5jaGFybGVzLmNv b2syQGNlbnR1cnlsaW5rLmNvbQ0KPg0KDQo= From nobody Wed May 21 04:54: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 BB8D61A056D for ; Wed, 21 May 2014 04:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, 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 RPsa8nyCVoWW for ; Wed, 21 May 2014 04:54:05 -0700 (PDT) Received: from p02c11o145.mxlogic.net (p02c11o145.mxlogic.net [208.65.144.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740891A0564 for ; Wed, 21 May 2014 04:54:05 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c11o145.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id cd39c735.2b736ca40940.5607.00-570.13880.p02c11o145.mxlogic.net (envelope-from ); Wed, 21 May 2014 05:54:04 -0600 (MDT) X-MXL-Hash: 537c93dc56add994-9da7c0fc5667a525736841e0f6fa6feb8ecb3c40 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c11o145.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id 3d39c735.0.5572.00-299.13787.p02c11o145.mxlogic.net (envelope-from ); Wed, 21 May 2014 05:54:02 -0600 (MDT) X-MXL-Hash: 537c93da01889567-6584df67417d5f48d38a06ad06319228713fddff 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, 21 May 2014 06:53:54 -0500 From: KEN KO To: "trevor.burbridge@bt.com" , "marc.ibrahim@usj.edu.lb" , "charles.cook2@centurylink.com" Thread-Topic: [lmap] Question on information model - Suppression Thread-Index: AQHPdEhQIGCze/cYSYq4/GSTku1dFJtLA/eA///qJLA= Date: Wed, 21 May 2014 11:53:54 +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.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=DaGZq5dW c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=8U0ojwJlBgkA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=y1pov1uI18EA:10 a=BLceEmwcHowA:10 a=IkcTkHD] X-AnalysisOut: [0fZMA:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=e9qsufxtAAAA:8 a=J_N6KFswAAAA:8 a=gxZvrgisAAAA:8 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=NMdtWtFZAAAA:8 a=zktjWajTn] X-AnalysisOut: [PywsdBpBeQA:9 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOx] X-AnalysisOut: [ZJtCQA:10 a=fK2py77DiAcA:10 a=pjBFNBMRyLAA:10 a=W1qU_X6G3J] X-AnalysisOut: [8A:10 a=Pwbduc0PQ3sA:10 a=zeshHG33Dl4A:10 a=3FZX-ydVlcEA:1] X-AnalysisOut: [0 a=lZB815dzVvQA:10 a=DvnSUQUdWHYA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014052108); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/fT920CsUYnL3IYI7SBjoaC2Wlrs Cc: "timothy.carey@alcatel-lucent.com" , "j.schoenwaelder@jacobs-university.de" , "lmap@ietf.org" Subject: Re: [lmap] Question on information model - Suppression 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, 21 May 2014 11:54:07 -0000 KzENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRyZXZvci5idXJicmlkZ2VA YnQuY29tIFttYWlsdG86dHJldm9yLmJ1cmJyaWRnZUBidC5jb21dIA0KU2VudDogV2VkbmVzZGF5 LCBNYXkgMjEsIDIwMTQgNDoxMiBBTQ0KVG86IG1hcmMuaWJyYWhpbUB1c2ouZWR1LmxiOyBjaGFy bGVzLmNvb2syQGNlbnR1cnlsaW5rLmNvbQ0KQ2M6IGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZTsgdGltb3RoeS5jYXJleUBhbGNhdGVsLWx1Y2VudC5jb207IEtFTiBLTzsgbG1h cEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtsbWFwXSBRdWVzdGlvbiBvbiBpbmZvcm1hdGlvbiBt b2RlbCAtIFN1cHByZXNzaW9uDQoNCk1heWJlLCBidXQgbGV0J3MgcmVtZW1iZXIgdGhhdCB0aGUg Q29udHJvbGxlciBpcyBhbHdheXMgZnJlZSB0byBjaGFuZ2UgdGhlIENvbnRyb2wgU2NoZWR1bGUg aW4gdGhlIENvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24uDQoNCkNoYW5naW5nIHRoZSBTY2hlZHVs ZSBpcyBhbHdheXMgYW4gb3B0aW9uIHdoZXJlIHRoZXJlIGlzIG5vdCBlbm91Z2ggZmxleGliaWxp dHkgaW4gdGhlIFN1cHByZXNzaW9uIGluZm9ybWF0aW9uLg0KDQpUcmV2b3IuDQoNClRyZXZvciBC dXJicmlkZ2UNCg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBtYXJjLmli cmFoaW1AdXNqLmVkdS5sYiBbbWFpbHRvOm1hcmMuaWJyYWhpbUB1c2ouZWR1LmxiXQ0KPlNlbnQ6 IDIwIE1heSAyMDE0IDE3OjI3DQo+VG86IEJ1cmJyaWRnZSxULFRyZXZvcixUVUI4IFI7IGNoYXJs ZXMuY29vazJAY2VudHVyeWxpbmsuY29tDQo+Q2M6IGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZTsgDQo+dGltb3RoeS5jYXJleUBhbGNhdGVsLWx1Y2VudC5jb207IEtFTi5LT0Bh ZHRyYW4uY29tOyBsbWFwQGlldGYub3JnDQo+U3ViamVjdDogUkU6IFtsbWFwXSBRdWVzdGlvbiBv biBpbmZvcm1hdGlvbiBtb2RlbCAtIFN1cHByZXNzaW9uDQo+DQo+SXQgaXMgdmVyeSBjbGVhciBu b3cgVHJldm9yLg0KPkNhbid0IHdlIGltYWdpbmUgYSBzY2VuYXJpbyB3aGVyZSB0aGUgY29udHJv bGxlciB3b3VsZCAgdGVsbCB0aGUgTUEgdG8gDQo+c3RvcCBjb21tdW5pY2F0aW5nIHdpdGggY29u dHJvbGxlciBmb3IgYSBnaXZlbiBwZXJpb2Qgb2YgdGltZSANCj4obWFpbnRlbmFuY2Ugb3Igb3Ro ZXIgcmVhc29uLi4uKT8NCj4NCj5tYXJjLg0KPi1vcmlnaW5hbCBtZXNzYWdlLQ0KPlN1YmplY3Q6 IFJFOiBbbG1hcF0gUXVlc3Rpb24gb24gaW5mb3JtYXRpb24gbW9kZWwgLSBTdXBwcmVzc2lvbg0K PkZyb206IDx0cmV2b3IuYnVyYnJpZGdlQGJ0LmNvbT4NCj5EYXRlOiAyMC8wNS8yMDE0IDE4OjUz DQo+DQo+VGhlIGNoYW5nZSB0aGF0IHdhcyBhZ3JlZWQgaW4gTG9uZG9uIHdhcyB0aGF0IGV2ZXJ5 dGhpbmcgd291bGQgYmUgDQo+dHJlYXRlZCBhcyBhIFRhc2sgLSBtZWFuaW5nIGFsc28gdGhhdCBl dmVyeXRoaW5nIGlzIHJ1biBmcm9tIGEgDQo+U2NoZWR1bGUuIFRoZSBjb25zZXF1ZW5jZXMgb2Yg dGhpcyBpcyB0aGF0IHdlIGhhdmUgYSBDb250cm9sIFNjaGVkdWxlIA0KPnRoYXQgZXhlY3V0ZXMg dGhlIENvbnRyb2wgVGFza3MgKHRoYXQgaW1wbGVtZW50IHRoZSBDb250cm9sIFByb3RvY29sKS4g DQo+VGhpcyBpcyBzZXQgaW4gcHJlLWNvbmZpZ3VyYXRpb24gYW5kIGNhbiBiZSB1cGRhdGVkIGlu IGNvbmZpZ3VyYXRpb24uDQo+DQo+V2UgdGhlbiBoYXZlIHNlcGFyYXRlIEluc3RydWN0aW9uIFNj aGVkdWxlcyBjb250YWluaW5nIGFsbCBvdGhlciBUYXNrcyAoZS5nLg0KPm1lYXN1cmVtZW50IGFu ZCByZXBvcnRpbmcgdGFza3MpLiBUaGVzZSBhcmUgc2V0IGFzIHBhcnQgb2YgdGhlIEluc3RydWN0 aW9uLg0KPg0KPlRoZSBzZXBhcmF0aW9uIG9mIHRoZXNlIHR3byBzZXRzIG9mIGluZm9ybWF0aW9u IChuZWNlc3Nhcnkgc2luY2Ugd2UgDQo+bmVlZCB0byBjb21tdW5pY2F0ZSBpbml0aWFsbHkgd2l0 aCBhIENvbnRyb2xsZXIgYmVmb3JlIHJlY2VpdmluZyANCj5JbnN0cnVjdGlvbikgbWVhbnMgd2Ug Y2FuIGV4cGxvaXQgdGhpcyBpbiB0aGUgZWZmZWN0IG9mIFN1cHByZXNzaW9uLiANCj5UaGlzIGlz IHdoYXQgSSB3YXMgc3VnZ2VzdGluZyAtIGFueXRoaW5nIGluIHRoZSAnY29udHJvbCcgaW5mb3Jt YXRpb24gDQo+d291bGQgbm90IGJlIHN1cHByZXNzZWQuIGkuZS4geW91IGNhbid0IHN1cHByZXNz IHRoZSBNQSB0YWxraW5nIHdpdGggdGhlIENvbnRyb2xsZXIuDQo+DQo+U29ycnkgc29tZSBvZiB0 aGlzIGlzIG5vdCB2ZXJ5IGNsZWFyIGFzIGl0IGlzIGFncmVlZCBidXQgdW5wdWJsaXNoZWQgDQo+ d29yayAoZm9ydGhjb21pbmcgaW4gcmV2aXNpb24gMDEpLg0KPg0KPlRyZXZvciBCdXJicmlkZ2UN Cj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogQ2hhcmxlcyBDb29rIFtt YWlsdG86Y2hhcmxlcy5jb29rMkBjZW50dXJ5bGluay5jb21dDQo+PlNlbnQ6IDIwIE1heSAyMDE0 IDE1OjU4DQo+PlRvOiBCdXJicmlkZ2UsVCxUcmV2b3IsVFVCOCBSDQo+PkNjOiBtYXJjLmlicmFo aW1AdXNqLmVkdS5sYjsgai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlOw0KPj50 aW1vdGh5LmNhcmV5QGFsY2F0ZWwtbHVjZW50LmNvbTsgS0VOLktPQGFkdHJhbi5jb207IGxtYXBA aWV0Zi5vcmcNCj4+U3ViamVjdDogUmU6IFtsbWFwXSBRdWVzdGlvbiBvbiBpbmZvcm1hdGlvbiBt b2RlbCAtIFN1cHByZXNzaW9uDQo+Pg0KPj5UcmV2b3IsDQo+Pg0KPj5JJ20gbm90IHN1cmUgd2hh dCB0aGUgc2Vjb25kIGRhc2ggaXRlbSBtZWFucyAtIHBhcnRpY3VsYXJseSB0aGUgZmlyc3QgDQo+ PmhhbGYgb2YgdGhlIGl0ZW0gcmVnYXJkaW5nIHRoZSBjb250cm9sbGVyIGNvbW11bmljYXRpb24g c2NoZWR1bGUuDQo+PlBlcmhhcHMgeW91IGNhbiBlbGFib3JhdGUuDQo+Pg0KPj5DaGFybGVzDQo+ Pg0KPj5PbiA1LzIwLzIwMTQgMjoxNCBBTSwgdHJldm9yLmJ1cmJyaWRnZUBidC5jb20gd3JvdGU6 DQo+Pj4gVGhpcyBpcyB3aGVyZSBJIHdhcyB1bnRpbCB3ZSBoYXZlIGV2ZXJ5dGhpbmcgYXMgYSB0 YXNrLiBNZWFzdXJlbWVudCANCj4+PiB0YXNrcywNCj4+cmVwb3J0aW5nIHRhc2tzLCBhbGFybSBj b2xsZWN0aW9uIHRhc2tzLCBJbnN0cnVjdGlvbiBmZXRjaGluZyB0YXNrcykuDQo+PldpdGhvdXQg c29tZSBzb3J0IG9mIHR3ZWFrIGEgc2luZ2xlICJzdXBwcmVzcyIgbWVzc2FnZSBjb3VsZCBwdXQg dGhlIA0KPj5NQSBvdXQgb2YgY29tbXVuaWNhdGlvbi4gQSBzaW5nbGUgc3VwcHJlc3MgbWVzc2Fn ZSB3aXRob3V0IGFuIGVuZHRpbWUgDQo+PndvdWxkIHB1dCB0aGUgTUEgb3V0IG9mIGNvbW11bmlj YXRpb24gcGVybWFuZW50bHkuDQo+Pj4NCj4+PiBUaGUgY29udHJvbGxlciBjb21tdW5pY2F0aW9u IHRhc2tzIGF0IGxlYXN0IG5lZWQgc29tZSBzb3J0IG9mIHByb3RlY3Rpb24uDQo+Pj4NCj4+PiBM ZXQgbWUgdHJ5IGFuIGFsdGVybmF0aXZlIHRoYXQgSSB0aGluayBpcyBjbG9zZSB0byBNYXJjIGFu ZCBKdWVyZ2VuOg0KPj4+DQo+Pj4gLSBhcyBNYXJjIHN1Z2dlc3RzIGJlbG93IChpLmUuIGFsbCB0 YXNrcyBjYW4gYmUgc3VwcHJlc3NlZCB3aXRob3V0DQo+Pj4gZGlzdGluY3Rpb24pDQo+Pj4gLSBC VVQgdGhlIHRhc2tzIHJ1biBpbiB0aGUgY29udHJvbGxlciBjb21tdW5pY2F0aW9uIHNjaGVkdWxl IGFyZSANCj4+PiBleGVtcHQgZnJvbQ0KPj5zdXBwcmVzc2lvbi4gaS5lLiBzdXBwcmVzc2lvbiBv bmx5IGFmZmVjdHMgdGhlIEluc3RydWN0aW9uIHNjaGVkdWxlcy4NCj4+Pg0KPj4+IFRyZXZvci4N Cj4+Pg0KPj4+IFRyZXZvciBCdXJicmlkZ2UNCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+PiBGcm9tOiBtYXJjLmlicmFoaW0gW21haWx0bzptYXJjLmlicmFoaW1AdXNq LmVkdS5sYl0NCj4+Pj4gU2VudDogMTkgTWF5IDIwMTQgMjA6MTENCj4+Pj4gVG86IEp1ZXJnZW4g U2Nob2Vud2FlbGRlcjsgQnVyYnJpZGdlLFQsVHJldm9yLFRVQjggUg0KPj4+PiBDYzogdGltb3Ro eS5jYXJleUBhbGNhdGVsLWx1Y2VudC5jb207IEtFTi5LT0BhZHRyYW4uY29tOyANCj4+Pj4gbG1h cEBpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogW2xtYXBdIFF1ZXN0aW9uIG9uIGluZm9ybWF0 aW9uIG1vZGVsIC0gU3VwcHJlc3Npb24NCj4+Pj4NCj4+Pj4gSSBqb2luIFRyZXZvciBpbiBjb25z aWRlcmluZyB0aGF0IG5vIGRpc3RpbmN0aW9uIHNob3VsZCBiZSBtYWRlIA0KPj4+PiBiZXR3ZWVu IGFjdGl2ZQ0KPj5hbmQNCj4+Pj4gcGFzc2l2ZSB0YXNrcy4NCj4+Pj4NCj4+Pj4gRm9yIHRhc2tz IHN1cHByZXNzaW9uIChUYXNrcyBhcnJheSBpbiBzdXBwcmVzc2lvbiBvYmplY3QpLCB0aGUgDQo+ Pj4+IGNvbnRyb2xsZXIgaXMgZnJlZQ0KPj50bw0KPj4+PiBzcGVjaWZ5IGFueSBraW5kIG9mIHRh c2tzIGl0IHdpc2hlcyB0byBzdXBwcmVzcy4gSWYgaXQgd2FudHMgdG8gDQo+Pj4+IHN1cHByZXNz IG9ubHkNCj4+YWN0aXZlDQo+Pj4+IG1lYXN1cmVtZW50cywgdGhlbiBpdCBqdXN0IGxpc3RzIHRo ZW0uIEkgZG9uJ3Qgc2VlIHRoYXQgIlRyZXZvciANCj4+Pj4gZmxhZyIgaXMgdXNlZnVsDQo+Pmhl cmUNCj4+Pj4gc2luY2UgdGhlIGZsYWcgYW5kIHRoZSBUYXNrcyBhcnJheSBhcmUgYm90aCB1bmRl ciB0aGUgQ29udHJvbGxlciBjb250cm9sLg0KPj4+Pg0KPj4+PiBGb3Igc2NoZWR1bGUgc3VwcHJl c3Npb24gKFNjaGVkdWxlcyBhcnJheSksIHRoZSBmbGFnIHdvdWxkIG1lYW4gdGhlDQo+PmZvbGxv d2luZzoNCj4+Pj4gYmVpbmcgYWJsZSB0byBzdXBwcmVzcyBhIHNjaGVkdWxlIFMgd2hpbGUga2Vl cGluZyBhICJub24gDQo+Pj4+IHN1cHByZXNzaWJsZSIgc3Vic2V0DQo+Pm9mDQo+Pj4+IHRhc2tz IHJ1bm5pbmcgYWNjb3JkaW5nIHRvIFMuIEluIG15IG9waW5pb24sIGl0IHdpbGwgY29tcGxpY2F0 ZSANCj4+Pj4gdGhpbmdzIGFzIEpTDQo+PnN0YXRlZCwNCj4+Pj4gZXNwZWNpYWxseSB0aGF0IHBy ZXZpb3VzIGRlY2lzaW9ucyBwcml2aWxlZ2VkIHNpbXBsaWNpdHkuDQo+Pj4+IEkgc2VlIHRoYXQg aWYgdGhlIGNvbnRyb2xsZXIgd2FudHMgdG8gZGVmaW5lIGEgc3Vic2V0IG9mICJub24gDQo+Pj4+ IHN1cHByZXNzaWJsZSB0YXNrcywNCj4+aXQNCj4+Pj4gY2FuIHNpbXBseSBjcmVhdGUgYSBkZWRp Y2F0ZWQgc2NoZWR1bGUgZm9yIHRoZXNlIHRhc2tzIGFuZCBub3QgbWl4IA0KPj4+PiB0aGVtIHdp dGggb3RoZXIgc3VwcHJlc3NpYmxlIHRhc2tzLg0KPj4+Pg0KPj4+PiBCUiwNCj4+Pj4NCj4+Pj4g TWFyYy4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gTW9uLCAxOSBNYXkgMjAxNCAyMDoyMzo0 MSArMDIwMCwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdyb3RlDQo+Pj4+PiBPbiBNb24sIE1heSAx OSwgMjAxNCBhdCAwMToyODo0N1BNICswMTAwLCB0cmV2b3IuYnVyYnJpZGdlQGJ0LmNvbQ0KPj53 cm90ZToNCj4+Pj4+PiBJdCBpcyBqdXN0IG1lYW50IHRvIGJlIGFuIGV4dGVuc2lvbiBvZiBzdXBw cmVzc2lvbiB0byBlbmNvbXBhc3MgDQo+Pj4+Pj4gY3VycmVudGx5DQo+Pj4+IGV4ZWN1dGluZw0K Pj4+PiB0YXNrcyBhcyB3ZWxsIGFzIHRob3NlIHNjaGVkdWxlZCB0byBvcGVyYXRlIGluIGZ1dHVy ZS4NCj4+Pj4+PiBJdCBkb2Vzbid0IGF0IHRoZSBtb21lbnQgbWFrZSBhIGp1ZGdlbWVudCBvbiB3 aGV0aGVyIHRoYXQgc2hvdWxkIA0KPj4+Pj4+IGJlDQo+Pj4+IGFjdGl2ZS9wYXNzaXZlL25vbi1t ZWFzdXJlbWVudCB0YXNrcyBvciB3aGV0aGVyIHRoZSBzdXBwcmVzc2lvbiANCj4+Pj4gc2hvdWxk DQo+PnN0b3ANCj4+Pj4gdGhlIHRhc2sNCj4+Pj4gcnVubmluZyBvciBibG9jayBuZXR3b3JrIHRy YWZmaWMuIFdlIHN0aWxsIG5lZWQgdG8gYWdyZWUgdGhlc2UgcG9pbnRzLg0KPj4+Pj4+IE15IG9w aW5pb24gd291bGQgZGVmaW5pdGVseSBmYXZvdXIgc3RvcHBpbmcgdGhlIHRhc2sgcnVubmluZyAN Cj4+Pj4+PiByYXRoZXIgdGhhbg0KPj4+PiBzaW1wbHkNCj4+Pj4gYmxvY2tpbmcgbmV0d29yayB0 cmFmZmljLiBTZWVtcyBzaW1wbGVyIHRvIGltcGxlbWVudCBhbmQgc3RvcHMgYW55IA0KPj4+PiBw b3NzaWJsZSBpbnRlcmFjdGlvbiBwcm9ibGVtcyBiZXR3ZWVuIHRhc2tzLg0KPj4+Pj4+IE9uIHRo ZSBsb25nLXN0YW5kaW5nIGRpc2N1c3Npb24gb24gd2hldGhlciBvbmx5IHRvIHN1cHByZXNzIA0K Pj4+Pj4+IGFjdGl2ZSB0YXNrcywNCj4+Pj4gcGVyc29uYWxseQ0KPj4+PiBJJ2QgcmF0aGVyIG5v dCBtYWtlIGFuIGFjdGl2ZSB2cyBwYXNzaXZlIHNlbWFudGljIGRpc3RpbmN0aW9uLg0KPj4+PiBI b3dldmVyLCBpbiB0aGUNCj4+dGFzaw0KPj4+PiBjb25maWd1cmF0aW9uIEkgYW0gbGVhbmluZyB0 b3dhcmRzIGhhdmluZyBhbiBhcmJpdHJhcnkgDQo+Pj4+ICJzdXBwcmVzc2libGUiIGZsYWcNCj4+ d2hpY2gNCj4+Pj4gd291bGQNCj4+Pj4gc2VydmUgdGhlIHNhbWUgcHVycG9zZSAoYnV0IGJlIG1v cmUgZmxleGlibGUpLiBPbmUgcmVhc29uIEknbSANCj4+Pj4gbGVhbmluZyBpbiB0aGlzIGRpcmVj dGlvbiBpcyB0aGF0IG5vdyBldmVyeXRoaW5nIGlzIGEgdGFzayAtIHdlIA0KPj4+PiBkb24ndCBu ZWNlc3NhcmlseSB3YW50IHN1cHByZXNzaW9uIHRvIHRha2UgZG93biB0aGUgdGFza3MgdGhhdCAN Cj4+Pj4gcmVwb3J0IGVycm9ycyBvciBzdGF0dXMsIHJlcG9ydCB0byB0aGUgQ29sbGVjdG9yIG9y IGNvbW11bmljYXRlIA0KPj4+PiB3aXRoIHRoZSBDb250cm9sbGVyIGV0Yy4gSWYgd2UgZGlkIHRo aXMgdGhvdWdoIHdlJ2QgYWxzbyBuZWVkIHRvIA0KPj4+PiBzYXkgd2hldGhlciB0aGlzIGNhbiBi ZQ0KPj4+PiBvdmVyLQ0KPj4+PiByaWRkZW4gYnkgYWN0dWFsbHkgc3BlY2lmeWluZyB0aGUgdGFz ayBuYW1lIGluIHRoZSB0YXNrIGxpc3QgdG8gYmUgc3VwcHJlc3NlZC4NCj4+Pj4+IFdvdWxkIGl0 IG5vdCBtYWtlIG1vcmUgc2Vuc2UgdG8gc3RhdGUgdGhhdCB0YXNrcyBub3QgaW52b2x2ZWQgaW4g DQo+Pj4+PiBtZWFzdXJlbWVudHMgYXJlIGFsd2F5cyBub3Qgc3VwcHJlc3NpYmxlPyBBZGRpbmcg bW9yZSBmbGFncyBhbmQgDQo+Pj4+PiBzcGVjaWFsIGNhc2VzIGFsbCBhZGRzIGNvbXBsZXhpdHku IERvZXMgZXZlcnkgaW1wbGVtZW50YXRpb24gaGF2ZSANCj4+Pj4+IHRvIHN1cHBvcnQgdGhlICdz dXBwcmVzc2libGUnIGZsYWcgb24gYWxsIHRhc2tzPyBPciBpcyB0aGF0IA0KPj4+Pj4gc29tZXRo aW5nIGFuIGltcGxlbWVudGF0aW9uIGNhbiBoYXJkd2lyZSAoZXZlbiB0byB0aGUgZXh0cmVtZSAN Cj4+Pj4+IHdoZXJlIG5vdGhpbmcgaXMgc3VwcHJlc3NpYmxlKT8gSG93IGRvIEkgbGVhcm4gd2hl dGhlciBhIGNlcnRhaW4gDQo+Pj4+PiB0YXNrIGNhbiBiZSBzdXBwcmVzc2FibGUgZm9yIGEgZ2l2 ZW4gaW1wbGVtZW50YXRpb24gLSBieSB0cmlhbCBhbmQgDQo+Pj4+PiBlcnJvcj8gSXQgaXMgYWxs IHRoZXNlIGxpdHRsZSBkZXRhaWxzIHRoYXQgaW5jcmVhc2UgY29tcGxleGl0eSBmb3IgDQo+Pj4+ PiBzb21ldGhpbmcgdGhhdCBvdWdodCB0byBiZSBzaW1wbGUgYW5kIHVzZWQgb25seSBpbiByYXJl IHNpdHVhdGlvbnMuLi4NCj4+Pj4+DQo+Pj4+PiAvanMNCj4+Pj4+DQo+Pj4+PiAtLQ0KPj4+Pj4g SnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4g Z0dtYkgNCj4+Pj4+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcg MSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55DQo+Pj4+PiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAg ICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4+Pj4+DQo+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gbG1h cCBtYWlsaW5nIGxpc3QNCj4+Pj4+IGxtYXBAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbG1hcA0KPj4+Pg0KPj4+PiAtLQ0KPj4+PiBPcGVuIFdl Yk1haWwgUHJvamVjdCAoaHR0cDovL29wZW53ZWJtYWlsLm9yZykNCj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IGxtYXAgbWFpbGluZyBsaXN0 DQo+Pj4gbG1hcEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbG1hcA0KPj4NCj4+LS0NCj4+DQo+PkNoYXJsZXMgQ29vaw0KPj5QcmluY2lwYWwgQXJj aGl0ZWN0DQo+Pk5ldHdvcmsNCj4+NTMyNSBadW5pIFN0cmVldDsgU3VpdGUgMjI0DQo+PkRlbnZl ciwgQ08gIDgwMjIxDQo+PlRlbDogIDMwMy45OTIuODk1MiAgRmF4OiAgOTI1LjI4MS4wNjYyIGNo YXJsZXMuY29vazJAY2VudHVyeWxpbmsuY29tDQo+DQoNCg== From nobody Wed May 21 14:49: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 0DABF1A075A for ; Wed, 21 May 2014 14:49:32 -0700 (PDT) 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 EVx2aKZ37kKP for ; Wed, 21 May 2014 14:49:30 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D341A0773 for ; Wed, 21 May 2014 14:49:29 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 21 May 2014 22:49:33 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 21 May 2014 22:49:26 +0100 From: To: , Date: Wed, 21 May 2014 22:49:26 +0100 Thread-Topic: framework comment on Configuration Protocol Thread-Index: Ac90XaqNn5JR2K7dTaqbtpxndb65CwA4CC9i Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130439717@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130439717@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-GB 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/yR24UEy9_9aMg9iqZVRHGCTRC70 Subject: Re: [lmap] framework comment on Configuration Protocol 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, 21 May 2014 21:49:32 -0000 Barbara, Greg, thanks for spotting this. this is my error. indeed, you are right - configu= ration is supported by the control protocol.=20 currently on holiday - will do an update corrected version as soon as back phil ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H [bs7652@at= t.com] Sent: 20 May 2014 20:00 To: lmap@ietf.org Subject: [lmap] framework comment on Configuration Protocol I've been reading back over the framework document (all words, not just loo= king for where I had comments) and saw the introduction of a new protocol: = the Configuration Protocol. This is described as a protocol between the Con= troller and the MA that isn't the Control Protocol. Elsewhere in framework,= there's still just mention of Control and Report Protocols as being the pr= otocols LMAP is working on. e.g., Other LMAP specifications will define an information model, the associated data models, and select/extend one or more protocols for the secure communication: firstly, a Control Protocol, from a Controller to instruct Measurement Agents what performance metrics to measure, when to measure them, how/when to report the measurement results to a Collector; secondly, a Report Protocol, for a Measurement Agent to report the results to the Collector. I'm really confused about whether LMAP is now intending to define a 3rd pro= tocol (not in its charter) and don't think there's been a lot of discussion= on the list about this new protocol. Why can configuration not be supporte= d by the Control Protocol? Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Wed May 21 15:10: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 902191A0389 for ; Wed, 21 May 2014 15:10:01 -0700 (PDT) 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 aa1z3gYkiTE2 for ; Wed, 21 May 2014 15:09:59 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E451A03BC for ; Wed, 21 May 2014 15:09:58 -0700 (PDT) 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; Wed, 21 May 2014 23:10:06 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Wed, 21 May 2014 23:09:55 +0100 From: To: , , Date: Wed, 21 May 2014 23:09:55 +0100 Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: Ac9wnCImVj27fTvNQg+bOgTqZ8+I4wEon5iC Message-ID: References: <20140513172159.14622.51471.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB 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/ZeXWlK6SGwMxXxYpIbJTaosRJDc Subject: Re: [lmap] I-D Action: draft-ietf-lmap-framework-05.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: Wed, 21 May 2014 22:10:01 -0000 Greg, thanks for the reading! must vs MUST initial LMAP work vs for future study suggest leave both of these issues for the AD /IESG / RFC editor to see wha= t they prefer. configuration - thanks for spotting, sorry this is my error. it should be s= omething that the Control protocol does. definition of active measurement method & task. perhaps this could be honed= . would like to understand your comment about "coordination is optional" a = bit better. an active measurement task involves the MA measuring traffic that's been s= ent by (*) another MA, or a measurement peer. (*) or received from. there = needs to be some kind of coordination to arrange for this traffic to be sen= t. is the problem that the current words could be read to imply that the co= ordination must be directly between the MAs, whereas it could be that the c= ontroller sends a task/schedule instruction to one MA and a report instruct= ion to another MA (as in example A3 in the appendix)? thanks phil ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Greg Mirsky [gregimirsky@gm= ail.com] Sent: 16 May 2014 01:16 To: lmap@ietf.org; draft-ietf-lmap-framework@tools.ietf.org Subject: Re: [lmap] I-D Action: draft-ietf-lmap-framework-05.txt Dear Authors, et. al, please find my comments to the latest updates of the LMAP Framework documen= t below: * Use of RFC 2119. Even though the Framework document is on Informationa= l track RFC 2119 may be used. Hence my question: Do we want to turn 'must' = into MUST and so on in the document? * Section 3. I think that definition of an Active Measurement Method onl= y as "A generalization of an Active Measurement Task" is not sufficiently c= lear. Perhaps the following may be used instead by re-using or referring to= explanation of Measurement Method: Active Measurement Method - The process of measuring some performance or re= liability parameter associated with the transfer of Traffic by generating a= nd/or receiving Active Measurement Traffic. * If definition of the Active Measurement Method references use of Activ= e Measurement Traffic, then the current definition can be updated to explai= n that Active Measurement Task is realization of Active Measurement Method = among participating Measurement Agents and Measurement Peers with specific = parameters, e.g. profile of the Active Measurement Traffic. And I believe that coordination of Active Measurement Task among participat= ing MAs and/or MPs is optional. The current definition reads as it is manda= tory. I suggest to change it by splitting the sentence and making it to say= "Coordination of an Active Measurement Task among participating Measuremen= t Agents and/or Measurement Peers may be achieved by using protocols. Defin= ition of such protocols by LMAP WG is for further study." * I don't see much difference between Configuration Protocol and Control= Protocol. I think that the former supports subset of functionality of the = latter. Besides, it is not clear whether Configuration Protocol uses Contro= l Channel between Controller and a MA or not. I think this differentiation = between Configuration and Control is unnecessary. * Reference to "initial LMAP work" may be too vague as charter of the LM= AP WG will likely to change with time. Can it be changed to "NNN is for fut= ure study"? * Section 5.2 been introduced in this version. Firstly, I don't recall t= hat the WG discussed Configuration Protocol and agreed that it is essential= part of the LMAP Framework. Adding new concepts, IMO, doesn't help to pass= WG LC. Regards, Greg On Tue, May 13, 2014 at 10:21 AM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Large-Scale Measurement of Broadband Perf= ormance Working Group of the IETF. Title : A framework for large-scale measurement platforms= (LMAP) Authors : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-05.txt Pages : 54 Date : 2014-05-13 Abstract: Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (large-scale measurement platforms). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-framework-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-framework-05 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Thu May 29 05:04: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 9F1051A0084; Thu, 29 May 2014 05:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 5QBHRWQR3vAV; Thu, 29 May 2014 05:04:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580021A0687; Thu, 29 May 2014 05:04:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHK15480; Thu, 29 May 2014 12:04:34 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 13:03:47 +0100 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 13:04:06 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.103]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Thu, 29 May 2014 20:04:01 +0800 From: Vero Zheng To: "philip.eardley@bt.com" , "gregimirsky@gmail.com" , "lmap@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" , "ippm@ietf.org" Thread-Topic: [ippm][lmap] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPbs/Z2oNfQXBaEkKLgILEVAje6ptB1HIAgAlKnICADDOaMA== Date: Thu, 29 May 2014 12:04:00 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> References: <20140513172159.14622.51471.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.115] 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/v8aFcN9mI6QGTvbs7Ij4DMCdMhk Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 12:04:42 -0000 Dear Authors, et. al, Please see my comments for the latest version of LMAP framework document be= low. I also include IPPM WG in the thread since I believe its valuable. 1. Active Measurement Method I like the way Greg define the Active Measurement Method which I quote belo= w. To me, it is more intuitive to define the method as the process of measu= ring on traffic than referring to the measurement task. I also agree that the Active Measurement Traffic could also be updated acco= rdingly.=20 Active Measurement Method - The process of measuring some performance or re= liability parameter associated with the transfer of Traffic by generating a= nd/or receiving Active Measurement Traffic. 2, Passive Measurement Method The current definition says: Passive Measurement Method (Task)- A Measureme= nt Method (Task) in which a Measurement Agent observes existing traffic but= does not inject Active Measurement Traffic. The word "observe" exclude many existing measurement schemes, which are cur= rently discussed in IPPM, as passive measurement method. My suggestion is t= o define the Passive Measurement Method as following: Passive Measurement Method- The process of measuring some performance or re= liability parameter associated with the existing traffic on the network. This definition may need to be honed, but it makes a clear line between act= ive and passive. For active, you are measuring on the injected traffic. For= passive, on the other hand, you are measuring on the existing traffic on t= he network. The key point for passive measurement, imho, is you are measuring on the RE= AL traffic on the network. For specific method, you may do something more t= han just observing. Examples can be found http://tools.ietf.org/html/draft-= elkins-ippm-pdm-metrics-04 and http://tools.ietf.org/html/draft-chen-ippm-c= oloring-based-ipfpm-framework-01. But as long as you are measuring on the e= xisting traffic, your method should be consider as passive. Another benefit of this definition is it avoids the concept of "pure passiv= e", which has never be properly defined and vague. Someone may consider these so called not "pure passive" measurement method = as hybrid. But in that case the Hybrid Measurement Method itself need to be= properly defined first.=20 The discussion about hybrid happened in IPPM mainly about how to combining = active and passive. It mentions some form of hybrid, such as "combined hybr= id" and "concurrent hybrid", which I don't see these example methods fall i= n any of the category. People in IPPM is working on the Framework of Passive Measurements, we will= submit the document soon. The definition of passive measurements is very i= mportant and the coordination between two working group is essential. I bel= ieve now is the key time to have both working group looking on it. I would like the authors consider my suggestion on the definition and encou= rage discussion in the working group. BR, Vero > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: Thursday, May 22, 2014 6:10 AM > To: gregimirsky@gmail.com; lmap@ietf.org; > draft-ietf-lmap-framework@tools.ietf.org > Subject: Re: [lmap] I-D Action: draft-ietf-lmap-framework-05.txt >=20 > Greg, > thanks for the reading! >=20 > must vs MUST > initial LMAP work vs for future study >=20 > suggest leave both of these issues for the AD /IESG / RFC editor to see w= hat > they prefer. >=20 > configuration - thanks for spotting, sorry this is my error. it should be > something that the Control protocol does. >=20 > definition of active measurement method & task. perhaps this could be hon= ed. > would like to understand your comment about "coordination is optional" a = bit > better. > an active measurement task involves the MA measuring traffic that's been > sent by (*) another MA, or a measurement peer. (*) or received from. the= re > needs to be some kind of coordination to arrange for this traffic to be s= ent. is > the problem that the current words could be read to imply that the > coordination must be directly between the MAs, whereas it could be that t= he > controller sends a task/schedule instruction to one MA and a report instr= uction > to another MA (as in example A3 in the appendix)? >=20 > thanks > phil >=20 > ________________________________________ > From: lmap [lmap-bounces@ietf.org] On Behalf Of Greg Mirsky > [gregimirsky@gmail.com] > Sent: 16 May 2014 01:16 > To: lmap@ietf.org; draft-ietf-lmap-framework@tools.ietf.org > Subject: Re: [lmap] I-D Action: draft-ietf-lmap-framework-05.txt >=20 > Dear Authors, et. al, > please find my comments to the latest updates of the LMAP Framework > document below: >=20 > * Use of RFC 2119. Even though the Framework document is on > Informational track RFC 2119 may be used. Hence my question: Do we want t= o > turn 'must' into MUST and so on in the document? > * Section 3. I think that definition of an Active Measurement Method o= nly > as "A generalization of an Active Measurement Task" is not sufficiently c= lear. > Perhaps the following may be used instead by re-using or referring to > explanation of Measurement Method: >=20 > Active Measurement Method - The process of measuring some performance or > reliability parameter associated with the transfer of Traffic by generati= ng > and/or receiving Active Measurement Traffic. >=20 > * If definition of the Active Measurement Method references use of Act= ive > Measurement Traffic, then the current definition can be updated to explai= n > that Active Measurement Task is realization of Active Measurement Method > among participating Measurement Agents and Measurement Peers with > specific parameters, e.g. profile of the Active Measurement Traffic. >=20 > And I believe that coordination of Active Measurement Task among > participating MAs and/or MPs is optional. The current definition reads as= it is > mandatory. I suggest to change it by splitting the sentence and making it= to say > "Coordination of an Active Measurement Task among participating > Measurement Agents and/or Measurement Peers may be achieved by using > protocols. Definition of such protocols by LMAP WG is for further study." >=20 >=20 > * I don't see much difference between Configuration Protocol and Contr= ol > Protocol. I think that the former supports subset of functionality of the= latter. > Besides, it is not clear whether Configuration Protocol uses Control Chan= nel > between Controller and a MA or not. I think this differentiation between > Configuration and Control is unnecessary. > * Reference to "initial LMAP work" may be too vague as charter of the > LMAP WG will likely to change with time. Can it be changed to "NNN is for > future study"? > * Section 5.2 been introduced in this version. Firstly, I don't recall= that the > WG discussed Configuration Protocol and agreed that it is essential part = of the > LMAP Framework. Adding new concepts, IMO, doesn't help to pass WG LC. >=20 > Regards, > Greg >=20 >=20 > On Tue, May 13, 2014 at 10:21 AM, > > wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Large-Scale Measurement of Broadband > Performance Working Group of the IETF. >=20 > Title : A framework for large-scale measurement > platforms (LMAP) > Authors : Philip Eardley > Al Morton > Marcelo Bagnulo > Trevor Burbridge > Paul Aitken > Aamer Akhter > Filename : draft-ietf-lmap-framework-05.txt > Pages : 54 > Date : 2014-05-13 >=20 > Abstract: > Measuring broadband service on a large scale requires a description > of the logical architecture and standardisation of the key protocols > that coordinate interactions between the components. The document > presents an overall framework for large-scale measurements. It also > defines terminology for LMAP (large-scale measurement platforms). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lmap-framework-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-framework-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=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 nobody Thu May 29 05:16: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 599171A08C9; Thu, 29 May 2014 05:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 J6qBN9TeI98y; Thu, 29 May 2014 05:16:17 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EFCE1A0687; Thu, 29 May 2014 05:16:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 11314FD3; Thu, 29 May 2014 14:16:10 +0200 (CEST) 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 Tyxvkl9zk6Lc; Thu, 29 May 2014 14:16:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 29 May 2014 14:16:09 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63C9F20013; Thu, 29 May 2014 14:16:10 +0200 (CEST) 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 2JGJ0mb8uqK6; Thu, 29 May 2014 14:16:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8956920017; Thu, 29 May 2014 14:16:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D5B992D1217D; Thu, 29 May 2014 14:16:07 +0200 (CEST) Date: Thu, 29 May 2014 14:16:07 +0200 From: Juergen Schoenwaelder To: Vero Zheng Message-ID: <20140529121607.GA82518@elstar.local> Mail-Followup-To: Vero Zheng , "philip.eardley@bt.com" , "gregimirsky@gmail.com" , "lmap@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" , "ippm@ietf.org" References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/xuQq_oaCWL2f7pU63kDWZOqv_Yg Cc: "gregimirsky@gmail.com" , "philip.eardley@bt.com" , "draft-ietf-lmap-framework@tools.ietf.org" , "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt 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, 29 May 2014 12:16:19 -0000 On Thu, May 29, 2014 at 12:04:00PM +0000, Vero Zheng wrote: > Dear Authors, et. al, > > Please see my comments for the latest version of LMAP framework document below. I also include IPPM WG in the thread since I believe its valuable. > > 1. Active Measurement Method > I like the way Greg define the Active Measurement Method which I quote below. To me, it is more intuitive to define the method as the process of measuring on traffic than referring to the measurement task. > I also agree that the Active Measurement Traffic could also be updated accordingly. > > Active Measurement Method - The process of measuring some performance or reliability parameter associated with the transfer of Traffic by generating and/or receiving Active Measurement Traffic. > > 2, Passive Measurement Method > The current definition says: Passive Measurement Method (Task)- A Measurement Method (Task) in which a Measurement Agent observes existing traffic but does not inject Active Measurement Traffic. > > The word "observe" exclude many existing measurement schemes, which are currently discussed in IPPM, as passive measurement method. My suggestion is to define the Passive Measurement Method as following: > > Passive Measurement Method- The process of measuring some performance or reliability parameter associated with the existing traffic on the network. > > This definition may need to be honed, but it makes a clear line between active and passive. For active, you are measuring on the injected traffic. For passive, on the other hand, you are measuring on the existing traffic on the network. > The key point for passive measurement, imho, is you are measuring on the REAL traffic on the network. For specific method, you may do something more than just observing. Examples can be found http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-04 and http://tools.ietf.org/html/draft-chen-ippm-coloring-based-ipfpm-framework-01. But as long as you are measuring on the existing traffic, your method should be consider as passive. > But what if I have an MA passively measuring traffic that was injected (perhaps by some other MA) for the purpose of measuring it? Why is this distinction REAL vs non-REAL useful? And what is the definition of REAL of "existing traffic" anyway? If I inject measurement traffic observed by some MA, it is "existing traffic", no? /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 May 29 05:32: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 166471A08DA for ; Thu, 29 May 2014 05:32:48 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 8zNNJG08Y95J for ; Thu, 29 May 2014 05:32:45 -0700 (PDT) Received: from nm7-vm0.bullet.mail.ne1.yahoo.com (nm7-vm0.bullet.mail.ne1.yahoo.com [98.138.91.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA481A0403 for ; Thu, 29 May 2014 05:32:45 -0700 (PDT) Received: from [98.138.100.111] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 12:32:41 -0000 Received: from [98.138.88.233] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 12:32:41 -0000 Received: from [127.0.0.1] by omp1033.mail.ne1.yahoo.com with NNFMP; 29 May 2014 12:32:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 142442.16376.bm@omp1033.mail.ne1.yahoo.com Received: (qmail 51976 invoked by uid 60001); 29 May 2014 12:32:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401366761; bh=rdNU1G9Ezm2BLIxntsNQUgHIwdpbpmaeZahNl8qMBJw=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pX+dpS3uRMIUr7+KaE3lwUp+APZZUbxiul5+SCvg/X2nLD9hgI8ys4BLgzvj7gut9VFu6FEFPOjkyjYk8wGn7x3nAeUywtIARWoHqu1tMqxjfCs3I+8AjZFVWbItZxxDD1yQ4kwIsU1K+gIVDOOioXoJJWGmbF/yDBY1RYpWl6g= X-YMail-OSG: 3AOyTGIVM1lc1or9E2FnnJBe3qZnbsR4wLLSrT4GxeBQELs RgQ3v9HLzhGQIqfcS1zd8fhIa.fo_3.5Zm0ebqGP8unoBVNP257Or.dGwqqS qr944kGdWn55Xo_VsV8mLphxEjr5ChzAyU9JJgENlFDHx7v2lh61mXNmN7c2 _b.W8U4Oo21FSBpSeDNay1I84oxxBph9Y8VRvEA4wG6bzfjWoF.YjeB3Lzmf s9tZ_qOs8mRkseA2SiubdOwAKlelPbaZeMMVEkjDBLXu80y6GU2MMEaKpv6r He0VVKFQ.M7Eyp7.9Zr5Ws6O7uPB6YPjeMW6jtKjCcRzWRgtylZV4fvpdKEv P8uGig6PPCdFakb51EEy_UOvHK95gOMMCmzCLRLA_sSY4zN4ppuC8zQnsAvg pQLW4ibwi.Jl8Fen6ZABzp48Bg.N38VVvVCEtteYkCS2bKCOLItSz9NBaNwl aPiPna1tAdcnW.bEUKYZenLONJVdadA2ET4kwpzdwzOmE7KuCQbDKjc8h_y_ G35MkgCmVBSrB1JsjmhagfTXy5xumRAsxXaxpR5XifXKy2QkfsPzz6u1CsC4 K7G.Fe2ikWFH7NC2jwVZiagHHepJtNkVP7HUle9b6gYZLpnPiIxAynQ4AzdI _cg9PE6RWtgi43ZsUbsA- Received: from [24.130.37.147] by web125104.mail.ne1.yahoo.com via HTTP; Thu, 29 May 2014 05:32:40 PDT X-Rocket-MIMEInfo: 002.001, SnVlcmdlbiwKCkkgYW0gb25lIG9mIHRoZSBwZW9wbGUgd29ya2luZyB3aXRoIFZlcm8gb24gdGhlIFBhc3NpdmUgRnJhbWV3b3JrIGRyYWZ0LiDCoCBZb3VyIGNvbW1lbnRzIGFyZSB2ZXJ5IGludGVyZXN0aW5nLiDCoFBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLgoKCk9uIFRodSwgTWF5IDI5LCAyMDE0IGF0IDEyOjA0OjAwUE0gKzAwMDAsIFZlcm8gWmhlbmcgd3JvdGU6Cgo.IERlYXIgQXV0aG9ycywgZXQuIGFsLAo.IAo.IFBsZWFzZSBzZWUgbXkgY29tbWVudHMgZm9yIHRoZSBsYXRlc3QgdmVyc2kBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> Message-ID: <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> Date: Thu, 29 May 2014 05:32:40 -0700 (PDT) From: Nalini Elkins To: Juergen Schoenwaelder , Vero Zheng In-Reply-To: <20140529121607.GA82518@elstar.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-409489618-331760915-1401366760=:51380" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/HNoMk_4p4cmOBT1PfDD1GXbkVvY Cc: "ippm@ietf.org" , "lmap@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:32:48 -0000 ---409489618-331760915-1401366760=:51380 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Juergen,=0A=0AI am one of the people working with Vero on the Passive Frame= work draft. =A0 Your comments are very interesting. =A0Please see my commen= ts inline.=0A=0A=0AOn Thu, May 29, 2014 at 12:04:00PM +0000, Vero Zheng wro= te:=0A=0A> Dear Authors, et. al,=0A> =0A> Please see my comments for the la= test version of LMAP framework document below. I also include IPPM WG in th= e thread since I believe its valuable.=0A> =0A> 1. Active Measurement Metho= d=0A> I like the way Greg define the Active Measurement Method which I quot= e below. To me, it is more intuitive to define the method as the process of= measuring on traffic than referring to the measurement task.=0A> I also ag= ree that the Active Measurement Traffic could also be updated accordingly. = =0A> =0A> Active Measurement Method - The process of measuring some perform= ance or reliability parameter associated with the transfer of Traffic by ge= nerating and/or receiving Active Measurement Traffic.=0A> =0A> 2, Passive M= easurement Method=0A> The current definition says: Passive Measurement Meth= od (Task)- A Measurement Method (Task) in which a Measurement Agent observe= s existing traffic but does not inject Active Measurement Traffic.=0A> =0A>= The word "observe" exclude many existing measurement schemes, which are cu= rrently discussed in IPPM, as passive measurement method. My suggestion is = to define the Passive Measurement Method as following:=0A> =0A> Passive Mea= surement Method- The process of measuring some performance or reliability p= arameter associated with the existing traffic on the network.=0A> =0A> This= definition may need to be honed, but it makes a clear line between active = and passive. For active, you are measuring on the injected traffic. For pas= sive, on the other hand, you are measuring on the existing traffic on the n= etwork.=0A> The key point for passive measurement, imho, is you are measuri= ng on the REAL traffic on the network. For specific method, you may do some= thing more than just observing. Examples can be found http://tools.ietf.org= /html/draft-elkins-ippm-pdm-metrics-04 and http://tools.ietf.org/html/draft= -chen-ippm-coloring-based-ipfpm-framework-01. But as long as you are measur= ing on the existing traffic, your method should be consider as passive.=0A>= =0A=0A>>But what if I have an MA passively measuring traffic that was inje= cted=0A>>(perhaps by some other MA) for the purpose of measuring it? Why is= =0A>>this distinction REAL vs non-REAL useful? And what is the definition= =0A>>of REAL of "existing traffic" anyway? If I inject measurement traffic= =0A>>observed by some MA, it is "existing traffic", no?=0A=0AYes, point wel= l taken. =A0 The distinction we wanted to make is that the passive measurem= ent technique does not inject traffic. =A0 Other MA's or indeed other devic= es on the network create traffic for their own purposes, some of which may = be performance measurement. =A0We also wanted to come up with a good defini= tion for passive measurement that would work for all parties. =A0 How is th= e following?=0A=0APassive Measurement Method- The process of measuring some= performance or reliability parameter associated with the traffic on the ne= twork. =A0 The passive measurement method does not inject traffic for the p= urposes of measurement.=A0=0A=0A=0A/js=0A=0A-- =0AJuergen Schoenwaelder=A0 = =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH=0APhone: +49 421 200 3587= =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany=0AFax:=A0 +49 421 20= 0 3103=A0 =A0 =A0 =A0 =0A=0A____________= ___________________________________=0Aippm mailing list=0Aippm@ietf.org=0Ah= ttps://www.ietf.org/mailman/listinfo/ippm ---409489618-331760915-1401366760=:51380 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Juergen,

I= am one of the people working with Vero on the Passive Framework draft. &nb= sp; Your comments are very interesting.  Please see my comments inline= .


On Thu, May 29, 2014 at 12:04:00PM +0000, Vero Zheng wrote:
> Dear A= uthors, et. al,
>
> Please see my comments = for the latest version of LMAP framework document below. I also include IPP= M WG in the thread since I believe its valuable.
> > 1. Active Measurement Method
> I = like the way Greg define the Active Measurement Method which I quote below.= To me, it is more intuitive to define the method as the process of measuri= ng on traffic than referring to the measurement task.
>= ; I also agree that the Active Measurement Traffic could also be updated ac= cordingly.
>
> Active Measureme= nt Method - The process of measuring some performance or reliability parame= ter associated with the transfer of Traffic by generating and/or receiving = Active Measurement Traffic.
>
> = 2, Passive Measurement Method
> The current definition= says: Passive Measurement Method (Task)- A Measurement Method (Task) in which a Measurem= ent Agent observes existing traffic but does not inject Active Measurement = Traffic.
>
> The word "observe" = exclude many existing measurement schemes, which are currently discussed in= IPPM, as passive measurement method. My suggestion is to define the Passiv= e Measurement Method as following:
>
> Passive Measurement Method- The process of measuring some performanc= e or reliability parameter associated with the existing traffic on the netw= ork.
>
> This definition may nee= d to be honed, but it makes a clear line between active and passive. For ac= tive, you are measuring on the injected traffic. For passive, on the other = hand, you are measuring on the existing traffic on the network.
> The key point for passive measurement, imho, is you are measuri= ng on the REAL traffic on the network. For specific method, you may do something= more than just observing. Examples can be found http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-04 and http://tools.ietf.org/html/dra= ft-chen-ippm-coloring-based-ipfpm-framework-01. But as long as you are = measuring on the existing traffic, your method should be consider as passiv= e.

>

>&= gt;But what if I have an MA passively measuring traffic that was injected>>(perhaps by some other MA) for the purpose of meas= uring it? Why is
>>this distinction REAL vs non-REA= L useful? And what is the definition
>>of REAL of "= existing traffic" anyway? If I inject measurement traffic
>>observed= by some MA, it is "existing traffic", no?

Yes, point well taken.   = The distinction we wanted to make is that the passive measurement technique= does not inject traffic.   Other MA's or indeed other devices on the = network create traffic for their own purposes, some of which may be perform= ance measurement.  We also wanted to come up with a good definition fo= r passive measurement that would work for all parties.   How is the fo= llowing?

Passive Measurement Method- The= process of measuring some performance or reliability parameter associated = with the traffic on the network.   The passive measurement method does= not inject traffic for the purposes of measurement. 
=

/js

--
Juergen Schoenwaelder     =     Jacobs University Bremen gGmbH
Phone: +49= 421 200 3587        Campus Ring 1, 28759 Bremen, Germ= any
Fax:  +49 421 200 3103      &nbs= p; <http://www.jacobs-university.de/>

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



<= /div>
---409489618-331760915-1401366760=:51380-- From nobody Thu May 29 05:43: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 1F5E01A08D9; Thu, 29 May 2014 05:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 ctPRCdgrfuUD; Thu, 29 May 2014 05:43:17 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889CA1A08D1; Thu, 29 May 2014 05:43:17 -0700 (PDT) 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 26b27835.2b5eeae5d940.5008691.00-2405.13932728.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 29 May 2014 12:43:14 +0000 (UTC) X-MXL-Hash: 53872b6216ea80b2-f472562eeee0847e78ad8d3ffd1f2b2ee2e3cf4a 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 a5b27835.0.5008644.00-2308.13932586.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 29 May 2014 12:43:10 +0000 (UTC) X-MXL-Hash: 53872b5e523a9837-1be86b6fd2e9839bbed06c73de087007c4bd2d64 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 s4TCh6cV004219; Thu, 29 May 2014 08:43:06 -0400 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 s4TCgxXh004148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 08:42:59 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 29 May 2014 12:42:42 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; Thu, 29 May 2014 08:42:41 -0400 From: "STARK, BARBARA H" To: Nalini Elkins , Juergen Schoenwaelder , Vero Zheng Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPezoeqD1KZZQ5ME6R7faiciBMHptXfvJA Date: Thu, 29 May 2014 12:42:41 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> In-Reply-To: <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.61.133] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=DOA4FVxb c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=4xzyoWqC86AA:10 a=ofMgfj31e3cA:10 a=xRrNQLmB5r0A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=42alkMyE8RwhlZdHW2cA:9 a=wPNLvfGTeEIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/yfCGnXyGUkjBmFejKsWMzO7p9O4 Cc: "draft-ietf-lmap-framework@tools.ietf.org" , "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 12:43:19 -0000 /*snip*/ >>> Active Measurement Method - The process of measuring some performance o= r reliability parameter associated with the transfer of Traffic by generati= ng and/or receiving Active Measurement Traffic. >>>=20 /*snip*/ >>> Passive Measurement Method- The process of measuring some performance o= r reliability parameter associated with the existing traffic on the network= . /*snip*/ >>But what if I have an MA passively measuring traffic that was injected >>(perhaps by some other MA) for the purpose of measuring it? Why is >>this distinction REAL vs non-REAL useful? And what is the definition >>of REAL of "existing traffic" anyway? If I inject measurement traffic >>observed by some MA, it is "existing traffic", no? > Yes, point well taken. =A0 The distinction we wanted to make is that the = passive measurement technique does not inject traffic. =A0 Other MA's or in= deed other devices on the network create traffic for their own purposes, so= me of which may be performance measurement. =A0We also wanted to come up wi= th a good definition for passive measurement that would work for all partie= s. =A0 How is the following? > Passive Measurement Method- The process of measuring some performance or = reliability parameter associated with the traffic on the network. =A0 The p= assive measurement method does not inject traffic for the purposes of measu= rement.=A0 Would that mean that the definition of Active Measurement Method wouldn't i= nvolve receiving Active Measurement Traffic, and only generated (injecting)= ? Active Measurement Method - The process of measuring some performance or re= liability parameter associated with the transfer of traffic by generating A= ctive Measurement Traffic. Barbara From nobody Thu May 29 05:49: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 F0F3E1A08EF for ; Thu, 29 May 2014 05:49:28 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 XMJN1eu9PTFe for ; Thu, 29 May 2014 05:49:27 -0700 (PDT) Received: from nm17-vm2.bullet.mail.ne1.yahoo.com (nm17-vm2.bullet.mail.ne1.yahoo.com [98.138.91.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3A61A08E9 for ; Thu, 29 May 2014 05:49:27 -0700 (PDT) Received: from [98.138.100.118] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 12:49:22 -0000 Received: from [98.138.226.166] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 12:49:22 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 29 May 2014 12:49:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 878294.2594.bm@omp1067.mail.ne1.yahoo.com Received: (qmail 39824 invoked by uid 60001); 29 May 2014 12:49:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401367762; bh=C8HpfnXf2vchBylP80hRT5j+XY4NXi894zlRcNVTO2Q=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SU20qPaPvVuDiPQhcqX9DbJBVfHtZfQBbNFjnBx1uerfzuXcqiibgAJCUuJt6+hi+xhMbfkF5+Hreh8MrAAZ713mJjAtFlgFuqGHsK5WRtVs6MGB6ldPCwSexWZ0r/89oNOCLNPbGRrrrAZi9btc1E/qP5w03EE5S/4EbJBc2XQ= X-YMail-OSG: UVPUAvIVM1mOHnasa6F60o.UaAobo.pqmMEpV_qd9BhofZr 07ipmRL_LIG78uan1iDVgvqpov3oSjkIpeQHpQIOo6lXYq0p3fn9KJF1A2_S aWbUNq5RnlTwomua9z1L77cGPXR.6ABny2CtNzMgqj5uOrFdbdh_pku1KY.3 AQ3vHkN7GKDKUqohPCNELcdx3k5gjMKBt.xtAg7vnwHNfgrCPGCIAhoYuFH6 vhFc3i245mYdxLBdL9SIUTG6rENgVnfodYyuzRObDuj1uJogkNfExbY_R31b r5nfYM5igGRnN4IMGAhPepV3feSsGwPGpf486X030lApjRfgqzPYfoa_551a GawmBKnNsr3.qeeL99m_8g3FEhXoyOF6rxDCK4k4CIFdVlPOgeIk370X.Xx0 c9oq.uEEvKmU2gEu6J0H2wkkh0XZ_JaD2VoLdlquwtVG0eXv08gkwjFRStWe iHZ5DMxgO3R9OK5tz45Am2LJ16qTH7g3SgM2gywu_PFtQLnorY6vGdx9BX52 J0yLUSI02JSXxGllAVcK_01fWQBaJzZUs4TIfhGkw0DCJXkzOQH.1mA-- Received: from [24.130.37.147] by web125105.mail.ne1.yahoo.com via HTTP; Thu, 29 May 2014 05:49:22 PDT X-Rocket-MIMEInfo: 002.001, CgovKnNuaXAqLwo.Pj4gQWN0aXZlIE1lYXN1cmVtZW50IE1ldGhvZCAtIFRoZSBwcm9jZXNzIG9mIG1lYXN1cmluZyBzb21lIHBlcmZvcm1hbmNlIG9yIHJlbGlhYmlsaXR5IHBhcmFtZXRlciBhc3NvY2lhdGVkIHdpdGggdGhlIHRyYW5zZmVyIG9mIFRyYWZmaWMgYnkgZ2VuZXJhdGluZyBhbmQvb3IgcmVjZWl2aW5nIEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljLgo.Pj4gCi8qc25pcCovCj4.PiBQYXNzaXZlIE1lYXN1cmVtZW50IE1ldGhvZC0gVGhlIHByb2Nlc3Mgb2YgbWVhc3VyaW5nIHNvbWUgcGVyZm8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> Message-ID: <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> Date: Thu, 29 May 2014 05:49:22 -0700 (PDT) From: Nalini Elkins To: "STARK, BARBARA H" , Juergen Schoenwaelder , Vero Zheng In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="461871616-276586985-1401367762=:8149" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/mFHnfAzU7LcmFmuT0g-14O4rC_c Cc: "lmap@ietf.org" , "ippm@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:49:29 -0000 --461871616-276586985-1401367762=:8149 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A/*snip*/=0A>>> Active Measurement Method - The process of measuring s= ome performance or reliability parameter associated with the transfer of Tr= affic by generating and/or receiving Active Measurement Traffic.=0A>>> =0A/= *snip*/=0A>>> Passive Measurement Method- The process of measuring some per= formance or reliability parameter associated with the existing traffic on t= he network.=0A/*snip*/=0A=0A=0A>>But what if I have an MA passively measuri= ng traffic that was injected=0A>>(perhaps by some other MA) for the purpose= of measuring it? Why is=0A>>this distinction REAL vs non-REAL useful? And = what is the definition=0A>>of REAL of "existing traffic" anyway? If I injec= t measurement traffic=0A>>observed by some MA, it is "existing traffic", no= ?=0A=0A> Yes, point well taken. =A0 The distinction we wanted to make is th= at the passive measurement technique does not inject traffic. =A0 Other MA'= s or indeed other devices on the network create traffic for their own purpo= ses, some of which may be performance measurement. =A0We also wanted to com= e up with a good definition for passive measurement that would work for all= parties. =A0 How is the following?=0A=0A> Passive Measurement Method- The = process of measuring some performance or reliability parameter associated w= ith the traffic on the network. =A0 The passive measurement method does not= inject traffic for the purposes of measurement.=A0=0A=0A>>Would that mean = that the definition of Active Measurement Method wouldn't involve receiving= Active Measurement Traffic, and only generated (injecting)?=0A>>Active Mea= surement Method - The process of measuring some performance or reliability = parameter associated with the transfer of traffic by generating Active Meas= urement Traffic.=0A=0AIndeed, the word "receiving" needs to be a portion of= the Active Measurement Method definition. =A0 Thanks!=0A=0ANalini=0A=0A___= ____________________________________________=0Almap mailing list=0Almap@iet= f.org=0Ahttps://www.ietf.org/mailman/listinfo/lmap --461871616-276586985-1401367762=:8149 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

/*snip*/
>>> Active= Measurement Method - The process of measuring some performance or reliabil= ity parameter associated with the transfer of Traffic by generating and/or = receiving Active Measurement Traffic.
>>>
/*snip*/
>>> Passive Measurement Me= thod- The process of measuring some performance or reliability parameter as= sociated with the existing traffic on the network.
/*snip= */


>>But what if I have an MA passively measuring traffic th= at was injected
>>(perhaps by some other MA) for the purpose of measu= ring it? Why is
>>this distinction REAL vs non-REAL= useful? And what is the definition
>>of REAL of "e= xisting traffic" anyway? If I inject measurement traffic
= >>observed by some MA, it is "existing traffic", no?

> Yes, point well taken.   The distinction we = wanted to make is that the passive measurement technique does not inject tr= affic.   Other MA's or indeed other devices on the network create traf= fic for their own purposes, some of which may be performance measurement. &= nbsp;We also wanted to come up with a good definition for passive measureme= nt that would work for all parties.   How is the following?

> Passive Measurement Method- The process o= f measuring some performance or reliability parameter associated with the t= raffic on the network.   The passive measurement method does not inject traffic= for the purposes of measurement. 


>>Would that mean that the definition of Active Measurement= Method wouldn't involve receiving Active Measurement Traffic, and only gen= erated (injecting)?
>>Active Measurement Method - T= he process of measuring some performance or reliability parameter associate= d with the transfer of traffic by generating Active Measurement Traffic.

= Indeed, the word "receiving" needs to be a portion of the Active Measuremen= t Method definition.   Thanks!

Nalini

______________________________________________= _
lmap mailing list
lmap@ietf.org=
https://www.ietf.org/mailman/listinfo/lmap

--461871616-276586985-1401367762=:8149-- From nobody Thu May 29 05:58: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 656801A08F2; Thu, 29 May 2014 05:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 cP5TZj_EM1yj; Thu, 29 May 2014 05:58:34 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9521A08EE; Thu, 29 May 2014 05:58:33 -0700 (PDT) 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 6fe27835.2ae5fda68940.5005341.00-2404.13933980.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 29 May 2014 12:58:30 +0000 (UTC) X-MXL-Hash: 53872ef64aacc088-4c422832c3eea453d597d3145375b87364e04fdd 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 3de27835.0.5005099.00-2153.13933310.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 29 May 2014 12:58:28 +0000 (UTC) X-MXL-Hash: 53872ef455b67dba-463365691858edd461cde2e4297d4f747b5fb17b 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 s4TCvsne016542; Thu, 29 May 2014 08:57:54 -0400 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 s4TCvndG016451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 08:57:50 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (GAALPA1MSGHUB9F.itservices.sbc.com [130.8.36.92]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 29 May 2014 12:57: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; Thu, 29 May 2014 08:57:35 -0400 From: "STARK, BARBARA H" To: Nalini Elkins , Juergen Schoenwaelder , Vero Zheng Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPezoeqD1KZZQ5ME6R7faiciBMHptXfvJAgABGewD//7358A== Date: Thu, 29 May 2014 12:57:35 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> In-Reply-To: <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.61.133] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6113043D765GAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Kpj6LxqN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=4xzyoWqC86AA:10 a=ofMgfj31e3cA:10 a=xRrNQLmB5r0A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=BnEHt0n6A] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=xtI5gVI5DEpLcZdq4l0A:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=V0EhKMwcDj4A:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA] X-AnalysisOut: [:8 a=SSmOFEACAAAA:8 a=xGod8FiLjoyAThtLuPwA:9 a=gKO2Hq4RSVk] X-AnalysisOut: [A:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-AnalysisOut: [ a=tXsnliwV7b4A:10 a=ctwlYHSYHsEQeXlM:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2M69GSoIiDWv4PTVj4obcBUh1h0 Cc: "lmap@ietf.org" , "ippm@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 12:58:36 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6113043D765GAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ?? Receiving does or doesn't need to be a portion of the Active Measurement= Method definition? If a Passive Measurement Method is any method that measures traffic without= injecting traffic, doesn't that cover a Measurement Method that measures r= eceived traffic? Barbara From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com] Sent: Thursday, May 29, 2014 8:49 AM To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt /*snip*/ >>> Active Measurement Method - The process of measuring some performance o= r reliability parameter associated with the transfer of Traffic by generati= ng and/or receiving Active Measurement Traffic. >>> /*snip*/ >>> Passive Measurement Method- The process of measuring some performance o= r reliability parameter associated with the existing traffic on the network= . /*snip*/ >>But what if I have an MA passively measuring traffic that was injected >>(perhaps by some other MA) for the purpose of measuring it? Why is >>this distinction REAL vs non-REAL useful? And what is the definition >>of REAL of "existing traffic" anyway? If I inject measurement traffic >>observed by some MA, it is "existing traffic", no? > Yes, point well taken. The distinction we wanted to make is that the pa= ssive measurement technique does not inject traffic. Other MA's or indeed= other devices on the network create traffic for their own purposes, some o= f which may be performance measurement. We also wanted to come up with a g= ood definition for passive measurement that would work for all parties. H= ow is the following? > Passive Measurement Method- The process of measuring some performance or = reliability parameter associated with the traffic on the network. The pas= sive measurement method does not inject traffic for the purposes of measure= ment. >>Would that mean that the definition of Active Measurement Method wouldn't= involve receiving Active Measurement Traffic, and only generated (injectin= g)? >>Active Measurement Method - The process of measuring some performance or = reliability parameter associated with the transfer of traffic by generating= Active Measurement Traffic. Indeed, the word "receiving" needs to be a portion of the Active Measuremen= t Method definition. Thanks! Nalini _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_2D09D61DDFA73D4C884805CC7865E6113043D765GAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

?? Receiving does or does= n’t need to be a portion of the Active Measurement Method definition?=

If a Passive Measurement = Method is any method that measures traffic without injecting traffic, doesn= ’t that cover a Measurement Method that measures received traffic?

Barbara=

 <= /p>

From: Nalini E= lkins [mailto:nalini.elkins@insidethestack.com]
Sent: Thursday, May 29, 2014 8:49 AM
To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng
Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; ippm@ie= tf.org
Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.= txt

 

 

/*snip*/
>>> Active Measurement Method - The process of measuring some perf= ormance or reliability parameter associated with the transfer of Traffic by= generating and/or receiving Active Measurement Traffic.
>>>
/*snip*/
>>> Passive Measurement Method- The process of measuring some perf= ormance or reliability parameter associated with the existing traffic on th= e network.
/*snip*/



>>But what if I have an MA passively measuring traffic that was injec= ted
>>(perhaps by some other MA) for the purpose of measuring it? Why is<= br> >>this distinction REAL vs non-REAL useful? And what is the definitio= n
>>of REAL of "existing traffic" anyway? If I inject measure= ment traffic
>>observed by some MA, it is "existing traffic", no?

> Yes, point well taken.   The distinction we wanted to make is tha= t the passive measurement technique does not inject traffic.   Other M= A's or indeed other devices on the network create traffic for their own pur= poses, some of which may be performance measurement.  We also wanted to come up with a good definition for passive measure= ment that would work for all parties.   How is the following?

> Passive Measurement Method- The process of measuring some performance = or reliability parameter associated with the traffic on the network.  = The passive measurement method does not inject traffic for the purposes of= measurement. 



>>Would that mean that the definition of Active Measurement Method wo= uldn't involve receiving Active Measurement Traffic, and only generated (in= jecting)?
>>Active Measurement Method - The process of measuring some performan= ce or reliability parameter associated with the transfer of traffic by gene= rating Active Measurement Traffic.

 

Indeed, the word "receiving" needs to be = a portion of the Active Measurement Method definition.   Thanks!

Nalini

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

--_000_2D09D61DDFA73D4C884805CC7865E6113043D765GAALPA1MSGUSR9L_-- From nobody Thu May 29 06:05: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 2DFD71A08FD for ; Thu, 29 May 2014 06:05:42 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 6C4AczS-1A05 for ; Thu, 29 May 2014 06:05:40 -0700 (PDT) Received: from nm23-vm6.bullet.mail.ne1.yahoo.com (nm23-vm6.bullet.mail.ne1.yahoo.com [98.138.91.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272151A08FC for ; Thu, 29 May 2014 06:05:40 -0700 (PDT) Received: from [98.138.100.102] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 13:05:35 -0000 Received: from [98.138.89.171] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 13:05:35 -0000 Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP; 29 May 2014 13:05:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 738033.4117.bm@omp1027.mail.ne1.yahoo.com Received: (qmail 42330 invoked by uid 60001); 29 May 2014 13:05:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401368735; bh=WMM1qA0/xEtQpQX8WCncbgN+SlOuAFDitjxynJhDi7Q=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=m+EvY1QaNj1AMtCZ6t1OUYCk98F1wMOe5S7xwCJPRiF73aYBnf56IcFJyWwLjDVaP4HvbAipCb3iNE43hbt2Y76sQbgJK+jLWTupM8usYQNlzdGm+xhnc52TQugrAc1hW3KZTZpWX0WQFrefgcKiWtaTQvubzqs8nmsjo3kxpQI= X-YMail-OSG: prtH1ccVM1mmBRn4T.xG42V5CA57uUt9z86VAfV7AUx6hlO _r1GcEOVkSw8I9IcaEAruhtdIqyjs0zdWpHFebDrmPLcPR.9CsaoPalpg7GB ZtkqxYBKkYePpsSyZ7Pz056XzwmtbSVm4Yb8rjdPAF08dmxQi4oxpVPuipod UtP2odA.sFKrRMPnvDdwTajnNc53rJXTpcDFA.kZrHUk8PdsOtWRhEv_6Cup lmT6GwkXzLeCtUimSqlIDwnV1ECVHA9Nd_u_JDz9ztOG4L5pP1fYJ_N0C.PY mWRwOUMyTKwyqjSUTNYuu0lcuxjg8qrpQknksiXlFlJDajx6YLsZrIuD90po mrRe9rUHfNcGjdcgvvueeh3YveXBN6AifzRBrnGOk6np55I6gle2H0RqoJDL ZxNteC4ltlr3sOIwIJq_6NmSB65aZtkojArEspIwvz7vZI1f5co505nXjyYi yVvKMmUepmR._AGKIKiD5QJQaftCHVGc73iHy1Qj4HFj3Xrol5BC2UvArx33 cREozPEz5xG1aXtgWjFUpmmbkSIeaetm0IiFsKNnjssSSGvZTw7aSjQ-- Received: from [24.130.37.147] by web125103.mail.ne1.yahoo.com via HTTP; Thu, 29 May 2014 06:05:35 PDT X-Rocket-MIMEInfo: 002.001, wqAKIAo_PyBSZWNlaXZpbmcgZG9lcyBvciBkb2VzbuKAmXQgbmVlZCB0byBiZSBhIHBvcnRpb24gb2YgdGhlIEFjdGl2ZSBNZWFzdXJlbWVudCBNZXRob2QgZGVmaW5pdGlvbj8KPj5JZiBhIFBhc3NpdmUgTWVhc3VyZW1lbnQgTWV0aG9kIGlzIGFueSBtZXRob2QgdGhhdCBtZWFzdXJlcyB0cmFmZmljIHdpdGhvdXQgaW5qZWN0aW5nIHRyYWZmaWMsIGRvZXNu4oCZdCB0aGF0IGNvdmVyIGEgTWVhc3VyZW1lbnQgTWV0aG9kIHRoYXQgbWVhc3VyZXMgcmVjZWl2ZWQgdHJhZmZpYz8KClllcy4gwqBCdXQsIHRoZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> Message-ID: <1401368735.80092.YahooMailNeo@web125103.mail.ne1.yahoo.com> Date: Thu, 29 May 2014 06:05:35 -0700 (PDT) From: Nalini Elkins To: "STARK, BARBARA H" , Juergen Schoenwaelder , Vero Zheng In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="856753768-484919892-1401368735=:80092" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/WB3P5XVhjrsgen_FdPiOs4yxZ_M Cc: "lmap@ietf.org" , "ippm@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:05:42 -0000 --856753768-484919892-1401368735=:80092 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =C2=A0=0A =0A?? Receiving does or doesn=E2=80=99t need to be a portion of t= he Active Measurement Method definition?=0A>>If a Passive Measurement Metho= d is any method that measures traffic without injecting traffic, doesn=E2= =80=99t that cover a Measurement Method that measures received traffic?=0A= =0AYes. =C2=A0But, the "overriding desire", if you will, of the Active Meas= urement Method is to receive and measure that which it has injected. =C2=A0= Not so for the Passive.=0A=0A=C2=A0=0AFrom:Nalini Elkins [mailto:nalini.el= kins@insidethestack.com] =0ASent: Thursday, May 29, 2014 8:49 AM=0ATo: STAR= K, BARBARA H; Juergen Schoenwaelder; Vero Zheng=0ACc: draft-ietf-lmap-frame= work@tools.ietf.org; lmap@ietf.org; ippm@ietf.org=0ASubject: Re: [lmap] [ip= pm] I-D Action: draft-ietf-lmap-framework-05.txt=0A=C2=A0=0A=C2=A0=0A/*snip= */=0A>>> Active Measurement Method - The process of measuring some performa= nce or reliability parameter associated with the transfer of Traffic by gen= erating and/or receiving Active Measurement Traffic.=0A>>> =0A/*snip*/=0A>>= > Passive Measurement Method- The process of measuring some performance or = reliability parameter associated with the existing traffic on the network.= =0A/*snip*/=0A=0A=0A>>But what if I have an MA passively measuring traffic = that was injected=0A>>(perhaps by some other MA) for the purpose of measuri= ng it? Why is=0A>>this distinction REAL vs non-REAL useful? And what is the= definition=0A>>of REAL of "existing traffic" anyway? If I inject measureme= nt traffic=0A>>observed by some MA, it is "existing traffic", no?=0A=0A> Ye= s, point well taken. =C2=A0 The distinction we wanted to make is that the p= assive measurement technique does not inject traffic. =C2=A0 Other MA's or = indeed other devices on the network create traffic for their own purposes, = some of which may be performance measurement.=0A =C2=A0We also wanted to co= me up with a good definition for passive measurement that would work for al= l parties. =C2=A0 How is the following?=0A=0A> Passive Measurement Method- = The process of measuring some performance or reliability parameter associat= ed with the traffic on the network. =C2=A0 The passive measurement method d= oes not inject traffic for the purposes of measurement.=C2=A0=0A=0A=0A>>Wou= ld that mean that the definition of Active Measurement Method wouldn't invo= lve receiving Active Measurement Traffic, and only generated (injecting)?= =0A>>Active Measurement Method - The process of measuring some performance = or reliability parameter associated with the transfer of traffic by generat= ing Active Measurement Traffic.=0A=C2=A0=0AIndeed, the word "receiving" nee= ds to be a portion of the Active Measurement Method definition. =C2=A0 Than= ks!=0A=0ANalini=0A=0A_______________________________________________=0Almap= mailing list=0Almap@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/lmap --856753768-484919892-1401368735=:80092 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
 
=
=0A
=0A=0A =0A =0A=0A=0A
=0A=
=0A
?? Receiving does or d= oesn=E2=80=99t need to be a portion of the Active Measurement Method defini= tion?
=0A
>>If a Passive Measurement Method is = any method that measures traffic without injecting traffic, doesn=E2=80=99t= that cover a Measurement Method that measures received=0A traffic?<= /div> =0A

Yes.  But, the "overriding desire", if you wi= ll, of the Active Measurement Method is to receive and measure that which i= t has injected.   Not so for the Passive.

=0A
 
=0A
=0A
From:= Nalini Elkins [mailto:nalini.elkins@insidethestack.com]=0A
=0ASent:<= /b> Thursday, May 29, 2014 8:49 AM
=0ATo: STARK, BARBARA H; Juerg= en Schoenwaelder; Vero Zheng
=0ACc: draft-ietf-lmap-framework@too= ls.ietf.org; lmap@ietf.org; ippm@ietf.org
=0ASubject: Re: [lmap] = [ippm] I-D Action: draft-ietf-lmap-framework-05.txt
=0A
= =0A
=0A
 
=0A
=0A<= div>=0A
 
=0A
=0A
=0A
=0A=
=0A
/*snip*/
=0A>>> Active Measurement M= ethod - The process of measuring some performance or reliability parameter = associated with the transfer of Traffic by generating and/or receiving Acti= ve Measurement Traffic.
=0A>>>
=0A/*snip*/
=0A>>&g= t; Passive Measurement Method- The process of measuring some performance or= reliability parameter associated with the existing traffic on the network.=
=0A/*snip*/
=0A
=0A

=0A
=0A>>But what if I have an MA passively meas= uring traffic that was injected
=0A>>(perhaps by some other MA) fo= r the purpose of measuring it? Why is
=0A>>this distinction REAL v= s non-REAL useful? And what is the definition
=0A>>of REAL of "exi= sting traffic" anyway? If I inject measurement traffic
=0A>>observ= ed by some MA, it is "existing traffic", no?
=0A
=0A> Yes, point w= ell taken.   The distinction we wanted to make is that the passive mea= surement technique does not inject traffic.   Other MA's or indeed oth= er devices on the network create traffic for their own purposes, some of wh= ich may be performance measurement.=0A  We also wanted to come up with= a good definition for passive measurement that would work for all parties.=   How is the following?
=0A
=0A> Passive Measurement Method-= The process of measuring some performance or reliability parameter associa= ted with the traffic on the network.   The passive measurement method = does not inject traffic for the purposes of measurement. 
= =0A
=0A

=0A
=0A>>Would that mean that = the definition of Active Measurement Method wouldn't involve receiving Acti= ve Measurement Traffic, and only generated (injecting)?
=0A>>Activ= e Measurement Method - The process of measuring some performance or reliabi= lity parameter associated with the transfer of traffic by generating Active= Measurement Traffic.
=0A
=0A
=0A
=  
=0A
=0A
=0A
Indeed, the word "receiving" needs to be a portion of the Active Measu= rement Method definition.   Thanks!
=0A
=0ANalini
=0A
=0A_= ______________________________________________
=0Almap mailing list
= =0Almap@ietf.org
=0Ahttps:/= /www.ietf.org/mailman/listinfo/lmap
=0A
=0A
=0A<= /div>=0A
=0A
=0A
=0A
=0A=0A


=
--856753768-484919892-1401368735=:80092-- From nobody Thu May 29 06:08: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 845CE1A0908; Thu, 29 May 2014 06:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 o2G39w_73o34; Thu, 29 May 2014 06:08:17 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A05A1A08F9; Thu, 29 May 2014 06:08:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 27CA7F64; Thu, 29 May 2014 15:08:11 +0200 (CEST) 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 T4b5nu7k9EA6; Thu, 29 May 2014 15:08:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 29 May 2014 15:08:10 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6F9020017; Thu, 29 May 2014 15:08:11 +0200 (CEST) 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 w9Rj84-6bV0r; Thu, 29 May 2014 15:08:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20C4520013; Thu, 29 May 2014 15:08:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1C1FD2D1221C; Thu, 29 May 2014 15:08:10 +0200 (CEST) Date: Thu, 29 May 2014 15:08:10 +0200 From: Juergen Schoenwaelder To: "lmap@ietf.org" Message-ID: <20140529130810.GB82599@elstar.local> Mail-Followup-To: "lmap@ietf.org" , "ippm@ietf.org" References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/M7xTNN1Y9R7_UsPG8lCPsD-NyrI Cc: "ippm@ietf.org" Subject: [lmap] active and passive measurement method / task definition 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, 29 May 2014 13:08:19 -0000 Here is what we have: Passive Measurement Method (Task): A Measurement Method (Task) in which a Measurement Agent observes existing traffic but does not inject Active Measurement Traffic. What is wrong with it? We also have this: Active Measurement Method: A generalisation of an Active Measurement Task. Active Measurement Task: A Measurement Task in which a Measurement Agent creates or receives Active Measurement Traffic, by coordinating with one or more other Measurement Agents or Measurement Peers using protocols outside the initial LMAP work scope. What is wrong with it? For symmetry reasons and since it is unclear what 'generalisation' really means, one could perhaps combine the two: Active Measurement Method (Task): A Measurement Method (Task) in which a Measurement Agent creates or receives Active Measurement Traffic, by coordinating with one or more other Measurement Agents or Measurement Peers using protocols outside the initial LMAP work scope. I like the combination (since I like symmetry). But other than that, I think the definitions are fine (in particular for the purpose of LMAP). /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 May 29 06:31: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 A369E1A0904 for ; Thu, 29 May 2014 06:31:06 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 Gn3IWzLWGayC for ; Thu, 29 May 2014 06:31:05 -0700 (PDT) Received: from nm12.bullet.mail.ne1.yahoo.com (nm12.bullet.mail.ne1.yahoo.com [98.138.90.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1874B1A0903 for ; Thu, 29 May 2014 06:31:05 -0700 (PDT) Received: from [98.138.101.132] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 13:31:00 -0000 Received: from [98.138.101.175] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 13:31:00 -0000 Received: from [127.0.0.1] by omp1086.mail.ne1.yahoo.com with NNFMP; 29 May 2014 13:31:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 675843.41502.bm@omp1086.mail.ne1.yahoo.com Received: (qmail 78315 invoked by uid 60001); 29 May 2014 13:31:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401370260; bh=0F9cePMNQl+JM1MWykKUZItJdNn2ga7gSFNogAT7yjc=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kZRWUywNPET7dvZxmul6EELt6JYlGWLC/eVTmYErvydsBgP6P4lPPMvLdkp8YZlniOqru+r5pPRC+v3CijrdX2FWFWlSvX7WjHg8Poz+q5V4iHOYpV9OUHUDd5dYl/FkPZlOZPUZpj2dAHTrcO6Q61CEbFJNNCVZjdCTT87a/7M= X-YMail-OSG: BWbW8YIVM1mkpA71nWnsHU80GV131F3IKtlkexGG8_yEEDF lIXwUVwQwEVuXrHuT3sWq7REKV4je1C4Iz4D.YBGqJKzkhZyV.bD2jnOeE47 2rY46QUJ2q85dZi1c69OABemsjpoEAS4SXaQ_jmTjJyz05EwpKFagcoBUeFv o56xIUESAMGxNUeboov4vTyiAOilc9Bf2HpFH2pzp1ug7HO3Xwaj96LwqWpE 8ZGwujuBCmPsgvB_3NI5Y7Ldb3XKbCpjZ7NOA8Z1YzNKxXZmAnYpcKBe_jwU bLr6TQmLsffi8cVDkKAd..RtdBRcjUmI9bBpip88ns6LM1qOWC1V0sGi8hW0 BVUavOcncRZnexIf1GDheTuKldZEXlAhZa6trK73B6BwqwW6ADPxH2AiXsvG AHLZVvtA0E_DefiuE.0qdjTkVjjM2u6URVhZBW.K.HwRu_DeMQq4k5AUGzyM JoD6Ny_yPOHrKE9.WmrlgzQEPgo15YzidxgYkC_hPdxo3fac83fcuRZYAti6 _t1Qk_9IIkIHcgBTyITTgUSw.xbbTnXkox18qt1PuqcMho.79c4dWrisNEzf 2sgdMqpalD_pT7O4TiZyQn2zB7eZ6eYVYJDInBjWG50Q1zM5tDOplZQrV0Xq _nuaTVl0mmcU2Xc1GKLQsg.gdAdl0su4ROs3OHWcV_.yTNd09dMQpiI31ctN CHl8- Received: from [24.130.37.147] by web125105.mail.ne1.yahoo.com via HTTP; Thu, 29 May 2014 06:31:00 PDT X-Rocket-MIMEInfo: 002.001, VGhlIHByb2JsZW0gaXMgd2hhdCB0byBjb25zaWRlciBhcyAiaW5qZWN0ZWQgdHJhZmZpYyIuIMKgRm9yIGV4YW1wbGUsIG9uIG1hbnkgbmV0d29ya3MsIHZhcmlvdXMgZGV2aWNlcywgZm9yIHRoZWlyIG93biBwdXJwb3NlcyBkbyBQSU5HIGNvbW1hbmRzLiDCoCDCoFNvLCB0aGVuIGRvZXMgdGhhdCBjb252ZXJ0IHRoZSBlbnRpcmUgbWVhc3VyZW1lbnQgdG8gYWN0aXZlPwrCoApUaGFua3MsCgoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkgNjU5LTgzNjAKd3d3Lmluc2lkZXRoZXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> Message-ID: <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.com> Date: Thu, 29 May 2014 06:31:00 -0700 (PDT) From: Nalini Elkins To: "marc.ibrahim" , "STARK, BARBARA H" , Juergen Schoenwaelder , Vero Zheng In-Reply-To: <20140529130345.M94452@mail.usj.edu.lb> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="461871616-242839613-1401370260=:60566" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/EEMAnjwb5XYz5idlGo9m0QNH-Bc Cc: "draft-ietf-lmap-framework@tools.ietf.org" , "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:31:06 -0000 --461871616-242839613-1401370260=:60566 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The problem is what to consider as "injected traffic". =A0For example, on m= any networks, various devices, for their own purposes do PING commands. =A0= =A0So, then does that convert the entire measurement to active?=0A=A0=0ATh= anks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.= insidethestack.com=0A=0A=0A=0A________________________________=0A From: mar= c.ibrahim =0ATo: "STARK, BARBARA H" ; Nalini Elkins ; Juergen Schoenwaelder= ; Vero Zheng = =0ACc: "lmap@ietf.org" ; "ippm@ietf.org" ; "= draft-ietf-lmap-framework@tools.ietf.org" =0ASent: Thursday, May 29, 2014 6:14 AM=0ASubject: Re: [lmap] [ip= pm] I-D Action: draft-ietf-lmap-framework-05.txt=0A =0A=0AHi, =0A=0AI thi= nk the confusion comes from whether or not to consider individual MA.=0AFor= a single MA, measuring existing traffic is passive relatively to this give= n MA.=0ABut if this traffic was sent from another MA, then the whole method= is active since =0Asomebody has injected traffic.=0A=0AI think the definit= ions of active and passive methods are not relative to an MA but to =0Aall = MAs/MPs involved each measurement. If this is the case, "Receiving" is not = really =0Adifferent from "generating" since an MA will receive and measure = what has been =0Agenerated. =0A=0A=0ABR,=0A=0AMarc.=0A=0AOn Thu, 29 May 201= 4 12:57:35 +0000, STARK, BARBARA H wrote=0A> ?? Receiving does or doesn't n= eed to be a portion of the Active Measurement =0A> Method definition? If a = Passive Measurement Method is any method that measures =0A> traffic without= injecting traffic, doesn't that cover a Measurement Method =0A> that measu= res received traffic? Barbara=0A> =0A> From: Nalini Elkins [mailto:nalini.e= lkins@insidethestack.com]=0A> Sent: Thursday, May 29, 2014 8:49 AM=0A> To: = STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng=0A> Cc: draft-ietf-lmap= -framework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org=0A> Subject: Re: [l= map] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt=0A> =0A> /*snip*/= =0A> >>> Active Measurement Method - The process of measuring some performa= nce or =0Areliability parameter associated with the transfer of Traffic by = generating and/or =0Areceiving Active Measurement Traffic.=0A> >>>=0A> /*sn= ip*/=0A> >>> Passive Measurement Method- The process of measuring some perf= ormance or =0Areliability parameter associated with the existing traffic on= the network.=0A> /*snip*/=0A> =0A> >>But what if I have an MA passively me= asuring traffic that was injected=0A> >>(perhaps by some other MA) for the = purpose of measuring it? Why is=0A> >>this distinction REAL vs non-REAL use= ful? And what is the definition=0A> >>of REAL of "existing traffic" anyway?= If I inject measurement traffic=0A> >>observed by some MA, it is "existing= traffic", no?=0A> =0A> > Yes, point well taken.=A0 The distinction we wan= ted to make is that the passive =0Ameasurement technique does not inject tr= affic.=A0 Other MA's or indeed other devices on =0Athe network create traf= fic for their own purposes, some of which may be performance =0Ameasurement= .=A0 We also wanted to come up with a good definition for passive measureme= nt =0Athat would work for all parties.=A0 How is the following?=0A> =0A> >= Passive Measurement Method- The process of measuring some performance or r= eliability =0Aparameter associated with the traffic on the network.=A0 The= passive measurement method =0Adoes not inject traffic for the purposes of = measurement.=0A> =0A> >>Would that mean that the definition of Active Measu= rement Method wouldn't involve =0Areceiving Active Measurement Traffic, and= only generated (injecting)?=0A> >>Active Measurement Method - The process = of measuring some performance or reliability =0Aparameter associated with t= he transfer of traffic by generating Active Measurement =0ATraffic.=0A> =0A= > Indeed, the word "receiving" needs to be a portion of the Active Measurem= ent =0A> Method definition.=A0 Thanks!=0A> =0A> Nalini=0A> =0A> __________= _____________________________________=0A> lmap mailing list=0A> lmap@ietf.o= rg=0A=0A> https://www.ietf.org/mailman/listinfo/lmap= =0A=0A=0A--=0AOpen WebMail Project (http://openwebmail.org=0A) --461871616-242839613-1401370260=:60566 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The problem is what t= o consider as "injected traffic".  For example, on many networks, vari= ous devices, for their own purposes do PING commands.    So, then= does that convert the entire measurement to active?
 
Thanks,


Nalini ElkinsInside Products, Inc.
(831) 659-8360
www.insidethestack.com

From: mar= c.ibrahim <marc.ibrahim@usj.edu.lb>
To: "STARK, BARBARA H" <bs7652@att.com>; Nalini E= lkins <nalini.elkins@insidethestack.com>; Juergen Schoenwaelder <j.scho= enwaelder@jacobs-university.de>; Vero Zheng <vero.zheng@huawei.com>= ;
Cc: "lmap@ietf.org" = <lmap@ietf.org>; "ippm@ietf.org" <ippm@ietf.org>; "draft-ietf-l= map-framework@tools.ietf.org" <draft-ietf-lmap-framework@tools.ietf.org&= gt;
Sent: Thursday, M= ay 29, 2014 6:14 AM
Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt
=

Hi,
<= br clear=3D"none">I think the confusion comes from whether or not to consid= er individual MA.
For a single MA, measuring existing tra= ffic is passive relatively to this given MA.
But if this = traffic was sent from another MA, then the whole method is active since
somebody has injected traffic.

I think the definitions of active and passive methods are not rel= ative to an MA but to
all MAs/MPs involved each measurem= ent. If this is the case, "Receiving" is not really
diff= erent from "generating" since an MA will receive and measure what has been =
generated.


BR,

Marc.

On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H w= rote
> ?? Receiving does or doesn't need to be a porti= on of the Active Measurement
> Method definition? If = a Passive Measurement Method is any method that measures
> traffic without injecting traffic, doesn't that cover a Measurement M= ethod
> that measures received traffic? Barbara
>
> From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com]
= > Sent: Thursday, May 29, 2014 8:49 AM
> To: STARK,= BARBARA H; Juergen Schoenwaelder; Vero Zheng
> Cc: draft-ietf-lmap-f= ramework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org
> Subject: Re: [lmap] [ippm] I-D Action: draft-ietf= -lmap-framework-05.txt
>
> /*sni= p*/
> >>> Active Measurement Method - The pro= cess of measuring some performance or
reliability parameter associated with the transfer o= f Traffic by generating and/or
receiving Active Measurem= ent Traffic.
> >>>
> /*s= nip*/
> >>> Passive Measurement Method- The p= rocess of measuring some performance or
reliability para= meter associated with the existing traffic on the network.
> /*snip*/
>
> >>But = what if I have an MA passively measuring traffic that was injected
> >>(perhaps by some other MA) for the purpose of measur= ing it? Why is
> >>this distinction REAL vs non-= REAL useful? And what is the definition
> >>of R= EAL of "existing traffic" anyway? If I inject measurement traffic
> >>observed by some MA, it is "existing traffic", no?>
> > Yes, point well taken.  The distinction= we wanted to make is that the passive
measurement techn= ique does not inject traffic.  Other MA's or indeed other devices on =
the network create traffic for their own purposes, some = of which may be performance
measurement.  We also w= anted to come up with a good definition for passive measurement
that would work for all parties.  How is the following?
>
> > Passive Measurement Method= - The process of measuring some performance or reliability
parameter associated with the traffic on the network.  The passive= measurement method
does not inject traffic for the purp= oses of measurement.
>
> >>= ;Would that mean that the definition of Active Measurement Method wouldn't = involve
receiving Active Measurement Traffic, and only generated (i= njecting)?
> >>Active Measurement Method - The p= rocess of measuring some performance or reliability
para= meter associated with the transfer of traffic by generating Active Measurem= ent
Traffic.
>
&= gt; Indeed, the word "receiving" needs to be a portion of the Active Measur= ement
> Method definition.  Thanks!
>
> Nalini
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org= <mailto:lmap@ietf.org>


--
Open W= ebMail Project (http://openwebmail.org
)



--461871616-242839613-1401370260=:60566-- From nobody Thu May 29 06:36: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 268AC1A0909; Thu, 29 May 2014 06:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 vc3c8R_sWZMU; Thu, 29 May 2014 06:36:39 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666021A0916; Thu, 29 May 2014 06:36:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 84511FC4; Thu, 29 May 2014 15:36:29 +0200 (CEST) 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 y5Xb6wqzdBh3; Thu, 29 May 2014 15:36:23 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 29 May 2014 15:36:29 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D65F20017; Thu, 29 May 2014 15:36:30 +0200 (CEST) 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 27pGQCkfj7tR; Thu, 29 May 2014 15:36:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 091E620013; Thu, 29 May 2014 15:36:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 077512D122BF; Thu, 29 May 2014 15:36:29 +0200 (CEST) Date: Thu, 29 May 2014 15:36:28 +0200 From: Juergen Schoenwaelder To: "marc. ibrahim" Message-ID: <20140529133628.GA82746@elstar.local> Mail-Followup-To: "marc. ibrahim" , "lmap@ietf.org" , "ippm@ietf.org" References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130810.GB82599@elstar.local> <20140529131922.M26067@mail.usj.edu.lb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140529131922.M26067@mail.usj.edu.lb> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/lCzkef4SLnWKDWvJMrXOsbg0K8o Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] active and passive measurement method / task definition 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, 29 May 2014 13:36:42 -0000 On Thu, May 29, 2014 at 04:24:01PM +0300, marc. ibrahim wrote: > According to the current Passive Measurement Method definition, an MA observing an > active traffic measurement sent to it is performing a passive task. But in the same time > it is an active task according the active definition. > > As I said in my previous mail, the definitions should not be relative to a single MA. > I believe, for LMAP the definitions are good enough. In particular for a passive/active measurement _task_ since tasks are executed by MAs. It seems you want to separate out passive/active measurement _method_, right? So what is the concrete proposal? /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 May 29 06:42: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 DDF3E1A092B for ; Thu, 29 May 2014 06:42:50 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 HTTFAjyB8JWU for ; Thu, 29 May 2014 06:42:45 -0700 (PDT) Received: from nm8-vm2.bullet.mail.ne1.yahoo.com (nm8-vm2.bullet.mail.ne1.yahoo.com [98.138.90.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C481A0928 for ; Thu, 29 May 2014 06:42:45 -0700 (PDT) Received: from [98.138.100.118] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 13:42:41 -0000 Received: from [98.138.89.164] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 13:42:41 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 29 May 2014 13:42:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 170014.31499.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 55520 invoked by uid 60001); 29 May 2014 13:42:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401370961; bh=QVPaIakcs9W7GzgEAQqOlnKsjtKGJEB8zd1t34m1jPU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eJyS4m4CGPIqi5yVLFqMeRZ0t2YaKEP3G2w9tGhmR6Ec0KnHtvPnQvo6MB/w5e2xp4EJI3wST89Xhe2FlKD3OksfKTaDKeeZdPcnE60KiNJxN6qIEQM4ik/XvVRtdzGQPSHdqRhAy7D7qOuPp4CrvvV7HHjFk2ObJDtyGyUBvTc= X-YMail-OSG: z82QwgkVM1luz2NgkR3fSBXB0fnzKkW_EZXq0mOJhHKuXnx CxsoqXlGSE3cKNC1fwYMQawAxeznL9UtjzxZhc7Q4bO9XYCWpA4gnuz28Y2Z Ck8IRi7Xe8jy_u1drJTTXG.B3fMCuoUEjd_co1fvLoo6clgaf5iY5mLr0CRb _Hmj61ioGAlci4_uzDhNLWZrWhKpJqCVMNOImlyFw58dZ7CXQFT3xUCMiLit Dqu7b7nBbnrSVCt_mc3GfValLFcimPq47o1rNIQjL7hzdDUE2GvjJ3v.Ttds VHgnAgY1mn3gG2euuHq5NeYExnyVdGBN3GZeNXZyz_9bGHmHVCzKl1M.i8KC GO8HMlx5Adzv0As6yccGqlyLVj9UeJP9DHDKFXDLCrHqm0B9WFpPWqJAPZA1 BebASI1LrZz8lSO0KXr7oP1EcaZw.gQ124uZZXJGxpHfAg7jaPgVQZ8VHm90 mH8JKmBKZAgYX3oiJz4t4_PxeSslpFQLc.f4eIV3b27ezx5sq29tJi.narks Z_1JZyzt47ZIHX8PUeRKjRwzsQfbRNovCZcb7H9ZrAgVxcr4wPwPlv7wbkVX xiSQ8_QZx0YXldfaCpi0l__lrZXU3P70C9RwCaKEFg486f8cuA1KkXveghZK pD7n7VD7CTxUwg4qfvO4ytuxxsGhWe5Mt8EtA1l825tegqKyBLq864.ZGxeT _hcJn3UBwAy89vXroI5miOq7ELA-- Received: from [24.130.37.147] by web125106.mail.ne1.yahoo.com via HTTP; Thu, 29 May 2014 06:42:40 PDT X-Rocket-MIMEInfo: 002.001, VHdvIGNvbW1lbnRzIG9uIHRoaXM6CgoxLiDCoEkgYmVsaWV2ZSB0aGUgY2hhcnRlciBvZiBJUFBNIGlzIHdpZGVyIHRoYW4gTE1BUDoKCiJUaGUgSVAgUGVyZm9ybWFuY2UgTWV0cmljcyAoSVBQTSkgV29ya2luZyBHcm91cCBkZXZlbG9wcyBhbmQgbWFpbnRhaW5zwqBzdGFuZGFyZCBtZXRyaWNzIHRoYXQgY2FuIGJlIGFwcGxpZWQgdG8gdGhlIHF1YWxpdHksIHBlcmZvcm1hbmNlLCBhbmTCoHJlbGlhYmlsaXR5IG9mIEludGVybmV0IGRhdGEgZGVsaXZlcnkgc2VydmljZXMgYW5kIGFwcGxpY2F0aW9ucyBydW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130810.GB82599@elstar.local> Message-ID: <1401370960.66301.YahooMailNeo@web125106.mail.ne1.yahoo.com> Date: Thu, 29 May 2014 06:42:40 -0700 (PDT) From: Nalini Elkins To: Juergen Schoenwaelder , "lmap@ietf.org" In-Reply-To: <20140529130810.GB82599@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2MoKyoS78439yyhWepu98qOlyiU Cc: "ippm@ietf.org" Subject: Re: [lmap] active and passive measurement method / task definition X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:42:51 -0000 Two comments on this:=0A=0A1. =A0I believe the charter of IPPM is wider tha= n LMAP:=0A=0A"The IP Performance Metrics (IPPM) Working Group develops and = maintains=A0standard metrics that can be applied to the quality, performanc= e, and=A0reliability of Internet data delivery services and applications ru= nning=0Aover transport layer protocols (e.g. TCP, UDP) over IP."=0A=0ASo, u= nless we are thinking of "Measurement Agent" in the abstract, then IMHO, th= e definition of Passive (and actually Active!) should not be tied at the hi= p to LMAP.=0A=0A=0A2. =A0I believe that measurement techniques which piggyb= ack a header (hjttp://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metric= s/) or coloring (http://tools.ietf.org/html/draft-chen-ippm-coloring-based-= ipfpm-framework-01) are validly passive techniques since they do not inject= traffic. =A0But, the word "observes" might preclude such methods.=0A=0A=0A= Thanks,=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.i= nsidethestack.com=0A=0A=0A=0A________________________________=0AFrom: Juerg= en Schoenwaelder =0ATo: "lmap@ietf.or= g" =0ACc: "ippm@ietf.org" =0ASent: Thursday= , May 29, 2014 6:08 AM=0ASubject: [lmap] active and passive measurement met= hod / task definition=0A=0A=0AHere is what we have:=0A=0A=A0=A0=A0Passive M= easurement Method (Task): A Measurement Method (Task) in=0A=A0=A0=A0which a= Measurement Agent observes existing traffic but does not=0A=A0=A0=A0inject= Active Measurement Traffic.=0A=0AWhat is wrong with it?=0A=0AWe also have = this:=0A=0A=A0=A0=A0Active Measurement Method: A generalisation of an Activ= e Measurement=0A=A0=A0=A0Task.=0A=0A=A0=A0=A0Active Measurement Task: A Mea= surement Task in which a Measurement=0A=A0=A0=A0Agent creates or receives A= ctive Measurement Traffic, by coordinating=0A=A0=A0=A0with one or more othe= r Measurement Agents or Measurement Peers using=0A=A0=A0=A0protocols outsid= e the initial LMAP work scope.=0A=0AWhat is wrong with it?=0A=0AFor symmetr= y reasons and since it is unclear what 'generalisation'=0Areally means, one= could perhaps combine the two:=0A=0A=A0=A0=A0Active Measurement Method (Ta= sk): A Measurement Method (Task) in=0A=A0=A0=A0which a Measurement Agent cr= eates or receives Active Measurement=0A=A0=A0=A0Traffic, by coordinating wi= th one or more other Measurement Agents=0A=A0=A0=A0or Measurement Peers usi= ng protocols outside the initial LMAP work=0A=A0=A0=A0scope.=0A=0AI like th= e combination (since I like symmetry). But other than that,=0AI think the d= efinitions are fine (in particular for the purpose of=0ALMAP).=0A=0A/js=0A= =0A-- =0AJuergen Schoenwaelder=A0 =A0 =A0 =A0 =A0=A0=A0Jacobs University Br= emen gGmbH=0APhone: +49 421 200 3587=A0 =A0 =A0 =A0=A0=A0Campus Ring 1, 287= 59 Bremen, Germany=0AFax:=A0=A0=A0+49 421 200 3103=A0 =A0 =A0 =A0=A0=A0=0A=0A=0A____________________________________= ___________=0Almap mailing list=0Almap@ietf.org=0Ahttps://www.ietf.org/mail= man/listinfo/lmap=A0 From nobody Thu May 29 07:06: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 3F1051A0950 for ; Thu, 29 May 2014 07:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 BIkrDUeKn0sG for ; Thu, 29 May 2014 07:06:47 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id A29131A094A for ; Thu, 29 May 2014 07:06:24 -0700 (PDT) X-ASG-Debug-ID: 1401372600-05fac105a3245dd0001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id pDT7BDYi0Y7zDERL; Thu, 29 May 2014 17:10:00 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from usj.edu.lb (localhost.localdomain [127.0.0.1]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4TE63PC006512; Thu, 29 May 2014 17:06:05 +0300 From: "marc.ibrahim" To: Juergen Schoenwaelder Date: Thu, 29 May 2014 17:06:03 +0300 X-ASG-Orig-Subj: Re: [lmap] active and passive measurement method / task definition Message-Id: <20140529134146.M20495@usj.edu.lb> In-Reply-To: <20140529133628.GA82746@elstar.local> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130810.GB82599@elstar.local> <20140529131922.M26067@mail.usj.edu.lb> <20140529133628.GA82746@elstar.local> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 37.209.253.165 (marc.ibrahim) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1401372600 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6210 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_RXH8lsVzTkkZwb5vufH4B92Hhs Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] active and passive measurement method / task definition 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, 29 May 2014 14:06:49 -0000 Juergen, I am just trying to discuss what I felt is unclear in the definitions. Let me give a practical example from a project i'm doing. We have MA1 sending UDP traffic to MA2. MA2 will receive UDP packet and compute jitter. This is clearly an active measurement task for MA1. What is unclear for me is how to define MA2 tasks. Is it just one active task consisting in receiving packets from MA1 and computing jitter, or two tasks: - One active task consisting in receiving the active traffic generated by MA1, - One passive task consisting in measuring jitter for the udp flow. It is passive according to the definition since MA2 does not generate the observed flow. BR, Marc. On Thu, 29 May 2014 15:36:28 +0200, Juergen Schoenwaelder wrote > On Thu, May 29, 2014 at 04:24:01PM +0300, marc. ibrahim wrote: > > According to the current Passive Measurement Method definition, an MA observing an > > active traffic measurement sent to it is performing a passive task. But in the same time > > it is an active task according the active definition. > > > > As I said in my previous mail, the definitions should not be relative to a single MA. > > > > I believe, for LMAP the definitions are good enough. In particular for > a passive/active measurement _task_ since tasks are executed by MAs. > It seems you want to separate out passive/active measurement _method_, > right? So what is the concrete proposal? > > /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 -- Open WebMail Project (http://openwebmail.org) From nobody Thu May 29 07:19: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 7824D1A0993; Thu, 29 May 2014 07:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, 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 Jr6eGGdZG-Yw; Thu, 29 May 2014 07:19:30 -0700 (PDT) Received: from p02c12o149.mxlogic.net (p02c12o149.mxlogic.net [208.65.145.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB8C1A0789; Thu, 29 May 2014 07:19:30 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c12o149.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id ee147835.2b3e1183b940.25890.00-505.71054.p02c12o149.mxlogic.net (envelope-from ); Thu, 29 May 2014 08:19:26 -0600 (MDT) X-MXL-Hash: 538741ee7aec99fb-02a3f29a51c893d7cfddccccf40d829897f9f216 Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c12o149.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id 38147835.0.24616.00-170.67574.p02c12o149.mxlogic.net (envelope-from ); Thu, 29 May 2014 08:17:51 -0600 (MDT) X-MXL-Hash: 5387418f4e2e6f7b-ce8d2b28d4d9ff2357f2c652b4090b56e6e4bb18 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; Thu, 29 May 2014 09:17:39 -0500 From: KEN KO To: Nalini Elkins , marc.ibrahim , "STARK, BARBARA H" , "Juergen Schoenwaelder" , Vero Zheng Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPez20702joYwCOkWjdsovVfKpjJtXjgGngAAKBCA= Date: Thu, 29 May 2014 14:17:38 +0000 Message-ID: References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.com> In-Reply-To: <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.195] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77756AC25exmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=fqBSZTIf c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=4xzyoWqC86AA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=y1pov1uI18EA:10 a=BLceEmwcHowA:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:] X-AnalysisOut: [8 a=BnEHt0n6AAAA:8 a=zQP7CpKOAAAA:8 a=i0EeH86SAAAA:8 a=NMd] X-AnalysisOut: [tWtFZAAAA:8 a=GueZoW4l7k-xC19GICoA:9 a=CjuIK1q_8ugA:10 a=v] X-AnalysisOut: [dlDKzqoUL8A:10 a=IfX7lmR_-rUA:10 a=25SSlH22FKcA:10 a=lZB81] X-AnalysisOut: [5dzVvQA:10 a=Hz7IrDYlS0cA:10 a=V0EhKMwcDj4A:10 a=zeshHG33D] X-AnalysisOut: [l4A:10 a=hPjdaMEvmhQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8] X-AnalysisOut: [ a=C7Bb6rhkyoqupNKWf-EA:9 a=wy-x5UiY-x2-sFxk:21 a=gKO2Hq4R] X-AnalysisOut: [SVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA] X-AnalysisOut: [:10 a=tXsnliwV7b4A:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014052915); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/uKGxXVuOEiVOQs2-oRrjo_0alXg Cc: "ippm@ietf.org" , "lmap@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 14:19:34 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756AC25exmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Marc's comments, e.g., a Measurement Method is Active if any M= A involved in the measurement is generating measurement traffic. And yes, P= ING is an Active Measurement Method. However, traffic measured by a Passive Method can easily include measuremen= t traffic generated by an unrelated Active Method. In this context for inst= ance, a Measurement Method that does nothing but count received packets is = still Passive, even if some of those packets are due to unrelated PINGs (or= throughput tests, etc.). From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Nalini Elkins Sent: Thursday, May 29, 2014 9:31 AM To: marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng Cc: draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@ietf.org Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt The problem is what to consider as "injected traffic". For example, on man= y networks, various devices, for their own purposes do PING commands. So= , then does that convert the entire measurement to active? Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: marc.ibrahim = > To: "STARK, BARBARA H" >; Nalini Elki= ns >; Juergen Schoenwaelder >; Vero Zheng > Cc: "lmap@ietf.org" >; "ippm@ietf.org" >; "draft-ietf-lmap-framework@tools.ietf.org" > Sent: Thursday, May 29, 2014 6:14 AM Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Hi, I think the confusion comes from whether or not to consider individual MA. For a single MA, measuring existing traffic is passive relatively to this g= iven MA. But if this traffic was sent from another MA, then the whole method is acti= ve since somebody has injected traffic. I think the definitions of active and passive methods are not relative to a= n MA but to all MAs/MPs involved each measurement. If this is the case, "Receiving" is = not really different from "generating" since an MA will receive and measure what has b= een generated. BR, Marc. On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote > ?? Receiving does or doesn't need to be a portion of the Active Measureme= nt > Method definition? If a Passive Measurement Method is any method that mea= sures > traffic without injecting traffic, doesn't that cover a Measurement Metho= d > that measures received traffic? Barbara > > From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com] > Sent: Thursday, May 29, 2014 8:49 AM > To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng > Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org > Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > /*snip*/ > >>> Active Measurement Method - The process of measuring some performance= or reliability parameter associated with the transfer of Traffic by generating= and/or receiving Active Measurement Traffic. > >>> > /*snip*/ > >>> Passive Measurement Method- The process of measuring some performance= or reliability parameter associated with the existing traffic on the network. > /*snip*/ > > >>But what if I have an MA passively measuring traffic that was injected > >>(perhaps by some other MA) for the purpose of measuring it? Why is > >>this distinction REAL vs non-REAL useful? And what is the definition > >>of REAL of "existing traffic" anyway? If I inject measurement traffic > >>observed by some MA, it is "existing traffic", no? > > > Yes, point well taken. The distinction we wanted to make is that the p= assive measurement technique does not inject traffic. Other MA's or indeed other = devices on the network create traffic for their own purposes, some of which may be per= formance measurement. We also wanted to come up with a good definition for passive = measurement that would work for all parties. How is the following? > > > Passive Measurement Method- The process of measuring some performance o= r reliability parameter associated with the traffic on the network. The passive measurem= ent method does not inject traffic for the purposes of measurement. > > >>Would that mean that the definition of Active Measurement Method wouldn= 't involve receiving Active Measurement Traffic, and only generated (injecting)? > >>Active Measurement Method - The process of measuring some performance o= r reliability parameter associated with the transfer of traffic by generating Active Meas= urement Traffic. > > Indeed, the word "receiving" needs to be a portion of the Active Measurem= ent > Method definition. Thanks! > > Nalini > > _______________________________________________ > lmap mailing list > lmap@ietf.org> > https://www.ietf.org/mailman/listinfo/lmap -- Open WebMail Project (http://openwebmail.org ) --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756AC25exmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Marc’s= comments, e.g., a Measurement Method is Active if any MA involved in the m= easurement is generating measurement traffic. And yes, PING is an Active Measurement Method.

 <= /p>

However, traffic measured= by a Passive Method can easily include measurement traffic generated by an= unrelated Active Method. In this context for instance, a Measurement Method that does nothing but count received packets is still= Passive, even if some of those packets are due to unrelated PINGs (or thro= ughput tests, etc.).

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Nalini Elkins
Sent: Thursday, May 29, 2014 9:31 AM
To: marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zhen= g
Cc: draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@ie= tf.org
Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.= txt

 

The problem is what= to consider as "injected traffic".  For example, on many ne= tworks, various devices, for their own purposes do PING commands.   &n= bsp;So, then does that convert the entire measurement to active?=

 

Thanks,<= /span>

 

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

 

From: marc.ibrahim <marc.ibrahim@usj.edu.lb>
To: "STARK, BARBARA H" <bs7652@att.com>; Nalini Elkins <nalini.elkins@insidethestack.com>; Juergen Sch= oenwaelder <j.sc= hoenwaelder@jacobs-university.de>; Vero Zheng <vero.zheng@huawei.= com>
Cc: "lmap@ietf.org" &= lt;lmap@ietf.org>; "ippm@ietf.org" <ippm@ietf.org>; "draft-ietf-lmap-framework@tools.ietf.org" <draft-ietf= -lmap-framework@tools.ietf.org>
Sent: Thursday, May 29, 2014 6:14 AM
Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.= txt


Hi,

I think the confusion comes from whether or not to consider individual MA.<= br> For a single MA, measuring existing traffic is passive relatively to this g= iven MA.
But if this traffic was sent from another MA, then the whole method is acti= ve since
somebody has injected traffic.

I think the definitions of active and passive methods are not relative to a= n MA but to
all MAs/MPs involved each measurement. If this is the case, "Receiving= " is not really
different from "generating" since an MA will receive and measure = what has been
generated.


BR,

Marc.

On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote
> ?? Receiving does or doesn't need to be a portion of the Active Measur= ement
> Method definition? If a Passive Measurement Method is any method that = measures
> traffic without injecting traffic, doesn't that cover a Measurement Me= thod
> that measures received traffic? Barbara
>
> From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com]
> Sent: Thursday, May 29, 2014 8:49 AM
> To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng
> Cc: draft-= ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org
> Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.tx= t
>
> /*snip*/
> >>> Active Measurement Method - The process of measuring some= performance or
reliability parameter associated with the transfer of Traffic by generating= and/or
receiving Active Measurement Traffic.
> >>>
> /*snip*/
> >>> Passive Measurement Method- The process of measuring some= performance or
reliability parameter associated with the existing traffic on the network.<= br> > /*snip*/
>
> >>But what if I have an MA passively measuring traffic that was = injected
> >>(perhaps by some other MA) for the purpose of measuring it? Wh= y is
> >>this distinction REAL vs non-REAL useful? And what is the defi= nition
> >>of REAL of "existing traffic" anyway? If I inject me= asurement traffic
> >>observed by some MA, it is "existing traffic", no? >
> > Yes, point well taken.  The distinction we wanted to make is= that the passive
measurement technique does not inject traffic.  Other MA's or indeed o= ther devices on
the network create traffic for their own purposes, some of which may be per= formance
measurement.  We also wanted to come up with a good definition for pas= sive measurement
that would work for all parties.  How is the following?
>
> > Passive Measurement Method- The process of measuring some perform= ance or reliability
parameter associated with the traffic on the network.  The passive mea= surement method
does not inject traffic for the purposes of measurement.
>
> >>Would that mean that the definition of Active Measurement Meth= od wouldn't involve
receiving Active Measurement Traffic, and only generated (injecting)?
> >>Active Measurement Method - The process of measuring some perf= ormance or reliability
parameter associated with the transfer of traffic by generating Active Meas= urement
Traffic.
>
> Indeed, the word "receiving" needs to be a portion of the Ac= tive Measurement
> Method definition.  Thanks!
>
> Nalini
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org<mailto:lmap@ietf.org>




--
Open WebMail Project (http://openwebmail.org

)

 

--_000_D14B7E40AEBFD54EA3AD964902DD7CB77756AC25exmb1corpadtran_-- From nobody Thu May 29 07:24: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 1E5101A0960; Thu, 29 May 2014 07:24:48 -0700 (PDT) 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_47=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 QiMWHljEu9qe; Thu, 29 May 2014 07:24:45 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7121A0962; Thu, 29 May 2014 07:24:44 -0700 (PDT) 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 s4TEORVP013233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 09:24:27 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2D0A51E0060; Thu, 29 May 2014 09:24:22 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id DBF521E0081; Thu, 29 May 2014 09:24:21 -0500 (CDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s4TEOLLs009625; Thu, 29 May 2014 08:24:21 -0600 (MDT) Received: from [10.183.200.45] (x1069818.dhcp.intranet [10.183.200.45]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s4TEOJ2N009606; Thu, 29 May 2014 08:24:19 -0600 (MDT) Message-ID: <53874313.7070507@centurylink.com> Date: Thu, 29 May 2014 08:24:19 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: KEN KO , Nalini Elkins , "marc.ibrahim" , "STARK, BARBARA H" , Juergen Schoenwaelder , Vero Zheng References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------080502010009090606040105" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/3FaZHDNaT96ZGbMxXLEy5K0SSuQ Cc: "draft-ietf-lmap-framework@tools.ietf.org" , "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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: Thu, 29 May 2014 14:24:48 -0000 This is a multi-part message in MIME format. --------------080502010009090606040105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with Ken's/Marc's comments on this. Charles On 5/29/2014 8:17 AM, KEN KO wrote: > > I agree with Marc's comments, e.g., a Measurement Method is Active if > any MA involved in the measurement is generating measurement traffic. > And yes, PING is an Active Measurement Method. > > > > However, traffic measured by a Passive Method can easily include > measurement traffic generated by an unrelated Active Method. In this > context for instance, a Measurement Method that does nothing but count > received packets is still Passive, even if some of those packets are > due to unrelated PINGs (or throughput tests, etc.). > > > > > *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of *Nalini Elkins > *Sent:* Thursday, May 29, 2014 9:31 AM > *To:* marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng > *Cc:* draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; > lmap@ietf.org > *Subject:* Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > > The problem is what to consider as "injected traffic". For example, > on many networks, various devices, for their own purposes do PING > commands. So, then does that convert the entire measurement to active? > > > > Thanks, > > > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > > > ------------------------------------------------------------------------ > > *From:*marc.ibrahim > > *To:* "STARK, BARBARA H" >; > Nalini Elkins >; Juergen Schoenwaelder > >; Vero Zheng > > > *Cc:* "lmap@ietf.org " >; "ippm@ietf.org " > >; > "draft-ietf-lmap-framework@tools.ietf.org > " > > > *Sent:* Thursday, May 29, 2014 6:14 AM > *Subject:* Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > Hi, > > I think the confusion comes from whether or not to consider individual MA. > For a single MA, measuring existing traffic is passive relatively to > this given MA. > But if this traffic was sent from another MA, then the whole method is > active since > somebody has injected traffic. > > I think the definitions of active and passive methods are not relative > to an MA but to > all MAs/MPs involved each measurement. If this is the case, > "Receiving" is not really > different from "generating" since an MA will receive and measure what > has been > generated. > > > BR, > > Marc. > > On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote > > ?? Receiving does or doesn't need to be a portion of the Active > Measurement > > Method definition? If a Passive Measurement Method is any method > that measures > > traffic without injecting traffic, doesn't that cover a Measurement > Method > > that measures received traffic? Barbara > > > > From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com > ] > > Sent: Thursday, May 29, 2014 8:49 AM > > To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng > > Cc: draft-ietf-lmap-framework@tools.ietf.org > ; lmap@ietf.org > ; ippm@ietf.org > > Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > > /*snip*/ > > >>> Active Measurement Method - The process of measuring some > performance or > reliability parameter associated with the transfer of Traffic by > generating and/or > receiving Active Measurement Traffic. > > >>> > > /*snip*/ > > >>> Passive Measurement Method- The process of measuring some > performance or > reliability parameter associated with the existing traffic on the network. > > /*snip*/ > > > > >>But what if I have an MA passively measuring traffic that was injected > > >>(perhaps by some other MA) for the purpose of measuring it? Why is > > >>this distinction REAL vs non-REAL useful? And what is the definition > > >>of REAL of "existing traffic" anyway? If I inject measurement traffic > > >>observed by some MA, it is "existing traffic", no? > > > > > Yes, point well taken. The distinction we wanted to make is that > the passive > measurement technique does not inject traffic. Other MA's or indeed > other devices on > the network create traffic for their own purposes, some of which may > be performance > measurement. We also wanted to come up with a good definition for > passive measurement > that would work for all parties. How is the following? > > > > > Passive Measurement Method- The process of measuring some > performance or reliability > parameter associated with the traffic on the network. The passive > measurement method > does not inject traffic for the purposes of measurement. > > > > >>Would that mean that the definition of Active Measurement Method > wouldn't involve > receiving Active Measurement Traffic, and only generated (injecting)? > > >>Active Measurement Method - The process of measuring some > performance or reliability > parameter associated with the transfer of traffic by generating Active > Measurement > Traffic. > > > > Indeed, the word "receiving" needs to be a portion of the Active > Measurement > > Method definition. Thanks! > > > > Nalini > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > -- > Open WebMail Project (http://openwebmail.org > > ) > > > > > > _______________________________________________ > 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 --------------080502010009090606040105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with Ken's/Marc's comments on this.
Charles

On 5/29/2014 8:17 AM, KEN KO wrote:

I agree with Marc’s comments, e.g., a Measurement Method is Active if any MA involved in the measurement is generating measurement traffic. And yes, PING is an Active Measurement Method.

 

However, traffic measured by a Passive Method can easily include measurement traffic generated by an unrelated Active Method. In this context for instance, a Measurement Method that does nothing but count received packets is still Passive, even if some of those packets are due to unrelated PINGs (or throughput tests, etc.).

                                                                                                                                                     &! nbsp;&nb sp;                                                                                                 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Nalini Elkins
Sent: Thursday, May 29, 2014 9:31 AM
To: marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng
Cc: draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@ietf.org
Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt

 

The problem is what to consider as "injected traffic".  For example, on many networks, various devices, for their own purposes do PING commands.    So, then does that convert the entire measurement to active?

 

Thanks,

 

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

 

From: marc.ibrahim <marc.ibrahim@usj.edu.lb>
To: "STARK, BARBARA H" <bs7652@att.com>; Nalini Elkins <nalini.elkins@insidethestack.com>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Vero Zheng <vero.zheng@huawei.com>
Cc: "lmap@ietf.org" <lmap@ietf.org>; "ippm@ietf.org" <ippm@ietf.org>; "draft-ietf-lmap-framework@tools.ietf.org" <draft-ietf-lmap-framework@tools.ietf.org>
Sent: Thursday, May 29, 2014 6:14 AM
Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt


Hi,

I think the confusion comes from whether or not to consider individual MA.
For a single MA, measuring existing traffic is passive relatively to this given MA.
But if this traffic was sent from another MA, then the whole method is active since
somebody has injected traffic.

I think the definitions of active and passive methods are not relative to an MA but to
all MAs/MPs involved each measurement. If this is the case, "Receiving" is not really
different from "generating" since an MA will receive and measure what has been
generated.


BR,

Marc.

On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote
> ?? Receiving does or doesn't need to be a portion of the Active Measurement
> Method definition? If a Passive Measurement Method is any method that measures
> traffic without injecting traffic, doesn't that cover a Measurement Method
> that measures received traffic? Barbara
>
> From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com]
> Sent: Thursday, May 29, 2014 8:49 AM
> To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng
> Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org
> Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt
>
> /*snip*/
> >>> Active Measurement Method - The process of measuring some performance or
reliability parameter associated with the transfer of Traffic by generating and/or
receiving Active Measurement Traffic.
> >>>
> /*snip*/
> >>> Passive Measurement Method- The process of measuring some performance or
reliability parameter associated with the existing traffic on the network.
> /*snip*/
>
> >>But what if I have an MA passively measuring traffic that was injected
> >>(perhaps by some other MA) for the purpose of measuring it? Why is
> >>this distinction REAL vs non-REAL useful? And what is the definition
> >>of REAL of "existing traffic" anyway? If I inject measurement traffic
> >>observed by some MA, it is "existing traffic", no?
>
> > Yes, point well taken.  The distinction we wanted to make is that the passive
measurement technique does not inject traffic.  Other MA's or indeed other devices on
the network create traffic for their own purposes, some of which may be performance
measurement.  We also wanted to come up with a good definition for passive measurement
that would work for all parties.  How is the following?
>
> > Passive Measurement Method- The process of measuring some performance or reliability
parameter associated with the traffic on the network.  The passive measurement method
does not inject traffic for the purposes of measurement.
>
> >>Would that mean that the definition of Active Measurement Method wouldn't involve
receiving Active Measurement Traffic, and only generated (injecting)?
> >>Active Measurement Method - The process of measuring some performance or reliability
parameter associated with the transfer of traffic by generating Active Measurement
Traffic.
>
> Indeed, the word "receiving" needs to be a portion of the Active Measurement
> Method definition.  Thanks!
>
> Nalini
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org<mailto:lmap@ietf.org>




--
Open WebMail Project (http://openwebmail.org

)

 



_______________________________________________
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
--------------080502010009090606040105-- From nobody Thu May 29 08:02: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 D9FA61A099F; Thu, 29 May 2014 08:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 2JXhX5IdcAyc; Thu, 29 May 2014 08:02:22 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7741A0411; Thu, 29 May 2014 08:02:21 -0700 (PDT) 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 afb47835.2b5efa876940.5098860.00-2419.14190770.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 29 May 2014 15:02:18 +0000 (UTC) X-MXL-Hash: 53874bfa59c009b9-4058dc6e562e656c9ed3831530d0f066a947fdd2 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 0fb47835.0.5098700.00-2225.14190328.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 29 May 2014 15:02:09 +0000 (UTC) X-MXL-Hash: 53874bf16e3fd1ef-d7c83dcea4a5536e2734730b80df7dfc70552407 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 s4TF28rD009392; Thu, 29 May 2014 11:02:08 -0400 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 s4TF1uab009212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 11:01:59 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (GAALPA1MSGHUB9A.itservices.sbc.com [130.8.36.87]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 29 May 2014 15:01:39 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; Thu, 29 May 2014 11:01:39 -0400 From: "STARK, BARBARA H" To: KEN KO , Nalini Elkins , "marc.ibrahim" , Juergen Schoenwaelder , Vero Zheng Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPezoeqD1KZZQ5ME6R7faiciBMHptXfvJAgABGewD//7358IAASSwAgAAEfQCAAA0HAP//v21g Date: Thu, 29 May 2014 15:01:38 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113043D89A@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.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.61.133] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6113043D89AGAALPA1MSGUSR9L_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=DOA4FVxb c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=4xzyoWqC86AA:10 a=ofMgfj31e3cA:10 a=xRrNQLmB5r0A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=eJNrpioGA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=BnEHt0n6AAAA:8 a=i0EeH86SAAAA:8 a] X-AnalysisOut: [=NMdtWtFZAAAA:8 a=JfqHcH24a3VGTKQOOxYA:9 a=CjuIK1q_8ugA:10] X-AnalysisOut: [ a=vdlDKzqoUL8A:10 a=IfX7lmR_-rUA:10 a=25SSlH22FKcA:10 a=D] X-AnalysisOut: [vnSUQUdWHYA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=V0EhK] X-AnalysisOut: [MwcDj4A:10 a=zeshHG33Dl4A:10 a=hPjdaMEvmhQA:10 a=lLNvOJZ5K] X-AnalysisOut: [PR8M2wh:21 a=mfK1jCxlyol30xKq:21 a=yMhMjlubAAAA:8 a=SSmOFE] X-AnalysisOut: [ACAAAA:8 a=lJGyvRfKZVeF99Fa3T0A:9 a=gKO2Hq4RSVkA:10 a=UiCQ] X-AnalysisOut: [7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV] X-AnalysisOut: [7b4A:10 a=kn280TLizfS_Y1Sd:21 a=XsFushKIVC0brti1:21 a=Tiq6] X-AnalysisOut: [cG11tVz7Oa0h:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/oW265NpsuXxpFSmgiHSDWJP2aZI Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 15:02:27 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6113043D89AGAALPA1MSGUSR9L_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I still have questions. I feel there's still ambiguity and overlap in propo= sed definitions. My main goal is to get rid of ambiguity and overlap. One thing I read in Marc's email was: We have MA1 sending UDP traffic to MA2. MA2 will receive UDP packet and com= pute jitter. This is clearly an active measurement task for MA1. This to me suggests an idea that Active Measurement Method (or Task, which = so far has been defined as an instantiation of a Method) doesn't need to ac= tually measure anything at all. It just needs to generate (inject) Active M= easurement Traffic. It may or may not measure any performance or reliabilit= y parameters. That is, there was no description of MA1 measuring the UDP tr= affic it sent to MA2, as a qualifier for identifying this as an Active Meas= urement Task. Looking at PING again. Let's consider a system where there is a MA (A) gene= rating a PING message, receiving a response message, and calculating the ti= me between these 2 events, an MA (B) receiving the PING and generating a re= sponse, and an MA (C) that is in between A and B and counts the number of P= ING messages it sees. What I think I'm reading is: 1. A is doing an Active Measurement Task. 2. B is doing an Active Measurement Task. [Note that B hasn't measure= d anything.] 3. C is doing a Passive Measurement Task. If the above is correct, I'd be fine with that. So here's a multiple choice question for y'all: B starts counting received PING messages. Select the correct answer from th= ose below, or invent a different answer. 1. B's counting of received PINGs is a new Passive Measurement Task, = unrelated to the PING responding Task. 2. B's counting of received PINGs is part of the existing Active Meas= urement Task that involves responding to PINGs. 3. B's counting of received PINGs is part of a new Active Measurement= Task, unrelated to the PING responding Task. 4. All of the above could be true, depending on how the Measurement M= ethods are defined. 5. 1 or 2 could be true, depending on how the Measurement Methods are= defined. Barbara From: KEN KO [mailto:KEN.KO@adtran.com] Sent: Thursday, May 29, 2014 10:18 AM To: Nalini Elkins; marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; V= ero Zheng Cc: draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@ietf.org Subject: RE: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt I agree with Marc's comments, e.g., a Measurement Method is Active if any M= A involved in the measurement is generating measurement traffic. And yes, P= ING is an Active Measurement Method. However, traffic measured by a Passive Method can easily include measuremen= t traffic generated by an unrelated Active Method. In this context for inst= ance, a Measurement Method that does nothing but count received packets is = still Passive, even if some of those packets are due to unrelated PINGs (or= throughput tests, etc.). From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Nalini Elkins Sent: Thursday, May 29, 2014 9:31 AM To: marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng Cc: draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@ietf.org Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt The problem is what to consider as "injected traffic". For example, on man= y networks, various devices, for their own purposes do PING commands. So= , then does that convert the entire measurement to active? Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: marc.ibrahim = > To: "STARK, BARBARA H" >; Nalini Elki= ns >; Juergen Schoenwaelder >; Vero Zheng > Cc: "lmap@ietf.org" >; "ippm@ietf.org" >; "draft-ietf-lmap-framework@tools.ietf.org" > Sent: Thursday, May 29, 2014 6:14 AM Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Hi, I think the confusion comes from whether or not to consider individual MA. For a single MA, measuring existing traffic is passive relatively to this g= iven MA. But if this traffic was sent from another MA, then the whole method is acti= ve since somebody has injected traffic. I think the definitions of active and passive methods are not relative to a= n MA but to all MAs/MPs involved each measurement. If this is the case, "Receiving" is = not really different from "generating" since an MA will receive and measure what has b= een generated. BR, Marc. On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote > ?? Receiving does or doesn't need to be a portion of the Active Measureme= nt > Method definition? If a Passive Measurement Method is any method that mea= sures > traffic without injecting traffic, doesn't that cover a Measurement Metho= d > that measures received traffic? Barbara > > From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com] > Sent: Thursday, May 29, 2014 8:49 AM > To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng > Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org > Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > /*snip*/ > >>> Active Measurement Method - The process of measuring some performance= or reliability parameter associated with the transfer of Traffic by generating= and/or receiving Active Measurement Traffic. > >>> > /*snip*/ > >>> Passive Measurement Method- The process of measuring some performance= or reliability parameter associated with the existing traffic on the network. > /*snip*/ > > >>But what if I have an MA passively measuring traffic that was injected > >>(perhaps by some other MA) for the purpose of measuring it? Why is > >>this distinction REAL vs non-REAL useful? And what is the definition > >>of REAL of "existing traffic" anyway? If I inject measurement traffic > >>observed by some MA, it is "existing traffic", no? > > > Yes, point well taken. The distinction we wanted to make is that the p= assive measurement technique does not inject traffic. Other MA's or indeed other = devices on the network create traffic for their own purposes, some of which may be per= formance measurement. We also wanted to come up with a good definition for passive = measurement that would work for all parties. How is the following? > > > Passive Measurement Method- The process of measuring some performance o= r reliability parameter associated with the traffic on the network. The passive measurem= ent method does not inject traffic for the purposes of measurement. > > >>Would that mean that the definition of Active Measurement Method wouldn= 't involve receiving Active Measurement Traffic, and only generated (injecting)? > >>Active Measurement Method - The process of measuring some performance o= r reliability parameter associated with the transfer of traffic by generating Active Meas= urement Traffic. > > Indeed, the word "receiving" needs to be a portion of the Active Measurem= ent > Method definition. Thanks! > > Nalini > > _______________________________________________ > lmap mailing list > lmap@ietf.org> > https://www.ietf.org/mailman/listinfo/lmap -- Open WebMail Project (http://openwebmail.org ) --_000_2D09D61DDFA73D4C884805CC7865E6113043D89AGAALPA1MSGUSR9L_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I still have questions. I= feel there’s still ambiguity and overlap in proposed definitions. My= main goal is to get rid of ambiguity and overlap.

 <= /p>

One thing I read in Marc&= #8217;s email was:

We have MA1 sending UDP traffic to MA2. MA2 will = receive UDP packet and compute jitter.

This is clearly an active measurement task for MA= 1.

This to me suggests an id= ea that Active Measurement Method (or Task, which so far has been defined a= s an instantiation of a Method) doesn’t need to actually measure anything at all. It just needs to generate (inject) Active Measure= ment Traffic. It may or may not measure any performance or reliability para= meters. That is, there was no description of MA1 measuring the UDP traffic = it sent to MA2, as a qualifier for identifying this as an Active Measurement Task.

 <= /p>

Looking at PING again. Le= t’s consider a system where there is a MA (A) generating a PING messa= ge, receiving a response message, and calculating the time between these 2 events, an MA (B) receiving the PING and generating a response, an= d an MA (C) that is in between A and B and counts the number of PING messag= es it sees. What I think I’m reading is:

1. = ;      A is doing an Act= ive Measurement Task.

2. = ;      B is doing an Act= ive Measurement Task. [Note that B hasn’t measured anything.]

3. = ;      C is doing a Pass= ive Measurement Task.

If the above is correct, = I’d be fine with that.

 <= /p>

So here’s a multipl= e choice question for y’all:

B starts counting receive= d PING messages. Select the correct answer from those below, or invent a di= fferent answer.

1. = ;      B’s countin= g of received PINGs is a new Passive Measurement Task, unrelated to the PIN= G responding Task.

2. = ;      B’s countin= g of received PINGs is part of the existing Active Measurement Task that in= volves responding to PINGs.

3. = ;      B’s countin= g of received PINGs is part of a new Active Measurement Task, unrelated to = the PING responding Task.

4. = ;      All of the above = could be true, depending on how the Measurement Methods are defined.

5. = ;      1 or 2 could be t= rue, depending on how the Measurement Methods are defined.

 <= /p>

Barbara=

 <= /p>

From: KEN KO [= mailto:KEN.KO@adtran.com]
Sent: Thursday, May 29, 2014 10:18 AM
To: Nalini Elkins; marc.ibrahim; STARK, BARBARA H; Juergen Schoenwae= lder; Vero Zheng
Cc: draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@ie= tf.org
Subject: RE: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.= txt

 

I agree with Marc’s= comments, e.g., a Measurement Method is Active if any MA involved in the m= easurement is generating measurement traffic. And yes, PING is an Active Measurement Method.

 <= /p>

However, traffic measured= by a Passive Method can easily include measurement traffic generated by an= unrelated Active Method. In this context for instance, a Measurement Method that does nothing but count received packets is still= Passive, even if some of those packets are due to unrelated PINGs (or thro= ughput tests, etc.).

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Nalini Elkins
Sent: Thursday, May 29, 2014 9:31 AM
To: marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zhen= g
Cc: draf= t-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@ietf.org
Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.= txt

 

The problem is what= to consider as "injected traffic".  For example, on many ne= tworks, various devices, for their own purposes do PING commands.   &n= bsp;So, then does that convert the entire measurement to active?=

 

Thanks,<= /span>

 

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

 

From: marc.ibrahim <marc.ibrahim@usj.edu.lb>
To: "STARK, BARBARA H" <bs7652@att.com>; Nalini Elkins <nalini.elkins@insidethestack.com>; Juergen Sch= oenwaelder <j.sc= hoenwaelder@jacobs-university.de>; Vero Zheng <vero.zheng@huawei.= com>
Cc: "lmap@ietf.org" &= lt;lmap@ietf.org>; "ippm@ietf.org" <ippm@ietf.org>; "draft-ietf-lmap-framework@tools.ietf.org" <draft-ietf= -lmap-framework@tools.ietf.org>
Sent: Thursday, May 29, 2014 6:14 AM
Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.= txt


Hi,

I think the confusion comes from whether or not to consider individual MA.<= br> For a single MA, measuring existing traffic is passive relatively to this g= iven MA.
But if this traffic was sent from another MA, then the whole method is acti= ve since
somebody has injected traffic.

I think the definitions of active and passive methods are not relative to a= n MA but to
all MAs/MPs involved each measurement. If this is the case, "Receiving= " is not really
different from "generating" since an MA will receive and measure = what has been
generated.


BR,

Marc.

On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote
> ?? Receiving does or doesn't need to be a portion of the Active Measur= ement
> Method definition? If a Passive Measurement Method is any method that = measures
> traffic without injecting traffic, doesn't that cover a Measurement Me= thod
> that measures received traffic? Barbara
>
> From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com]
> Sent: Thursday, May 29, 2014 8:49 AM
> To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng
> Cc: draft-= ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org
> Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.tx= t
>
> /*snip*/
> >>> Active Measurement Method - The process of measuring some= performance or
reliability parameter associated with the transfer of Traffic by generating= and/or
receiving Active Measurement Traffic.
> >>>
> /*snip*/
> >>> Passive Measurement Method- The process of measuring some= performance or
reliability parameter associated with the existing traffic on the network.<= br> > /*snip*/
>
> >>But what if I have an MA passively measuring traffic that was = injected
> >>(perhaps by some other MA) for the purpose of measuring it? Wh= y is
> >>this distinction REAL vs non-REAL useful? And what is the defi= nition
> >>of REAL of "existing traffic" anyway? If I inject me= asurement traffic
> >>observed by some MA, it is "existing traffic", no? >
> > Yes, point well taken.  The distinction we wanted to make is= that the passive
measurement technique does not inject traffic.  Other MA's or indeed o= ther devices on
the network create traffic for their own purposes, some of which may be per= formance
measurement.  We also wanted to come up with a good definition for pas= sive measurement
that would work for all parties.  How is the following?
>
> > Passive Measurement Method- The process of measuring some perform= ance or reliability
parameter associated with the traffic on the network.  The passive mea= surement method
does not inject traffic for the purposes of measurement.
>
> >>Would that mean that the definition of Active Measurement Meth= od wouldn't involve
receiving Active Measurement Traffic, and only generated (injecting)?
> >>Active Measurement Method - The process of measuring some perf= ormance or reliability
parameter associated with the transfer of traffic by generating Active Meas= urement
Traffic.
>
> Indeed, the word "receiving" needs to be a portion of the Ac= tive Measurement
> Method definition.  Thanks!
>
> Nalini
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org<mailto:lmap@ietf.org>




--
Open WebMail Project (http://openwebmail.org

)

 

--_000_2D09D61DDFA73D4C884805CC7865E6113043D89AGAALPA1MSGUSR9L_-- From nobody Thu May 29 08:57: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 739931A09BB; Thu, 29 May 2014 08:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 OCUVXtuTYwEg; Thu, 29 May 2014 08:57:52 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD57C1A0426; Thu, 29 May 2014 08:57:51 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id pa12so619519veb.4 for ; Thu, 29 May 2014 08:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oJky/izDJmDWPLavXtZh5A6pz9JbXXdErlnImvSCrRk=; b=DCRuBeQW0h2yrdbA0PkDsZz8L4jjmr2h7RhbUL+wNXAptNbvwULpSznQIZj0r/exUz +Jx/I2ej0UbO04uRSSE4ODttdTnVjoU+RBinI4JZ2Ppxx4wNdqDKepdinuVHGet4LnKo mzAUZqNvNO/A1shuwxQn60k96mxIHKMd8wNPNEkzGsd3bMVnJgVCoc+yhRxhbpOBzTJ0 hxGq8zwfhXxMKx4C13Y7wUpEHazY5SeZEbQLcO4ecmHAd3wzrYPll8G+AW9W1uuSwCzG 7fq4QOWl+AJl3DgIxdMSdNyx5O/LdpMcXnz90pQFH3uG95Gxcpe82ATyNQQHFlIi2PGh AxFw== MIME-Version: 1.0 X-Received: by 10.58.185.165 with SMTP id fd5mr2848860vec.41.1401379067174; Thu, 29 May 2014 08:57:47 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 29 May 2014 08:57:46 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Thu, 29 May 2014 08:57:46 -0700 Message-ID: From: Greg Mirsky To: "STARK, BARBARA H" Content-Type: multipart/alternative; boundary=047d7b66f3337ea75904fa8bfdb8 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/DtbETJAkkC4tRGjMZzKmdbHWSOE Cc: "ippm@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" , Juergen Schoenwaelder , "lmap@ietf.org" , Nalini Elkins , Vero Zheng Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 15:57:54 -0000 --047d7b66f3337ea75904fa8bfdb8 Content-Type: text/plain; charset=UTF-8 Hi Barbara, if we look into the proposed definition of the Active Measurement Method >>> Active Measurement Method - The process of measuring some performance or reliability parameter associated with the transfer of Traffic by generating and/or receiving Active Measurement Traffic. it does include receiving Active Measurement Traffic. I think that clarifies the question Juergen asked earlier in the discussion. IMO, observing active traffic, i.e. traffic injected by an MA, is still an example of active measurement. Regards, Greg On Thu, May 29, 2014 at 5:42 AM, STARK, BARBARA H wrote: > > /*snip*/ > >>> Active Measurement Method - The process of measuring some performance > or reliability parameter associated with the transfer of Traffic by > generating and/or receiving Active Measurement Traffic. > >>> > /*snip*/ > >>> Passive Measurement Method- The process of measuring some performance > or reliability parameter associated with the existing traffic on the > network. > /*snip*/ > > >>But what if I have an MA passively measuring traffic that was injected > >>(perhaps by some other MA) for the purpose of measuring it? Why is > >>this distinction REAL vs non-REAL useful? And what is the definition > >>of REAL of "existing traffic" anyway? If I inject measurement traffic > >>observed by some MA, it is "existing traffic", no? > > > Yes, point well taken. The distinction we wanted to make is that the > passive measurement technique does not inject traffic. Other MA's or > indeed other devices on the network create traffic for their own purposes, > some of which may be performance measurement. We also wanted to come up > with a good definition for passive measurement that would work for all > parties. How is the following? > > > Passive Measurement Method- The process of measuring some performance or > reliability parameter associated with the traffic on the network. The > passive measurement method does not inject traffic for the purposes of > measurement. > > Would that mean that the definition of Active Measurement Method wouldn't > involve receiving Active Measurement Traffic, and only generated > (injecting)? > Active Measurement Method - The process of measuring some performance or > reliability parameter associated with the transfer of traffic by generating > Active Measurement Traffic. > > Barbara > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > --047d7b66f3337ea75904fa8bfdb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Barbara,
if we look into t= he proposed definition of the Active Measurement Method
>>> Act= ive Measurement Method - The process of measuring some=20 performance or reliability parameter associated with the transfer of=20 Traffic by generating and/or receiving Active Measurement Traffic.
it does include receiving Active Measurement Traffic. I think that clarifi= es the question Juergen asked earlier in the discussion. IMO, observing act= ive traffic, i.e. traffic injected by an MA, is still an example of active = measurement.

Regards,
Greg

On Thu, May 29, 2014 at 5:42 AM, STARK, BARBAR= A H <bs7652@att.com> wrote:

/*snip*/
>>> Active Measurement Method - The process of mea= suring some performance or reliability parameter associated with the transf= er of Traffic by generating and/or receiving Active Measurement Traffic. >>>
/*snip*/
>>> Passive Measurement Method- The process of mea= suring some performance or reliability parameter associated with the existi= ng traffic on the network.
/*snip*/

>>But what if I have an MA passively measuring traffic that was injec= ted
>>(perhaps by some other MA) for the purpose of measuring it? Why is<= br> >>this distinction REAL vs non-REAL useful? And what is the definitio= n
>>of REAL of "existing traffic" anyway? If I inject measure= ment traffic
>>observed by some MA, it is "existing traffic", no?

> Yes, point well taken. =C2=A0 The distinction we wanted to make is tha= t the passive measurement technique does not inject traffic. =C2=A0 Other M= A's or indeed other devices on the network create traffic for their own= purposes, some of which may be performance measurement. =C2=A0We also want= ed to come up with a good definition for passive measurement that would wor= k for all parties. =C2=A0 How is the following?

> Passive Measurement Method- The process of measuring some performance = or reliability parameter associated with the traffic on the network. =C2=A0= The passive measurement method does not inject traffic for the purposes of= measurement.=C2=A0

Would that mean that the definition of Active Measurement Method woul= dn't involve receiving Active Measurement Traffic, and only generated (= injecting)?
Active Measurement Method - The process of measuring some performance or re= liability parameter associated with the transfer of traffic by generating A= ctive Measurement Traffic.

Barbara

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

--047d7b66f3337ea75904fa8bfdb8-- From nobody Thu May 29 09:00: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 6051D1A6FCA; Thu, 29 May 2014 09:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 RLeuj693HjyY; Thu, 29 May 2014 09:00:14 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F7B1A6FD0; Thu, 29 May 2014 08:59:49 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id oz11so622128veb.2 for ; Thu, 29 May 2014 08:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PXJpzPDMex8+ZBNQKu0Swtvk3WmvGaPOIXsPlLhJIEo=; b=m0YI1auxokFhSRNwGGpOu+YHCVt+yK8AiJSzA/HmrqXnlaPKonEODSHQIFAn4Mq1BP FBhCF9BpA5VfhDQsZCAlrseUqscIKcB1K+4sHrNBrvIB65+guK8JApI/mWNTPjfQjQcg dn+qiuaOuD6Ue3yZCxK9z7/aOzGcAtlkpAPqDR0WU/SsmjPK6wwZJYRSThkAvSaZ5/jU yK9CxA4bdgtR6j/mWtGMT+u/L0suLo9eRjkv7OpRxw4WnnGAsXVxvQO1DOx58ttz1Bkf +vGwqTrFVKdAIFlwASJLHzkTLWHU2BxY8q4pgqOL65C4BG6wIm4ijpj1g5TcJV0ZQGCn OUHg== MIME-Version: 1.0 X-Received: by 10.58.195.202 with SMTP id ig10mr7510367vec.33.1401379185426; Thu, 29 May 2014 08:59:45 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 29 May 2014 08:59:45 -0700 (PDT) In-Reply-To: <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> Date: Thu, 29 May 2014 08:59:45 -0700 Message-ID: From: Greg Mirsky To: Nalini Elkins Content-Type: multipart/alternative; boundary=047d7b66fce78b354004fa8c0439 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/t3-N_tBj1-QdtuqgQV9W5umYlAU Cc: "draft-ietf-lmap-framework@tools.ietf.org" , "lmap@ietf.org" , Juergen Schoenwaelder , "ippm@ietf.org" , Vero Zheng , "STARK, BARBARA H" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 16:00:21 -0000 --047d7b66fce78b354004fa8c0439 Content-Type: text/plain; charset=UTF-8 Hi Nalini, I believe it already there: >>> Active Measurement Method - The process of measuring some performance or reliability parameter associated with the transfer of Traffic by generating *and/or receiving* Active Measurement Traffic. Thank you for your support. Regards, Greg On Thu, May 29, 2014 at 5:49 AM, Nalini Elkins < nalini.elkins@insidethestack.com> wrote: > > /*snip*/ > >>> Active Measurement Method - The process of measuring some performance > or reliability parameter associated with the transfer of Traffic by > generating and/or receiving Active Measurement Traffic. > >>> > /*snip*/ > >>> Passive Measurement Method- The process of measuring some performance > or reliability parameter associated with the existing traffic on the > network. > /*snip*/ > > > >>But what if I have an MA passively measuring traffic that was injected > >>(perhaps by some other MA) for the purpose of measuring it? Why is > >>this distinction REAL vs non-REAL useful? And what is the definition > >>of REAL of "existing traffic" anyway? If I inject measurement traffic > >>observed by some MA, it is "existing traffic", no? > > > Yes, point well taken. The distinction we wanted to make is that the > passive measurement technique does not inject traffic. Other MA's or > indeed other devices on the network create traffic for their own purposes, > some of which may be performance measurement. We also wanted to come up > with a good definition for passive measurement that would work for all > parties. How is the following? > > > Passive Measurement Method- The process of measuring some performance or > reliability parameter associated with the traffic on the network. The > passive measurement method does not inject traffic for the purposes of > measurement. > > > >>Would that mean that the definition of Active Measurement Method > wouldn't involve receiving Active Measurement Traffic, and only generated > (injecting)? > >>Active Measurement Method - The process of measuring some performance or > reliability parameter associated with the transfer of traffic by generating > Active Measurement Traffic. > > Indeed, the word "receiving" needs to be a portion of the Active > Measurement Method definition. Thanks! > > Nalini > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --047d7b66fce78b354004fa8c0439 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Nalini,
I believe it alrea= dy there:
>>> Active Measurement Method - The process of measur= ing some=20 performance or reliability parameter associated with the transfer of=20 Traffic by generating and/or receiving Active Measurement Traffic.

Thank you for your support.

Regards,
Greg=



On Thu, May 29, 2014 at 5:49 AM, Nalini Elkins <nalini.elki= ns@insidethestack.com> wrote:

/*snip*/
>>> Active = Measurement Method - The process of measuring some performance or reliabili= ty parameter associated with the transfer of Traffic by generating and/or r= eceiving Active Measurement Traffic.
>>>
/*snip*/
>>> Pas= sive Measurement Method- The process of measuring some performance or relia= bility parameter associated with the existing traffic on the network.
/*snip*/


>>But what if I ha= ve an MA passively measuring traffic that was injected
&g= t;>(perhaps by some other MA) for the purpose of measuring it? Why is >>this distinction REAL vs non-REAL useful? And what is the definitio= n
>>of REAL of "existing traffic" anyway?= If I inject measurement traffic
>>observed by some= MA, it is "existing traffic", no?

> Yes, point well taken. =C2=A0 The distinction we wa= nted to make is that the passive measurement technique does not inject traf= fic. =C2=A0 Other MA's or indeed other devices on the network create tr= affic for their own purposes, some of which may be performance measurement.= =C2=A0We also wanted to come up with a good definition for passive measure= ment that would work for all parties. =C2=A0 How is the following?

> Passive Measurement Method- The process of measurin= g some performance or reliability parameter associated with the traffic on the network. =C2=A0 The passive measurement method does not inject traffic= for the purposes of measurement.=C2=A0


>>Would that mean that the definition of Active Measurement= Method wouldn't involve receiving Active Measurement Traffic, and only= generated (injecting)?
>>Active Measurement Method - The process of measuring some performan= ce or reliability parameter associated with the transfer of traffic by gene= rating Active Measurement Traffic.

Indeed, the word "receiving" needs to be a portion of the Active = Measurement Method definition. =C2=A0 Thanks!

Nalini


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


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


--047d7b66fce78b354004fa8c0439-- From nobody Thu May 29 09:07: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 8BAAE1A09B0 for ; Thu, 29 May 2014 09:07:39 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 qOw8nDwYJ4uQ for ; Thu, 29 May 2014 09:07:37 -0700 (PDT) Received: from nm18.bullet.mail.ne1.yahoo.com (nm18.bullet.mail.ne1.yahoo.com [98.138.90.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF08D1A0177 for ; Thu, 29 May 2014 09:07:36 -0700 (PDT) Received: from [98.138.226.178] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 16:07:32 -0000 Received: from [98.138.101.172] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2014 16:07:32 -0000 Received: from [127.0.0.1] by omp1083.mail.ne1.yahoo.com with NNFMP; 29 May 2014 16:07:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 608114.25194.bm@omp1083.mail.ne1.yahoo.com Received: (qmail 54549 invoked by uid 60001); 29 May 2014 16:07:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401379652; bh=1THFyC5iz/FE0rf4Qm7c/0IKOENkshHf2Y2H56cXivw=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0i/oc1cbtR0zjXRMgxO5bv8glzEKOMfhU0a57yH6OKJW0By/oyauukaBvEjgneVgYA7gQ8FB4zaRsnNS14feBXjJfd6N9Pp9DrWzV9hBTUTpkzZH7pkxJKcDzaOboWX05s6Q2kU4CabObhyM1Qt6alUUbnhCR43cK5QD11m4mlU= X-YMail-OSG: zt88ugoVM1mxk_G2bsl_BKqoM52QNFjUsq2uDvC3KCXn1Je l1c48ort_RpDPeKQfDCNvv3CEfdXuTGvhJcnU84TyMWnlLZIGC8BR2Sb6v1Z B30mmJ28ELG8d82Jkfw464V6eRuHmT2hGCo0rGrNZkZlmI9DfPUNY261Qxxy CR7UGVr0hLrXwL0O4j0Nv.RtjC6E5n9hsejw4JUVJrVds6dpujffQPeZWeEZ EF70QQ3IuEYSGuHvaB3_gFTg.d0nLjDj2BYWREuUE3F39eAwYbGchRdakF3L hYqKVyVV2Yor7iu.Oa9NuA9OK0R.8RRMwLZeJKzBMp5Vp6vLQ1inE0oZjzoB .q0Wmbo9h.fAOtEVRiMN.3u9akpgLGmmzrex_rhv81exngelyYpu_1CQRI5K Qtb.kbXJftCeQcptoA9Qw5Oe6UlQMqp9PZtz8UxcFDqm3XAlNnzWLdIduZyN k3cMlUg6v5pCDwWSim9t5yBIf.F4rJKdbQunjVIZlKrq_eYaurJu5d4Sbubq bL.ZDKhqoZOXgxnMxa2Asc0vbkgnpbSvSlH1qFnnlSzRlnTZX95hEl4nKqrX ti2H0Ny.wWvNl8q7d9whqDEgxN5PHsqD5wYcdh_kbvb9yvUqMGKEHf7nQ8mL jcEfntfS7CEQa3a1QIO73HeOF3FyVlWAhhR8CvhqxC_94whC7NhADnQ4WMvh .BTgzGmM- Received: from [24.130.37.147] by web125105.mail.ne1.yahoo.com via HTTP; Thu, 29 May 2014 09:07:32 PDT X-Rocket-MIMEInfo: 002.001, QmFyYmFyYSwKCkluIG15IG9waW5pb246CgoxLsKgwqDCoMKgwqDCoMKgQuKAmXMgY291bnRpbmcgb2YgcmVjZWl2ZWQgUElOR3MgaXMgYSBuZXcgUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrLCB1bnJlbGF0ZWQgdG8gdGhlIFBJTkcgcmVzcG9uZGluZyBUYXNrLgrCoApUaGFua3MsCgpOYWxpbmkgRWxraW5zCkluc2lkZSBQcm9kdWN0cywgSW5jLgooODMxKSA2NTktODM2MAp3d3cuaW5zaWRldGhlc3RhY2suY29tCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiAiU1RBUkssIEJBUkIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D89A@GAALPA1MSGUSR9L.ITServices.sbc.com> Message-ID: <1401379652.47544.YahooMailNeo@web125105.mail.ne1.yahoo.com> Date: Thu, 29 May 2014 09:07:32 -0700 (PDT) From: Nalini Elkins To: "STARK, BARBARA H" , KEN KO , "marc.ibrahim" , Juergen Schoenwaelder , Vero Zheng In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043D89A@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="461871616-797352472-1401379652=:47544" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/7uFsgz8Rpg_6j7xVn_en7C6AAPU Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:07:39 -0000 --461871616-797352472-1401379652=:47544 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Barbara,=0A=0AIn my opinion:=0A=0A1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0B=E2=80=99s counting of received PINGs is a new Passive Measurement Task= , unrelated to the PING responding Task.=0A=C2=A0=0AThanks,=0A=0ANalini Elk= ins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A= =0A=0A________________________________=0A From: "STARK, BARBARA H" =0ATo: KEN KO ; Nalini Elkins ; marc.ibrahim ; Juergen Schoenwae= lder ; Vero Zheng =0ACc: "ippm@ietf.org" ; "lmap@ietf.org" =0ASent: Thursday, May 29, 2014 8:01 AM=0ASubject: RE: [lmap] [ippm] I-= D Action: draft-ietf-lmap-framework-05.txt=0A =0A=0A=0AI still have questio= ns. I feel there=E2=80=99s still ambiguity and overlap in proposed definiti= ons. My main goal is to get rid of ambiguity and overlap.=0A=C2=A0=0AOne th= ing I read in Marc=E2=80=99s email was:=0AWe have MA1 sending UDP traffic t= o MA2. MA2 will receive UDP packet and compute jitter. =0AThis is clearly a= n active measurement task for MA1.=0AThis to me suggests an idea that Activ= e Measurement Method (or Task, which so far has been defined as an instanti= ation of a Method) doesn=E2=80=99t need to actually measure anything at all= . It just needs to generate (inject) Active Measurement Traffic. It may or = may not measure any performance or reliability parameters. That is, there w= as no description of MA1 measuring the UDP traffic it sent to MA2, as a qua= lifier for identifying this as an Active Measurement Task.=0A=C2=A0=0ALooki= ng at PING again. Let=E2=80=99s consider a system where there is a MA (A) g= enerating a PING message, receiving a response message, and calculating the= time between these 2 events, an MA (B) receiving the PING and generating a= response, and an MA (C) that is in between A and B and counts the number o= f PING messages it sees. What I think I=E2=80=99m reading is:=0A1.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 A is doing an Active Measurement Task.=0A2.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B is doing an Active Measurement Task. [N= ote that B hasn=E2=80=99t measured anything.]=0A3.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 C is doing a Passive Measurement Task.=0AIf the above is corre= ct, I=E2=80=99d be fine with that.=0A=C2=A0=0ASo here=E2=80=99s a multiple = choice question for y=E2=80=99all:=0AB starts counting received PING messag= es. Select the correct answer from those below, or invent a different answe= r.=0A1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B=E2=80=99s counting of receive= d PINGs is a new Passive Measurement Task, unrelated to the PING responding= Task.=0A2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B=E2=80=99s counting of rec= eived PINGs is part of the existing Active Measurement Task that involves r= esponding to PINGs.=0A3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B=E2=80=99s co= unting of received PINGs is part of a new Active Measurement Task, unrelate= d to the PING responding Task.=0A4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 All= of the above could be true, depending on how the Measurement Methods are d= efined.=0A5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 or 2 could be true, depe= nding on how the Measurement Methods are defined.=0A=C2=A0=0ABarbara=0A=C2= =A0=0AFrom:KEN KO [mailto:KEN.KO@adtran.com] =0ASent: Thursday, May 29, 201= 4 10:18 AM=0ATo: Nalini Elkins; marc.ibrahim; STARK, BARBARA H; Juergen Sch= oenwaelder; Vero Zheng=0ACc: draft-ietf-lmap-framework@tools.ietf.org; ippm= @ietf.org; lmap@ietf.org=0ASubject: RE: [lmap] [ippm] I-D Action: draft-iet= f-lmap-framework-05.txt=0A=C2=A0=0AI agree with Marc=E2=80=99s comments, e.= g., a Measurement Method is Active if any MA involved in the measurement is= generating measurement traffic. And yes, PING is an Active Measurement Met= hod.=0A=C2=A0=0AHowever, traffic measured by a Passive Method can easily in= clude measurement traffic generated by an unrelated Active Method. In this = context for instance, a Measurement Method that does nothing but count rece= ived packets is still Passive, even if some of those packets are due to unr= elated PINGs (or throughput tests, etc.).=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =0AFrom:lmap [mailto:lmap-bounces@ietf.or= g] On Behalf Of Nalini Elkins=0ASent: Thursday, May 29, 2014 9:31 AM=0ATo: = marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng=0ACc: dra= ft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@ietf.org=0ASubje= ct: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt=0A=C2=A0= =0AThe problem is what to consider as "injected traffic". =C2=A0For example= , on many networks, various devices, for their own purposes do PING command= s. =C2=A0 =C2=A0So, then does that convert the entire measurement to active= ?=0A=C2=A0=0AThanks,=0A=C2=A0=0ANalini Elkins=0AInside Products, Inc.=0A(83= 1) 659-8360=0Awww.insidethestack.com=0A=C2=A0=0A=0A________________________= ________=0A =0AFrom:marc.ibrahim =0ATo: "STARK, BA= RBARA H" ; Nalini Elkins = ; Juergen Schoenwaelder ; Vero Zheng = =0ACc: "lmap@ietf.org" ; "ippm@ietf.= org" ; "draft-ietf-lmap-framework@tools.ietf.org" =0ASent: Thursday, May 29, 2014 6:14 AM=0A= Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt=0A= =0AHi, =0A=0AI think the confusion comes from whether or not to consider in= dividual MA.=0AFor a single MA, measuring existing traffic is passive relat= ively to this given MA.=0ABut if this traffic was sent from another MA, the= n the whole method is active since =0Asomebody has injected traffic.=0A=0AI= think the definitions of active and passive methods are not relative to an= MA but to =0Aall MAs/MPs involved each measurement. If this is the case, "= Receiving" is not really =0Adifferent from "generating" since an MA will re= ceive and measure what has been =0Agenerated. =0A=0A=0ABR,=0A=0AMarc.=0A=0A= On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote=0A> ?? Receiving= does or doesn't need to be a portion of the Active Measurement =0A> Method= definition? If a Passive Measurement Method is any method that measures = =0A> traffic without injecting traffic, doesn't that cover a Measurement Me= thod =0A> that measures received traffic? Barbara=0A> =0A> From: Nalini Elk= ins [mailto:nalini.elkins@insidethestack.com]=0A> Sent: Thursday, May 29, 2= 014 8:49 AM=0A> To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng=0A>= Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org= =0A> Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.tx= t=0A> =0A> /*snip*/=0A> >>> Active Measurement Method - The process of meas= uring some performance or =0Areliability parameter associated with the tran= sfer of Traffic by generating and/or =0Areceiving Active Measurement Traffi= c.=0A> >>>=0A> /*snip*/=0A> >>> Passive Measurement Method- The process of = measuring some performance or =0Areliability parameter associated with the = existing traffic on the network.=0A> /*snip*/=0A> =0A> >>But what if I have= an MA passively measuring traffic that was injected=0A> >>(perhaps by some= other MA) for the purpose of measuring it? Why is=0A> >>this distinction R= EAL vs non-REAL useful? And what is the definition=0A> >>of REAL of "existi= ng traffic" anyway? If I inject measurement traffic=0A> >>observed by some = MA, it is "existing traffic", no?=0A> =0A> > Yes, point well taken.=C2=A0 T= he distinction we wanted to make is that the passive =0Ameasurement techniq= ue does not inject traffic.=C2=A0 Other MA's or indeed other devices on =0A= the network create traffic for their own purposes, some of which may be per= formance =0Ameasurement.=C2=A0 We also wanted to come up with a good defini= tion for passive measurement =0Athat would work for all parties.=C2=A0 How = is the following?=0A> =0A> > Passive Measurement Method- The process of mea= suring some performance or reliability =0Aparameter associated with the tra= ffic on the network.=C2=A0 The passive measurement method =0Adoes not injec= t traffic for the purposes of measurement.=0A> =0A> >>Would that mean that = the definition of Active Measurement Method wouldn't involve =0Areceiving A= ctive Measurement Traffic, and only generated (injecting)?=0A> >>Active Mea= surement Method - The process of measuring some performance or reliability = =0Aparameter associated with the transfer of traffic by generating Active M= easurement =0ATraffic.=0A> =0A> Indeed, the word "receiving" needs to be a = portion of the Active Measurement =0A> Method definition.=C2=A0 Thanks!=0A>= =0A> Nalini=0A> =0A> _______________________________________________=0A> l= map mailing list=0A> lmap@ietf.org=0A=0A> https://www= .ietf.org/mailman/listinfo/lmap=0A=0A=0A=0A--=0AOpen WebMail Project (http:= //openwebmail.org=0A) --461871616-797352472-1401379652=:47544 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

In my opinion:

1.       B=E2=80=99s counting of received PINGs is a new Passive M= easurement Task, unrelated to the PING responding Task.
 
Thanks,

Nalini Elk= ins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

=
=
From: "STARK, B= ARBARA H" <bs7652@att.com>
= To: KEN KO <KEN.KO@adtran.com>; Nalini Elkins <nalini.e= lkins@insidethestack.com>; marc.ibrahim <marc.ibrahim@usj.edu.lb>;= Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Vero Z= heng <vero.zheng@huawei.com>
Sent:<= /b> Thursday, May 29, 2014 8:01 AM
Subject: RE: [lmap] [ippm] I-D Action: draft-ietf-lmap= -framework-05.txt

=0A
=0A
I still have questions. I feel there=E2=80=99s still= ambiguity and overlap in proposed definitions. My main goal is to get rid = of ambiguity and overlap.
=0A
 
=0A
One thing I r= ead in Marc=E2=80=99s email was:
=0A
We have MA1 sending UDP traffic to MA2. MA2 will receive UDP= packet and compute jitter.=0A
=0A
This is clearly an active measurement task for MA1.
=0A
This to me = suggests an idea that Active Measurement Method (or Task, which so far has = been defined as an instantiation of a Method) doesn=E2=80=99t need to actua= lly=0A measure anything at all. It just needs to generate (inject) Active M= easurement Traffic. It may or may not measure any performance or reliabilit= y parameters. That is, there was no description of MA1 measuring the UDP tr= affic it sent to MA2, as a qualifier for=0A identifying this as an Active M= easurement Task.
=0A
 
=0A
Looking at PING again. L= et=E2=80=99s consider a system where there is a MA (A) generating a PING me= ssage, receiving a response message, and calculating the time between=0A th= ese 2 events, an MA (B) receiving the PING and generating a response, and a= n MA (C) that is in between A and B and counts the number of PING messages = it sees. What I think I=E2=80=99m reading is:
=0A
1.    &n= bsp; =0AA is do= ing an Active Measurement Task.
=0A
2.      =0A= B is doing an Active= Measurement Task. [Note that B hasn=E2=80=99t measured anything.] =0A
3. = ;     =0AC is doing a Passive Measurement Task.
=0A
If the ab= ove is correct, I=E2=80=99d be fine with that.
=0A
 
=0A
So here=E2=80=99s a multiple choice question for y=E2=80=99all:
=0A
B starts counting received PING messages. Select the correct answ= er from those below, or invent a different answer.
=0A
1.   &nb= sp;  =0AB= =E2=80=99s counting of received PINGs is a new Passive Measurement Task, un= related to the PING responding Task.
=0A
2.      = ;=0AB=E2=80=99s coun= ting of received PINGs is part of the existing Active Measurement Task that= involves responding to PINGs.
=0A
3.      =0A= B=E2=80=99s counting= of received PINGs is part of a new Active Measurement Task, unrelated to t= he PING responding Task.
=0A
4.=       =0A<= /span>All of the above could be tr= ue, depending on how the Measurement Methods are defined.
=0A<= div class=3D"yiv6577133121MsoListParagraph" style=3D"">5.  &n= bsp;   =0A1 or 2 could be true, depending on how the Measurement Methods are def= ined.
=0A
 
=0A
Barbara
=0A
 
=0A
=0A
=0A
=0A
From: KEN KO [mailto:KEN.KO@adtran.com]=0A
=0ASent: Thursday, May 29, 2014 10:18 AM
=0ATo: = Nalini Elkins; marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero = Zheng
=0ACc: draft-ietf-lmap-framework@tools.ietf.= org; ippm@ietf.org; lmap@ietf.org
=0ASubject: RE: = [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt
=0A=
=0A
=0A
 
=0AI agr= ee with Marc=E2=80=99s comments, e.g., a Measurement Method is Active if an= y MA involved in the measurement is generating measurement traffic. And yes= , PING is=0A an Active Measurement Method.
=0A
  =0A
However, traffic measured by a Passive Method can easily include measurem= ent traffic generated by an unrelated Active Method. In this context for in= stance,=0A a Measurement Method that does nothing but count received packet= s is still Passive, even if some of those packets are due to unrelated PING= s (or throughput tests, etc.).
=0A
       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          &nbs p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;   =0A
=0A
=0A
=0A
= =0A
From: lmap [mailto:lmap-bounces@ietf.org]= =0AOn Behalf Of Nalini Elkins
=0ASent: Thur= sday, May 29, 2014 9:31 AM
=0ATo: marc.ibrahim; ST= ARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng
=0AC= c: draft-ietf-lmap-framework@tools.ietf.org;=0A= ippm@ietf.org; =0Almap@ietf.org
=0ASub= ject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt
=0A
=0A
=0A
&nbs= p;
=0A
=0A
=0A
The problem is what to consider as = "injected traffic".  For example, on many networks, various devices, f= or their own purposes do PING commands.    So,=0A then does that = convert the entire measurement to active?
=0A
=0A
=0A=
 
=0A
=0A
=0A
Thanks, =0A
=0A
=0A
 
=0A=
=0A
=0A
Nalini Elkins
=0AInside Products= , Inc.
=0A(831) 659-8360
=0Awww.insidethestack.com
=0A
=0A
 <= /span>
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
From: marc.ibrahim <marc.ibrahim@usj.edu.lb>
=0ATo: "STARK, BARBARA H" <bs7652@att.com>; Nalini Elkins <nalini.elkins@insidet= hestack.com>; Juergen Schoenwaelder <j.schoenwaelder@= jacobs-university.de>;=0A Vero Zheng <vero.zheng@huawei.com>
=0ACc: "lmap@ietf= .org" <lmap@ietf.org>= ;; "ippm@ietf.org" <ippm@ietf.org>; "draft-ietf-lmap-framework@tools.ietf.org"=0A <draft-ietf-lmap-framework@tools.ietf.org>=0A
=0A= Sent: Thursday, May 29, 2014 6:14 AM
=0ASubject= : Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt=
=0A
=0A
=0A

=0AHi,
=0A
=0AI think the confusion comes from whether or not to consider individual= MA.
=0AFor a single MA, measuring existing traffic is pa= ssive relatively to this given MA.
=0ABut if this traffic= was sent from another MA, then the whole method is active since=0A
=0Asomebody has injected traffic.
=0A
=0AI think the definitions of active and passive methods are not = relative to an MA but to=0A
=0Aall MAs/MPs involved each = measurement. If this is the case, "Receiving" is not really=0A
=0Adifferent from "generating" since an MA will receive and measure w= hat has been
=0Agenerated.
=0A
=0A
=0ABR,
=0A
=0AMarc.
=0A
=0AOn Thu, 29 May 20= 14 12:57:35 +0000, STARK, BARBARA H wrote
=0A> ?? Rece= iving does or doesn't need to be a portion of the Active Measurement
=0A> Method definition? If a Passive Measurement Method is = any method that measures
=0A> traffic without injecti= ng traffic, doesn't that cover a Measurement Method
=0A&= gt; that measures received traffic? Barbara
=0A>
=0A> From: Nalini Elkins [mailto:nalini.elkins@insidet= hestack.com]
=0A> Sent: Thursday, May 29, 2014 8:4= 9 AM
=0A> To: STARK, BARBARA H; Juergen Schoenwaelder;= Vero Zheng
=0A> Cc: draft-ietf-lm= ap-framework@tools.ietf.org;=0Almap@ietf.org; =0Aippm@ietf.o= rg
=0A> Subject: Re: [lmap] [ippm] I-D Action: dra= ft-ietf-lmap-framework-05.txt
=0A>
= =0A> /*snip*/
=0A> >>> Active Measurement = Method - The process of measuring some performance or
= =0Areliability parameter associated with the transfer of Traffic by generat= ing and/or=0A
=0Areceiving Active Measurement Traffic.=0A> >>>
=0A> /*snip*/
=0A> >>> Passive Measurement Method- The process= of measuring some performance or
=0Areliability paramet= er associated with the existing traffic on the network.
= =0A> /*snip*/
=0A>
=0A> >&= gt;But what if I have an MA passively measuring traffic that was injected=0A> >>(perhaps by some other MA) for the purpose= of measuring it? Why is
=0A> >>this distinction= REAL vs non-REAL useful? And what is the definition
=0A&= gt; >>of REAL of "existing traffic" anyway? If I inject measurement t= raffic
=0A> >>observed by some MA, it is "existi= ng traffic", no?
=0A>
=0A> > = Yes, point well taken.  The distinction we wanted to make is that the = passive=0A
=0Ameasurement technique does not inject traff= ic.  Other MA's or indeed other devices on=0A
=0Athe= network create traffic for their own purposes, some of which may be perfor= mance=0A
=0Ameasurement.  We also wanted to come up = with a good definition for passive measurement=0A
=0Athat= would work for all parties.  How is the following?
= =0A>
=0A> > Passive Measurement Method- The pro= cess of measuring some performance or reliability=0A
=0Ap= arameter associated with the traffic on the network.  The passive meas= urement method=0A
=0Adoes not inject traffic for the purp= oses of measurement.
=0A>
=0A> &= gt;>Would that mean that the definition of Active Measurement Method wou= ldn't involve=0A
=0Areceiving Active Measurement Traffic,= and only generated (injecting)?
=0A> >>Active M= easurement Method - The process of measuring some performance or reliabilit= y=0A
=0Aparameter associated with the transfer of traffic= by generating Active Measurement=0A
=0ATraffic.
=0A>
=0A> Indeed, the word "receiving" n= eeds to be a portion of the Active Measurement
=0A> M= ethod definition.  Thanks!
=0A>
=0A> Nalini
=0A>
=0A> _____= __________________________________________
=0A> lmap m= ailing list
=0A> lmap@ietf.org<mailto:l= map@ietf.org>
=0A= =0A

=0A
=0A
=0A--
=0AOpen WebMail Project (http= ://openwebmail.org
=0A
= =0A
)
=0A
= =0A
 
=0A
= =0A
=0A
=0A
=0A
=0A
=0A
=0A

--461871616-797352472-1401379652=:47544-- From nobody Thu May 29 09:14: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 D06E91A6FDA; Thu, 29 May 2014 09:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 wuCd8HgU4DT5; Thu, 29 May 2014 09:14:45 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1971A6FBA; Thu, 29 May 2014 09:14:45 -0700 (PDT) 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 1fc57835.2ae607077940.5139371.00-2409.14318412.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 29 May 2014 16:14:41 +0000 (UTC) X-MXL-Hash: 53875cf10be87f3a-1dd16a9794728d044b9d5d27001f99ae547c6828 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 cec57835.0.5139291.00-2270.14318166.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 29 May 2014 16:14:40 +0000 (UTC) X-MXL-Hash: 53875cf07916649b-1dc691e5cddfe9321e1ef4bd9bc762e80d9efdf4 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 s4TGEYiQ030889; Thu, 29 May 2014 12:14:36 -0400 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 s4TGEU8p030864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 12:14:31 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 29 May 2014 16:14:18 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; Thu, 29 May 2014 12:14:17 -0400 From: "STARK, BARBARA H" To: "marc.ibrahim" , Nalini Elkins , Juergen Schoenwaelder , Vero Zheng Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPezoeqD1KZZQ5ME6R7faiciBMHptXfvJAgABGewD//7358IAASSwA///qD1A= Date: Thu, 29 May 2014 16:14:17 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> In-Reply-To: <20140529130345.M94452@mail.usj.edu.lb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.61.133] 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=Kpj6LxqN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=4xzyoWqC86AA:10 a=ofMgfj31e3cA:10 a=xRrNQLmB5r0A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=Ge6uXqJ8Jxhvw5cxu08A:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/VIT6DAxN7ebxDn3qGK6lVWwrQS0 Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 16:14:47 -0000 > I think the confusion comes from whether or not to consider individual MA= . > For a single MA, measuring existing traffic is passive relatively to this= given > MA. > But if this traffic was sent from another MA, then the whole method is ac= tive > since somebody has injected traffic. >=20 > I think the definitions of active and passive methods are not relative to= an > MA but to all MAs/MPs involved each measurement. If this is the case, > "Receiving" is not really different from "generating" since an MA will re= ceive > and measure what has been generated. I'm not sure if it's confusion so much as it is the term ippm needs vs. the= term lmap needs. Lmap looks at the world from the perspective of the MA, a= nd from the perspective of the operation systems. Ippm looks at the world f= rom the perspective of metrics (and what needs to happen to generate the me= trics). Lmap needs terms that describe (generally and as a specific instantiation o= f the general term) what an MA does to accomplish its role in the term that= ippm needs. It sounds like Ippm needs a term to describe holistically what is involved = in generation of a particular metric. Using the same term (Measurement Method or its Measurement Task instantiati= on) as both the MA functional role and as the holistic metric generation me= thod (task) is problematic. These need to be distinct terms. In the context of the ippm registry, we really need registry entries to pro= vide specifics for configuring each MA role that is part of the holistic sy= stem needed for the metric. So if Measurement Method / Task describe the holistic technique, then lmap = needs new terms. If Measurement Method / Task describe an MA's specific rol= e, then ippm needs new terms for the holistic technique (and holistic insta= ntiations of that technique). Barbara From nobody Thu May 29 09:15:19 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 DA3261A6FDB; Thu, 29 May 2014 09:15:17 -0700 (PDT) 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 m9ZSJasUCyQr; Thu, 29 May 2014 09:15:16 -0700 (PDT) Received: from p01c12o147.mxlogic.net (p01c12o147.mxlogic.net [208.65.145.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900301A6FE2; Thu, 29 May 2014 09:15:16 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p01c12o147.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 11d57835.2ba6c4646940.2363.00-550.6308.p01c12o147.mxlogic.net (envelope-from ); Thu, 29 May 2014 10:15:13 -0600 (MDT) X-MXL-Hash: 53875d11399bb634-5e6b9a53e3cc54c4fb605d906354a506a5855e5d Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p01c12o147.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id 38c57835.0.351.00-390.853.p01c12o147.mxlogic.net (envelope-from ); Thu, 29 May 2014 10:12:55 -0600 (MDT) X-MXL-Hash: 53875c8743ae2340-7fbe16387ab7c3cb4f45528bc4be0ad8b5297c7c 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, 29 May 2014 11:12:50 -0500 From: KEN KO To: "STARK, BARBARA H" , Nalini Elkins , marc.ibrahim , Juergen Schoenwaelder , Vero Zheng Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPez20702joYwCOkWjdsovVfKpjJtXjgGngAAKBCCAAGMZAP//vdpQ Date: Thu, 29 May 2014 16:12:49 +0000 Message-ID: References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D89A@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043D89A@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.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=HpX4GijS c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=4xzyoWqC86AA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=y1pov1uI18EA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=wcmwSzZ-Do27GHJv_CYA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014052919); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/rrg4L-Wlx_jThs4qnlSQ9aPIITc Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 16:15:18 -0000 I'll play. Inline ... >Looking at PING again. Let's consider a system where there is a MA (A)=20 >generating a PING message, receiving a response message, and calculating t= he=20 >time between these 2 events, an MA (B) receiving the PING and generating a= =20 >response, and an MA (C) that is in between A and B and counts the number o= f PING=20 >messages it sees. What I think I'm reading is: >1. A is doing an Active Measurement Task. >2. B is doing an Active Measurement Task. [Note that B hasn't measured any= thing.] >3. C is doing a Passive Measurement Task. >If the above is correct, I'd be fine with that. I agree with all three points. >So here's a multiple choice question for y'all: >B starts counting received PING messages. Select the correct answer from t= hose=20 >below, or invent a different answer. >1. B's counting of received PINGs is a new Passive Measurement Task, unrel= ated=20 >to the PING responding Task. >2. B's counting of received PINGs is part of the existing Active Measureme= nt=20 >Task that involves responding to PINGs. >3. B's counting of received PINGs is part of a new Active Measurement Task= ,=20 >unrelated to the PING responding Task. >4. All of the above could be true, depending on how the Measurement Method= s are=20 >defined. >5. 1 or 2 could be true, depending on how the Measurement Methods are defi= ned. IMO the correct answer is 5, with the following detail: - If the original Active Measurement Method specifies that B is to count re= ceived PINGs, then the answer is 2. - If the original Active Measurement Method does not specify the counting (= e.g., it is a 'vanilla' PING), then the answer is 1. From nobody Thu May 29 09:33: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 47DB71A6FC8; Thu, 29 May 2014 09:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, 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 YiYyJFsnKv_i; Thu, 29 May 2014 09:33:40 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E881A6FB9; Thu, 29 May 2014 09:33:40 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id la4so677058vcb.1 for ; Thu, 29 May 2014 09:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fOxt9wgAJSDGWr29AwmrYgNxeZxJbHTh6GKlY0I1mvg=; b=ltiBf2sCkFxMo2rhChsEuvCZx6DIvuC63akLjI56j+9gXzVccfQKPC1eoLOQEIjrbA ExLmbvFYZPgdWytL+zhMz3HLkQ/hFUCAQr23RCphHXvO8qeXAeQwOqjj4DL0YzM2a5ew svoi932L5f8FArNlBYEScYR0CbHFralbbb78saXKWjQEhBTEb9D1b9TIRewR60YH3GQj Q5tUa+jR5hAt0noW+ApioJd0MYfLjxZnmpreiascIQFaeJluRAiEqYQA4gDbwPxrridB RRcH5YxiphfmeKSvTBXOsDaQqESVGBzJ3e4MKI+7ZL2OprvlERH+Cqy3qed/bwHGK8XO cOHw== MIME-Version: 1.0 X-Received: by 10.221.66.131 with SMTP id xq3mr2849863vcb.43.1401381216136; Thu, 29 May 2014 09:33:36 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 29 May 2014 09:33:36 -0700 (PDT) In-Reply-To: References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.com> Date: Thu, 29 May 2014 09:33:36 -0700 Message-ID: From: Greg Mirsky To: KEN KO Content-Type: multipart/alternative; boundary=001a1136463295322104fa8c7da2 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/YDekuy8HfV8UR3uAwLWcxuqBH1o Cc: "draft-ietf-lmap-framework@tools.ietf.org" , "marc.ibrahim" , "ippm@ietf.org" , Nalini Elkins , Juergen Schoenwaelder , "lmap@ietf.org" , "STARK, BARBARA H" , Vero Zheng Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 16:33:43 -0000 --001a1136463295322104fa8c7da2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ken, I agree with the point Marc and you have brought up. I think that to differentiate whether articular method is Active or Passive may require introduction of a Measurement Domain object as set of cooperating MAs and MPs. Then measuring *explicitly* traffic that been injected by MA(s) in the same Measurement Domain would be Active Measurement Method/Task. But measuring on overall traffic even if that *may include* injected traffic, IMO, would be Passive Measurement Method/Task. Regards, Greg On Thu, May 29, 2014 at 7:17 AM, KEN KO wrote: > I agree with Marc=E2=80=99s comments, e.g., a Measurement Method is Acti= ve if > any MA involved in the measurement is generating measurement traffic. And > yes, PING is an Active Measurement Method. > > > > However, traffic measured by a Passive Method can easily include > measurement traffic generated by an unrelated Active Method. In this > context for instance, a Measurement Method that does nothing but count > received packets is still Passive, even if some of those packets are due = to > unrelated PINGs (or throughput tests, etc.). > > > > > *From:* lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of *Nalini Elkins > *Sent:* Thursday, May 29, 2014 9:31 AM > *To:* marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng > *Cc:* draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; > lmap@ietf.org > > *Subject:* Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > > The problem is what to consider as "injected traffic". For example, on > many networks, various devices, for their own purposes do PING commands. > So, then does that convert the entire measurement to active? > > > > Thanks, > > > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > > ------------------------------ > > *From:* marc.ibrahim > *To:* "STARK, BARBARA H" ; Nalini Elkins < > nalini.elkins@insidethestack.com>; Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de>; Vero Zheng > *Cc:* "lmap@ietf.org" ; "ippm@ietf.org" ; " > draft-ietf-lmap-framework@tools.ietf.org" < > draft-ietf-lmap-framework@tools.ietf.org> > *Sent:* Thursday, May 29, 2014 6:14 AM > *Subject:* Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > Hi, > > I think the confusion comes from whether or not to consider individual MA= . > For a single MA, measuring existing traffic is passive relatively to this > given MA. > But if this traffic was sent from another MA, then the whole method is > active since > somebody has injected traffic. > > I think the definitions of active and passive methods are not relative to > an MA but to > all MAs/MPs involved each measurement. If this is the case, "Receiving" i= s > not really > different from "generating" since an MA will receive and measure what has > been > generated. > > > BR, > > Marc. > > On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote > > ?? Receiving does or doesn't need to be a portion of the Active > Measurement > > Method definition? If a Passive Measurement Method is any method that > measures > > traffic without injecting traffic, doesn't that cover a Measurement > Method > > that measures received traffic? Barbara > > > > From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com] > > Sent: Thursday, May 29, 2014 8:49 AM > > To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng > > Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; > ippm@ietf.org > > Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > > /*snip*/ > > >>> Active Measurement Method - The process of measuring some > performance or > reliability parameter associated with the transfer of Traffic by > generating and/or > receiving Active Measurement Traffic. > > >>> > > /*snip*/ > > >>> Passive Measurement Method- The process of measuring some > performance or > reliability parameter associated with the existing traffic on the network= . > > /*snip*/ > > > > >>But what if I have an MA passively measuring traffic that was injecte= d > > >>(perhaps by some other MA) for the purpose of measuring it? Why is > > >>this distinction REAL vs non-REAL useful? And what is the definition > > >>of REAL of "existing traffic" anyway? If I inject measurement traffic > > >>observed by some MA, it is "existing traffic", no? > > > > > Yes, point well taken. The distinction we wanted to make is that the > passive > measurement technique does not inject traffic. Other MA's or indeed othe= r > devices on > the network create traffic for their own purposes, some of which may be > performance > measurement. We also wanted to come up with a good definition for passiv= e > measurement > that would work for all parties. How is the following? > > > > > Passive Measurement Method- The process of measuring some performance > or reliability > parameter associated with the traffic on the network. The passive > measurement method > does not inject traffic for the purposes of measurement. > > > > >>Would that mean that the definition of Active Measurement Method > wouldn't involve > receiving Active Measurement Traffic, and only generated (injecting)? > > >>Active Measurement Method - The process of measuring some performance > or reliability > parameter associated with the transfer of traffic by generating Active > Measurement > Traffic. > > > > Indeed, the word "receiving" needs to be a portion of the Active > Measurement > > Method definition. Thanks! > > > > Nalini > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > -- > Open WebMail Project (http://openwebmail.org > > ) > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > --001a1136463295322104fa8c7da2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ken,
I agree with the point Mar= c and you have brought up. I think that to differentiate whether articular = method is Active or Passive may require introduction of a Measurement Domai= n object as set of cooperating MAs and MPs. Then measuring explicitly traffic that been injected by MA(s) in the same Measurement Domain would = be Active Measurement Method/Task. But measuring on overall traffic even if= that may include injected traffic, IMO, would be Passive Measuremen= t Method/Task.

Regards,
Greg

On Thu, May 29, 2014 at 7:17 AM, KEN KO <KEN.= KO@adtran.com> wrote:

I agree with Marc=E2=80= =99s comments, e.g., a Measurement Method is Active if any MA involved in t= he measurement is generating measurement traffic. And yes, PING is an Active Measurement Method.

=C2=A0

However, traffic measured= by a Passive Method can easily include measurement traffic generated by an= unrelated Active Method. In this context for instance, a Measurement Method that does nothing but count received packets is still= Passive, even if some of those packets are due to unrelated PINGs (or thro= ughput tests, etc.).

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

From: lmap [ma= ilto:lmap-bounce= s@ietf.org] On Behalf Of Nalini Elkins
Sent: Thursday, May 29, 2014 9:31 AM
To: marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zhen= g
Cc: draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@ietf.org


Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.= txt

=C2=A0

The problem is what= to consider as "injected traffic". =C2=A0For example, on many ne= tworks, various devices, for their own purposes do PING commands. =C2=A0 = =C2=A0So, then does that convert the entire measurement to active?

=C2=A0

Thanks,

=C2=A0

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethest= ack.com

=C2=A0

From: marc.ibrahim <marc.ibrahim@usj.edu.lb>=
To: "STARK, BARBARA H" <bs7652@att.com>; Nalini Elkins <nalini.elkins@ins= idethestack.com>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-un= iversity.de>; Vero Zheng <= vero.zheng@huawei.com>
Cc: "lmap@ie= tf.org" <lma= p@ietf.org>; "ippm@ietf.org" <ippm@ietf.org>; "draft-ietf-lmap-framework@tools.ietf.= org" <draft-ietf-lmap-framework@tools.ietf.org>
Sent: Thursday, May 29, 2014 6:14 AM
Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.= txt


Hi,

I think the confusion comes from whether or not to consider individual MA.<= br> For a single MA, measuring existing traffic is passive relatively to this g= iven MA.
But if this traffic was sent from another MA, then the whole method is acti= ve since
somebody has injected traffic.

I think the definitions of active and passive methods are not relative to a= n MA but to
all MAs/MPs involved each measurement. If this is the case, "Receiving= " is not really
different from "generating" since an MA will receive and measure = what has been
generated.


BR,

Marc.

On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote
> ?? Receiving does or doesn't need to be a portion of the Active Me= asurement
> Method definition? If a Passive Measurement Method is any method that = measures
> traffic without injecting traffic, doesn't that cover a Measuremen= t Method
> that measures received traffic? Barbara
>
> From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com]
> Sent: Thursday, May 29, 2014 8:49 AM
> To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng
> Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org
> Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.tx= t
>
> /*snip*/
> >>> Active Measurement Method - The process of measuring some= performance or
reliability parameter associated with the transfer of Traffic by generating= and/or
receiving Active Measurement Traffic.
> >>>
> /*snip*/
> >>> Passive Measurement Method- The process of measuring some= performance or
reliability parameter associated with the existing traffic on the network.<= br> > /*snip*/
>
> >>But what if I have an MA passively measuring traffic that was = injected
> >>(perhaps by some other MA) for the purpose of measuring it? Wh= y is
> >>this distinction REAL vs non-REAL useful? And what is the defi= nition
> >>of REAL of "existing traffic" anyway? If I inject me= asurement traffic
> >>observed by some MA, it is "existing traffic", no? >
> > Yes, point well taken.=C2=A0 The distinction we wanted to make is= that the passive
measurement technique does not inject traffic.=C2=A0 Other MA's or inde= ed other devices on
the network create traffic for their own purposes, some of which may be per= formance
measurement.=C2=A0 We also wanted to come up with a good definition for pas= sive measurement
that would work for all parties.=C2=A0 How is the following?
>
> > Passive Measurement Method- The process of measuring some perform= ance or reliability
parameter associated with the traffic on the network.=C2=A0 The passive mea= surement method
does not inject traffic for the purposes of measurement.
>
> >>Would that mean that the definition of Active Measurement Meth= od wouldn't involve
receiving Active Measurement Traffic, and only generated (injecting)?
> >>Active Measurement Method - The process of measuring some perf= ormance or reliability
parameter associated with the transfer of traffic by generating Active Meas= urement
Traffic.
>
> Indeed, the word "receiving" needs to be a portion of the Ac= tive Measurement
> Method definition.=C2=A0 Thanks!
>
> Nalini
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org&l= t;mailto:lmap@ietf.org>




--
Open WebMail Project (http://openwebmail.org

)

=C2=A0


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


--001a1136463295322104fa8c7da2-- From nobody Thu May 29 09:40: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 542FB1A700C; Thu, 29 May 2014 09:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, 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 HXn1qYV7qGeP; Thu, 29 May 2014 09:40:41 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A63F1A6FFE; Thu, 29 May 2014 09:40:41 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id db11so688150veb.29 for ; Thu, 29 May 2014 09:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rohydHdHZP1z2fpWZ8eKylPKOg8mxmhQZ8v+nDa5DJs=; b=GGqpx6Qrrv5cXc6hVcT3AFwgzktuWvc5ds8U3+0LauxmafChADZY7L3g2CnO8bVa/A FlPnKcOcBwVsvFvs9nqBsa8nKMQraIvB14l2k2j1+w/W7gLHzaTgQfxL349eCfybeVln KQlSlHFo+TEpdsvlfP/JkpC3OIL5TNiEvjp6LYg4zk5EayAzbdd/zxi13FPiUg6swvlx MRfoGKMN0HAKGYgacDtH/SHCB/DdAZkqQgvFyBpi3dcHDreIq15c2TXEl8l8UaQmDopI CSAoaTHnBIv7CuVyUxWhoAEbO1tdUqhzNPpNcAIOa+VjFIaqs6q18DuYzwDJpsg1ln89 xSKw== MIME-Version: 1.0 X-Received: by 10.52.181.132 with SMTP id dw4mr1832916vdc.86.1401381636855; Thu, 29 May 2014 09:40:36 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 29 May 2014 09:40:36 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043D89A@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D89A@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Thu, 29 May 2014 09:40:36 -0700 Message-ID: From: Greg Mirsky To: "STARK, BARBARA H" Content-Type: multipart/alternative; boundary=bcaec547cba1a8dd3f04fa8c96e2 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/p7lITFhvF_O61gezA3lIdj9Rgyg Cc: "marc.ibrahim" , "lmap@ietf.org" , Nalini Elkins , Juergen Schoenwaelder , "ippm@ietf.org" , KEN KO , Vero Zheng Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 16:40:45 -0000 --bcaec547cba1a8dd3f04fa8c96e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Barbara, I think that if MA C counts only PINGs generated by A and B, then it is still Active Measurement Task. If MA C counts any PING it sees, then I'd consider it performing Passive Measurement in Measurement Domain that includes MAs A, B, and C. On the second set of questions: I agree with #3 Regards, Greg On Thu, May 29, 2014 at 8:01 AM, STARK, BARBARA H wrote: > I still have questions. I feel there=E2=80=99s still ambiguity and overl= ap in > proposed definitions. My main goal is to get rid of ambiguity and overlap= . > > > > One thing I read in Marc=E2=80=99s email was: > > We have MA1 sending UDP traffic to MA2. MA2 will receive UDP packet and > compute jitter. > > This is clearly an active measurement task for MA1. > > This to me suggests an idea that Active Measurement Method (or Task, whic= h > so far has been defined as an instantiation of a Method) doesn=E2=80=99t = need to > actually measure anything at all. It just needs to generate (inject) Acti= ve > Measurement Traffic. It may or may not measure any performance or > reliability parameters. That is, there was no description of MA1 measurin= g > the UDP traffic it sent to MA2, as a qualifier for identifying this as an > Active Measurement Task. > > > > Looking at PING again. Let=E2=80=99s consider a system where there is a M= A (A) > generating a PING message, receiving a response message, and calculating > the time between these 2 events, an MA (B) receiving the PING and > generating a response, and an MA (C) that is in between A and B and count= s > the number of PING messages it sees. What I think I=E2=80=99m reading is: > > 1. A is doing an Active Measurement Task. > > 2. B is doing an Active Measurement Task. [Note that B hasn=E2=80= =99t > measured anything.] > > 3. C is doing a Passive Measurement Task. > > If the above is correct, I=E2=80=99d be fine with that. > > > > So here=E2=80=99s a multiple choice question for y=E2=80=99all: > > B starts counting received PING messages. Select the correct answer from > those below, or invent a different answer. > > 1. B=E2=80=99s counting of received PINGs is a new Passive Measurem= ent > Task, unrelated to the PING responding Task. > > 2. B=E2=80=99s counting of received PINGs is part of the existing A= ctive > Measurement Task that involves responding to PINGs. > > 3. B=E2=80=99s counting of received PINGs is part of a new Active > Measurement Task, unrelated to the PING responding Task. > > 4. All of the above could be true, depending on how the Measurement > Methods are defined. > > 5. 1 or 2 could be true, depending on how the Measurement Methods > are defined. > > > > Barbara > > > > *From:* KEN KO [mailto:KEN.KO@adtran.com] > *Sent:* Thursday, May 29, 2014 10:18 AM > *To:* Nalini Elkins; marc.ibrahim; STARK, BARBARA H; Juergen > Schoenwaelder; Vero Zheng > *Cc:* draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; > lmap@ietf.org > *Subject:* RE: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > > I agree with Marc=E2=80=99s comments, e.g., a Measurement Method is Activ= e if any > MA involved in the measurement is generating measurement traffic. And yes= , > PING is an Active Measurement Method. > > > > However, traffic measured by a Passive Method can easily include > measurement traffic generated by an unrelated Active Method. In this > context for instance, a Measurement Method that does nothing but count > received packets is still Passive, even if some of those packets are due = to > unrelated PINGs (or throughput tests, etc.). > > > > > *From:* lmap [mailto:lmap-bounces@ietf.org ] *On > Behalf Of *Nalini Elkins > *Sent:* Thursday, May 29, 2014 9:31 AM > *To:* marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng > *Cc:* draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; > lmap@ietf.org > *Subject:* Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > > The problem is what to consider as "injected traffic". For example, on > many networks, various devices, for their own purposes do PING commands. > So, then does that convert the entire measurement to active? > > > > Thanks, > > > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > > ------------------------------ > > *From:* marc.ibrahim > *To:* "STARK, BARBARA H" ; Nalini Elkins < > nalini.elkins@insidethestack.com>; Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de>; Vero Zheng > *Cc:* "lmap@ietf.org" ; "ippm@ietf.org" ; " > draft-ietf-lmap-framework@tools.ietf.org" < > draft-ietf-lmap-framework@tools.ietf.org> > *Sent:* Thursday, May 29, 2014 6:14 AM > *Subject:* Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > Hi, > > I think the confusion comes from whether or not to consider individual MA= . > For a single MA, measuring existing traffic is passive relatively to this > given MA. > But if this traffic was sent from another MA, then the whole method is > active since > somebody has injected traffic. > > I think the definitions of active and passive methods are not relative to > an MA but to > all MAs/MPs involved each measurement. If this is the case, "Receiving" i= s > not really > different from "generating" since an MA will receive and measure what has > been > generated. > > > BR, > > Marc. > > On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote > > ?? Receiving does or doesn't need to be a portion of the Active > Measurement > > Method definition? If a Passive Measurement Method is any method that > measures > > traffic without injecting traffic, doesn't that cover a Measurement > Method > > that measures received traffic? Barbara > > > > From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com] > > Sent: Thursday, May 29, 2014 8:49 AM > > To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng > > Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; > ippm@ietf.org > > Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > > /*snip*/ > > >>> Active Measurement Method - The process of measuring some > performance or > reliability parameter associated with the transfer of Traffic by > generating and/or > receiving Active Measurement Traffic. > > >>> > > /*snip*/ > > >>> Passive Measurement Method- The process of measuring some > performance or > reliability parameter associated with the existing traffic on the network= . > > /*snip*/ > > > > >>But what if I have an MA passively measuring traffic that was injecte= d > > >>(perhaps by some other MA) for the purpose of measuring it? Why is > > >>this distinction REAL vs non-REAL useful? And what is the definition > > >>of REAL of "existing traffic" anyway? If I inject measurement traffic > > >>observed by some MA, it is "existing traffic", no? > > > > > Yes, point well taken. The distinction we wanted to make is that the > passive > measurement technique does not inject traffic. Other MA's or indeed othe= r > devices on > the network create traffic for their own purposes, some of which may be > performance > measurement. We also wanted to come up with a good definition for passiv= e > measurement > that would work for all parties. How is the following? > > > > > Passive Measurement Method- The process of measuring some performance > or reliability > parameter associated with the traffic on the network. The passive > measurement method > does not inject traffic for the purposes of measurement. > > > > >>Would that mean that the definition of Active Measurement Method > wouldn't involve > receiving Active Measurement Traffic, and only generated (injecting)? > > >>Active Measurement Method - The process of measuring some performance > or reliability > parameter associated with the transfer of traffic by generating Active > Measurement > Traffic. > > > > Indeed, the word "receiving" needs to be a portion of the Active > Measurement > > Method definition. Thanks! > > > > Nalini > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > -- > Open WebMail Project (http://openwebmail.org > > ) > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --bcaec547cba1a8dd3f04fa8c96e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Barbara,
I think that= if MA C counts only PINGs generated by A and B, then it is still Active Me= asurement Task. If MA C counts any PING it sees, then I'd consider it p= erforming Passive Measurement in Measurement Domain that includes MAs A, B,= and C.
On the second set of questions:
I agree with #3

Regards,
Greg


On Thu, May 29, 2014 at 8:01 AM, STARK, BARBARA H <bs7652= @att.com> wrote:

I still have questions. I= feel there=E2=80=99s still ambiguity and overlap in proposed definitions. = My main goal is to get rid of ambiguity and overlap.

=C2=A0

One thing I read in Marc= =E2=80=99s email was:

We have MA1 sending UDP traffic to MA2. MA2 will receive UDP packet and = compute jitter.

This is clearly an active measurement task for MA1.

This to me suggests an id= ea that Active Measurement Method (or Task, which so far has been defined a= s an instantiation of a Method) doesn=E2=80=99t need to actually measure anything at all. It just needs to generate (inject) Active Measure= ment Traffic. It may or may not measure any performance or reliability para= meters. That is, there was no description of MA1 measuring the UDP traffic = it sent to MA2, as a qualifier for identifying this as an Active Measurement Task.

=C2=A0

Looking at PING again. Le= t=E2=80=99s consider a system where there is a MA (A) generating a PING mes= sage, receiving a response message, and calculating the time between these 2 events, an MA (B) receiving the PING and generating a response, an= d an MA (C) that is in between A and B and counts the number of PING messag= es it sees. What I think I=E2=80=99m reading is:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A is doing an Active= Measurement Task.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B is doing an Active= Measurement Task. [Note that B hasn=E2=80=99t measured anything.]

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C is doing a Passive= Measurement Task.

If the above is correct, = I=E2=80=99d be fine with that.

=C2=A0

So here=E2=80=99s a multi= ple choice question for y=E2=80=99all:

B starts counting receive= d PING messages. Select the correct answer from those below, or invent a di= fferent answer.

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B=E2=80=99s counting= of received PINGs is a new Passive Measurement Task, unrelated to the PING= responding Task.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B=E2=80=99s counting= of received PINGs is part of the existing Active Measurement Task that inv= olves responding to PINGs.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B=E2=80=99s counting= of received PINGs is part of a new Active Measurement Task, unrelated to t= he PING responding Task.

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 All of the above cou= ld be true, depending on how the Measurement Methods are defined.=

5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 or 2 could be true= , depending on how the Measurement Methods are defined.

=C2=A0

Barbara

=C2=A0

From: KEN KO [= mailto:KEN.KO@adtran= .com]
Sent: Thursday, May 29, 2014 10:18 AM
To: Nalini Elkins; marc.ibrahim; STARK, BARBARA H; Juergen Schoenwae= lder; Vero Zheng
Cc: draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@ietf.org
Subject: RE: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.= txt

=C2=A0

I agree with Marc=E2=80= =99s comments, e.g., a Measurement Method is Active if any MA involved in t= he measurement is generating measurement traffic. And yes, PING is an Active Measurement Method.

=C2=A0

However, traffic measured= by a Passive Method can easily include measurement traffic generated by an= unrelated Active Method. In this context for instance, a Measurement Method that does nothing but count received packets is still= Passive, even if some of those packets are due to unrelated PINGs (or thro= ughput tests, etc.).

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

From: lmap [mailto:lmap-bounce= s@ietf.org] On Behalf Of Nalini Elkins
Sent: Thursday, May 29, 2014 9:31 AM
To: marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zhen= g
Cc: draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@ietf.org
Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.= txt

=C2=A0

The problem is what= to consider as "injected traffic". =C2=A0For example, on many ne= tworks, various devices, for their own purposes do PING commands. =C2=A0 = =C2=A0So, then does that convert the entire measurement to active?

=C2=A0

Thanks,

=C2=A0

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethest= ack.com

=C2=A0

From: marc.ibrahim <marc.ibrahim@usj.edu.lb>=
To: "STARK, BARBARA H" <bs7652@att.com>; Nalini Elkins <nalini.elkins@ins= idethestack.com>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-un= iversity.de>; Vero Zheng <= vero.zheng@huawei.com>
Cc: "lmap@ie= tf.org" <lma= p@ietf.org>; "ippm@ietf.org" <ippm@ietf.org>; "draft-ietf-lmap-framework@tools.ietf.= org" <draft-ietf-lmap-framework@tools.ietf.org>
Sent: Thursday, May 29, 2014 6:14 AM
Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.= txt


Hi,

I think the confusion comes from whether or not to consider individual MA.<= br> For a single MA, measuring existing traffic is passive relatively to this g= iven MA.
But if this traffic was sent from another MA, then the whole method is acti= ve since
somebody has injected traffic.

I think the definitions of active and passive methods are not relative to a= n MA but to
all MAs/MPs involved each measurement. If this is the case, "Receiving= " is not really
different from "generating" since an MA will receive and measure = what has been
generated.


BR,

Marc.

On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote
> ?? Receiving does or doesn't need to be a portion of the Active Me= asurement
> Method definition? If a Passive Measurement Method is any method that = measures
> traffic without injecting traffic, doesn't that cover a Measuremen= t Method
> that measures received traffic? Barbara
>
> From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com]
> Sent: Thursday, May 29, 2014 8:49 AM
> To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng
> Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org
> Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.tx= t
>
> /*snip*/
> >>> Active Measurement Method - The process of measuring some= performance or
reliability parameter associated with the transfer of Traffic by generating= and/or
receiving Active Measurement Traffic.
> >>>
> /*snip*/
> >>> Passive Measurement Method- The process of measuring some= performance or
reliability parameter associated with the existing traffic on the network.<= br> > /*snip*/
>
> >>But what if I have an MA passively measuring traffic that was = injected
> >>(perhaps by some other MA) for the purpose of measuring it? Wh= y is
> >>this distinction REAL vs non-REAL useful? And what is the defi= nition
> >>of REAL of "existing traffic" anyway? If I inject me= asurement traffic
> >>observed by some MA, it is "existing traffic", no? >
> > Yes, point well taken.=C2=A0 The distinction we wanted to make is= that the passive
measurement technique does not inject traffic.=C2=A0 Other MA's or inde= ed other devices on
the network create traffic for their own purposes, some of which may be per= formance
measurement.=C2=A0 We also wanted to come up with a good definition for pas= sive measurement
that would work for all parties.=C2=A0 How is the following?
>
> > Passive Measurement Method- The process of measuring some perform= ance or reliability
parameter associated with the traffic on the network.=C2=A0 The passive mea= surement method
does not inject traffic for the purposes of measurement.
>
> >>Would that mean that the definition of Active Measurement Meth= od wouldn't involve
receiving Active Measurement Traffic, and only generated (injecting)?
> >>Active Measurement Method - The process of measuring some perf= ormance or reliability
parameter associated with the transfer of traffic by generating Active Meas= urement
Traffic.
>
> Indeed, the word "receiving" needs to be a portion of the Ac= tive Measurement
> Method definition.=C2=A0 Thanks!
>
> Nalini
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org&l= t;mailto:lmap@ietf.org>




--
Open WebMail Project (http://openwebmail.org

)

=C2=A0


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


--bcaec547cba1a8dd3f04fa8c96e2-- From nobody Thu May 29 09:45: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 1810F1A6F66; Thu, 29 May 2014 09:45:15 -0700 (PDT) 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 LGMMvs4gUBZd; Thu, 29 May 2014 09:45:11 -0700 (PDT) Received: from p02c12o149.mxlogic.net (p02c12o149.mxlogic.net [208.65.145.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5E41A09AC; Thu, 29 May 2014 09:45:11 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o149.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 31467835.2b285a41c940.40110.00-552.112320.p02c12o149.mxlogic.net (envelope-from ); Thu, 29 May 2014 10:45:07 -0600 (MDT) X-MXL-Hash: 538764135d7ecfbe-d1bd931211a19a7ba4651d1e99cc385c3cbb5de1 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o149.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id bc367835.0.39398.00-378.110319.p02c12o149.mxlogic.net (envelope-from ); Thu, 29 May 2014 10:43:59 -0600 (MDT) X-MXL-Hash: 538763cf6c0cda28-1d66c74151a689cae1573af5228e4fdfdf647172 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, 29 May 2014 11:43:54 -0500 From: KEN KO To: "STARK, BARBARA H" , marc.ibrahim , Nalini Elkins , Juergen Schoenwaelder , Vero Zheng Thread-Topic: [ippm] [lmap] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe1kfukQnf68ckEy0AiWIyXF+rptXv6JQ Date: Thu, 29 May 2014 16:43:54 +0000 Message-ID: References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043D987@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.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=YLARyH2x c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=NHiKxY6niKYA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=y1pov1uI18EA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=48vgC7mUAAAA:8 a=Tu0VQQ1-OMNLfioict8A:9 a=CjuIK1q_8ug] X-AnalysisOut: [A:10 a=lZB815dzVvQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014052919); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/6Mz31D5W8hCr3_xxa9003nNGinE Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 16:45:15 -0000 I have always viewed Measurement Method/Task as independent from the viewpo= int of a specific MA - holistic, if you will. I would support any necessary= terminology that clarifies that definition. Even if we all accept the above interpretation, I don't think we need new t= erms in lmap. The 'initiating' MA's operational role should be fully define= d by the configuration and scheduling of a Measurement Task. Any other MAs = roles are communicated to them by the initiating MA, either in the form of = messages (eg, http GET) or something more specific to the Measurement Metho= d - again, fully defined via the configuration of the Task. Do we really ne= ed something new? > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of STARK, BARBARA > H > Sent: Thursday, May 29, 2014 12:14 PM > To: marc.ibrahim; Nalini Elkins; Juergen Schoenwaelder; Vero Zheng > Cc: ippm@ietf.org; lmap@ietf.org > Subject: Re: [ippm] [lmap] I-D Action: draft-ietf-lmap-framework-05.txt >=20 > > I think the confusion comes from whether or not to consider individual = MA. > > For a single MA, measuring existing traffic is passive relatively to > > this given MA. > > But if this traffic was sent from another MA, then the whole method is > > active since somebody has injected traffic. > > > > I think the definitions of active and passive methods are not relative > > to an MA but to all MAs/MPs involved each measurement. If this is the > > case, "Receiving" is not really different from "generating" since an > > MA will receive and measure what has been generated. >=20 > I'm not sure if it's confusion so much as it is the term ippm needs vs. t= he term > lmap needs. Lmap looks at the world from the perspective of the MA, and > from the perspective of the operation systems. Ippm looks at the world fr= om > the perspective of metrics (and what needs to happen to generate the > metrics). >=20 > Lmap needs terms that describe (generally and as a specific instantiation= of > the general term) what an MA does to accomplish its role in the term that > ippm needs. > It sounds like Ippm needs a term to describe holistically what is involve= d in > generation of a particular metric. >=20 > Using the same term (Measurement Method or its Measurement Task > instantiation) as both the MA functional role and as the holistic metric > generation method (task) is problematic. These need to be distinct terms. >=20 > In the context of the ippm registry, we really need registry entries to p= rovide > specifics for configuring each MA role that is part of the holistic syste= m > needed for the metric. >=20 > So if Measurement Method / Task describe the holistic technique, then lma= p > needs new terms. If Measurement Method / Task describe an MA's specific > role, then ippm needs new terms for the holistic technique (and holistic > instantiations of that technique). > Barbara >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Thu May 29 09:59: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 370061A7009 for ; Thu, 29 May 2014 09:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable 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 vj7CRezHqhJA for ; Thu, 29 May 2014 09:59:44 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id 63E451A04C5 for ; Thu, 29 May 2014 09:59:44 -0700 (PDT) X-ASG-Debug-ID: 1401383002-05fac105a224ddc0001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id BlupDqCrwanwOAm6; Thu, 29 May 2014 20:03:22 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from usj.edu.lb (localhost.localdomain [127.0.0.1]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s4TGxIRk031873; Thu, 29 May 2014 19:59:26 +0300 From: "marc.ibrahim" To: KEN KO , "STARK, BARBARA H" , Nalini Elkins , Juergen Schoenwaelder , Vero Zheng Date: Thu, 29 May 2014 19:59:18 +0300 X-ASG-Orig-Subj: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Message-Id: <20140529164842.M20408@usj.edu.lb> In-Reply-To: References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 37.209.253.165 (marc.ibrahim) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1401383002 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6215 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/20wjynEkaZ1epjD3gtAdukO7tX0 Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 16:59:47 -0000 On Thu, 29 May 2014 16:43:54 +0000, KEN KO wrote > I have always viewed Measurement Method/Task as independent from the viewpoint > of a specific MA - holistic, if you will. I would support any necessary > terminology that clarifies that definition. > > Even if we all accept the above interpretation, I don't think we need new > terms in lmap. The 'initiating' MA's operational role should be fully defined > by the configuration and scheduling of a Measurement Task. Any other MAs roles > are communicated to them by the initiating MA, either in the form of messages > (eg, http GET) or something more specific to the Measurement Method - again, > fully defined via the configuration of the Task. Do we really need something new? I agree with this view. I tend to say that the task transcends individual MA. In a simple A-B ping example, it is a single task initiated by A that is executing an active task that has been instructed by the controller, while B is just "participating" in the task. I don't see that we can we talk about a task being executed by B. Is replying to a ping a full task that can be instructed and scheduled by the controller? I don't see that. BR, Marc. > > > -----Original Message----- > > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of STARK, BARBARA > > H > > Sent: Thursday, May 29, 2014 12:14 PM > > To: marc.ibrahim; Nalini Elkins; Juergen Schoenwaelder; Vero Zheng > > Cc: ippm@ietf.org; lmap@ietf.org > > Subject: Re: [ippm] [lmap] I-D Action: draft-ietf-lmap-framework-05.txt > > > > > I think the confusion comes from whether or not to consider individual MA. > > > For a single MA, measuring existing traffic is passive relatively to > > > this given MA. > > > But if this traffic was sent from another MA, then the whole method is > > > active since somebody has injected traffic. > > > > > > I think the definitions of active and passive methods are not relative > > > to an MA but to all MAs/MPs involved each measurement. If this is the > > > case, "Receiving" is not really different from "generating" since an > > > MA will receive and measure what has been generated. > > > > I'm not sure if it's confusion so much as it is the term ippm needs vs. the term > > lmap needs. Lmap looks at the world from the perspective of the MA, and > > from the perspective of the operation systems. Ippm looks at the world from > > the perspective of metrics (and what needs to happen to generate the > > metrics). > > > > Lmap needs terms that describe (generally and as a specific instantiation of > > the general term) what an MA does to accomplish its role in the term that > > ippm needs. > > It sounds like Ippm needs a term to describe holistically what is involved in > > generation of a particular metric. > > > > Using the same term (Measurement Method or its Measurement Task > > instantiation) as both the MA functional role and as the holistic metric > > generation method (task) is problematic. These need to be distinct terms. > > > > In the context of the ippm registry, we really need registry entries to provide > > specifics for configuring each MA role that is part of the holistic system > > needed for the metric. > > > > So if Measurement Method / Task describe the holistic technique, then lmap > > needs new terms. If Measurement Method / Task describe an MA's specific > > role, then ippm needs new terms for the holistic technique (and holistic > > instantiations of that technique). > > Barbara > > > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Open WebMail Project (http://openwebmail.org) From nobody Thu May 29 10:20: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 3D4F01A0452; Thu, 29 May 2014 10:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 WyV3FTDx1JIX; Thu, 29 May 2014 10:20:27 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50CD1A03E9; Thu, 29 May 2014 10:20:26 -0700 (PDT) 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 75c67835.2b492181b940.5047170.00-2481.13038364.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 29 May 2014 17:20:23 +0000 (UTC) X-MXL-Hash: 53876c5772525e0f-d3a38927779399e3fbd080d503949d414016614a 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 b4c67835.0.5047068.00-2303.13038046.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 29 May 2014 17:20:13 +0000 (UTC) X-MXL-Hash: 53876c4d2625ab14-a1fe8229bb4fd9d91e5a13365f326ada1bfe5c4e 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 s4THKAGS013477; Thu, 29 May 2014 13:20:11 -0400 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 s4THK2qS013182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 13:20:05 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (GAALPA1MSGHUB9D.itservices.sbc.com [130.8.36.90]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 29 May 2014 17:19:46 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.03.0174.001; Thu, 29 May 2014 13:19:33 -0400 From: "STARK, BARBARA H" To: "marc.ibrahim" , KEN KO , "Nalini Elkins" , Juergen Schoenwaelder , Vero Zheng Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe19g7JlyMC2zj0SiwX4AAU19WZtXynkg Date: Thu, 29 May 2014 17:19:33 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> In-Reply-To: <20140529164842.M20408@usj.edu.lb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.61.133] 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=HL104PRv c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=in1mFPvdBZUA:10 a=ofMgfj31e3cA:10 a=xRrNQLmB5r0A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=rqxgusz_uzaVAIF0c0YA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/f5dTPwzDg04QNmpOS0YUUeYOlP8 Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 17:20:28 -0000 > In a simple A-B ping example, it is a single task initiated by A that is = executing > an active task that has been instructed by the controller, while B is jus= t > "participating" > in the task. I don't see that we can we talk about a task being executed = by B. > Is replying to a ping a full task that can be instructed and scheduled by= the > controller? I don't see that. I think it would be possible to schedule B to only respond to pings at cert= ain times of day. Responding to ping is something that can be enabled/disab= led. In which case it can be enabled and disabled according to a schedule. = The enabling/disabling of B's ability to respond to pings can be completely= and totally distinct from any schedules that involve B initiating ping -- = they are 2 distinct roles. Configuration of these roles is also distinct (r= esponding may not require any configuration other than the schedule, or it = could be configured to only respond to pings from certain IP addresses). It= may even be that an MA only has the ability to initiate ping and never res= pond, or vice versa. I very much believe that from the MA perspective (lmap), it is critical tha= t we be able to talk about the MA's role in a holistic technique. I also be= lieve that the MA can have a passive role (does not generate measurement tr= affic) or an active role (generates measurement traffic) independent of how= ippm may choose to characterize the holistic technique. Barbara=20 From nobody Thu May 29 11:17: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 734731A0940; Thu, 29 May 2014 11:17:31 -0700 (PDT) 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 8YhfWwuZ7GGX; Thu, 29 May 2014 11:17:28 -0700 (PDT) Received: from p02c11o149.mxlogic.net (p02c11o149.mxlogic.net [208.65.144.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9C51A04A3; Thu, 29 May 2014 11:17:28 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c11o149.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 5b977835.2adde1047940.5107.00-535.13168.p02c11o149.mxlogic.net (envelope-from ); Thu, 29 May 2014 12:17:25 -0600 (MDT) X-MXL-Hash: 538779b5575003a1-2bf5fb47c65cc0b732355ba29274eb631890b7bb Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c11o149.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id f5977835.0.4211.00-388.10905.p02c11o149.mxlogic.net (envelope-from ); Thu, 29 May 2014 12:16:05 -0600 (MDT) X-MXL-Hash: 538779657d8e10ed-a67e47d8c02a71417ae114a8dd3fda7b92999892 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; Thu, 29 May 2014 13:15:58 -0500 From: KEN KO To: "STARK, BARBARA H" , marc.ibrahim , Nalini Elkins , Juergen Schoenwaelder , Vero Zheng , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe19m4ogsNcYgEECVMd9hDcgkN5tYIWOA//+zJkA= Date: Thu, 29 May 2014 18:15:58 +0000 Message-ID: References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043DA2B@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.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=B6830YdM c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=in1mFPvdBZUA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=y1pov1uI18EA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=zQP7CpKOAAAA:8 a=48vgC7mUAAAA:8 a=TlXxsM7sYVR4ih2dm6g] X-AnalysisOut: [A:9 a=CjuIK1q_8ugA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014052921); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/zcvTJBIJEKKmmSTrfdxQRIH8Kik Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 18:17:31 -0000 Barbara, I agree with most of what you are saying. Measurement Methods can be complex and can create different roles for diffe= rent MAs, and it is very possible for each MA to be configured only with it= s own role. There may be Methods for which MA A could participate with MAs = B and C without a priori knowledge of their roles, and get completely diffe= rent yet equally proper responses from each of them. I hadn't considered th= is and it contradicts my earlier comment (which I rescind) about the initia= ting MA having all information relevant to a Task. Having said all that, I still don't see the need for a new term beyond the = language we have already used - that is, each MA's role in executing a Task= . While we're at it, we might want to consider the above scenario with regard= to the draft Information Model. Can we currently configure a Task as being= triggered by something other than a Schedule - in response to an external = stimulus like a message from a remote MA? I think we can: - One or more ma-task-options objects within ma-task-obj specifies the non-= Schedule conditions under which the Task is initiated. Unless Schedule-base= d initiation is also desired, the Measurement Task Configuration would not = be referenced in a local Schedule. However, I don't see this addressed explicitly in either the framework or t= he information model, and if this behavior is in scope I think it needs lan= guage for clarity. The other area you touch on (unilateral exceptions where, for instance, a M= A does not respond to MAs outside a configured address range) seems equally= valid, and I'm more open to a new term to describe it. Does "exceptions" = fit the bill? Ken > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Thursday, May 29, 2014 1:20 PM > To: marc.ibrahim; KEN KO; Nalini Elkins; Juergen Schoenwaelder; Vero Zhen= g > Cc: lmap@ietf.org; ippm@ietf.org > Subject: RE: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt >=20 > > In a simple A-B ping example, it is a single task initiated by A that > > is executing an active task that has been instructed by the > > controller, while B is just "participating" > > in the task. I don't see that we can we talk about a task being execute= d by > B. > > Is replying to a ping a full task that can be instructed and scheduled > > by the controller? I don't see that. >=20 > I think it would be possible to schedule B to only respond to pings at ce= rtain > times of day. Responding to ping is something that can be enabled/disable= d. > In which case it can be enabled and disabled according to a schedule. The > enabling/disabling of B's ability to respond to pings can be completely a= nd > totally distinct from any schedules that involve B initiating ping -- the= y are 2 > distinct roles. Configuration of these roles is also distinct (responding= may not > require any configuration other than the schedule, or it could be configu= red > to only respond to pings from certain IP addresses). It may even be that = an > MA only has the ability to initiate ping and never respond, or vice versa= . >=20 > I very much believe that from the MA perspective (lmap), it is critical t= hat we > be able to talk about the MA's role in a holistic technique. I also belie= ve that > the MA can have a passive role (does not generate measurement traffic) or > an active role (generates measurement traffic) independent of how ippm > may choose to characterize the holistic technique. > Barbara From nobody Thu May 29 14:26: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 7AF291A0437; Thu, 29 May 2014 14:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 dagiRyEiKnCA; Thu, 29 May 2014 14:26:43 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13291A0417; Thu, 29 May 2014 14:26:42 -0700 (PDT) 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 f06a7835.2b491820c940.5216158.00-2443.13484760.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 29 May 2014 21:26:39 +0000 (UTC) X-MXL-Hash: 5387a60f20ea0a5d-6a310c21abde003ef4d15a7fd9b4ad388bcfb355 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 b06a7835.0.5216137.00-2372.13484699.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 29 May 2014 21:26:36 +0000 (UTC) X-MXL-Hash: 5387a60c35279472-03e66e1ff19ad271197313f3928a80c0f1b5f659 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 s4TLQYic000345; Thu, 29 May 2014 17:26:34 -0400 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 s4TLQSqa032744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 17:26:29 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (GAALPA1MSGHUB9D.itservices.sbc.com [130.8.36.90]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 29 May 2014 21:26:15 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.03.0174.001; Thu, 29 May 2014 17:26:15 -0400 From: "STARK, BARBARA H" To: KEN KO , "marc.ibrahim" , "Nalini Elkins" , Juergen Schoenwaelder , Vero Zheng , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe19g7JlyMC2zj0SiwX4AAU19WZtXynkggABV6gD//99KoA== Date: Thu, 29 May 2014 21:26:14 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113043DB82@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@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.61.133] 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=HL104PRv c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=in1mFPvdBZUA:10 a=ofMgfj31e3cA:10 a=xRrNQLmB5r0A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=6zLQ2WrgX0fIloVoRcAA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/CUqNLOR2YtIFptlurVeqAuUMN7s Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 21:26:45 -0000 > Measurement Methods can be complex and can create different roles for > different MAs, and it is very possible for each MA to be configured only = with > its own role. There may be Methods for which MA A could participate with > MAs B and C without a priori knowledge of their roles, and get completely > different yet equally proper responses from each of them. I hadn't > considered this and it contradicts my earlier comment (which I rescind) a= bout > the initiating MA having all information relevant to a Task. >=20 > Having said all that, I still don't see the need for a new term beyond th= e > language we have already used - that is, each MA's role in executing a Ta= sk. I'm becoming ever more strongly convinced that either ippm or lmap needs a = new term -- I don't care which. But my reading of framework and the informa= tion model is that what lmap is calling a Measurement Method and Measuremen= t Task is related to the specific role the MA plays in the holistic techniq= ue. The MA absolutely does not need to know what other roles do or how they= are configured. It doesn't care what they do. It only knows what it has to= do. I think this is also important to understand in the design of the regi= stry -- if there is some metric in the registry that requires proper config= uration of multiple roles, the registry needs to be able to express what th= e proper configuration is for each distinct role. As a compromise (since ma= ny seem to want Measurement Method to be the holistic technique) maybe we s= hould use Measurement Method for the holistic technique (and ippm can defin= e that, because it's not really central to lmap), Measurement Method Role f= or the role of the Measurement Method that is implemented on a MA, and Meas= urement Task is an instantiation of a Measurement Method Role (which means = a Task is *not* an instantiation of the Measurement Method -- which assumes= ippm doesn't need a term for an instantiation of the holistic technique). = Then lmap can have a Measurement Method Active Role that generates measurem= ent traffic and may measure parameters, and a Measurement Method Passive Ro= le that does not generate traffic and measures parameters. Ippm can define = if there're such things as Active or Passive Measurement Methods. In lmap, = we really only need to care about whether the role is active or passive, an= d not how the holistic technique is characterized.=20 > While we're at it, we might want to consider the above scenario with rega= rd > to the draft Information Model. Can we currently configure a Task as bein= g > triggered by something other than a Schedule - in response to an external > stimulus like a message from a remote MA? I think we can: > - One or more ma-task-options objects within ma-task-obj specifies the no= n- > Schedule conditions under which the Task is initiated. Unless Schedule-ba= sed > initiation is also desired, the Measurement Task Configuration would not = be > referenced in a local Schedule. I thought we'd discussed the possibility of a schedule that had no end time= /date? Which could effectively schedule a Measurement Task to always be "on= " and awaiting a trigger. > However, I don't see this addressed explicitly in either the framework or= the > information model, and if this behavior is in scope I think it needs lang= uage > for clarity. Agreed. I think it would be useful to describe. After we get our terms stra= ightened out (again). =20 > The other area you touch on (unilateral exceptions where, for instance, a= MA > does not respond to MAs outside a configured address range) seems equally > valid, and I'm more open to a new term to describe it. Does "exceptions"= fit > the bill? I think this is just configuration. I think it's likely that most every Mea= surement Method "role" will have some configuration elements that are expec= ted to stay relatively fixed. The MA will probably come with defaults for t= hese. I think this can be part of the bootstrapped configuration that may b= e changed by the Controller. Barbara From nobody Thu May 29 20: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 2EFAD1A031B; Thu, 29 May 2014 20:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 LRGNHfytz6I7; Thu, 29 May 2014 20:36:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CF41A02F9; Thu, 29 May 2014 20:36:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHK66189; Fri, 30 May 2014 03:36:05 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 04:35:28 +0100 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 04:36:03 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.46]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 30 May 2014 11:36:01 +0800 From: Mach Chen To: Greg Mirsky , KEN KO Thread-Topic: [ippm] [lmap] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe1vLkFxfWjL7IU+8nWf9FVkUd5tYeG1Q Date: Fri, 30 May 2014 03:36:00 +0000 Message-ID: References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D9F2066SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/LihL92hYEcMXS3o2VRD5O2CIOoA Cc: "ippm@ietf.org" , "marc.ibrahim" , "lmap@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 30 May 2014 03:36:19 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D9F2066SZXEMA510MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZyBhbmQgYWxsLA0KDQpJIHRvdGFsbHkgYWdyZWUgd2l0aCBHcmVn4oCZcyBwb2ludCBo ZXJlLiBJIGxpa2UgdGhlIGlkZWEgb2Yg4oCcTWVhc3VyZW1lbnQgRG9tYWluIG9iamVjdOKAnS4N Cg0KQmVzdCByZWdhcmRzLA0KTWFjaA0KDQpGcm9tOiBpcHBtIFttYWlsdG86aXBwbS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZyBNaXJza3kNClNlbnQ6IEZyaWRheSwgTWF5IDMw LCAyMDE0IDEyOjM0IEFNDQpUbzogS0VOIEtPDQpDYzogZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29y a0B0b29scy5pZXRmLm9yZzsgbWFyYy5pYnJhaGltOyBpcHBtQGlldGYub3JnOyBsbWFwQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW2lwcG1dIFtsbWFwXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWxt YXAtZnJhbWV3b3JrLTA1LnR4dA0KDQpIaSBLZW4sDQpJIGFncmVlIHdpdGggdGhlIHBvaW50IE1h cmMgYW5kIHlvdSBoYXZlIGJyb3VnaHQgdXAuIEkgdGhpbmsgdGhhdCB0byBkaWZmZXJlbnRpYXRl IHdoZXRoZXIgYXJ0aWN1bGFyIG1ldGhvZCBpcyBBY3RpdmUgb3IgUGFzc2l2ZSBtYXkgcmVxdWly ZSBpbnRyb2R1Y3Rpb24gb2YgYSBNZWFzdXJlbWVudCBEb21haW4gb2JqZWN0IGFzIHNldCBvZiBj b29wZXJhdGluZyBNQXMgYW5kIE1Qcy4gVGhlbiBtZWFzdXJpbmcgZXhwbGljaXRseSB0cmFmZmlj IHRoYXQgYmVlbiBpbmplY3RlZCBieSBNQShzKSBpbiB0aGUgc2FtZSBNZWFzdXJlbWVudCBEb21h aW4gd291bGQgYmUgQWN0aXZlIE1lYXN1cmVtZW50IE1ldGhvZC9UYXNrLiBCdXQgbWVhc3VyaW5n IG9uIG92ZXJhbGwgdHJhZmZpYyBldmVuIGlmIHRoYXQgbWF5IGluY2x1ZGUgaW5qZWN0ZWQgdHJh ZmZpYywgSU1PLCB3b3VsZCBiZSBQYXNzaXZlIE1lYXN1cmVtZW50IE1ldGhvZC9UYXNrLg0KUmVn YXJkcywNCkdyZWcNCg0KT24gVGh1LCBNYXkgMjksIDIwMTQgYXQgNzoxNyBBTSwgS0VOIEtPIDxL RU4uS09AYWR0cmFuLmNvbTxtYWlsdG86S0VOLktPQGFkdHJhbi5jb20+PiB3cm90ZToNCkkgYWdy ZWUgd2l0aCBNYXJj4oCZcyBjb21tZW50cywgZS5nLiwgYSBNZWFzdXJlbWVudCBNZXRob2QgaXMg QWN0aXZlIGlmIGFueSBNQSBpbnZvbHZlZCBpbiB0aGUgbWVhc3VyZW1lbnQgaXMgZ2VuZXJhdGlu ZyBtZWFzdXJlbWVudCB0cmFmZmljLiBBbmQgeWVzLCBQSU5HIGlzIGFuIEFjdGl2ZSBNZWFzdXJl bWVudCBNZXRob2QuDQoNCkhvd2V2ZXIsIHRyYWZmaWMgbWVhc3VyZWQgYnkgYSBQYXNzaXZlIE1l dGhvZCBjYW4gZWFzaWx5IGluY2x1ZGUgbWVhc3VyZW1lbnQgdHJhZmZpYyBnZW5lcmF0ZWQgYnkg YW4gdW5yZWxhdGVkIEFjdGl2ZSBNZXRob2QuIEluIHRoaXMgY29udGV4dCBmb3IgaW5zdGFuY2Us IGEgTWVhc3VyZW1lbnQgTWV0aG9kIHRoYXQgZG9lcyBub3RoaW5nIGJ1dCBjb3VudCByZWNlaXZl ZCBwYWNrZXRzIGlzIHN0aWxsIFBhc3NpdmUsIGV2ZW4gaWYgc29tZSBvZiB0aG9zZSBwYWNrZXRz IGFyZSBkdWUgdG8gdW5yZWxhdGVkIFBJTkdzIChvciB0aHJvdWdocHV0IHRlc3RzLCBldGMuKS4N Cg0KRnJvbTogbG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bG1hcC1i b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIE5hbGluaSBFbGtpbnMNClNlbnQ6IFRodXJz ZGF5LCBNYXkgMjksIDIwMTQgOTozMSBBTQ0KVG86IG1hcmMuaWJyYWhpbTsgU1RBUkssIEJBUkJB UkEgSDsgSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBWZXJvIFpoZW5nDQpDYzogZHJhZnQtaWV0Zi1s bWFwLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1sbWFwLWZyYW1l d29ya0B0b29scy5pZXRmLm9yZz47IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+ OyBsbWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW2xt YXBdIFtpcHBtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA1LnR4dA0K DQpUaGUgcHJvYmxlbSBpcyB3aGF0IHRvIGNvbnNpZGVyIGFzICJpbmplY3RlZCB0cmFmZmljIi4g IEZvciBleGFtcGxlLCBvbiBtYW55IG5ldHdvcmtzLCB2YXJpb3VzIGRldmljZXMsIGZvciB0aGVp ciBvd24gcHVycG9zZXMgZG8gUElORyBjb21tYW5kcy4gICAgU28sIHRoZW4gZG9lcyB0aGF0IGNv bnZlcnQgdGhlIGVudGlyZSBtZWFzdXJlbWVudCB0byBhY3RpdmU/DQoNClRoYW5rcywNCg0KTmFs aW5pIEVsa2lucw0KSW5zaWRlIFByb2R1Y3RzLCBJbmMuDQooODMxKSA2NTktODM2MDx0ZWw6JTI4 ODMxJTI5JTIwNjU5LTgzNjA+DQp3d3cuaW5zaWRldGhlc3RhY2suY29tPGh0dHA6Ly93d3cuaW5z aWRldGhlc3RhY2suY29tPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJv bTogbWFyYy5pYnJhaGltIDxtYXJjLmlicmFoaW1AdXNqLmVkdS5sYjxtYWlsdG86bWFyYy5pYnJh aGltQHVzai5lZHUubGI+Pg0KVG86ICJTVEFSSywgQkFSQkFSQSBIIiA8YnM3NjUyQGF0dC5jb208 bWFpbHRvOmJzNzY1MkBhdHQuY29tPj47IE5hbGluaSBFbGtpbnMgPG5hbGluaS5lbGtpbnNAaW5z aWRldGhlc3RhY2suY29tPG1haWx0bzpuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT4+ OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0 eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj47IFZlcm8g WmhlbmcgPHZlcm8uemhlbmdAaHVhd2VpLmNvbTxtYWlsdG86dmVyby56aGVuZ0BodWF3ZWkuY29t Pj4NCkNjOiAibG1hcEBpZXRmLm9yZzxtYWlsdG86bG1hcEBpZXRmLm9yZz4iIDxsbWFwQGlldGYu b3JnPG1haWx0bzpsbWFwQGlldGYub3JnPj47ICJpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGll dGYub3JnPiIgPGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+PjsgImRyYWZ0LWll dGYtbG1hcC1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbG1hcC1m cmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0b29s cy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0b29scy5pZXRmLm9y Zz4+DQpTZW50OiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0IDY6MTQgQU0NClN1YmplY3Q6IFJlOiBb bG1hcF0gW2lwcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDUudHh0 DQoNCkhpLA0KDQpJIHRoaW5rIHRoZSBjb25mdXNpb24gY29tZXMgZnJvbSB3aGV0aGVyIG9yIG5v dCB0byBjb25zaWRlciBpbmRpdmlkdWFsIE1BLg0KRm9yIGEgc2luZ2xlIE1BLCBtZWFzdXJpbmcg ZXhpc3RpbmcgdHJhZmZpYyBpcyBwYXNzaXZlIHJlbGF0aXZlbHkgdG8gdGhpcyBnaXZlbiBNQS4N CkJ1dCBpZiB0aGlzIHRyYWZmaWMgd2FzIHNlbnQgZnJvbSBhbm90aGVyIE1BLCB0aGVuIHRoZSB3 aG9sZSBtZXRob2QgaXMgYWN0aXZlIHNpbmNlDQpzb21lYm9keSBoYXMgaW5qZWN0ZWQgdHJhZmZp Yy4NCg0KSSB0aGluayB0aGUgZGVmaW5pdGlvbnMgb2YgYWN0aXZlIGFuZCBwYXNzaXZlIG1ldGhv ZHMgYXJlIG5vdCByZWxhdGl2ZSB0byBhbiBNQSBidXQgdG8NCmFsbCBNQXMvTVBzIGludm9sdmVk IGVhY2ggbWVhc3VyZW1lbnQuIElmIHRoaXMgaXMgdGhlIGNhc2UsICJSZWNlaXZpbmciIGlzIG5v dCByZWFsbHkNCmRpZmZlcmVudCBmcm9tICJnZW5lcmF0aW5nIiBzaW5jZSBhbiBNQSB3aWxsIHJl Y2VpdmUgYW5kIG1lYXN1cmUgd2hhdCBoYXMgYmVlbg0KZ2VuZXJhdGVkLg0KDQoNCkJSLA0KDQpN YXJjLg0KDQpPbiBUaHUsIDI5IE1heSAyMDE0IDEyOjU3OjM1ICswMDAwLCBTVEFSSywgQkFSQkFS QSBIIHdyb3RlDQo+ID8/IFJlY2VpdmluZyBkb2VzIG9yIGRvZXNuJ3QgbmVlZCB0byBiZSBhIHBv cnRpb24gb2YgdGhlIEFjdGl2ZSBNZWFzdXJlbWVudA0KPiBNZXRob2QgZGVmaW5pdGlvbj8gSWYg YSBQYXNzaXZlIE1lYXN1cmVtZW50IE1ldGhvZCBpcyBhbnkgbWV0aG9kIHRoYXQgbWVhc3VyZXMN Cj4gdHJhZmZpYyB3aXRob3V0IGluamVjdGluZyB0cmFmZmljLCBkb2Vzbid0IHRoYXQgY292ZXIg YSBNZWFzdXJlbWVudCBNZXRob2QNCj4gdGhhdCBtZWFzdXJlcyByZWNlaXZlZCB0cmFmZmljPyBC YXJiYXJhDQo+DQo+IEZyb206IE5hbGluaSBFbGtpbnMgW21haWx0bzpuYWxpbmkuZWxraW5zQGlu c2lkZXRoZXN0YWNrLmNvbTxtYWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20+ XQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0IDg6NDkgQU0NCj4gVG86IFNUQVJLLCBC QVJCQVJBIEg7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgVmVybyBaaGVuZw0KPiBDYzogZHJhZnQt aWV0Zi1sbWFwLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1sbWFw LWZyYW1ld29ya0B0b29scy5pZXRmLm9yZz47IGxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBAaWV0 Zi5vcmc+OyBpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KPiBTdWJqZWN0OiBS ZTogW2xtYXBdIFtpcHBtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA1 LnR4dA0KPg0KPiAvKnNuaXAqLw0KPiA+Pj4gQWN0aXZlIE1lYXN1cmVtZW50IE1ldGhvZCAtIFRo ZSBwcm9jZXNzIG9mIG1lYXN1cmluZyBzb21lIHBlcmZvcm1hbmNlIG9yDQpyZWxpYWJpbGl0eSBw YXJhbWV0ZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSB0cmFuc2ZlciBvZiBUcmFmZmljIGJ5IGdlbmVy YXRpbmcgYW5kL29yDQpyZWNlaXZpbmcgQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMuDQo+ID4+ Pg0KPiAvKnNuaXAqLw0KPiA+Pj4gUGFzc2l2ZSBNZWFzdXJlbWVudCBNZXRob2QtIFRoZSBwcm9j ZXNzIG9mIG1lYXN1cmluZyBzb21lIHBlcmZvcm1hbmNlIG9yDQpyZWxpYWJpbGl0eSBwYXJhbWV0 ZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSBleGlzdGluZyB0cmFmZmljIG9uIHRoZSBuZXR3b3JrLg0K PiAvKnNuaXAqLw0KPg0KPiA+PkJ1dCB3aGF0IGlmIEkgaGF2ZSBhbiBNQSBwYXNzaXZlbHkgbWVh c3VyaW5nIHRyYWZmaWMgdGhhdCB3YXMgaW5qZWN0ZWQNCj4gPj4ocGVyaGFwcyBieSBzb21lIG90 aGVyIE1BKSBmb3IgdGhlIHB1cnBvc2Ugb2YgbWVhc3VyaW5nIGl0PyBXaHkgaXMNCj4gPj50aGlz IGRpc3RpbmN0aW9uIFJFQUwgdnMgbm9uLVJFQUwgdXNlZnVsPyBBbmQgd2hhdCBpcyB0aGUgZGVm aW5pdGlvbg0KPiA+Pm9mIFJFQUwgb2YgImV4aXN0aW5nIHRyYWZmaWMiIGFueXdheT8gSWYgSSBp bmplY3QgbWVhc3VyZW1lbnQgdHJhZmZpYw0KPiA+Pm9ic2VydmVkIGJ5IHNvbWUgTUEsIGl0IGlz ICJleGlzdGluZyB0cmFmZmljIiwgbm8/DQo+DQo+ID4gWWVzLCBwb2ludCB3ZWxsIHRha2VuLiAg VGhlIGRpc3RpbmN0aW9uIHdlIHdhbnRlZCB0byBtYWtlIGlzIHRoYXQgdGhlIHBhc3NpdmUNCm1l YXN1cmVtZW50IHRlY2huaXF1ZSBkb2VzIG5vdCBpbmplY3QgdHJhZmZpYy4gIE90aGVyIE1BJ3Mg b3IgaW5kZWVkIG90aGVyIGRldmljZXMgb24NCnRoZSBuZXR3b3JrIGNyZWF0ZSB0cmFmZmljIGZv ciB0aGVpciBvd24gcHVycG9zZXMsIHNvbWUgb2Ygd2hpY2ggbWF5IGJlIHBlcmZvcm1hbmNlDQpt ZWFzdXJlbWVudC4gIFdlIGFsc28gd2FudGVkIHRvIGNvbWUgdXAgd2l0aCBhIGdvb2QgZGVmaW5p dGlvbiBmb3IgcGFzc2l2ZSBtZWFzdXJlbWVudA0KdGhhdCB3b3VsZCB3b3JrIGZvciBhbGwgcGFy dGllcy4gIEhvdyBpcyB0aGUgZm9sbG93aW5nPw0KPg0KPiA+IFBhc3NpdmUgTWVhc3VyZW1lbnQg TWV0aG9kLSBUaGUgcHJvY2VzcyBvZiBtZWFzdXJpbmcgc29tZSBwZXJmb3JtYW5jZSBvciByZWxp YWJpbGl0eQ0KcGFyYW1ldGVyIGFzc29jaWF0ZWQgd2l0aCB0aGUgdHJhZmZpYyBvbiB0aGUgbmV0 d29yay4gIFRoZSBwYXNzaXZlIG1lYXN1cmVtZW50IG1ldGhvZA0KZG9lcyBub3QgaW5qZWN0IHRy YWZmaWMgZm9yIHRoZSBwdXJwb3NlcyBvZiBtZWFzdXJlbWVudC4NCj4NCj4gPj5Xb3VsZCB0aGF0 IG1lYW4gdGhhdCB0aGUgZGVmaW5pdGlvbiBvZiBBY3RpdmUgTWVhc3VyZW1lbnQgTWV0aG9kIHdv dWxkbid0IGludm9sdmUNCnJlY2VpdmluZyBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYywgYW5k IG9ubHkgZ2VuZXJhdGVkIChpbmplY3RpbmcpPw0KPiA+PkFjdGl2ZSBNZWFzdXJlbWVudCBNZXRo b2QgLSBUaGUgcHJvY2VzcyBvZiBtZWFzdXJpbmcgc29tZSBwZXJmb3JtYW5jZSBvciByZWxpYWJp bGl0eQ0KcGFyYW1ldGVyIGFzc29jaWF0ZWQgd2l0aCB0aGUgdHJhbnNmZXIgb2YgdHJhZmZpYyBi eSBnZW5lcmF0aW5nIEFjdGl2ZSBNZWFzdXJlbWVudA0KVHJhZmZpYy4NCj4NCj4gSW5kZWVkLCB0 aGUgd29yZCAicmVjZWl2aW5nIiBuZWVkcyB0byBiZSBhIHBvcnRpb24gb2YgdGhlIEFjdGl2ZSBN ZWFzdXJlbWVudA0KPiBNZXRob2QgZGVmaW5pdGlvbi4gIFRoYW5rcyENCj4NCj4gTmFsaW5pDQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGxt YXAgbWFpbGluZyBsaXN0DQo+IGxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBAaWV0Zi5vcmc+PG1h aWx0bzpsbWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYub3JnPj4NCg0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCg0KDQoNCi0tDQpPcGVuIFdlYk1haWwg UHJvamVjdCAoaHR0cDovL29wZW53ZWJtYWlsLm9yZzxodHRwOi8vb3BlbndlYm1haWwub3JnLz4N CikNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bG1hcCBtYWlsaW5nIGxpc3QNCmxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCg0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D9F2066SZXEMA510MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIj4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDEyIj4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxQ0Y3QkZCLjU0NTQxQ0MwIj48bGluayByZWw9IkVkaXQtVGltZS1EYXRhIiBocmVm PSJjaWQ6ZWRpdGRhdGEubXNvIj48IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3 XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgj ZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPG86QWxsb3dQTkcvPg0KPG86RG9Ob3RS ZWx5T25DU1MvPg0KPG86VGFyZ2V0U2NyZWVuU2l6ZT4xMDI0eDc2ODwvbzpUYXJnZXRTY3JlZW5T aXplPg0KPC9vOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OldvcmREb2N1bWVudD4NCjx3Olpvb20+MTEwPC93Olpv b20+DQo8dzpTcGVsbGluZ1N0YXRlPkNsZWFuPC93OlNwZWxsaW5nU3RhdGU+DQo8dzpUcmFja01v dmVzLz4NCjx3OlRyYWNrRm9ybWF0dGluZy8+DQo8dzpFbnZlbG9wZVZpcy8+DQo8dzpWYWxpZGF0 ZUFnYWluc3RTY2hlbWFzLz4NCjx3OlNhdmVJZlhNTEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1M SW52YWxpZD4NCjx3Oklnbm9yZU1peGVkQ29udGVudD5mYWxzZTwvdzpJZ25vcmVNaXhlZENvbnRl bnQ+DQo8dzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0PmZhbHNlPC93OkFsd2F5c1Nob3dQbGFj ZWhvbGRlclRleHQ+DQo8dzpEb05vdFByb21vdGVRRi8+DQo8dzpMaWRUaGVtZU90aGVyPkVOLVVT PC93OkxpZFRoZW1lT3RoZXI+DQo8dzpMaWRUaGVtZUFzaWFuPlpILUNOPC93OkxpZFRoZW1lQXNp YW4+DQo8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNj cmlwdD4NCjx3OkNvbXBhdGliaWxpdHk+DQo8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCjx3 OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpE b250VmVydEFsaWduQ2VsbFdpdGhTcC8+DQo8dzpEb250QnJlYWtDb25zdHJhaW5lZEZvcmNlZFRh Ymxlcy8+DQo8dzpEb250VmVydEFsaWduSW5UeGJ4Lz4NCjx3OldvcmQxMUtlcm5pbmdQYWlycy8+ DQo8dzpDYWNoZWRDb2xCYWxhbmNlLz4NCjx3OlVzZUZFTGF5b3V0Lz4NCjwvdzpDb21wYXRpYmls aXR5Pg0KPHc6QnJvd3NlckxldmVsPk1pY3Jvc29mdEludGVybmV0RXhwbG9yZXI0PC93OkJyb3dz ZXJMZXZlbD4NCjxtOm1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4N CjxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIv Pg0KPG06c21hbGxGcmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBt OnZhbD0iMCIvPg0KPG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRl ckdyb3VwIi8+DQo8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9 InN1YlN1cCIvPg0KPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpX b3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N Cjx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBEZWZTZW1pSGlkZGVuPSJ0cnVlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJpb3Jp dHk9Ijk5IiBMYXRlbnRTdHlsZUNvdW50PSIyNjciPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp bmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5h bWU9ImhlYWRpbmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDkiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRv YyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1l PSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg TmFtZT0idG9jIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIE5hbWU9InRvYyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBOYW1lPSJ0b2MgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgTmFtZT0idG9jIDkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTAiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRpdGxlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIE5hbWU9IkRlZmF1bHQgUGFy YWdyYXBoIEZvbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MTEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IlN1YnRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjIyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IFFGb3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjU5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJQbGFjZWhvbGRlciBUZXh0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vIFNwYWNpbmci Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmciLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkRhcmsgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i Q29sb3JmdWwgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTGlnaHQgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i UmV2aXNpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzQi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjI5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBT aGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFj Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlz dCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGlu ZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i Q29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBB Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2Vu dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNj ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9y ZnVsIEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50 IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEg QWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBH cmlkIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkRhcmsgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJ bnRlbnNlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjMxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjMyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRsZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgTmFtZT0iQmli bGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KPC93OkxhdGVudFN0eWxlcz4N CjwveG1sPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxOw0KCW1zby1mb250LWFsdDpTaW1TdW47DQoJbXNvLWZvbnQtY2hhcnNldDoxMzQ7DQoJ bXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsN Cgltc28tZm9udC1zaWduYXR1cmU6MyA2ODA0NjAyODggMjIgMCAyNjIxNDUgMDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5 OnJvbWFuOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTot NTM2ODcwMTQ1IDExMDczMDU3MjcgMCAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1j aGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0 Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwOTI5MjkgMTA3Mzc4NjExMSA5 IDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9z ZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJbXNvLWZvbnQtY2hhcnNldDoxMzQ7DQoJbXNvLWdl bmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28t Zm9udC1zaWduYXR1cmU6MyA2ODA0NjAyODggMjIgMCAyNjIxNDUgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDsNCglt c28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNv LWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwODE2NjUgLTEw NzM3MTcxNTcgNDEgMCA2NjA0NyAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87 DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3Jw aGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtbm9zaG93Onll czsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnANCgl7bXNvLXN0eWxl LW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWls eTrlrovkvZM7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXpl OjkuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWlseTrlrovk vZM7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7 DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6 5om55rOo5qGG5paH5pysOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTo5LjBwdDsNCgltc28tYmlkaS1m b250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1hc2NpaS1mb250LWZh bWlseTrlrovkvZM7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1oYW5z aS1mb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk65a6L5L2TOw0KCW1z by1mb250LWtlcm5pbmc6MHB0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS11bmhp ZGU6bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjVwdDsNCgltc28tYmlkaS1mb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lp LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TOw0K CW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0Ow0KCW1zby1oZWFkZXItbWFyZ2luOjM2LjBwdDsNCgltc28tZm9vdGVyLW1hcmdpbjozNi4w cHQ7DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gMTBdPjxzdHlsZT4vKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9ybWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6 5pmu6YCa6KGo5qC8Ow0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1j b2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJ bXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBj bTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lk b3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1mb250LWtlcm5pbmc6MS4w cHQ7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ0YWItaW50ZXJ2YWw6MjEuMHB0Ij4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFt aWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGkgR3JlZw0KIGFuZCBhbGwsPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L 5L2TO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdG90YWxs eQ0KIGFncmVlIHdpdGggR3JlZ+KAmXMgcG9pbnQgaGVyZS4gSSBsaWtlIHRoZSBpZGVhIG9mIOKA nE1lYXN1cmVtZW50IERvbWFpbiBvYmplY3TigJ0uPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TO21z by1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QNCiByZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFjaDxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWu i+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3Nw YW4+PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0Bp ZXRmLm9yZ10gPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPk9uIEJlaGFsZiBPZg0K PC9zcGFuPjwvYj5HcmVnIE1pcnNreTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TZW50Ojwvc3Bhbj48L2I+IEZyaWRheSwgTWF5IDMwLCAyMDE0IDEyOjM0IEFNPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+IEtFTiBLTzxi cj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzo8L3NwYW4+PC9iPiBkcmFm dC1pZXRmLWxtYXAtZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnOyBtYXJjLmlicmFoaW07IGlwcG1A aWV0Zi5vcmc7IGxtYXBAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW2lwcG1dIFtsbWFwXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA1LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2T Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhpIEtlbiw8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIGFncmVlIHdpdGgg dGhlIHBvaW50IE1hcmMgYW5kIHlvdSBoYXZlIGJyb3VnaHQgdXAuIEkgdGhpbmsgdGhhdCB0byBk aWZmZXJlbnRpYXRlIHdoZXRoZXIgYXJ0aWN1bGFyIG1ldGhvZCBpcyBBY3RpdmUgb3IgUGFzc2l2 ZSBtYXkgcmVxdWlyZQ0KIGludHJvZHVjdGlvbiBvZiBhIE1lYXN1cmVtZW50IERvbWFpbiBvYmpl Y3QgYXMgc2V0IG9mIGNvb3BlcmF0aW5nIE1BcyBhbmQgTVBzLiBUaGVuIG1lYXN1cmluZw0KPHU+ ZXhwbGljaXRseTwvdT4gdHJhZmZpYyB0aGF0IGJlZW4gaW5qZWN0ZWQgYnkgTUEocykgaW4gdGhl IHNhbWUgTWVhc3VyZW1lbnQgRG9tYWluIHdvdWxkIGJlIEFjdGl2ZSBNZWFzdXJlbWVudCBNZXRo b2QvVGFzay4gQnV0IG1lYXN1cmluZyBvbiBvdmVyYWxsIHRyYWZmaWMgZXZlbiBpZiB0aGF0DQo8 dT5tYXkgaW5jbHVkZTwvdT4gaW5qZWN0ZWQgdHJhZmZpYywgSU1PLCB3b3VsZCBiZSBQYXNzaXZl IE1lYXN1cmVtZW50IE1ldGhvZC9UYXNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5HcmVnPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk9uIFRodSwgTWF5IDI5LCAy MDE0IGF0IDc6MTcgQU0sIEtFTiBLTyAmbHQ7PGEgaHJlZj0ibWFpbHRvOktFTi5LT0BhZHRyYW4u Y29tIiB0YXJnZXQ9Il9ibGFuayI+S0VOLktPQGFkdHJhbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdy ZWUgd2l0aCBNYXJj4oCZcyBjb21tZW50cywgZS5nLiwgYQ0KIE1lYXN1cmVtZW50IE1ldGhvZCBp cyBBY3RpdmUgaWYgYW55IE1BIGludm9sdmVkIGluIHRoZSBtZWFzdXJlbWVudCBpcyBnZW5lcmF0 aW5nIG1lYXN1cmVtZW50IHRyYWZmaWMuIEFuZCB5ZXMsIFBJTkcgaXMgYW4gQWN0aXZlIE1lYXN1 cmVtZW50IE1ldGhvZC48L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgdHJhZmZp YyBtZWFzdXJlZCBieSBhIFBhc3NpdmUNCiBNZXRob2QgY2FuIGVhc2lseSBpbmNsdWRlIG1lYXN1 cmVtZW50IHRyYWZmaWMgZ2VuZXJhdGVkIGJ5IGFuIHVucmVsYXRlZCBBY3RpdmUgTWV0aG9kLiBJ biB0aGlzIGNvbnRleHQgZm9yIGluc3RhbmNlLCBhIE1lYXN1cmVtZW50IE1ldGhvZCB0aGF0IGRv ZXMgbm90aGluZyBidXQgY291bnQgcmVjZWl2ZWQgcGFja2V0cyBpcyBzdGlsbCBQYXNzaXZlLCBl dmVuIGlmIHNvbWUgb2YgdGhvc2UgcGFja2V0cyBhcmUgZHVlIHRvIHVucmVsYXRlZCBQSU5Hcw0K IChvciB0aHJvdWdocHV0IHRlc3RzLCBldGMuKS48L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv Zm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLW91dGxpbmUtbGV2ZWw6MSI+DQo8Yj48Zm9udCBzaXplPSIyIiBm YWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztmb250 LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9 IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiBsbWFw IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmxtYXAtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj48c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+T24gQmVoYWxmIE9mIDwvc3Bhbj48L2I+TmFsaW5pIEVsa2luczxicj4NCjxi PjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IFRodXJzZGF5 LCBNYXkgMjksIDIwMTQgOTozMSBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5Ubzo8L3NwYW4+PC9iPiBtYXJjLmlicmFoaW07IFNUQVJLLCBCQVJCQVJBIEg7IEp1ZXJn ZW4gU2Nob2Vud2FlbGRlcjsgVmVybyBaaGVuZzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5DYzo8L3NwYW4+PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1sbWFw LWZyYW1ld29ya0B0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtaWV0Zi1s bWFwLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppcHBtQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQppcHBtQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFp bHRvOmxtYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sbWFwQGlldGYub3JnPC9hPjwvc3Bh bj48L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2T Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBbbG1h cF0gW2lwcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDUudHh0PG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZh Y2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8Zm9udCBzaXplPSIzIiBjb2xvcj0i YmxhY2siIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+VGhlIHByb2JsZW0gaXMgd2hhdCB0byBjb25zaWRlciBhcyAmcXVvdDtp bmplY3RlZCB0cmFmZmljJnF1b3Q7LiAmbmJzcDtGb3IgZXhhbXBsZSwgb24gbWFueSBuZXR3b3Jr cywgdmFyaW91cyBkZXZpY2VzLCBmb3IgdGhlaXIgb3duIHB1cnBvc2VzDQogZG8gUElORyBjb21t YW5kcy4gJm5ic3A7ICZuYnNwO1NvLCB0aGVuIGRvZXMgdGhhdCBjb252ZXJ0IHRoZSBlbnRpcmUg bWVhc3VyZW1lbnQgdG8gYWN0aXZlPzwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0i QXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQo8Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkFyaWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmtzLDwvc3Bh bj48L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxmb250IHNpemU9 IjMiIGNvbG9yPSJibGFjayIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxh Y2siIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+TmFsaW5pIEVsa2luczxicj4NCkluc2lkZSBQcm9kdWN0cywgSW5jLjxicj4N CjxhIGhyZWY9InRlbDolMjg4MzElMjklMjA2NTktODM2MCIgdGFyZ2V0PSJfYmxhbmsiPig4MzEp IDY1OS04MzYwPC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5zaWRldGhlc3RhY2suY29t IiB0YXJnZXQ9Il9ibGFuayI+d3d3Lmluc2lkZXRoZXN0YWNrLmNvbTwvYT48L3NwYW4+PC9mb250 PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxmb250IHNpemU9IjMiIGNvbG9y PSJibGFjayIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3Jv dW5kOndoaXRlIj4NCjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0i5a6L5L2TIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPg0K PGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2ZvbnQ+ PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLW91dGxpbmUtbGV2ZWw6MTtiYWNrZ3Jv dW5kOndoaXRlIj4NCjxiPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQXJpYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO2ZvbnQt d2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 ImJsYWNrIiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPg0KIG1hcmMuaWJyYWhpbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmMu aWJyYWhpbUB1c2ouZWR1LmxiIiB0YXJnZXQ9Il9ibGFuayI+bWFyYy5pYnJhaGltQHVzai5lZHUu bGI8L2E+Jmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3Nw YW4+PC9iPiAmcXVvdDtTVEFSSywgQkFSQkFSQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 YnM3NjUyQGF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj5iczc2NTJAYXR0LmNvbTwvYT4mZ3Q7OyBO YWxpbmkgRWxraW5zICZsdDs8YSBocmVmPSJtYWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVz dGFjay5jb20iIHRhcmdldD0iX2JsYW5rIj5uYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNv bTwvYT4mZ3Q7Ow0KIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxhbmsiPmouc2No b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7OyBWZXJvIFpoZW5nICZsdDs8 YSBocmVmPSJtYWlsdG86dmVyby56aGVuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmVy by56aGVuZ0BodWF3ZWkuY29tPC9hPiZndDsNCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5DYzo8L3NwYW4+PC9iPiAmcXVvdDs8YSBocmVmPSJtYWlsdG86bG1hcEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxtYXBAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bG1hcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxtYXBAaWV0Zi5vcmc8L2E+ Jmd0OzsgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pcHBtQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5pcHBtQGlldGYub3JnPC9hPiZndDs7DQogJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5kcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmtAdG9vbHMu aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrQHRvb2xz LmlldGYub3JnPC9hPiZndDsNCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5TZW50Ojwvc3Bhbj48L2I+IFRodXJzZGF5LCBNYXkgMjksIDIwMTQgNjoxNCBBTTxicj4NCjxi PjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBb bG1hcF0gW2lwcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDUudHh0 PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0K PGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PGJyPg0KSGksIDxicj4N Cjxicj4NCkkgdGhpbmsgdGhlIGNvbmZ1c2lvbiBjb21lcyBmcm9tIHdoZXRoZXIgb3Igbm90IHRv IGNvbnNpZGVyIGluZGl2aWR1YWwgTUEuPGJyPg0KRm9yIGEgc2luZ2xlIE1BLCBtZWFzdXJpbmcg ZXhpc3RpbmcgdHJhZmZpYyBpcyBwYXNzaXZlIHJlbGF0aXZlbHkgdG8gdGhpcyBnaXZlbiBNQS48 YnI+DQpCdXQgaWYgdGhpcyB0cmFmZmljIHdhcyBzZW50IGZyb20gYW5vdGhlciBNQSwgdGhlbiB0 aGUgd2hvbGUgbWV0aG9kIGlzIGFjdGl2ZSBzaW5jZQ0KPGJyPg0Kc29tZWJvZHkgaGFzIGluamVj dGVkIHRyYWZmaWMuPGJyPg0KPGJyPg0KSSB0aGluayB0aGUgZGVmaW5pdGlvbnMgb2YgYWN0aXZl IGFuZCBwYXNzaXZlIG1ldGhvZHMgYXJlIG5vdCByZWxhdGl2ZSB0byBhbiBNQSBidXQgdG8NCjxi cj4NCmFsbCBNQXMvTVBzIGludm9sdmVkIGVhY2ggbWVhc3VyZW1lbnQuIElmIHRoaXMgaXMgdGhl IGNhc2UsICZxdW90O1JlY2VpdmluZyZxdW90OyBpcyBub3QgcmVhbGx5DQo8YnI+DQpkaWZmZXJl bnQgZnJvbSAmcXVvdDtnZW5lcmF0aW5nJnF1b3Q7IHNpbmNlIGFuIE1BIHdpbGwgcmVjZWl2ZSBh bmQgbWVhc3VyZSB3aGF0IGhhcyBiZWVuIDxicj4NCmdlbmVyYXRlZC4gPGJyPg0KPGJyPg0KPGJy Pg0KQlIsPGJyPg0KPGJyPg0KTWFyYy48YnI+DQo8YnI+DQpPbiBUaHUsIDI5IE1heSAyMDE0IDEy OjU3OjM1ICYjNDM7MDAwMCwgU1RBUkssIEJBUkJBUkEgSCB3cm90ZTxicj4NCiZndDsgPz8gUmVj ZWl2aW5nIGRvZXMgb3IgZG9lc24ndCBuZWVkIHRvIGJlIGEgcG9ydGlvbiBvZiB0aGUgQWN0aXZl IE1lYXN1cmVtZW50IDxicj4NCiZndDsgTWV0aG9kIGRlZmluaXRpb24/IElmIGEgUGFzc2l2ZSBN ZWFzdXJlbWVudCBNZXRob2QgaXMgYW55IG1ldGhvZCB0aGF0IG1lYXN1cmVzIDxicj4NCiZndDsg dHJhZmZpYyB3aXRob3V0IGluamVjdGluZyB0cmFmZmljLCBkb2Vzbid0IHRoYXQgY292ZXIgYSBN ZWFzdXJlbWVudCBNZXRob2QgPGJyPg0KJmd0OyB0aGF0IG1lYXN1cmVzIHJlY2VpdmVkIHRyYWZm aWM/IEJhcmJhcmE8YnI+DQomZ3Q7IDxicj4NCiZndDsgRnJvbTogTmFsaW5pIEVsa2lucyBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzpuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPC9hPl08YnI+DQom Z3Q7IFNlbnQ6IFRodXJzZGF5LCBNYXkgMjksIDIwMTQgODo0OSBBTTxicj4NCiZndDsgVG86IFNU QVJLLCBCQVJCQVJBIEg7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgVmVybyBaaGVuZzxicj4NCiZn dDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrQHRvb2xzLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0b29scy5p ZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bG1hcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmxtYXBAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPg0KaXBwbUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBb bG1hcF0gW2lwcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDUudHh0 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC8qc25pcCovPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgQWN0 aXZlIE1lYXN1cmVtZW50IE1ldGhvZCAtIFRoZSBwcm9jZXNzIG9mIG1lYXN1cmluZyBzb21lIHBl cmZvcm1hbmNlIG9yIDxicj4NCnJlbGlhYmlsaXR5IHBhcmFtZXRlciBhc3NvY2lhdGVkIHdpdGgg dGhlIHRyYW5zZmVyIG9mIFRyYWZmaWMgYnkgZ2VuZXJhdGluZyBhbmQvb3INCjxicj4NCnJlY2Vp dmluZyBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgLypzbmlwKi88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBQYXNzaXZlIE1lYXN1cmVt ZW50IE1ldGhvZC0gVGhlIHByb2Nlc3Mgb2YgbWVhc3VyaW5nIHNvbWUgcGVyZm9ybWFuY2Ugb3Ig PGJyPg0KcmVsaWFiaWxpdHkgcGFyYW1ldGVyIGFzc29jaWF0ZWQgd2l0aCB0aGUgZXhpc3Rpbmcg dHJhZmZpYyBvbiB0aGUgbmV0d29yay48YnI+DQomZ3Q7IC8qc25pcCovPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICZndDsmZ3Q7QnV0IHdoYXQgaWYgSSBoYXZlIGFuIE1BIHBhc3NpdmVseSBtZWFzdXJp bmcgdHJhZmZpYyB0aGF0IHdhcyBpbmplY3RlZDxicj4NCiZndDsgJmd0OyZndDsocGVyaGFwcyBi eSBzb21lIG90aGVyIE1BKSBmb3IgdGhlIHB1cnBvc2Ugb2YgbWVhc3VyaW5nIGl0PyBXaHkgaXM8 YnI+DQomZ3Q7ICZndDsmZ3Q7dGhpcyBkaXN0aW5jdGlvbiBSRUFMIHZzIG5vbi1SRUFMIHVzZWZ1 bD8gQW5kIHdoYXQgaXMgdGhlIGRlZmluaXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7b2YgUkVBTCBv ZiAmcXVvdDtleGlzdGluZyB0cmFmZmljJnF1b3Q7IGFueXdheT8gSWYgSSBpbmplY3QgbWVhc3Vy ZW1lbnQgdHJhZmZpYzxicj4NCiZndDsgJmd0OyZndDtvYnNlcnZlZCBieSBzb21lIE1BLCBpdCBp cyAmcXVvdDtleGlzdGluZyB0cmFmZmljJnF1b3Q7LCBubz88YnI+DQomZ3Q7IDxicj4NCiZndDsg Jmd0OyBZZXMsIHBvaW50IHdlbGwgdGFrZW4uJm5ic3A7IFRoZSBkaXN0aW5jdGlvbiB3ZSB3YW50 ZWQgdG8gbWFrZSBpcyB0aGF0IHRoZSBwYXNzaXZlDQo8YnI+DQptZWFzdXJlbWVudCB0ZWNobmlx dWUgZG9lcyBub3QgaW5qZWN0IHRyYWZmaWMuJm5ic3A7IE90aGVyIE1BJ3Mgb3IgaW5kZWVkIG90 aGVyIGRldmljZXMgb24NCjxicj4NCnRoZSBuZXR3b3JrIGNyZWF0ZSB0cmFmZmljIGZvciB0aGVp ciBvd24gcHVycG9zZXMsIHNvbWUgb2Ygd2hpY2ggbWF5IGJlIHBlcmZvcm1hbmNlDQo8YnI+DQpt ZWFzdXJlbWVudC4mbmJzcDsgV2UgYWxzbyB3YW50ZWQgdG8gY29tZSB1cCB3aXRoIGEgZ29vZCBk ZWZpbml0aW9uIGZvciBwYXNzaXZlIG1lYXN1cmVtZW50DQo8YnI+DQp0aGF0IHdvdWxkIHdvcmsg Zm9yIGFsbCBwYXJ0aWVzLiZuYnNwOyBIb3cgaXMgdGhlIGZvbGxvd2luZz88YnI+DQomZ3Q7IDxi cj4NCiZndDsgJmd0OyBQYXNzaXZlIE1lYXN1cmVtZW50IE1ldGhvZC0gVGhlIHByb2Nlc3Mgb2Yg bWVhc3VyaW5nIHNvbWUgcGVyZm9ybWFuY2Ugb3IgcmVsaWFiaWxpdHkNCjxicj4NCnBhcmFtZXRl ciBhc3NvY2lhdGVkIHdpdGggdGhlIHRyYWZmaWMgb24gdGhlIG5ldHdvcmsuJm5ic3A7IFRoZSBw YXNzaXZlIG1lYXN1cmVtZW50IG1ldGhvZA0KPGJyPg0KZG9lcyBub3QgaW5qZWN0IHRyYWZmaWMg Zm9yIHRoZSBwdXJwb3NlcyBvZiBtZWFzdXJlbWVudC48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0 OyZndDtXb3VsZCB0aGF0IG1lYW4gdGhhdCB0aGUgZGVmaW5pdGlvbiBvZiBBY3RpdmUgTWVhc3Vy ZW1lbnQgTWV0aG9kIHdvdWxkbid0IGludm9sdmUNCjxicj4NCnJlY2VpdmluZyBBY3RpdmUgTWVh c3VyZW1lbnQgVHJhZmZpYywgYW5kIG9ubHkgZ2VuZXJhdGVkIChpbmplY3RpbmcpPzxicj4NCiZn dDsgJmd0OyZndDtBY3RpdmUgTWVhc3VyZW1lbnQgTWV0aG9kIC0gVGhlIHByb2Nlc3Mgb2YgbWVh c3VyaW5nIHNvbWUgcGVyZm9ybWFuY2Ugb3IgcmVsaWFiaWxpdHkNCjxicj4NCnBhcmFtZXRlciBh c3NvY2lhdGVkIHdpdGggdGhlIHRyYW5zZmVyIG9mIHRyYWZmaWMgYnkgZ2VuZXJhdGluZyBBY3Rp dmUgTWVhc3VyZW1lbnQNCjxicj4NClRyYWZmaWMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluZGVl ZCwgdGhlIHdvcmQgJnF1b3Q7cmVjZWl2aW5nJnF1b3Q7IG5lZWRzIHRvIGJlIGEgcG9ydGlvbiBv ZiB0aGUgQWN0aXZlIE1lYXN1cmVtZW50IDxicj4NCiZndDsgTWV0aG9kIGRlZmluaXRpb24uJm5i c3A7IFRoYW5rcyE8YnI+DQomZ3Q7IDxicj4NCiZndDsgTmFsaW5pPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyBsbWFwIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmxtYXBAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sbWFwQGlldGYub3JnPC9hPiZsdDttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sbWFwQGlldGYub3JnPC9h PiZndDs8L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPGZv bnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PGJyPg0KJmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXAiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXA8L2E+PC9zcGFu PjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8Zm9udCBzaXplPSIz IiBjb2xvcj0iYmxhY2siIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8YnI+DQotLTxicj4NCk9w ZW4gV2ViTWFpbCBQcm9qZWN0ICg8YSBocmVmPSJodHRwOi8vb3BlbndlYm1haWwub3JnLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9vcGVud2VibWFpbC5vcmc8L2E+PC9zcGFuPjwvZm9udD48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFj ZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPik8L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxm b250IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L2Zv bnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KbG1hcCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bG1h cEBpZXRmLm9yZyI+bG1hcEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXA8L2E+PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D9F2066SZXEMA510MBXchi_-- From nobody Thu May 29 20:45: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 BDA591A02F9; Thu, 29 May 2014 20:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 OeVuv5YcOxa4; Thu, 29 May 2014 20:45:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B681A02E8; Thu, 29 May 2014 20:45:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHK66740; Fri, 30 May 2014 03:45:44 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 04:45:06 +0100 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 04:45:42 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.46]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Fri, 30 May 2014 11:45:36 +0800 From: Mach Chen To: Greg Mirsky , "STARK, BARBARA H" Thread-Topic: [ippm] [lmap] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe1zkpDxW2Ca5A0O7I4S9KrC7lZtYei2g Date: Fri, 30 May 2014 03:45:36 +0000 Message-ID: References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D89A@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D9F2081SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9p4iPJxqbrIcf9N-Ojo0-jLe8Ow Cc: "ippm@ietf.org" , "marc.ibrahim" , "lmap@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 30 May 2014 03:45:55 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D9F2081SZXEMA510MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KSU1ITywgd2hldGhlciBDIGlzIGRvaW5nIEFjdGl2ZSBvciBQYXNzaXZlIGlz IGRlcGVuZGVudCBvbiB3aGV0aGVyIGl0IGJlbG9uZ3MgdG8gdGhlIHNhbWUgTWVhc3VyZW1lbnQg SW5zdGFuY2Ugb2YgQSBhbmQgQi4gSWYgaXQgaXMsIHRoZW4gaXQgaXMgQWN0aXZlLCBvdGhlcndp c2UgUGFzc2l2ZS4NCg0KQmVzdCByZWdhcmRzLA0KTWFjaA0KDQpGcm9tOiBpcHBtIFttYWlsdG86 aXBwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZyBNaXJza3kNClNlbnQ6IEZy aWRheSwgTWF5IDMwLCAyMDE0IDEyOjQxIEFNDQpUbzogU1RBUkssIEJBUkJBUkEgSA0KQ2M6IG1h cmMuaWJyYWhpbTsgbG1hcEBpZXRmLm9yZzsgaXBwbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtp cHBtXSBbbG1hcF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wNS50eHQN Cg0KSGkgQmFyYmFyYSwNCkkgdGhpbmsgdGhhdCBpZiBNQSBDIGNvdW50cyBvbmx5IFBJTkdzIGdl bmVyYXRlZCBieSBBIGFuZCBCLCB0aGVuIGl0IGlzIHN0aWxsIEFjdGl2ZSBNZWFzdXJlbWVudCBU YXNrLiBJZiBNQSBDIGNvdW50cyBhbnkgUElORyBpdCBzZWVzLCB0aGVuIEknZCBjb25zaWRlciBp dCBwZXJmb3JtaW5nIFBhc3NpdmUgTWVhc3VyZW1lbnQgaW4gTWVhc3VyZW1lbnQgRG9tYWluIHRo YXQgaW5jbHVkZXMgTUFzIEEsIEIsIGFuZCBDLg0KT24gdGhlIHNlY29uZCBzZXQgb2YgcXVlc3Rp b25zOg0KSSBhZ3JlZSB3aXRoICMzDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBUaHUsIE1heSAyOSwg MjAxNCBhdCA4OjAxIEFNLCBTVEFSSywgQkFSQkFSQSBIIDxiczc2NTJAYXR0LmNvbTxtYWlsdG86 YnM3NjUyQGF0dC5jb20+PiB3cm90ZToNCkkgc3RpbGwgaGF2ZSBxdWVzdGlvbnMuIEkgZmVlbCB0 aGVyZeKAmXMgc3RpbGwgYW1iaWd1aXR5IGFuZCBvdmVybGFwIGluIHByb3Bvc2VkIGRlZmluaXRp b25zLiBNeSBtYWluIGdvYWwgaXMgdG8gZ2V0IHJpZCBvZiBhbWJpZ3VpdHkgYW5kIG92ZXJsYXAu DQoNCk9uZSB0aGluZyBJIHJlYWQgaW4gTWFyY+KAmXMgZW1haWwgd2FzOg0KDQpXZSBoYXZlIE1B MSBzZW5kaW5nIFVEUCB0cmFmZmljIHRvIE1BMi4gTUEyIHdpbGwgcmVjZWl2ZSBVRFAgcGFja2V0 IGFuZCBjb21wdXRlIGppdHRlci4NCg0KVGhpcyBpcyBjbGVhcmx5IGFuIGFjdGl2ZSBtZWFzdXJl bWVudCB0YXNrIGZvciBNQTEuDQpUaGlzIHRvIG1lIHN1Z2dlc3RzIGFuIGlkZWEgdGhhdCBBY3Rp dmUgTWVhc3VyZW1lbnQgTWV0aG9kIChvciBUYXNrLCB3aGljaCBzbyBmYXIgaGFzIGJlZW4gZGVm aW5lZCBhcyBhbiBpbnN0YW50aWF0aW9uIG9mIGEgTWV0aG9kKSBkb2VzbuKAmXQgbmVlZCB0byBh Y3R1YWxseSBtZWFzdXJlIGFueXRoaW5nIGF0IGFsbC4gSXQganVzdCBuZWVkcyB0byBnZW5lcmF0 ZSAoaW5qZWN0KSBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYy4gSXQgbWF5IG9yIG1heSBub3Qg bWVhc3VyZSBhbnkgcGVyZm9ybWFuY2Ugb3IgcmVsaWFiaWxpdHkgcGFyYW1ldGVycy4gVGhhdCBp cywgdGhlcmUgd2FzIG5vIGRlc2NyaXB0aW9uIG9mIE1BMSBtZWFzdXJpbmcgdGhlIFVEUCB0cmFm ZmljIGl0IHNlbnQgdG8gTUEyLCBhcyBhIHF1YWxpZmllciBmb3IgaWRlbnRpZnlpbmcgdGhpcyBh cyBhbiBBY3RpdmUgTWVhc3VyZW1lbnQgVGFzay4NCg0KTG9va2luZyBhdCBQSU5HIGFnYWluLiBM ZXTigJlzIGNvbnNpZGVyIGEgc3lzdGVtIHdoZXJlIHRoZXJlIGlzIGEgTUEgKEEpIGdlbmVyYXRp bmcgYSBQSU5HIG1lc3NhZ2UsIHJlY2VpdmluZyBhIHJlc3BvbnNlIG1lc3NhZ2UsIGFuZCBjYWxj dWxhdGluZyB0aGUgdGltZSBiZXR3ZWVuIHRoZXNlIDIgZXZlbnRzLCBhbiBNQSAoQikgcmVjZWl2 aW5nIHRoZSBQSU5HIGFuZCBnZW5lcmF0aW5nIGEgcmVzcG9uc2UsIGFuZCBhbiBNQSAoQykgdGhh dCBpcyBpbiBiZXR3ZWVuIEEgYW5kIEIgYW5kIGNvdW50cyB0aGUgbnVtYmVyIG9mIFBJTkcgbWVz c2FnZXMgaXQgc2Vlcy4gV2hhdCBJIHRoaW5rIEnigJltIHJlYWRpbmcgaXM6DQoNCjEuICAgICAg IEEgaXMgZG9pbmcgYW4gQWN0aXZlIE1lYXN1cmVtZW50IFRhc2suDQoNCjIuICAgICAgIEIgaXMg ZG9pbmcgYW4gQWN0aXZlIE1lYXN1cmVtZW50IFRhc2suIFtOb3RlIHRoYXQgQiBoYXNu4oCZdCBt ZWFzdXJlZCBhbnl0aGluZy5dDQoNCjMuICAgICAgIEMgaXMgZG9pbmcgYSBQYXNzaXZlIE1lYXN1 cmVtZW50IFRhc2suDQpJZiB0aGUgYWJvdmUgaXMgY29ycmVjdCwgSeKAmWQgYmUgZmluZSB3aXRo IHRoYXQuDQoNClNvIGhlcmXigJlzIGEgbXVsdGlwbGUgY2hvaWNlIHF1ZXN0aW9uIGZvciB54oCZ YWxsOg0KQiBzdGFydHMgY291bnRpbmcgcmVjZWl2ZWQgUElORyBtZXNzYWdlcy4gU2VsZWN0IHRo ZSBjb3JyZWN0IGFuc3dlciBmcm9tIHRob3NlIGJlbG93LCBvciBpbnZlbnQgYSBkaWZmZXJlbnQg YW5zd2VyLg0KDQoxLiAgICAgICBC4oCZcyBjb3VudGluZyBvZiByZWNlaXZlZCBQSU5HcyBpcyBh IG5ldyBQYXNzaXZlIE1lYXN1cmVtZW50IFRhc2ssIHVucmVsYXRlZCB0byB0aGUgUElORyByZXNw b25kaW5nIFRhc2suDQoNCjIuICAgICAgIELigJlzIGNvdW50aW5nIG9mIHJlY2VpdmVkIFBJTkdz IGlzIHBhcnQgb2YgdGhlIGV4aXN0aW5nIEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrIHRoYXQgaW52 b2x2ZXMgcmVzcG9uZGluZyB0byBQSU5Hcy4NCg0KMy4gICAgICAgQuKAmXMgY291bnRpbmcgb2Yg cmVjZWl2ZWQgUElOR3MgaXMgcGFydCBvZiBhIG5ldyBBY3RpdmUgTWVhc3VyZW1lbnQgVGFzaywg dW5yZWxhdGVkIHRvIHRoZSBQSU5HIHJlc3BvbmRpbmcgVGFzay4NCg0KNC4gICAgICAgQWxsIG9m IHRoZSBhYm92ZSBjb3VsZCBiZSB0cnVlLCBkZXBlbmRpbmcgb24gaG93IHRoZSBNZWFzdXJlbWVu dCBNZXRob2RzIGFyZSBkZWZpbmVkLg0KDQo1LiAgICAgICAxIG9yIDIgY291bGQgYmUgdHJ1ZSwg ZGVwZW5kaW5nIG9uIGhvdyB0aGUgTWVhc3VyZW1lbnQgTWV0aG9kcyBhcmUgZGVmaW5lZC4NCg0K QmFyYmFyYQ0KDQpGcm9tOiBLRU4gS08gW21haWx0bzpLRU4uS09AYWR0cmFuLmNvbTxtYWlsdG86 S0VOLktPQGFkdHJhbi5jb20+XQ0KU2VudDogVGh1cnNkYXksIE1heSAyOSwgMjAxNCAxMDoxOCBB TQ0KVG86IE5hbGluaSBFbGtpbnM7IG1hcmMuaWJyYWhpbTsgU1RBUkssIEJBUkJBUkEgSDsgSnVl cmdlbiBTY2hvZW53YWVsZGVyOyBWZXJvIFpoZW5nDQpDYzogZHJhZnQtaWV0Zi1sbWFwLWZyYW1l d29ya0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0b29s cy5pZXRmLm9yZz47IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+OyBsbWFwQGll dGYub3JnPG1haWx0bzpsbWFwQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtsbWFwXSBbaXBwbV0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wNS50eHQNCg0KSSBhZ3JlZSB3 aXRoIE1hcmPigJlzIGNvbW1lbnRzLCBlLmcuLCBhIE1lYXN1cmVtZW50IE1ldGhvZCBpcyBBY3Rp dmUgaWYgYW55IE1BIGludm9sdmVkIGluIHRoZSBtZWFzdXJlbWVudCBpcyBnZW5lcmF0aW5nIG1l YXN1cmVtZW50IHRyYWZmaWMuIEFuZCB5ZXMsIFBJTkcgaXMgYW4gQWN0aXZlIE1lYXN1cmVtZW50 IE1ldGhvZC4NCg0KSG93ZXZlciwgdHJhZmZpYyBtZWFzdXJlZCBieSBhIFBhc3NpdmUgTWV0aG9k IGNhbiBlYXNpbHkgaW5jbHVkZSBtZWFzdXJlbWVudCB0cmFmZmljIGdlbmVyYXRlZCBieSBhbiB1 bnJlbGF0ZWQgQWN0aXZlIE1ldGhvZC4gSW4gdGhpcyBjb250ZXh0IGZvciBpbnN0YW5jZSwgYSBN ZWFzdXJlbWVudCBNZXRob2QgdGhhdCBkb2VzIG5vdGhpbmcgYnV0IGNvdW50IHJlY2VpdmVkIHBh Y2tldHMgaXMgc3RpbGwgUGFzc2l2ZSwgZXZlbiBpZiBzb21lIG9mIHRob3NlIHBhY2tldHMgYXJl IGR1ZSB0byB1bnJlbGF0ZWQgUElOR3MgKG9yIHRocm91Z2hwdXQgdGVzdHMsIGV0Yy4pLg0KDQpG cm9tOiBsbWFwIFttYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmFs aW5pIEVsa2lucw0KU2VudDogVGh1cnNkYXksIE1heSAyOSwgMjAxNCA5OjMxIEFNDQpUbzogbWFy Yy5pYnJhaGltOyBTVEFSSywgQkFSQkFSQSBIOyBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IFZlcm8g WmhlbmcNCkNjOiBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnPjsgaXBwbUBpZXRmLm9y ZzxtYWlsdG86aXBwbUBpZXRmLm9yZz47IGxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW2xtYXBdIFtpcHBtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWxt YXAtZnJhbWV3b3JrLTA1LnR4dA0KDQpUaGUgcHJvYmxlbSBpcyB3aGF0IHRvIGNvbnNpZGVyIGFz ICJpbmplY3RlZCB0cmFmZmljIi4gIEZvciBleGFtcGxlLCBvbiBtYW55IG5ldHdvcmtzLCB2YXJp b3VzIGRldmljZXMsIGZvciB0aGVpciBvd24gcHVycG9zZXMgZG8gUElORyBjb21tYW5kcy4gICAg U28sIHRoZW4gZG9lcyB0aGF0IGNvbnZlcnQgdGhlIGVudGlyZSBtZWFzdXJlbWVudCB0byBhY3Rp dmU/DQoNClRoYW5rcywNCg0KTmFsaW5pIEVsa2lucw0KSW5zaWRlIFByb2R1Y3RzLCBJbmMuDQoo ODMxKSA2NTktODM2MDx0ZWw6JTI4ODMxJTI5JTIwNjU5LTgzNjA+DQp3d3cuaW5zaWRldGhlc3Rh Y2suY29tPGh0dHA6Ly93d3cuaW5zaWRldGhlc3RhY2suY29tPg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRnJvbTogbWFyYy5pYnJhaGltIDxtYXJjLmlicmFoaW1AdXNqLmVk dS5sYjxtYWlsdG86bWFyYy5pYnJhaGltQHVzai5lZHUubGI+Pg0KVG86ICJTVEFSSywgQkFSQkFS QSBIIiA8YnM3NjUyQGF0dC5jb208bWFpbHRvOmJzNzY1MkBhdHQuY29tPj47IE5hbGluaSBFbGtp bnMgPG5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPG1haWx0bzpuYWxpbmkuZWxraW5z QGluc2lkZXRoZXN0YWNrLmNvbT4+OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2Fl bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlPj47IFZlcm8gWmhlbmcgPHZlcm8uemhlbmdAaHVhd2VpLmNvbTxtYWlsdG86 dmVyby56aGVuZ0BodWF3ZWkuY29tPj4NCkNjOiAibG1hcEBpZXRmLm9yZzxtYWlsdG86bG1hcEBp ZXRmLm9yZz4iIDxsbWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYub3JnPj47ICJpcHBtQGll dGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPiIgPGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1A aWV0Zi5vcmc+PjsgImRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0 Zi1sbWFwLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1sbWFwLWZy YW1ld29ya0B0b29scy5pZXRmLm9yZz4+DQpTZW50OiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0IDY6 MTQgQU0NClN1YmplY3Q6IFJlOiBbbG1hcF0gW2lwcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt bG1hcC1mcmFtZXdvcmstMDUudHh0DQoNCkhpLA0KDQpJIHRoaW5rIHRoZSBjb25mdXNpb24gY29t ZXMgZnJvbSB3aGV0aGVyIG9yIG5vdCB0byBjb25zaWRlciBpbmRpdmlkdWFsIE1BLg0KRm9yIGEg c2luZ2xlIE1BLCBtZWFzdXJpbmcgZXhpc3RpbmcgdHJhZmZpYyBpcyBwYXNzaXZlIHJlbGF0aXZl bHkgdG8gdGhpcyBnaXZlbiBNQS4NCkJ1dCBpZiB0aGlzIHRyYWZmaWMgd2FzIHNlbnQgZnJvbSBh bm90aGVyIE1BLCB0aGVuIHRoZSB3aG9sZSBtZXRob2QgaXMgYWN0aXZlIHNpbmNlDQpzb21lYm9k eSBoYXMgaW5qZWN0ZWQgdHJhZmZpYy4NCg0KSSB0aGluayB0aGUgZGVmaW5pdGlvbnMgb2YgYWN0 aXZlIGFuZCBwYXNzaXZlIG1ldGhvZHMgYXJlIG5vdCByZWxhdGl2ZSB0byBhbiBNQSBidXQgdG8N CmFsbCBNQXMvTVBzIGludm9sdmVkIGVhY2ggbWVhc3VyZW1lbnQuIElmIHRoaXMgaXMgdGhlIGNh c2UsICJSZWNlaXZpbmciIGlzIG5vdCByZWFsbHkNCmRpZmZlcmVudCBmcm9tICJnZW5lcmF0aW5n IiBzaW5jZSBhbiBNQSB3aWxsIHJlY2VpdmUgYW5kIG1lYXN1cmUgd2hhdCBoYXMgYmVlbg0KZ2Vu ZXJhdGVkLg0KDQoNCkJSLA0KDQpNYXJjLg0KDQpPbiBUaHUsIDI5IE1heSAyMDE0IDEyOjU3OjM1 ICswMDAwLCBTVEFSSywgQkFSQkFSQSBIIHdyb3RlDQo+ID8/IFJlY2VpdmluZyBkb2VzIG9yIGRv ZXNuJ3QgbmVlZCB0byBiZSBhIHBvcnRpb24gb2YgdGhlIEFjdGl2ZSBNZWFzdXJlbWVudA0KPiBN ZXRob2QgZGVmaW5pdGlvbj8gSWYgYSBQYXNzaXZlIE1lYXN1cmVtZW50IE1ldGhvZCBpcyBhbnkg bWV0aG9kIHRoYXQgbWVhc3VyZXMNCj4gdHJhZmZpYyB3aXRob3V0IGluamVjdGluZyB0cmFmZmlj LCBkb2Vzbid0IHRoYXQgY292ZXIgYSBNZWFzdXJlbWVudCBNZXRob2QNCj4gdGhhdCBtZWFzdXJl cyByZWNlaXZlZCB0cmFmZmljPyBCYXJiYXJhDQo+DQo+IEZyb206IE5hbGluaSBFbGtpbnMgW21h aWx0bzpuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbTxtYWlsdG86bmFsaW5pLmVsa2lu c0BpbnNpZGV0aGVzdGFjay5jb20+XQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0IDg6 NDkgQU0NCj4gVG86IFNUQVJLLCBCQVJCQVJBIEg7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgVmVy byBaaGVuZw0KPiBDYzogZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZz47IGxtYXBAaWV0 Zi5vcmc8bWFpbHRvOmxtYXBAaWV0Zi5vcmc+OyBpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGll dGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW2xtYXBdIFtpcHBtXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWxtYXAtZnJhbWV3b3JrLTA1LnR4dA0KPg0KPiAvKnNuaXAqLw0KPiA+Pj4gQWN0aXZlIE1l YXN1cmVtZW50IE1ldGhvZCAtIFRoZSBwcm9jZXNzIG9mIG1lYXN1cmluZyBzb21lIHBlcmZvcm1h bmNlIG9yDQpyZWxpYWJpbGl0eSBwYXJhbWV0ZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSB0cmFuc2Zl ciBvZiBUcmFmZmljIGJ5IGdlbmVyYXRpbmcgYW5kL29yDQpyZWNlaXZpbmcgQWN0aXZlIE1lYXN1 cmVtZW50IFRyYWZmaWMuDQo+ID4+Pg0KPiAvKnNuaXAqLw0KPiA+Pj4gUGFzc2l2ZSBNZWFzdXJl bWVudCBNZXRob2QtIFRoZSBwcm9jZXNzIG9mIG1lYXN1cmluZyBzb21lIHBlcmZvcm1hbmNlIG9y DQpyZWxpYWJpbGl0eSBwYXJhbWV0ZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSBleGlzdGluZyB0cmFm ZmljIG9uIHRoZSBuZXR3b3JrLg0KPiAvKnNuaXAqLw0KPg0KPiA+PkJ1dCB3aGF0IGlmIEkgaGF2 ZSBhbiBNQSBwYXNzaXZlbHkgbWVhc3VyaW5nIHRyYWZmaWMgdGhhdCB3YXMgaW5qZWN0ZWQNCj4g Pj4ocGVyaGFwcyBieSBzb21lIG90aGVyIE1BKSBmb3IgdGhlIHB1cnBvc2Ugb2YgbWVhc3VyaW5n IGl0PyBXaHkgaXMNCj4gPj50aGlzIGRpc3RpbmN0aW9uIFJFQUwgdnMgbm9uLVJFQUwgdXNlZnVs PyBBbmQgd2hhdCBpcyB0aGUgZGVmaW5pdGlvbg0KPiA+Pm9mIFJFQUwgb2YgImV4aXN0aW5nIHRy YWZmaWMiIGFueXdheT8gSWYgSSBpbmplY3QgbWVhc3VyZW1lbnQgdHJhZmZpYw0KPiA+Pm9ic2Vy dmVkIGJ5IHNvbWUgTUEsIGl0IGlzICJleGlzdGluZyB0cmFmZmljIiwgbm8/DQo+DQo+ID4gWWVz LCBwb2ludCB3ZWxsIHRha2VuLiAgVGhlIGRpc3RpbmN0aW9uIHdlIHdhbnRlZCB0byBtYWtlIGlz IHRoYXQgdGhlIHBhc3NpdmUNCm1lYXN1cmVtZW50IHRlY2huaXF1ZSBkb2VzIG5vdCBpbmplY3Qg dHJhZmZpYy4gIE90aGVyIE1BJ3Mgb3IgaW5kZWVkIG90aGVyIGRldmljZXMgb24NCnRoZSBuZXR3 b3JrIGNyZWF0ZSB0cmFmZmljIGZvciB0aGVpciBvd24gcHVycG9zZXMsIHNvbWUgb2Ygd2hpY2gg bWF5IGJlIHBlcmZvcm1hbmNlDQptZWFzdXJlbWVudC4gIFdlIGFsc28gd2FudGVkIHRvIGNvbWUg dXAgd2l0aCBhIGdvb2QgZGVmaW5pdGlvbiBmb3IgcGFzc2l2ZSBtZWFzdXJlbWVudA0KdGhhdCB3 b3VsZCB3b3JrIGZvciBhbGwgcGFydGllcy4gIEhvdyBpcyB0aGUgZm9sbG93aW5nPw0KPg0KPiA+ IFBhc3NpdmUgTWVhc3VyZW1lbnQgTWV0aG9kLSBUaGUgcHJvY2VzcyBvZiBtZWFzdXJpbmcgc29t ZSBwZXJmb3JtYW5jZSBvciByZWxpYWJpbGl0eQ0KcGFyYW1ldGVyIGFzc29jaWF0ZWQgd2l0aCB0 aGUgdHJhZmZpYyBvbiB0aGUgbmV0d29yay4gIFRoZSBwYXNzaXZlIG1lYXN1cmVtZW50IG1ldGhv ZA0KZG9lcyBub3QgaW5qZWN0IHRyYWZmaWMgZm9yIHRoZSBwdXJwb3NlcyBvZiBtZWFzdXJlbWVu dC4NCj4NCj4gPj5Xb3VsZCB0aGF0IG1lYW4gdGhhdCB0aGUgZGVmaW5pdGlvbiBvZiBBY3RpdmUg TWVhc3VyZW1lbnQgTWV0aG9kIHdvdWxkbid0IGludm9sdmUNCnJlY2VpdmluZyBBY3RpdmUgTWVh c3VyZW1lbnQgVHJhZmZpYywgYW5kIG9ubHkgZ2VuZXJhdGVkIChpbmplY3RpbmcpPw0KPiA+PkFj dGl2ZSBNZWFzdXJlbWVudCBNZXRob2QgLSBUaGUgcHJvY2VzcyBvZiBtZWFzdXJpbmcgc29tZSBw ZXJmb3JtYW5jZSBvciByZWxpYWJpbGl0eQ0KcGFyYW1ldGVyIGFzc29jaWF0ZWQgd2l0aCB0aGUg dHJhbnNmZXIgb2YgdHJhZmZpYyBieSBnZW5lcmF0aW5nIEFjdGl2ZSBNZWFzdXJlbWVudA0KVHJh ZmZpYy4NCj4NCj4gSW5kZWVkLCB0aGUgd29yZCAicmVjZWl2aW5nIiBuZWVkcyB0byBiZSBhIHBv cnRpb24gb2YgdGhlIEFjdGl2ZSBNZWFzdXJlbWVudA0KPiBNZXRob2QgZGVmaW5pdGlvbi4gIFRo YW5rcyENCj4NCj4gTmFsaW5pDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IGxtYXAgbWFpbGluZyBsaXN0DQo+IGxtYXBAaWV0Zi5vcmc8bWFp bHRvOmxtYXBAaWV0Zi5vcmc+PG1haWx0bzpsbWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYu b3JnPj4NCg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCg0K DQoNCi0tDQpPcGVuIFdlYk1haWwgUHJvamVjdCAoaHR0cDovL29wZW53ZWJtYWlsLm9yZzxodHRw Oi8vb3BlbndlYm1haWwub3JnLz4NCikNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmc8bWFp bHRvOmlwcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwcG0NCg0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D9F2081SZXEMA510MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIj4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDEyIj4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxQ0Y3QkZDLkFCOEEwRDAwIj48bGluayByZWw9IkVkaXQtVGltZS1EYXRhIiBocmVm PSJjaWQ6ZWRpdGRhdGEubXNvIj48IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3 XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgj ZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPG86QWxsb3dQTkcvPg0KPG86RG9Ob3RS ZWx5T25DU1MvPg0KPG86VGFyZ2V0U2NyZWVuU2l6ZT4xMDI0eDc2ODwvbzpUYXJnZXRTY3JlZW5T aXplPg0KPC9vOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OldvcmREb2N1bWVudD4NCjx3Olpvb20+MTEwPC93Olpv b20+DQo8dzpTcGVsbGluZ1N0YXRlPkNsZWFuPC93OlNwZWxsaW5nU3RhdGU+DQo8dzpUcmFja01v dmVzLz4NCjx3OlRyYWNrRm9ybWF0dGluZy8+DQo8dzpFbnZlbG9wZVZpcy8+DQo8dzpWYWxpZGF0 ZUFnYWluc3RTY2hlbWFzLz4NCjx3OlNhdmVJZlhNTEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1M SW52YWxpZD4NCjx3Oklnbm9yZU1peGVkQ29udGVudD5mYWxzZTwvdzpJZ25vcmVNaXhlZENvbnRl bnQ+DQo8dzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0PmZhbHNlPC93OkFsd2F5c1Nob3dQbGFj ZWhvbGRlclRleHQ+DQo8dzpEb05vdFByb21vdGVRRi8+DQo8dzpMaWRUaGVtZU90aGVyPkVOLVVT PC93OkxpZFRoZW1lT3RoZXI+DQo8dzpMaWRUaGVtZUFzaWFuPlpILUNOPC93OkxpZFRoZW1lQXNp YW4+DQo8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNj cmlwdD4NCjx3OkNvbXBhdGliaWxpdHk+DQo8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCjx3 OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpE b250VmVydEFsaWduQ2VsbFdpdGhTcC8+DQo8dzpEb250QnJlYWtDb25zdHJhaW5lZEZvcmNlZFRh Ymxlcy8+DQo8dzpEb250VmVydEFsaWduSW5UeGJ4Lz4NCjx3OldvcmQxMUtlcm5pbmdQYWlycy8+ DQo8dzpDYWNoZWRDb2xCYWxhbmNlLz4NCjx3OlVzZUZFTGF5b3V0Lz4NCjwvdzpDb21wYXRpYmls aXR5Pg0KPHc6QnJvd3NlckxldmVsPk1pY3Jvc29mdEludGVybmV0RXhwbG9yZXI0PC93OkJyb3dz ZXJMZXZlbD4NCjxtOm1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4N CjxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIv Pg0KPG06c21hbGxGcmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBt OnZhbD0iMCIvPg0KPG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRl ckdyb3VwIi8+DQo8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9 InN1YlN1cCIvPg0KPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpX b3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N Cjx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBEZWZTZW1pSGlkZGVuPSJ0cnVlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJpb3Jp dHk9Ijk5IiBMYXRlbnRTdHlsZUNvdW50PSIyNjciPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp bmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5h bWU9ImhlYWRpbmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDkiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRv YyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1l PSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg TmFtZT0idG9jIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIE5hbWU9InRvYyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBOYW1lPSJ0b2MgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgTmFtZT0idG9jIDkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTAiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRpdGxlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIE5hbWU9IkRlZmF1bHQgUGFy YWdyYXBoIEZvbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MTEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IlN1YnRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjIyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IFFGb3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjU5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJQbGFjZWhvbGRlciBUZXh0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vIFNwYWNpbmci Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmciLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkRhcmsgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i Q29sb3JmdWwgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTGlnaHQgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i UmV2aXNpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzQi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjI5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBT aGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFj Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlz dCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGlu ZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i Q29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBB Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2Vu dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNj ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9y ZnVsIEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50 IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEg QWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBH cmlkIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkRhcmsgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJ bnRlbnNlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjMxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjMyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRsZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgTmFtZT0iQmli bGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KPC93OkxhdGVudFN0eWxlcz4N CjwveG1sPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxOw0KCW1zby1mb250LWFsdDpTaW1TdW47DQoJbXNvLWZvbnQtY2hhcnNldDoxMzQ7DQoJ bXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsN Cgltc28tZm9udC1zaWduYXR1cmU6MyA2ODA0NjAyODggMjIgMCAyNjIxNDUgMDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5 OnJvbWFuOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTot NTM2ODcwMTQ1IDExMDczMDU3MjcgMCAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1j aGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0 Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwOTI5MjkgMTA3Mzc4NjExMSA5 IDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9z ZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJbXNvLWZvbnQtY2hhcnNldDoxMzQ7DQoJbXNvLWdl bmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28t Zm9udC1zaWduYXR1cmU6MyA2ODA0NjAyODggMjIgMCAyNjIxNDUgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDsNCglt c28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNv LWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwODE2NjUgLTEw NzM3MTcxNTcgNDEgMCA2NjA0NyAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87 DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3Jw aGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtbm9zaG93Onll czsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnANCgl7bXNvLXN0eWxl LW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWls eTrlrovkvZM7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXpl OjkuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWlseTrlrovk vZM7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7 DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6 5om55rOo5qGG5paH5pysOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTo5LjBwdDsNCgltc28tYmlkaS1m b250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1hc2NpaS1mb250LWZh bWlseTrlrovkvZM7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1oYW5z aS1mb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk65a6L5L2TOw0KCW1z by1mb250LWtlcm5pbmc6MHB0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS11bmhp ZGU6bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjVwdDsNCgltc28tYmlkaS1mb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lp LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TOw0K CW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0Ow0KCW1zby1oZWFkZXItbWFyZ2luOjM2LjBwdDsNCgltc28tZm9vdGVyLW1hcmdpbjozNi4w cHQ7DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gMTBdPjxzdHlsZT4vKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9ybWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6 5pmu6YCa6KGo5qC8Ow0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1j b2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJ bXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBj bTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lk b3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1mb250LWtlcm5pbmc6MS4w cHQ7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ0YWItaW50ZXJ2YWw6MjEuMHB0Ij4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFt aWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGkgR3JlZyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28t YmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJp ZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+SU1ITywNCiB3aGV0aGVyIEMg aXMgZG9pbmcgQWN0aXZlIG9yIFBhc3NpdmUgaXMgZGVwZW5kZW50IG9uIHdoZXRoZXIgaXQgYmVs b25ncyB0byB0aGUgc2FtZSBNZWFzdXJlbWVudCBJbnN0YW5jZSBvZiBBIGFuZCBCLiBJZiBpdCBp cywgdGhlbiBpdCBpcyBBY3RpdmUsIG90aGVyd2lzZSBQYXNzaXZlLjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGkt Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TO21zby1iaWRpLWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0 DQogcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1hY2g8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250 LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2ZvbnQtd2VpZ2h0OmJvbGQi PkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIGlwcG0gW21haWx0bzppcHBt LWJvdW5jZXNAaWV0Zi5vcmddIDxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5PbiBC ZWhhbGYgT2YNCjwvc3Bhbj48L2I+R3JlZyBNaXJza3k8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBGcmlkYXksIE1heSAzMCwgMjAxNCAxMjo0 MSBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9i PiBTVEFSSywgQkFSQkFSQSBIPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkNjOjwvc3Bhbj48L2I+IG1hcmMuaWJyYWhpbTsgbG1hcEBpZXRmLm9yZzsgaXBwbUBpZXRmLm9y Zzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48 L2I+IFJlOiBbaXBwbV0gW2xtYXBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdv cmstMDUudHh0PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5IaSBCYXJiYXJhLDxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5JIHRoaW5rIHRoYXQgaWYgTUEgQyBjb3VudHMgb25seSBQSU5HcyBnZW5lcmF0 ZWQgYnkgQSBhbmQgQiwgdGhlbiBpdCBpcyBzdGlsbCBBY3RpdmUgTWVhc3VyZW1lbnQgVGFzay4g SWYgTUEgQyBjb3VudHMgYW55IFBJTkcgaXQgc2VlcywgdGhlbiBJJ2QgY29uc2lkZXIgaXQgcGVy Zm9ybWluZw0KIFBhc3NpdmUgTWVhc3VyZW1lbnQgaW4gTWVhc3VyZW1lbnQgRG9tYWluIHRoYXQg aW5jbHVkZXMgTUFzIEEsIEIsIGFuZCBDLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5PbiB0aGUgc2Vjb25k IHNldCBvZiBxdWVzdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBz aXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+SSBhZ3JlZSB3aXRoICMzPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T24gVGh1LCBNYXkgMjksIDIw MTQgYXQgODowMSBBTSwgU1RBUkssIEJBUkJBUkEgSCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJzNzY1 MkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnM3NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg c3RpbGwgaGF2ZSBxdWVzdGlvbnMuIEkgZmVlbCB0aGVyZeKAmXMNCiBzdGlsbCBhbWJpZ3VpdHkg YW5kIG92ZXJsYXAgaW4gcHJvcG9zZWQgZGVmaW5pdGlvbnMuIE15IG1haW4gZ29hbCBpcyB0byBn ZXQgcmlkIG9mIGFtYmlndWl0eSBhbmQgb3ZlcmxhcC48L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+T25lIHRoaW5nIEkgcmVhZCBpbiBNYXJj4oCZcyBlbWFpbCB3YXM6PC9zcGFuPjwvZm9udD48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PGZvbnQgc2l6ZT0i MyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPldlIGhhdmUgTUExIHNlbmRpbmcgVURQIHRyYWZmaWMgdG8gTUEyLiBNQTIgd2lsbCByZWNl aXZlIFVEUCBwYWNrZXQgYW5kIGNvbXB1dGUgaml0dGVyLg0KPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwPjxmb250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGlzIGlzIGNsZWFybHkgYW4gYWN0aXZlIG1l YXN1cmVtZW50IHRhc2sgZm9yIE1BMS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGlzIHRvIG1lIHN1Z2dlc3RzIGFuIGlkZWEgdGhhdCBBY3RpdmUNCiBNZWFzdXJl bWVudCBNZXRob2QgKG9yIFRhc2ssIHdoaWNoIHNvIGZhciBoYXMgYmVlbiBkZWZpbmVkIGFzIGFu IGluc3RhbnRpYXRpb24gb2YgYSBNZXRob2QpIGRvZXNu4oCZdCBuZWVkIHRvIGFjdHVhbGx5IG1l YXN1cmUgYW55dGhpbmcgYXQgYWxsLiBJdCBqdXN0IG5lZWRzIHRvIGdlbmVyYXRlIChpbmplY3Qp IEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljLiBJdCBtYXkgb3IgbWF5IG5vdCBtZWFzdXJlIGFu eSBwZXJmb3JtYW5jZSBvciByZWxpYWJpbGl0eQ0KIHBhcmFtZXRlcnMuIFRoYXQgaXMsIHRoZXJl IHdhcyBubyBkZXNjcmlwdGlvbiBvZiBNQTEgbWVhc3VyaW5nIHRoZSBVRFAgdHJhZmZpYyBpdCBz ZW50IHRvIE1BMiwgYXMgYSBxdWFsaWZpZXIgZm9yIGlkZW50aWZ5aW5nIHRoaXMgYXMgYW4gQWN0 aXZlIE1lYXN1cmVtZW50IFRhc2suPC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxvb2tpbmcg YXQgUElORyBhZ2Fpbi4gTGV04oCZcyBjb25zaWRlcg0KIGEgc3lzdGVtIHdoZXJlIHRoZXJlIGlz IGEgTUEgKEEpIGdlbmVyYXRpbmcgYSBQSU5HIG1lc3NhZ2UsIHJlY2VpdmluZyBhIHJlc3BvbnNl IG1lc3NhZ2UsIGFuZCBjYWxjdWxhdGluZyB0aGUgdGltZSBiZXR3ZWVuIHRoZXNlIDIgZXZlbnRz LCBhbiBNQSAoQikgcmVjZWl2aW5nIHRoZSBQSU5HIGFuZCBnZW5lcmF0aW5nIGEgcmVzcG9uc2Us IGFuZCBhbiBNQSAoQykgdGhhdCBpcyBpbiBiZXR3ZWVuIEEgYW5kIEIgYW5kIGNvdW50cyB0aGUg bnVtYmVyDQogb2YgUElORyBtZXNzYWdlcyBpdCBzZWVzLiBXaGF0IEkgdGhpbmsgSeKAmW0gcmVh ZGluZyBpczo8L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4x Ljwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjwvZm9udD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BIGlz IGRvaW5nIGFuIEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrLjwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIuPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIxIiBj b2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkIgaXMgZG9pbmcgYW4gQWN0aXZlIE1lYXN1cmVtZW50IFRh c2suIFtOb3RlIHRoYXQgQiBoYXNu4oCZdCBtZWFzdXJlZCBhbnl0aGluZy5dPC9zcGFuPjwvZm9u dD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+My48L3NwYW4+PC9mb250Pjxmb250 IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QyBpcyBkb2luZyBhIFBhc3NpdmUgTWVh c3VyZW1lbnQgVGFzay48L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHRoZSBhYm92ZSBpcyBjb3JyZWN0LCBJ4oCZZCBi ZSBmaW5lIHdpdGgNCiB0aGF0Ljwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBoZXJl4oCZ cyBhIG11bHRpcGxlIGNob2ljZSBxdWVzdGlvbiBmb3INCiB54oCZYWxsOjwvc3Bhbj48L2ZvbnQ+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QiBz dGFydHMgY291bnRpbmcgcmVjZWl2ZWQgUElORyBtZXNzYWdlcy4NCiBTZWxlY3QgdGhlIGNvcnJl Y3QgYW5zd2VyIGZyb20gdGhvc2UgYmVsb3csIG9yIGludmVudCBhIGRpZmZlcmVudCBhbnN3ZXIu PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MS48L3NwYW4+ PC9mb250Pjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QuKAmXMgY291bnRp bmcgb2YgcmVjZWl2ZWQgUElOR3MgaXMgYSBuZXcgUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrLCB1 bnJlbGF0ZWQgdG8gdGhlIFBJTkcgcmVzcG9uZGluZyBUYXNrLjwvc3Bhbj48L2ZvbnQ+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIuPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIx IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkLigJlzIGNvdW50aW5nIG9mIHJlY2VpdmVkIFBJTkdz IGlzIHBhcnQgb2YgdGhlIGV4aXN0aW5nIEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrIHRoYXQgaW52 b2x2ZXMgcmVzcG9uZGluZw0KIHRvIFBJTkdzLjwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjMuPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIxIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdk IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkLigJlzIGNvdW50aW5nIG9mIHJlY2VpdmVkIFBJTkdzIGlzIHBhcnQg b2YgYSBuZXcgQWN0aXZlIE1lYXN1cmVtZW50IFRhc2ssIHVucmVsYXRlZCB0byB0aGUgUElORyBy ZXNwb25kaW5nDQogVGFzay48L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj40Ljwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5BbGwgb2YgdGhlIGFib3ZlIGNvdWxkIGJlIHRydWUsIGRlcGVuZGluZyBvbiBob3cgdGhl IE1lYXN1cmVtZW50IE1ldGhvZHMgYXJlIGRlZmluZWQuPC9zcGFuPjwvZm9udD48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+NS48L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjEiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+MSBvciAyIGNvdWxkIGJlIHRydWUsIGRlcGVuZGluZyBvbiBo b3cgdGhlIE1lYXN1cmVtZW50IE1ldGhvZHMgYXJlIGRlZmluZWQuPC9zcGFuPjwvZm9udD48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkJhcmJhcmE8L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1vdXRsaW5lLWxldmVsOjEiPg0KPGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Zm9udC13ZWlnaHQ6Ym9sZCI+ RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogS0VOIEtPIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOktFTi5LT0BhZHRyYW4uY29tIiB0YXJnZXQ9Il9ibGFuayI+S0VOLktPQGFk dHJhbi5jb208L2E+XQ0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNl bnQ6PC9zcGFuPjwvYj4gVGh1cnNkYXksIE1heSAyOSwgMjAxNCAxMDoxOCBBTTxicj4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBOYWxpbmkgRWxraW5z OyBtYXJjLmlicmFoaW07IFNUQVJLLCBCQVJCQVJBIEg7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsg VmVybyBaaGVuZzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzo8L3Nw YW4+PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0b29scy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0b29s cy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQppcHBtQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5sbWFwQGlldGYub3JnPC9hPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJFOiBbbG1hcF0gW2lwcG1dIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDUudHh0PC9zcGFuPjwvZm9udD48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNl PSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRo IE1hcmPigJlzIGNvbW1lbnRzLCBlLmcuLCBhDQogTWVhc3VyZW1lbnQgTWV0aG9kIGlzIEFjdGl2 ZSBpZiBhbnkgTUEgaW52b2x2ZWQgaW4gdGhlIG1lYXN1cmVtZW50IGlzIGdlbmVyYXRpbmcgbWVh c3VyZW1lbnQgdHJhZmZpYy4gQW5kIHllcywgUElORyBpcyBhbiBBY3RpdmUgTWVhc3VyZW1lbnQg TWV0aG9kLjwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5 N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3dldmVyLCB0cmFmZmljIG1lYXN1 cmVkIGJ5IGEgUGFzc2l2ZQ0KIE1ldGhvZCBjYW4gZWFzaWx5IGluY2x1ZGUgbWVhc3VyZW1lbnQg dHJhZmZpYyBnZW5lcmF0ZWQgYnkgYW4gdW5yZWxhdGVkIEFjdGl2ZSBNZXRob2QuIEluIHRoaXMg Y29udGV4dCBmb3IgaW5zdGFuY2UsIGEgTWVhc3VyZW1lbnQgTWV0aG9kIHRoYXQgZG9lcyBub3Ro aW5nIGJ1dCBjb3VudCByZWNlaXZlZCBwYWNrZXRzIGlzIHN0aWxsIFBhc3NpdmUsIGV2ZW4gaWYg c29tZSBvZiB0aG9zZSBwYWNrZXRzIGFyZSBkdWUgdG8gdW5yZWxhdGVkIFBJTkdzDQogKG9yIHRo cm91Z2hwdXQgdGVzdHMsIGV0Yy4pLjwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tb3V0bGluZS1sZXZlbDoxIj4NCjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRh aG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2ZvbnQtd2VpZ2h0 OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21h Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIGxtYXAgWzxhIGhy ZWY9Im1haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86 bG1hcC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvYj5OYWxpbmkgRWxraW5zPGJyPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gVGh1cnNkYXksIE1heSAy OSwgMjAxNCA5OjMxIEFNPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRv Ojwvc3Bhbj48L2I+IG1hcmMuaWJyYWhpbTsgU1RBUkssIEJBUkJBUkEgSDsgSnVlcmdlbiBTY2hv ZW53YWVsZGVyOyBWZXJvIFpoZW5nPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPkNjOjwvc3Bhbj48L2I+IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWxtYXAtZnJhbWV3 b3JrQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLWxtYXAtZnJh bWV3b3JrQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj4NCmlwcG1AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bG1h cEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxtYXBAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IFtsbWFw XSBbaXBwbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wNS50eHQ8L3Nw YW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSLl rovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNr IiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPlRoZSBwcm9ibGVtIGlzIHdoYXQgdG8gY29uc2lkZXIgYXMgJnF1b3Q7aW5qZWN0 ZWQgdHJhZmZpYyZxdW90Oy4gJm5ic3A7Rm9yIGV4YW1wbGUsIG9uIG1hbnkgbmV0d29ya3MsIHZh cmlvdXMgZGV2aWNlcywgZm9yIHRoZWlyIG93biBwdXJwb3Nlcw0KIGRvIFBJTkcgY29tbWFuZHMu ICZuYnNwOyAmbmJzcDtTbywgdGhlbiBkb2VzIHRoYXQgY29udmVydCB0aGUgZW50aXJlIG1lYXN1 cmVtZW50IHRvIGFjdGl2ZT88L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkFyaWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KPGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBmYWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8L3NwYW4+PC9m b250PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+DQo8Zm9udCBzaXplPSIzIiBj b2xvcj0iYmxhY2siIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPGZvbnQgc2l6ZT0iMyIgY29sb3I9ImJsYWNrIiBm YWNlPSJBcmlhbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPk5hbGluaSBFbGtpbnM8YnI+DQpJbnNpZGUgUHJvZHVjdHMsIEluYy48YnI+DQo8YSBo cmVmPSJ0ZWw6JTI4ODMxJTI5JTIwNjU5LTgzNjAiIHRhcmdldD0iX2JsYW5rIj4oODMxKSA2NTkt ODM2MDwvYT48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3Lmluc2lkZXRoZXN0YWNrLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnd3dy5pbnNpZGV0aGVzdGFjay5jb208L2E+PC9zcGFuPjwvZm9udD48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxh Y2siIGZhY2U9IkFyaWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3 aGl0ZSI+DQo8Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IuWui+S9kyI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4NCjxociBz aXplPSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9mb250PjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1vdXRsaW5lLWxldmVsOjE7YmFja2dyb3VuZDp3 aGl0ZSI+DQo8Yj48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkFyaWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjaztmb250LXdlaWdo dDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFj ayIgZmFjZT0iQXJpYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4NCiBtYXJjLmlicmFoaW0gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJjLmlicmFo aW1AdXNqLmVkdS5sYiIgdGFyZ2V0PSJfYmxhbmsiPm1hcmMuaWJyYWhpbUB1c2ouZWR1LmxiPC9h PiZndDs8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwv Yj4gJnF1b3Q7U1RBUkssIEJBUkJBUkEgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJzNzY1 MkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnM3NjUyQGF0dC5jb208L2E+Jmd0OzsgTmFsaW5p IEVsa2lucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2su Y29tIiB0YXJnZXQ9Il9ibGFuayI+bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb208L2E+ Jmd0OzsNCiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiIHRhcmdldD0iX2JsYW5rIj5qLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8L2E+Jmd0OzsgVmVybyBaaGVuZyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnZlcm8uemhlbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlcm8uemhl bmdAaHVhd2VpLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+Q2M6PC9zcGFuPjwvYj4gJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5sbWFwQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmxtYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sbWFwQGlldGYub3JnPC9hPiZndDs7 ICZxdW90OzxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXBw bUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aXBwbUBpZXRmLm9yZzwvYT4mZ3Q7Ow0KICZxdW90OzxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+ZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrQHRvb2xzLmlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0b29scy5pZXRm Lm9yZzwvYT4mZ3Q7DQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2Vu dDo8L3NwYW4+PC9iPiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0IDY6MTQgQU08YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW2xtYXBd IFtpcHBtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA1LnR4dDwvc3Bh bj48L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxmb250 IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxicj4NCkhpLCA8YnI+DQo8YnI+ DQpJIHRoaW5rIHRoZSBjb25mdXNpb24gY29tZXMgZnJvbSB3aGV0aGVyIG9yIG5vdCB0byBjb25z aWRlciBpbmRpdmlkdWFsIE1BLjxicj4NCkZvciBhIHNpbmdsZSBNQSwgbWVhc3VyaW5nIGV4aXN0 aW5nIHRyYWZmaWMgaXMgcGFzc2l2ZSByZWxhdGl2ZWx5IHRvIHRoaXMgZ2l2ZW4gTUEuPGJyPg0K QnV0IGlmIHRoaXMgdHJhZmZpYyB3YXMgc2VudCBmcm9tIGFub3RoZXIgTUEsIHRoZW4gdGhlIHdo b2xlIG1ldGhvZCBpcyBhY3RpdmUgc2luY2UNCjxicj4NCnNvbWVib2R5IGhhcyBpbmplY3RlZCB0 cmFmZmljLjxicj4NCjxicj4NCkkgdGhpbmsgdGhlIGRlZmluaXRpb25zIG9mIGFjdGl2ZSBhbmQg cGFzc2l2ZSBtZXRob2RzIGFyZSBub3QgcmVsYXRpdmUgdG8gYW4gTUEgYnV0IHRvDQo8YnI+DQph bGwgTUFzL01QcyBpbnZvbHZlZCBlYWNoIG1lYXN1cmVtZW50LiBJZiB0aGlzIGlzIHRoZSBjYXNl LCAmcXVvdDtSZWNlaXZpbmcmcXVvdDsgaXMgbm90IHJlYWxseQ0KPGJyPg0KZGlmZmVyZW50IGZy b20gJnF1b3Q7Z2VuZXJhdGluZyZxdW90OyBzaW5jZSBhbiBNQSB3aWxsIHJlY2VpdmUgYW5kIG1l YXN1cmUgd2hhdCBoYXMgYmVlbiA8YnI+DQpnZW5lcmF0ZWQuIDxicj4NCjxicj4NCjxicj4NCkJS LDxicj4NCjxicj4NCk1hcmMuPGJyPg0KPGJyPg0KT24gVGh1LCAyOSBNYXkgMjAxNCAxMjo1Nzoz NSAmIzQzOzAwMDAsIFNUQVJLLCBCQVJCQVJBIEggd3JvdGU8YnI+DQomZ3Q7ID8/IFJlY2Vpdmlu ZyBkb2VzIG9yIGRvZXNuJ3QgbmVlZCB0byBiZSBhIHBvcnRpb24gb2YgdGhlIEFjdGl2ZSBNZWFz dXJlbWVudCA8YnI+DQomZ3Q7IE1ldGhvZCBkZWZpbml0aW9uPyBJZiBhIFBhc3NpdmUgTWVhc3Vy ZW1lbnQgTWV0aG9kIGlzIGFueSBtZXRob2QgdGhhdCBtZWFzdXJlcyA8YnI+DQomZ3Q7IHRyYWZm aWMgd2l0aG91dCBpbmplY3RpbmcgdHJhZmZpYywgZG9lc24ndCB0aGF0IGNvdmVyIGEgTWVhc3Vy ZW1lbnQgTWV0aG9kIDxicj4NCiZndDsgdGhhdCBtZWFzdXJlcyByZWNlaXZlZCB0cmFmZmljPyBC YXJiYXJhPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZyb206IE5hbGluaSBFbGtpbnMgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20iIHRhcmdldD0i X2JsYW5rIj5uYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbTwvYT5dPGJyPg0KJmd0OyBT ZW50OiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0IDg6NDkgQU08YnI+DQomZ3Q7IFRvOiBTVEFSSywg QkFSQkFSQSBIOyBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IFZlcm8gWmhlbmc8YnI+DQomZ3Q7IENj OiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0b29scy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5v cmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmxtYXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5s bWFwQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCmlwcG1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW2xtYXBd IFtpcHBtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA1LnR4dDxicj4N CiZndDsgPGJyPg0KJmd0OyAvKnNuaXAqLzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEFjdGl2ZSBN ZWFzdXJlbWVudCBNZXRob2QgLSBUaGUgcHJvY2VzcyBvZiBtZWFzdXJpbmcgc29tZSBwZXJmb3Jt YW5jZSBvciA8YnI+DQpyZWxpYWJpbGl0eSBwYXJhbWV0ZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSB0 cmFuc2ZlciBvZiBUcmFmZmljIGJ5IGdlbmVyYXRpbmcgYW5kL29yDQo8YnI+DQpyZWNlaXZpbmcg QWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7IC8qc25pcCovPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgUGFzc2l2ZSBNZWFzdXJlbWVudCBN ZXRob2QtIFRoZSBwcm9jZXNzIG9mIG1lYXN1cmluZyBzb21lIHBlcmZvcm1hbmNlIG9yIDxicj4N CnJlbGlhYmlsaXR5IHBhcmFtZXRlciBhc3NvY2lhdGVkIHdpdGggdGhlIGV4aXN0aW5nIHRyYWZm aWMgb24gdGhlIG5ldHdvcmsuPGJyPg0KJmd0OyAvKnNuaXAqLzxicj4NCiZndDsgPGJyPg0KJmd0 OyAmZ3Q7Jmd0O0J1dCB3aGF0IGlmIEkgaGF2ZSBhbiBNQSBwYXNzaXZlbHkgbWVhc3VyaW5nIHRy YWZmaWMgdGhhdCB3YXMgaW5qZWN0ZWQ8YnI+DQomZ3Q7ICZndDsmZ3Q7KHBlcmhhcHMgYnkgc29t ZSBvdGhlciBNQSkgZm9yIHRoZSBwdXJwb3NlIG9mIG1lYXN1cmluZyBpdD8gV2h5IGlzPGJyPg0K Jmd0OyAmZ3Q7Jmd0O3RoaXMgZGlzdGluY3Rpb24gUkVBTCB2cyBub24tUkVBTCB1c2VmdWw/IEFu ZCB3aGF0IGlzIHRoZSBkZWZpbml0aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0O29mIFJFQUwgb2YgJnF1 b3Q7ZXhpc3RpbmcgdHJhZmZpYyZxdW90OyBhbnl3YXk/IElmIEkgaW5qZWN0IG1lYXN1cmVtZW50 IHRyYWZmaWM8YnI+DQomZ3Q7ICZndDsmZ3Q7b2JzZXJ2ZWQgYnkgc29tZSBNQSwgaXQgaXMgJnF1 b3Q7ZXhpc3RpbmcgdHJhZmZpYyZxdW90Oywgbm8/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsg WWVzLCBwb2ludCB3ZWxsIHRha2VuLiZuYnNwOyBUaGUgZGlzdGluY3Rpb24gd2Ugd2FudGVkIHRv IG1ha2UgaXMgdGhhdCB0aGUgcGFzc2l2ZQ0KPGJyPg0KbWVhc3VyZW1lbnQgdGVjaG5pcXVlIGRv ZXMgbm90IGluamVjdCB0cmFmZmljLiZuYnNwOyBPdGhlciBNQSdzIG9yIGluZGVlZCBvdGhlciBk ZXZpY2VzIG9uDQo8YnI+DQp0aGUgbmV0d29yayBjcmVhdGUgdHJhZmZpYyBmb3IgdGhlaXIgb3du IHB1cnBvc2VzLCBzb21lIG9mIHdoaWNoIG1heSBiZSBwZXJmb3JtYW5jZQ0KPGJyPg0KbWVhc3Vy ZW1lbnQuJm5ic3A7IFdlIGFsc28gd2FudGVkIHRvIGNvbWUgdXAgd2l0aCBhIGdvb2QgZGVmaW5p dGlvbiBmb3IgcGFzc2l2ZSBtZWFzdXJlbWVudA0KPGJyPg0KdGhhdCB3b3VsZCB3b3JrIGZvciBh bGwgcGFydGllcy4mbmJzcDsgSG93IGlzIHRoZSBmb2xsb3dpbmc/PGJyPg0KJmd0OyA8YnI+DQom Z3Q7ICZndDsgUGFzc2l2ZSBNZWFzdXJlbWVudCBNZXRob2QtIFRoZSBwcm9jZXNzIG9mIG1lYXN1 cmluZyBzb21lIHBlcmZvcm1hbmNlIG9yIHJlbGlhYmlsaXR5DQo8YnI+DQpwYXJhbWV0ZXIgYXNz b2NpYXRlZCB3aXRoIHRoZSB0cmFmZmljIG9uIHRoZSBuZXR3b3JrLiZuYnNwOyBUaGUgcGFzc2l2 ZSBtZWFzdXJlbWVudCBtZXRob2QNCjxicj4NCmRvZXMgbm90IGluamVjdCB0cmFmZmljIGZvciB0 aGUgcHVycG9zZXMgb2YgbWVhc3VyZW1lbnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7 V291bGQgdGhhdCBtZWFuIHRoYXQgdGhlIGRlZmluaXRpb24gb2YgQWN0aXZlIE1lYXN1cmVtZW50 IE1ldGhvZCB3b3VsZG4ndCBpbnZvbHZlDQo8YnI+DQpyZWNlaXZpbmcgQWN0aXZlIE1lYXN1cmVt ZW50IFRyYWZmaWMsIGFuZCBvbmx5IGdlbmVyYXRlZCAoaW5qZWN0aW5nKT88YnI+DQomZ3Q7ICZn dDsmZ3Q7QWN0aXZlIE1lYXN1cmVtZW50IE1ldGhvZCAtIFRoZSBwcm9jZXNzIG9mIG1lYXN1cmlu ZyBzb21lIHBlcmZvcm1hbmNlIG9yIHJlbGlhYmlsaXR5DQo8YnI+DQpwYXJhbWV0ZXIgYXNzb2Np YXRlZCB3aXRoIHRoZSB0cmFuc2ZlciBvZiB0cmFmZmljIGJ5IGdlbmVyYXRpbmcgQWN0aXZlIE1l YXN1cmVtZW50DQo8YnI+DQpUcmFmZmljLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJbmRlZWQsIHRo ZSB3b3JkICZxdW90O3JlY2VpdmluZyZxdW90OyBuZWVkcyB0byBiZSBhIHBvcnRpb24gb2YgdGhl IEFjdGl2ZSBNZWFzdXJlbWVudCA8YnI+DQomZ3Q7IE1ldGhvZCBkZWZpbml0aW9uLiZuYnNwOyBU aGFua3MhPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5hbGluaTxicj4NCiZndDsgPGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg bG1hcCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpsbWFwQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bG1hcEBpZXRmLm9yZzwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpsbWFwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bG1hcEBpZXRmLm9yZzwvYT4mZ3Q7 PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxmb250IHNp emU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sbWFwIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sbWFwPC9hPjwvc3Bhbj48L2Zv bnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPGZvbnQgc2l6ZT0iMyIgY29s b3I9ImJsYWNrIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPGJyPg0KLS08YnI+DQpPcGVuIFdl Yk1haWwgUHJvamVjdCAoPGEgaHJlZj0iaHR0cDovL29wZW53ZWJtYWlsLm9yZy8iIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vb3BlbndlYm1haWwub3JnPC9hPjwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7 YmFja2dyb3VuZDp3aGl0ZSI+DQo8Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IuWu i+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj4pPC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+DQo8Zm9udCBz aXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9mb250Pjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KaXBwbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 aXBwbUBpZXRmLm9yZyI+aXBwbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG08L2E+PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0i5a6L5L2TIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D9F2081SZXEMA510MBXchi_-- From nobody Thu May 29 22:34: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 F3D781A0740; Thu, 29 May 2014 22:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, 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 Ne1IPDBHCC9X; Thu, 29 May 2014 22:34:35 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E178A1A032C; Thu, 29 May 2014 22:34:34 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id db11so1557806veb.22 for ; Thu, 29 May 2014 22:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o1pfp6JoZtiX96UD8tNfr7mUMRKAjgMberz+qUujvNo=; b=soTuKQGEQacoTJ68wBFonKETYx0NDG7PXSvTI76nPNLSYb0cBOxi0k8t9hb3S/KV7e c4SxKJ8zXszNO15pzK2SYaToR37jxd+6amXiyeG3XEyP3F9jixi/comOO/HeJP2eomKS C8csBRxLJkmSBCp+KjLK9NoUfqJjqq+dXCBuiiPQehmbhLdKsf7J/641B7r3vp7/tsvr J3gl6qPZLkrHj4Nuym46GuIQKEkxxPp3Rrm8nSOZX2M4oEtS84bSWonUWsIiLOd5tLEs lYFGhWjWy3J1siDn+kMCuNUco4LmpS6VBnKCV153yLlieh1j/MBe8l3j2Z2BLoVcbK8/ 2VrQ== MIME-Version: 1.0 X-Received: by 10.52.13.41 with SMTP id e9mr9725193vdc.21.1401428069896; Thu, 29 May 2014 22:34:29 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 29 May 2014 22:34:29 -0700 (PDT) In-Reply-To: References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <1401370260.60566.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D89A@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Thu, 29 May 2014 22:34:29 -0700 Message-ID: From: Greg Mirsky To: Mach Chen Content-Type: multipart/alternative; boundary=20cf302efaf648da4f04fa9766ea Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2_3Q9MM0N0_dw1w2Htmp6z3JmIU Cc: "ippm@ietf.org" , "marc.ibrahim" , "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 30 May 2014 05:34:38 -0000 --20cf302efaf648da4f04fa9766ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mach, yes, I agree. In my thinking I implicitly thought that selecting specific traffic flow for measurement is one of characteristics of being part of Measurement Domain/Instance. That may be so, but I expect that it could be not complete to define/identify the Measurement Domain/Instance. Regards, Greg On Thu, May 29, 2014 at 8:45 PM, Mach Chen wrote: > Hi Greg, > > > > IMHO, whether C is doing Active or Passive is dependent on whether it > belongs to the same Measurement Instance of A and B. If it is, then it is > Active, otherwise Passive. > > > > Best regards, > > Mach > > > > *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Friday, May 30, 2014 12:41 AM > *To:* STARK, BARBARA H > *Cc:* marc.ibrahim; lmap@ietf.org; ippm@ietf.org > > *Subject:* Re: [ippm] [lmap] I-D Action: draft-ietf-lmap-framework-05.txt > > > > Hi Barbara, > > I think that if MA C counts only PINGs generated by A and B, then it is > still Active Measurement Task. If MA C counts any PING it sees, then I'd > consider it performing Passive Measurement in Measurement Domain that > includes MAs A, B, and C. > > On the second set of questions: > > I agree with #3 > > Regards, > > Greg > > > > On Thu, May 29, 2014 at 8:01 AM, STARK, BARBARA H wrote: > > I still have questions. I feel there=E2=80=99s still ambiguity and overla= p in > proposed definitions. My main goal is to get rid of ambiguity and overlap= . > > > > One thing I read in Marc=E2=80=99s email was: > > We have MA1 sending UDP traffic to MA2. MA2 will receive UDP packet and > compute jitter. > > This is clearly an active measurement task for MA1. > > This to me suggests an idea that Active Measurement Method (or Task, whic= h > so far has been defined as an instantiation of a Method) doesn=E2=80=99t = need to > actually measure anything at all. It just needs to generate (inject) Acti= ve > Measurement Traffic. It may or may not measure any performance or > reliability parameters. That is, there was no description of MA1 measurin= g > the UDP traffic it sent to MA2, as a qualifier for identifying this as an > Active Measurement Task. > > > > Looking at PING again. Let=E2=80=99s consider a system where there is a M= A (A) > generating a PING message, receiving a response message, and calculating > the time between these 2 events, an MA (B) receiving the PING and > generating a response, and an MA (C) that is in between A and B and count= s > the number of PING messages it sees. What I think I=E2=80=99m reading is: > > 1. A is doing an Active Measurement Task. > > 2. B is doing an Active Measurement Task. [Note that B hasn=E2=80= =99t > measured anything.] > > 3. C is doing a Passive Measurement Task. > > If the above is correct, I=E2=80=99d be fine with that. > > > > So here=E2=80=99s a multiple choice question for y=E2=80=99all: > > B starts counting received PING messages. Select the correct answer from > those below, or invent a different answer. > > 1. B=E2=80=99s counting of received PINGs is a new Passive Measurem= ent > Task, unrelated to the PING responding Task. > > 2. B=E2=80=99s counting of received PINGs is part of the existing A= ctive > Measurement Task that involves responding to PINGs. > > 3. B=E2=80=99s counting of received PINGs is part of a new Active > Measurement Task, unrelated to the PING responding Task. > > 4. All of the above could be true, depending on how the Measurement > Methods are defined. > > 5. 1 or 2 could be true, depending on how the Measurement Methods > are defined. > > > > Barbara > > > > *From:* KEN KO [mailto:KEN.KO@adtran.com] > *Sent:* Thursday, May 29, 2014 10:18 AM > *To:* Nalini Elkins; marc.ibrahim; STARK, BARBARA H; Juergen > Schoenwaelder; Vero Zheng > *Cc:* draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; > lmap@ietf.org > *Subject:* RE: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > > I agree with Marc=E2=80=99s comments, e.g., a Measurement Method is Activ= e if any > MA involved in the measurement is generating measurement traffic. And yes= , > PING is an Active Measurement Method. > > > > However, traffic measured by a Passive Method can easily include > measurement traffic generated by an unrelated Active Method. In this > context for instance, a Measurement Method that does nothing but count > received packets is still Passive, even if some of those packets are due = to > unrelated PINGs (or throughput tests, etc.). > > > > > *From:* lmap [mailto:lmap-bounces@ietf.org ] *On > Behalf Of *Nalini Elkins > *Sent:* Thursday, May 29, 2014 9:31 AM > *To:* marc.ibrahim; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng > *Cc:* draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; > lmap@ietf.org > *Subject:* Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > > The problem is what to consider as "injected traffic". For example, on > many networks, various devices, for their own purposes do PING commands. > So, then does that convert the entire measurement to active? > > > > Thanks, > > > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > > ------------------------------ > > *From:* marc.ibrahim > *To:* "STARK, BARBARA H" ; Nalini Elkins < > nalini.elkins@insidethestack.com>; Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de>; Vero Zheng > *Cc:* "lmap@ietf.org" ; "ippm@ietf.org" ; " > draft-ietf-lmap-framework@tools.ietf.org" < > draft-ietf-lmap-framework@tools.ietf.org> > *Sent:* Thursday, May 29, 2014 6:14 AM > *Subject:* Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > Hi, > > I think the confusion comes from whether or not to consider individual MA= . > For a single MA, measuring existing traffic is passive relatively to this > given MA. > But if this traffic was sent from another MA, then the whole method is > active since > somebody has injected traffic. > > I think the definitions of active and passive methods are not relative to > an MA but to > all MAs/MPs involved each measurement. If this is the case, "Receiving" i= s > not really > different from "generating" since an MA will receive and measure what has > been > generated. > > > BR, > > Marc. > > On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote > > ?? Receiving does or doesn't need to be a portion of the Active > Measurement > > Method definition? If a Passive Measurement Method is any method that > measures > > traffic without injecting traffic, doesn't that cover a Measurement > Method > > that measures received traffic? Barbara > > > > From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com] > > Sent: Thursday, May 29, 2014 8:49 AM > > To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng > > Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; > ippm@ietf.org > > Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > > /*snip*/ > > >>> Active Measurement Method - The process of measuring some > performance or > reliability parameter associated with the transfer of Traffic by > generating and/or > receiving Active Measurement Traffic. > > >>> > > /*snip*/ > > >>> Passive Measurement Method- The process of measuring some > performance or > reliability parameter associated with the existing traffic on the network= . > > /*snip*/ > > > > >>But what if I have an MA passively measuring traffic that was injecte= d > > >>(perhaps by some other MA) for the purpose of measuring it? Why is > > >>this distinction REAL vs non-REAL useful? And what is the definition > > >>of REAL of "existing traffic" anyway? If I inject measurement traffic > > >>observed by some MA, it is "existing traffic", no? > > > > > Yes, point well taken. The distinction we wanted to make is that the > passive > measurement technique does not inject traffic. Other MA's or indeed othe= r > devices on > the network create traffic for their own purposes, some of which may be > performance > measurement. We also wanted to come up with a good definition for passiv= e > measurement > that would work for all parties. How is the following? > > > > > Passive Measurement Method- The process of measuring some performance > or reliability > parameter associated with the traffic on the network. The passive > measurement method > does not inject traffic for the purposes of measurement. > > > > >>Would that mean that the definition of Active Measurement Method > wouldn't involve > receiving Active Measurement Traffic, and only generated (injecting)? > > >>Active Measurement Method - The process of measuring some performance > or reliability > parameter associated with the transfer of traffic by generating Active > Measurement > Traffic. > > > > Indeed, the word "receiving" needs to be a portion of the Active > Measurement > > Method definition. Thanks! > > > > Nalini > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > -- > Open WebMail Project (http://openwebmail.org > > ) > > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > --20cf302efaf648da4f04fa9766ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mach,
yes, I agree. In my think= ing I implicitly thought that selecting specific traffic flow for measureme= nt is one of characteristics of being part of Measurement Domain/Instance. = That may be so, but I expect that it could be not complete to define/identi= fy the Measurement Domain/Instance.

Regards,
Greg

On Thu, May 29, 2014 at 8:45 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg,

=C2=A0

IMHO, whether C is doing Active or Passive is dependent on whether it belongs to= the same Measurement Instance of A and B. If it is, then it is Active, oth= erwise Passive.

=C2=A0

Best regards,

Mach

=C2=A0

From: ippm [mailto:ip= pm-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Friday, May 30, 2014 1= 2:41 AM
To: STARK, BARBARA H
Cc: marc.ibrahim; lmap@ietf.org; ippm@ietf.org


Subject: Re: [ippm] [lmap] I= -D Action: draft-ietf-lmap-framework-05.txt

=C2=A0=

Hi Barbara,

I think that if MA C counts only P= INGs generated by A and B, then it is still Active Measurement Task. If MA = C counts any PING it sees, then I'd consider it performing Passive Measurement in Measurement Domain that includes MAs A, B, and C.

On the second set of questions:=

I = agree with #3

Regards,

Greg

=C2=A0

On Thu, May 29, 2014 at 8:01 AM, S= TARK, BARBARA H <bs7= 652@att.com> wrote:

I still have questions. I feel there=E2=80= =99s still ambiguity and overlap in proposed definitions. My main goal is to ge= t rid of ambiguity and overlap.

=C2=A0=

One thing I read in Marc=E2=80=99s email was= :

We have MA1 sending UDP traffic to MA2. MA2 will recei= ve UDP packet and compute jitter.

This is clearly an active measurement task for MA1.=

This to me suggests an idea that Active Measurement Method (or Task, which so far has been defined as an instantia= tion of a Method) doesn=E2=80=99t need to actually measure anything at all.= It just needs to generate (inject) Active Measurement Traffic. It may or m= ay not measure any performance or reliability parameters. That is, there was no description of MA1 measuring the UDP tra= ffic it sent to MA2, as a qualifier for identifying this as an Active Measu= rement Task.

=C2=A0=

Looking at PING again. Let=E2=80=99s conside= r a system where there is a MA (A) generating a PING message, receiving a re= sponse message, and calculating the time between these 2 events, an MA (B) = receiving the PING and generating a response, and an MA (C) that is in betw= een A and B and counts the number of PING messages it sees. What I think I=E2=80=99m reading is:

1.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 A is doing an Active Measurement Task.<= span lang=3D"EN-US">

2.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 B is doing an Active Measurement Task. [Note that B h= asn=E2=80=99t measured anything.]=

3.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 C is doing a Passive Measurement Task.<= span lang=3D"EN-US">

If the above is correct, I=E2=80=99d be fine= with that.

=C2=A0=

So here=E2=80=99s a multiple choice question= for y=E2=80=99all:

B starts counting received PING messages. Select the correct answer from those below, or invent a different answer.<= /span>

1.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 B=E2=80=99s counting of received PINGs is a new Passi= ve Measurement Task, unrelated to the PING responding Task.

2.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 B=E2=80=99s counting of received PINGs is part of the= existing Active Measurement Task that involves responding to PINGs.

3.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 B=E2=80=99s counting of received PINGs is part of a n= ew Active Measurement Task, unrelated to the PING responding Task.

4.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 All of the above could be true, depending on how the = Measurement Methods are defined.<= u>

5.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 1 or 2 could be true, depending on how the Measuremen= t Methods are defined.

=C2=A0=

Barbara

=C2=A0=

From:<= /span> KEN KO [mailto:KEN.= KO@adtran.com]
Sent: Thursday, May 29, 2014= 10:18 AM
To: Nalini Elkins; marc.ibra= him; STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng
Cc: draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@= ietf.org
Subject: RE: [lmap] [ippm] I= -D Action: draft-ietf-lmap-framework-05.txt

=C2=A0=

I agree with Marc=E2=80=99s comments, e.g., = a Measurement Method is Active if any MA involved in the measurement is gene= rating measurement traffic. And yes, PING is an Active Measurement Method.<= /span>

=C2=A0=

However, traffic measured by a Passive Method can easily include measurement traffic generated by an unrelated Ac= tive Method. In this context for instance, a Measurement Method that does n= othing but count received packets is still Passive, even if some of those p= ackets are due to unrelated PINGs (or throughput tests, etc.).<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0

From:<= /span> lmap [mailto:lm= ap-bounces@ietf.org] On Behalf Of Nalini Elkins Sent: Thursday, May 29, 2014= 9:31 AM
To: marc.ibrahim; STARK, BAR= BARA H; Juergen Schoenwaelder; Vero Zheng
Cc: draft-ietf-lmap-framework@tools.ietf.org; ippm@ietf.org; lmap@= ietf.org
Subject: Re: [lmap] [ippm] I= -D Action: draft-ietf-lmap-framework-05.txt

=C2=A0=

The problem is what to consider as "injected traffic".= =C2=A0For example, on many networks, various devices, for their own purpos= es do PING commands. =C2=A0 =C2=A0So, then does that convert the entire measu= rement to active?

=C2=A0

Thanks,<= /p>

=C2=A0

Nalini Elkins
Inside Products, Inc.
(831) 659-8360 www.insidethest= ack.com

=C2=A0

From: marc.ibrahim <marc.ibrahim@usj.edu.lb>
To: "STARK, BARBARA H&q= uot; <bs7652@att.com= >; Nalini Elkins <nalini.elkins@insidethestack.com>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Ver= o Zheng <vero= .zheng@huawei.com>
Cc: "lmap@ietf.org" <lmap@ietf.org>; "ippm@ietf.org" <ippm@ietf.org>; "draft-ietf-lmap-framework@tools.ietf.org" <draf= t-ietf-lmap-framework@tools.ietf.org>
Sent: Thursday, May 29, 2014= 6:14 AM
Subject: Re: [lmap] [ippm] I= -D Action: draft-ietf-lmap-framework-05.txt


Hi,

I think the confusion comes from whether or not to consider individual MA.<= br> For a single MA, measuring existing traffic is passive relatively to this g= iven MA.
But if this traffic was sent from another MA, then the whole method is acti= ve since
somebody has injected traffic.

I think the definitions of active and passive methods are not relative to a= n MA but to
all MAs/MPs involved each measurement. If this is the case, "Receiving= " is not really
different from "generating" since an MA will receive and measure = what has been
generated.


BR,

Marc.

On Thu, 29 May 2014 12:57:35 +0000, STARK, BARBARA H wrote
> ?? Receiving does or doesn't need to be a portion of the Active Me= asurement
> Method definition? If a Passive Measurement Method is any method that = measures
> traffic without injecting traffic, doesn't that cover a Measuremen= t Method
> that measures received traffic? Barbara
>
> From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com]
> Sent: Thursday, May 29, 2014 8:49 AM
> To: STARK, BARBARA H; Juergen Schoenwaelder; Vero Zheng
> Cc: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org; ippm@ietf.org
> Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.tx= t
>
> /*snip*/
> >>> Active Measurement Method - The process of measuring some= performance or
reliability parameter associated with the transfer of Traffic by generating= and/or
receiving Active Measurement Traffic.
> >>>
> /*snip*/
> >>> Passive Measurement Method- The process of measuring some= performance or
reliability parameter associated with the existing traffic on the network.<= br> > /*snip*/
>
> >>But what if I have an MA passively measuring traffic that was = injected
> >>(perhaps by some other MA) for the purpose of measuring it? Wh= y is
> >>this distinction REAL vs non-REAL useful? And what is the defi= nition
> >>of REAL of "existing traffic" anyway? If I inject me= asurement traffic
> >>observed by some MA, it is "existing traffic", no? >
> > Yes, point well taken.=C2=A0 The distinction we wanted to make is= that the passive
measurement technique does not inject traffic.=C2=A0 Other MA's or inde= ed other devices on
the network create traffic for their own purposes, some of which may be per= formance
measurement.=C2=A0 We also wanted to come up with a good definition for pas= sive measurement
that would work for all parties.=C2=A0 How is the following?
>
> > Passive Measurement Method- The process of measuring some perform= ance or reliability
parameter associated with the traffic on the network.=C2=A0 The passive mea= surement method
does not inject traffic for the purposes of measurement.
>
> >>Would that mean that the definition of Active Measurement Meth= od wouldn't involve
receiving Active Measurement Traffic, and only generated (injecting)?
> >>Active Measurement Method - The process of measuring some perf= ormance or reliability
parameter associated with the transfer of traffic by generating Active Meas= urement
Traffic.
>
> Indeed, the word "receiving" needs to be a portion of the Ac= tive Measurement
> Method definition.=C2=A0 Thanks!
>
> Nalini
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org&l= t;mailto:lmap@ietf.org>




--
Open WebMail Project (http://openwebmail.org

)

=C2=A0

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

=C2=A0=


--20cf302efaf648da4f04fa9766ea-- From nobody Thu May 29 23:08: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 8D5C91A06EE; Thu, 29 May 2014 23:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 FwmnQ2wILDVI; Thu, 29 May 2014 23:08:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC621A0313; Thu, 29 May 2014 23:07:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B70C5FF3; Fri, 30 May 2014 08:07:53 +0200 (CEST) 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 OWzUtYzVT88d; Fri, 30 May 2014 08:07:44 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 30 May 2014 08:07:53 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49A1D20017; Fri, 30 May 2014 08:07:54 +0200 (CEST) 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 qNQCgO7CejeA; Fri, 30 May 2014 08:07:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3DFE20013; Fri, 30 May 2014 08:07:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 754FC2D1275B; Fri, 30 May 2014 08:07:52 +0200 (CEST) Date: Fri, 30 May 2014 08:07:52 +0200 From: Juergen Schoenwaelder To: "marc. ibrahim" Message-ID: <20140530060752.GB84228@elstar.local> Mail-Followup-To: "marc. ibrahim" , "ippm@ietf.org" , "lmap@ietf.org" References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130810.GB82599@elstar.local> <20140529131922.M26067@mail.usj.edu.lb> <20140529133628.GA82746@elstar.local> <20140529134146.M20495@usj.edu.lb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140529134146.M20495@usj.edu.lb> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/50CAWNJ2qsX5_DYFuY45qWOyobk Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] active and passive measurement method / task definition 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, 30 May 2014 06:08:03 -0000 On Thu, May 29, 2014 at 05:06:03PM +0300, marc. ibrahim wrote: > Juergen, > > I am just trying to discuss what I felt is unclear in the definitions. > Let me give a practical example from a project i'm doing. > We have MA1 sending UDP traffic to MA2. MA2 will receive UDP packet and compute jitter. > This is clearly an active measurement task for MA1. > What is unclear for me is how to define MA2 tasks. > Is it just one active task consisting in receiving packets from MA1 and computing > jitter, or two tasks: > > - One active task consisting in receiving the active traffic generated by MA1, > - One passive task consisting in measuring jitter for the udp flow. It is passive > according to the definition since MA2 does not generate the observed flow. > Since tasks are local to an MA, there are clearly two tasks involved. And if a classification is necessary (I do not know why), then one could be active and the other passive. My preference however is to design things such that a such a classification is not really necessary. /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 May 29 23:24: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 3317D1A06EE; Thu, 29 May 2014 23:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 55s7oTRcuGXA; Thu, 29 May 2014 23:24:08 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DA31A02B0; Thu, 29 May 2014 23:24:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 39A2B788; Fri, 30 May 2014 08:24:02 +0200 (CEST) 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 CKtB0giksdzh; Fri, 30 May 2014 08:23:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 30 May 2014 08:24:01 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1CC22002C; Fri, 30 May 2014 08:24:02 +0200 (CEST) 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 facoXhwdVHH4; Fri, 30 May 2014 08:24:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1047920013; Fri, 30 May 2014 08:24:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F08FC2D1283E; Fri, 30 May 2014 08:23:59 +0200 (CEST) Date: Fri, 30 May 2014 08:23:59 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140530062359.GC84228@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , KEN KO , "marc. ibrahim" , Nalini Elkins , Vero Zheng , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "lmap@ietf.org" , "ippm@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113043DB82@GAALPA1MSGUSR9L.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043DB82@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9vQlDfqPD2hiteKCzS2mp0IIZgM Cc: "marc. ibrahim" , Nalini Elkins , "philip.eardley@bt.com" , "lmap@ietf.org" , "ippm@ietf.org" , Vero Zheng , KEN KO , "trevor.burbridge@bt.com" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt 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, 30 May 2014 06:24:10 -0000 On Thu, May 29, 2014 at 09:26:14PM +0000, STARK, BARBARA H wrote: > > I'm becoming ever more strongly convinced that either ippm or lmap > needs a new term -- I don't care which. But my reading of framework > and the information model is that what lmap is calling a Measurement > Method and Measurement Task is related to the specific role the MA > plays in the holistic technique. [...] > As a compromise (since many seem to want Measurement Method to be > the holistic technique) maybe we should use Measurement Method for > the holistic technique (and ippm can define that, because it's not > really central to lmap), Measurement Method Role for the role of the > Measurement Method that is implemented on a MA, and Measurement Task > is an instantiation of a Measurement Method Role (which means a Task > is *not* an instantiation of the Measurement Method -- which assumes > ippm doesn't need a term for an instantiation of the holistic > technique). Perhaps this is a way to go. But then, I am not sure why Measurement Role is needed either. For LMAP, it may be sufficient to just talk about Measurement Tasks. The word 'method' does not show up at all in the information model. In the framework document, 'method' is used in many places but it seems in some places it really should be 'task', in others 'method' may be appropriate if we read it with a more holistic view. It seems making this distinction will make the framework clearer. While searching through the text, I did not see a need to define 'Measurement Method Role' as a new term. /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 May 30 00:34: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 9A2491A0663; Thu, 29 May 2014 15:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ZFBJC-IA8nWK; Thu, 29 May 2014 15:06:30 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABCB1A023E; Thu, 29 May 2014 15:06:30 -0700 (PDT) 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 6F9E4554B04; Thu, 29 May 2014 18:08:44 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-green.research.att.com (Postfix) with ESMTP id 4D369E2891; Thu, 29 May 2014 18:05:52 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Thu, 29 May 2014 18:06:26 -0400 From: "MORTON, ALFRED C (AL)" To: KEN KO , "STARK, BARBARA H" , marc.ibrahim , Nalini Elkins , Juergen Schoenwaelder , Vero Zheng , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" Date: Thu, 29 May 2014 18:06:25 -0400 Thread-Topic: [ippm] [lmap] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe19m4ogsNcYgEECVMd9hDcgkN5tYIWOA//+zJkCAAD4IFw== Message-ID: <2845723087023D4CB5114223779FA9C80178E0CD93@njfpsrvexg8.research.att.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/tZPh-0r2bP57TP8ekGsiod-O6Cs X-Mailman-Approved-At: Fri, 30 May 2014 00:34:43 -0700 Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 29 May 2014 22:06:32 -0000 Long thread today... I think it ended-up in a productive place, a logical examination of a realistic scenario and whether the framework and (more importantly) the Information Model have the flexibility to instantiate it=20 ( A - C - B hosts observing or performing ICMP echo req/replies). It's a similar concept to one we examined in IPPM and wrote about:=20 http://tools.ietf.org/html/rfc5644 The key factor in determining the type of measurement in this RFC was the a priori knowledge of the packet (or stream) from the source. Packet loss could be measured at mid-point "C"(and subsequent points) because the measurement system knew when packets were sent from "A" could distinguish between different packets of the same stream, and knew=20 how long to wait for them.=20 Once we are satisfied that the Information Model allows the needed flexibil= ity for control, it would be good to take another step: The Information Model depends on the Performance Metrics Registry, which we have split into active and passive sub-registries. If the observations you want to make at mid-point "C" can be supported with a metric from the passive registry, that's input to the measurement categorization. If not, try the active regi= stry. If the active and/or passive registries support some important scenarios,=20 then we've come a long way. regards, Al ________________________________________ From: ippm [ippm-bounces@ietf.org] On Behalf Of KEN KO [KEN.KO@adtran.com] Sent: Thursday, May 29, 2014 2:15 PM To: STARK, BARBARA H; marc.ibrahim; Nalini Elkins; Juergen Schoenwaelder; V= ero Zheng; trevor.burbridge@bt.com; philip.eardley@bt.com Cc: ippm@ietf.org; lmap@ietf.org Subject: Re: [ippm] [lmap] I-D Action: draft-ietf-lmap-framework-05.txt Barbara, I agree with most of what you are saying. Measurement Methods can be complex and can create different roles for diffe= rent MAs, and it is very possible for each MA to be configured only with it= s own role. There may be Methods for which MA A could participate with MAs = B and C without a priori knowledge of their roles, and get completely diffe= rent yet equally proper responses from each of them. I hadn't considered th= is and it contradicts my earlier comment (which I rescind) about the initia= ting MA having all information relevant to a Task. Having said all that, I still don't see the need for a new term beyond the = language we have already used - that is, each MA's role in executing a Task= . While we're at it, we might want to consider the above scenario with regard= to the draft Information Model. Can we currently configure a Task as being= triggered by something other than a Schedule - in response to an external = stimulus like a message from a remote MA? I think we can: - One or more ma-task-options objects within ma-task-obj specifies the non-= Schedule conditions under which the Task is initiated. Unless Schedule-base= d initiation is also desired, the Measurement Task Configuration would not = be referenced in a local Schedule. However, I don't see this addressed explicitly in either the framework or t= he information model, and if this behavior is in scope I think it needs lan= guage for clarity. The other area you touch on (unilateral exceptions where, for instance, a M= A does not respond to MAs outside a configured address range) seems equally= valid, and I'm more open to a new term to describe it. Does "exceptions" = fit the bill? Ken > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Thursday, May 29, 2014 1:20 PM > To: marc.ibrahim; KEN KO; Nalini Elkins; Juergen Schoenwaelder; Vero Zhen= g > Cc: lmap@ietf.org; ippm@ietf.org > Subject: RE: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt > > > In a simple A-B ping example, it is a single task initiated by A that > > is executing an active task that has been instructed by the > > controller, while B is just "participating" > > in the task. I don't see that we can we talk about a task being execute= d by > B. > > Is replying to a ping a full task that can be instructed and scheduled > > by the controller? I don't see that. > > I think it would be possible to schedule B to only respond to pings at ce= rtain > times of day. Responding to ping is something that can be enabled/disable= d. > In which case it can be enabled and disabled according to a schedule. The > enabling/disabling of B's ability to respond to pings can be completely a= nd > totally distinct from any schedules that involve B initiating ping -- the= y are 2 > distinct roles. Configuration of these roles is also distinct (responding= may not > require any configuration other than the schedule, or it could be configu= red > to only respond to pings from certain IP addresses). It may even be that = an > MA only has the ability to initiate ping and never respond, or vice versa= . > > I very much believe that from the MA perspective (lmap), it is critical t= hat we > be able to talk about the MA's role in a holistic technique. I also belie= ve that > the MA can have a passive role (does not generate measurement traffic) or > an active role (generates measurement traffic) independent of how ippm > may choose to characterize the holistic technique. > Barbara _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm= From nobody Fri May 30 00:53: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 9A7B71A08A3; Fri, 30 May 2014 00:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 3LKkSTweQ5m7; Fri, 30 May 2014 00:36:45 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032F11A0869; Fri, 30 May 2014 00:36:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQGADk0iFPGmAcV/2dsb2JhbABZDoJXIoEqqhUBAQEBAQEGmBkBgQYWdIIlAQEBAQMSKBolDAQCAQgNBAQBAQsUCQcyFAkIAgQBDQUIGoggAac7rzoXhVWITDEHBoMlgRUEoRCMFoJ4QIIv X-IronPort-AV: E=Sophos;i="4.98,939,1392181200"; d="scan'208";a="65525408" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 30 May 2014 03:36:40 -0400 X-OutboundMail_SMTP: 1 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; 30 May 2014 03:18:57 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 30 May 2014 09:36:37 +0200 From: "Romascanu, Dan (Dan)" To: "STARK, BARBARA H" , KEN KO , marc.ibrahim , Nalini Elkins , Juergen Schoenwaelder , Vero Zheng , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe2pIljOlG/4PhUicmp7JdEELWptX8OEAgADLAMA= Date: Fri, 30 May 2014 07:36:37 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7F4DB3@AZ-FFEXMB04.global.avaya.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113043DB82@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043DB82@GAALPA1MSGUSR9L.ITServices.sbc.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/dB04StJWGOpzOnhwM6KiJqinEOw X-Mailman-Approved-At: Fri, 30 May 2014 00:53:51 -0700 Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 30 May 2014 07:36:54 -0000 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Friday, May 30, 2014 12:26 AM > To: KEN KO; marc.ibrahim; Nalini Elkins; Juergen Schoenwaelder; Vero Zhen= g; > trevor.burbridge@bt.com; philip.eardley@bt.com > Cc: ippm@ietf.org; lmap@ietf.org > Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt >=20 > > Measurement Methods can be complex and can create different roles for > > different MAs, and it is very possible for each MA to be configured > > only with its own role. There may be Methods for which MA A could > > participate with MAs B and C without a priori knowledge of their > > roles, and get completely different yet equally proper responses from > > each of them. I hadn't considered this and it contradicts my earlier > > comment (which I rescind) about the initiating MA having all informatio= n > relevant to a Task. > > > > Having said all that, I still don't see the need for a new term beyond > > the language we have already used - that is, each MA's role in executin= g a > Task. >=20 > I'm becoming ever more strongly convinced that either ippm or lmap needs = a > new term -- I don't care which. But my reading of framework and the > information model is that what lmap is calling a Measurement Method and > Measurement Task is related to the specific role the MA plays in the holi= stic > technique. The MA absolutely does not need to know what other roles do or > how they are configured. It doesn't care what they do. It only knows what= it > has to do. I think this is also important to understand in the design of = the > registry -- if there is some metric in the registry that requires proper > configuration of multiple roles, the registry needs to be able to express= what > the proper configuration is for each distinct role. As a compromise (sinc= e > many seem to want Measurement Method to be the holistic technique) > maybe we should use Measurement Method for the holistic technique (and > ippm can define that, because it's not really central to lmap), Measureme= nt > Method Role for the role of the Meas urement Method that is implemented > on a MA, and Measurement Task is an instantiation of a Measurement > Method Role (which means a Task is *not* an instantiation of the > Measurement Method -- which assumes ippm doesn't need a term for an > instantiation of the holistic technique). Then lmap can have a Measuremen= t > Method Active Role that generates measurement traffic and may measure > parameters, and a Measurement Method Passive Role that does not > generate traffic and measures parameters. Ippm can define if there're suc= h > things as Active or Passive Measurement Methods. In lmap, we really only > need to care about whether the role is active or passive, and not how the > holistic technique is characterized. >=20 Hi Barbara. Doesn't become too complicated? What is the difference between the Measurem= ent Method Role and Measurement Task and why do we need the two distinct te= rms? Maybe it would help if you can provide a definition of Measurement Met= hod Role because I frankly cannot compile ' Measurement Task is an instanti= ation of a Measurement Method Role', in other words why do we need a generi= c term and an instantiation?=20 Thanks and Regards, Dan (speaking as contributor) From nobody Fri May 30 01:18: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 E3BDF1A026D for ; Fri, 30 May 2014 01:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 ZnSixhtWLOJu for ; Fri, 30 May 2014 01:18:36 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id A29541A00AA for ; Fri, 30 May 2014 01:18:35 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee153883eba580-09580; Fri, 30 May 2014 16:18:03 +0800 (CST) X-RM-TRANSID: 2ee153883eba580-09580 Received: from cmccPC (unknown[10.2.52.189]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee253883eb6c78-9ad94; Fri, 30 May 2014 16:18:03 +0800 (CST) X-RM-TRANSID: 2ee253883eb6c78-9ad94 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: Date: Fri, 30 May 2014 16:18:32 +0800 Message-ID: <016601cf7bdf$bf0bd1a0$3d2374e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac965e2i7q+8TIQNQEePj/z8QuQldgA+YogA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Kbu7VN5nI2TeGS9-Hac5s4qoY1U Subject: [lmap] FW: New Version Notification for draft-deng-lmap-collaboration-00.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, 30 May 2014 08:18:38 -0000 Hi all, We submitted a new use-case draft for collaborative measurements, and = look forward to your review and comments. Thanks, Lingli > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, May 29, 2014 10:21 AM > To: Rachel Huang; Deng Lingli; Shihui Duan; Shihui Duan; Lingli Deng; = Rachel > Huang > Subject: New Version Notification for = draft-deng-lmap-collaboration-00.txt >=20 >=20 > A new version of I-D, draft-deng-lmap-collaboration-00.txt > has been successfully submitted by Lingli Deng and posted to the > IETF repository. >=20 > Name: draft-deng-lmap-collaboration > Revision: 00 > Title: Use-cases for Collaborative LMAP > Document date: 2014-05-29 > Group: Individual Submission > Pages: 11 > URL: > = http://www.ietf.org/internet-drafts/draft-deng-lmap-collaboration-00.txt > Status: > https://datatracker.ietf.org/doc/draft-deng-lmap-collaboration/ > Htmlized: = http://tools.ietf.org/html/draft-deng-lmap-collaboration-00 >=20 >=20 > Abstract: > This document discusses the motivation and use-cases for > collaborative LMAP practices, where multiple autonomous measurement > systems collaborate together to help with UoE enhancement by ICPs, > network performance monitory to guide ISP/Regulator coordination > between autonomous network domains and/or regulatory policies and > cross-boundary troubleshooting for complaints from end consumers. >=20 >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat From nobody Fri May 30 01:26: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 CDE1E1A037A; Fri, 30 May 2014 01:26:30 -0700 (PDT) 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 xsb2bXHAc7kr; Fri, 30 May 2014 01:26:28 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462FF1A026D; Fri, 30 May 2014 01:26:28 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 30 May 2014 09:26:17 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.240]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Fri, 30 May 2014 09:26:22 +0100 From: To: , Date: Fri, 30 May 2014 09:26:21 +0100 Thread-Topic: [ippm] [lmap] active and passive measurement method / task definition Thread-Index: Ac97zYXm4PxF1QRrQbCW8L/b6B2SQQAEm4cg Message-ID: References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130810.GB82599@elstar.local> <20140529131922.M26067@mail.usj.edu.lb> <20140529133628.GA82746@elstar.local> <20140529134146.M20495@usj.edu.lb> <20140530060752.GB84228@elstar.local> In-Reply-To: <20140530060752.GB84228@elstar.local> 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/k96G9PEmRxrFOCwRxafat5BOWGU Cc: ippm@ietf.org, lmap@ietf.org Subject: Re: [lmap] [ippm] active and passive measurement method / task definition 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, 30 May 2014 08:26:30 -0000 On active vs. passive I think it really is about viewpoint rather than abso= lutes. i.e. the ping example is active if I have set up the pings, but pass= ive if they were set up by someone else for a different purpose. However, I have to echo Juergen's point below - I do think we should be abl= e to design the framework and information model to be agnostic to whether a= test is passive or active. Trevor. >-----Original Message----- >From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Juergen >Schoenwaelder >Sent: 30 May 2014 07:08 >To: marc. ibrahim >Cc: lmap@ietf.org; ippm@ietf.org >Subject: Re: [ippm] [lmap] active and passive measurement method / task >definition > >On Thu, May 29, 2014 at 05:06:03PM +0300, marc. ibrahim wrote: >> Juergen, >> >> I am just trying to discuss what I felt is unclear in the definitions. >> Let me give a practical example from a project i'm doing. >> We have MA1 sending UDP traffic to MA2. MA2 will receive UDP packet and >compute jitter. >> This is clearly an active measurement task for MA1. >> What is unclear for me is how to define MA2 tasks. >> Is it just one active task consisting in receiving packets from MA1 >> and computing jitter, or two tasks: >> >> - One active task consisting in receiving the active traffic generated >> by MA1, >> - One passive task consisting in measuring jitter for the udp flow. It >> is passive according to the definition since MA2 does not generate the o= bserved >flow. >> > >Since tasks are local to an MA, there are clearly two tasks involved. And = if a >classification is necessary (I do not know why), then one could be active = and the >other passive. My preference however is to design things such that a such = a >classification is not really necessary. > >/js > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From nobody Fri May 30 03:26: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 BC9211A086C; Fri, 30 May 2014 03:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 rc2gvHf4dA03; Fri, 30 May 2014 03:25:04 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 0A5FB1A0851; Fri, 30 May 2014 03:25:03 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee253885c56bd3-69bd3; Fri, 30 May 2014 18:24:22 +0800 (CST) X-RM-TRANSID: 2ee253885c56bd3-69bd3 Received: from cmccPC (unknown[10.2.43.246]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee153885c549e0-abd35; Fri, 30 May 2014 18:24:22 +0800 (CST) X-RM-TRANSID: 2ee153885c549e0-abd35 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'MORTON, ALFRED C \(AL\)'" , "'KEN KO'" , "'STARK, BARBARA H'" , "'marc.ibrahim'" , "'Nalini Elkins'" , "'Juergen Schoenwaelder'" , "'Vero Zheng'" , , References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com>, <2845723087023D4CB5114223779FA9C80178E0CD93@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80178E0CD93@njfpsrvexg8.research.att.com> Date: Fri, 30 May 2014 18:24:50 +0800 Message-ID: <017a01cf7bf1$644daa60$2ce8ff20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPe19m4ogsNcYgEECVMd9hDcgkN5tYIWOA//+zJkCAAD4IF4AAvPUg Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/gVOy6EmvRBBxRXbBM9EK60xH8d0 X-Mailman-Approved-At: Fri, 30 May 2014 03:26:08 -0700 Cc: ippm@ietf.org, lmap@ietf.org Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 30 May 2014 10:25:06 -0000 Hi Al, I agree with you on all your points, except the use of the word = "observation" for passive measurement. More inline. > The key factor in determining the type of measurement in this RFC was = the > a priori knowledge of the packet (or stream) from the source. [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] Support. From the perspective = of an MP performing a passive task, it has to do the measurement without = any reliance on the prior knowledge from the source about the targeted = traffic (when to expect it, how long and how large it would be, etc.). = While in contrast, there is an active traffic generator in any active = measurement task acting as the source, to ensure the participating MPs = measures metrics for targeted traffic with known characteristics.=20 > Packet loss could be measured at mid-point "C"(and subsequent = points) > because the measurement system knew when packets were sent from "A" > could distinguish between different packets of the same stream, and = knew > how long to wait for them. [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] There are also passive = measurement methods, which can measure packet loss at mid-point by doing = a little more than pure observation. Examples include = http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-04 and = http://tools.ietf.org/html/draft-chen-ippm-coloring-based-ipfpm-framework= -01 (where the IP header is being marked/appended by an upstream MP to = coordinate with the downstream MP for measurement on existing traffic = and no traffic is injected for the purpose of measurement therefore no = prior knowledge other than the appended/markded information piggybacked = to the targeted traffic can be assumed for any participating MP). >=20 > Once we are satisfied that the Information Model allows the needed = flexibility > for control, it would be good to take another step: The Information = Model > depends on the Performance Metrics Registry, which we have split into > active and passive sub-registries. If the observations you want to = make at > mid-point "C" can be supported with a metric from the passive = registry, > that's input to the measurement categorization. If not, try the active = registry. > If the active and/or passive registries support some important = scenarios, > then we've come a long way. [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] I would like it more if the = word "observation" is replaced by "measurement". It gives two implications which I think Vero and Nalini wanted to avoid = by raising the discussion in the first place. 1, It gives one the impression that a passive measurement task is always = performed by an individual MP and does not need any coordination from = outside.=20 2, An MP doing passive measurement is not supposed to "touch" the = traffic, but only "observes" them, in which case packet loss can hardly = be measured. > Given the fact that "passive measurement" has a lot of possibilities = more than pure observation, I echo Vero and Nalini that one should cease = using "observation" as an synonym for passive measurement. Lingli From nobody Fri May 30 06:52: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 B8A171A08AB; Fri, 30 May 2014 06:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 sFRJQ2FlT54F; Fri, 30 May 2014 06:51:55 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4811A090F; Fri, 30 May 2014 06:51:55 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 278E0120CBE; Fri, 30 May 2014 09:54:08 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id 3817FF03CB; Fri, 30 May 2014 09:51:51 -0400 (EDT) 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, 30 May 2014 09:51:51 -0400 From: "MORTON, ALFRED C (AL)" To: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= , 'Nalini Elkins' , 'Vero Zheng' Date: Fri, 30 May 2014 09:51:49 -0400 Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe19m4ogsNcYgEECVMd9hDcgkN5tYIWOA//+zJkCAAD4IF4AAvPUggABJgFA= Message-ID: <2845723087023D4CB5114223779FA9C8017992C8F1@njfpsrvexg8.research.att.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com>, <2845723087023D4CB5114223779FA9C80178E0CD93@njfpsrvexg8.research.att.com> <017a01cf7bf1$644daa60$2ce8ff20$@com> In-Reply-To: <017a01cf7bf1$644daa60$2ce8ff20$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/-ohAaukrqfFsLU_ITsFoUhELTJc Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 30 May 2014 13:51:58 -0000 SGkgTGluZ2xpLA0KDQpGb3IgYSBsb25nIHRpbWUsIHdlJ3ZlIGhhZCBhbiBlbm9ybW91cyBudW1i ZXIgb2YgDQptZWFzdXJlbWVudCBzeXN0ZW0gaW1wbGVtZW50YXRpb25zDQp0aGF0IHdlcmUgZWl0 aGVyIHB1cmVseSBhY3RpdmUgb3IgcHVyZWx5IHBhc3NpdmUuDQpJbiBhIHJlYWwgd2F5LCBhY3Rp dmUgYW5kIHBhc3NpdmUgYXJlIGF0IG9wcG9zaXRlDQplbmRzIG9mIGEgY29udGludXVtKiosIHdo ZXJlIHlvdSBoYXZlIHRoZSANCg0KLSBhbGwgdGhlIHByb2JsZW1zIG9mIGRpc3R1cmJpbmcgdGhl IG5ldHdvcmsgY29uZGl0aW9ucw0KLSBhbGwgdGhlIGFkdmFudGFnZXMgb2Yga25vd2luZyB3aGF0 IHdhcyBzZW50IGFuZCB3aGVuDQoNCndpdGggaW5qZWN0ZWQgdHJhZmZpYywgd2hhdCB3ZSBjYWxs IGFjdGl2ZSBtZXRyaWNzIGFuZCBtZWFzdXJlbWVudCwNCmFuZCB0aGUgZXhhY3Qgb3Bwb3NpdGUg c2l0dWF0aW9uIHdpdGggcGFzc2l2ZSAobm9uZSBvZiANCnRoZSBwcm9ibGVtcyBhbmQgbm9uZSBv ZiB0aGUgYWR2YW50YWdlcykuDQoNClJlY2VudGx5IHRoZXJlIGFyZSBuZXcgdGVjaG5pcXVlcyBs aWtlIE5hbGluaSBhbmQgTWlrZSdzIFBETQ0Kd2hpY2ggeW91IGNpdGUgYmVsb3cgKGFuZCBJIGZp bmQgdmVyeSBpbnRlcmVzdGluZykuDQpJIGJlbGlldmUgdGhlc2UgdGVjaG5pcXVlcywgYW5kIG90 aGVycyBmb2xrcyBoYXZlIG1lbnRpb25lZCwNCmxpZSBzb21ld2hlcmUgYmV0d2VlbiBwdXJlIGFj dGl2ZSBhbmQgcHVyZSBwYXNzaXZlLg0KDQpJdCdzIGltcG9ydGFudCB0byBtZSAoYW5kIHBvc3Np Ymx5IG90aGVycykgdG8gYW5jaG9yIG91ciANCnRlcm1pbm9sb2d5IHdpdGggYm90aCBjb21tb24g dXNlIGFuZCBkaWN0aW9uYXJ5IG1lYW5pbmcsDQpzbyBJIHVzZSB0aGUgdGVybSAib2JzZXJ2ZSIg d2l0aCB0aGUgcHVyZSBwYXNzaXZlIGNhdGVnb3J5Lg0KSWYgeW91ciB0ZWNobmlxdWUgZG9lcyBt b3JlIHRoYW4gb2JzZXJ2ZSAoYW5kIGFuYWx5emUsIHdoZXJlIA0KeW91IGNvdWxkIGNvbWJpbmUg b2JzZXJ2YXRpb25zIGZyb20gbXVsdGlwbGUgcG9pbnRzLCBldGMuKSANCnRoZW4gdGhlIHRlY2hu aXF1ZSBpcyBpbi1iZXR3ZWVuIHRoZSBleHRyZW1lcywgSU1PLg0KDQpyZWdhcmRzLA0KQWwNCg0K Kiogd2UgbWlnaHQgZHJhdyB0aGlzIGFzIGEgMkQtc3BhY2UsIGFjdGl2ZSBhbmQgcGFzc2l2ZSB3 b3VsZCBiZQ0KYXQgb3Bwb3NpdGUgY29ybmVycy4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IOmCk+eBteiOiS9MaW5nbGkgRGVuZyBbbWFpbHRvOmRlbmdsaW5nbGlA Y2hpbmFtb2JpbGUuY29tXQ0KPiBTZW50OiBGcmlkYXksIE1heSAzMCwgMjAxNCA2OjI1IEFNDQo+ IFRvOiBNT1JUT04sIEFMRlJFRCBDIChBTCk7ICdLRU4gS08nOyBTVEFSSywgQkFSQkFSQSBIOyAn bWFyYy5pYnJhaGltJzsNCj4gJ05hbGluaSBFbGtpbnMnOyAnSnVlcmdlbiBTY2hvZW53YWVsZGVy JzsgJ1Zlcm8gWmhlbmcnOw0KPiB0cmV2b3IuYnVyYnJpZGdlQGJ0LmNvbTsgcGhpbGlwLmVhcmRs ZXlAYnQuY29tDQo+IENjOiBsbWFwQGlldGYub3JnOyBpcHBtQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJFOiBbbG1hcF0gW2lwcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmst MDUudHh0DQo+IA0KPiBIaSBBbCwNCj4gDQo+IEkgYWdyZWUgd2l0aCB5b3Ugb24gYWxsIHlvdXIg cG9pbnRzLCBleGNlcHQgdGhlIHVzZSBvZiB0aGUgd29yZA0KPiAib2JzZXJ2YXRpb24iIGZvciBw YXNzaXZlIG1lYXN1cmVtZW50Lg0KPiBNb3JlIGlubGluZS4NCj4gDQo+ID4gVGhlIGtleSBmYWN0 b3IgaW4gZGV0ZXJtaW5pbmcgdGhlIHR5cGUgb2YgbWVhc3VyZW1lbnQgaW4gdGhpcyBSRkMgd2Fz DQo+IHRoZQ0KPiA+IGEgcHJpb3JpIGtub3dsZWRnZSBvZiB0aGUgcGFja2V0IChvciBzdHJlYW0p IGZyb20gdGhlIHNvdXJjZS4NCj4gW+mCk+eBteiOiS9MaW5nbGkgRGVuZ10gU3VwcG9ydC4gRnJv bSB0aGUgcGVyc3BlY3RpdmUgb2YgYW4gTVAgcGVyZm9ybWluZyBhDQo+IHBhc3NpdmUgdGFzaywg aXQgaGFzIHRvIGRvIHRoZSBtZWFzdXJlbWVudCB3aXRob3V0IGFueSByZWxpYW5jZSBvbiB0aGUN Cj4gcHJpb3Iga25vd2xlZGdlIGZyb20gdGhlIHNvdXJjZSBhYm91dCB0aGUgdGFyZ2V0ZWQgdHJh ZmZpYyAod2hlbiB0byBleHBlY3QNCj4gaXQsIGhvdyBsb25nIGFuZCBob3cgbGFyZ2UgaXQgd291 bGQgYmUsIGV0Yy4pLiBXaGlsZSBpbiBjb250cmFzdCwgdGhlcmUgaXMNCj4gYW4gYWN0aXZlIHRy YWZmaWMgZ2VuZXJhdG9yIGluIGFueSBhY3RpdmUgbWVhc3VyZW1lbnQgdGFzayBhY3RpbmcgYXMg dGhlDQo+IHNvdXJjZSwgdG8gZW5zdXJlIHRoZSBwYXJ0aWNpcGF0aW5nIE1QcyBtZWFzdXJlcyBt ZXRyaWNzIGZvciB0YXJnZXRlZA0KPiB0cmFmZmljIHdpdGgga25vd24gY2hhcmFjdGVyaXN0aWNz Lg0KPiANCj4gPiBQYWNrZXQgbG9zcyBjb3VsZCBiZSBtZWFzdXJlZCBhdCAgbWlkLXBvaW50ICAi QyIoYW5kIHN1YnNlcXVlbnQgcG9pbnRzKQ0KPiA+IGJlY2F1c2UgdGhlIG1lYXN1cmVtZW50IHN5 c3RlbSBrbmV3IHdoZW4gcGFja2V0cyB3ZXJlIHNlbnQgZnJvbSAiQSINCj4gPiBjb3VsZCBkaXN0 aW5ndWlzaCBiZXR3ZWVuIGRpZmZlcmVudCBwYWNrZXRzIG9mIHRoZSBzYW1lIHN0cmVhbSwgYW5k IGtuZXcNCj4gPiBob3cgbG9uZyB0byB3YWl0IGZvciB0aGVtLg0KPiBb6YKT54G16I6JL0xpbmds aSBEZW5nXSBUaGVyZSBhcmUgYWxzbyBwYXNzaXZlIG1lYXN1cmVtZW50IG1ldGhvZHMsIHdoaWNo IGNhbg0KPiBtZWFzdXJlIHBhY2tldCBsb3NzIGF0IG1pZC1wb2ludCBieSBkb2luZyBhIGxpdHRs ZSBtb3JlIHRoYW4gcHVyZQ0KPiBvYnNlcnZhdGlvbi4NCj4gRXhhbXBsZXMgaW5jbHVkZSBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lbGtpbnMtaXBwbS1wZG0tbWV0cmljcy0NCj4g MDQgYW5kIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4taXBwbS1jb2xvcmlu Zy1iYXNlZC1pcGZwbS0NCj4gZnJhbWV3b3JrLTAxICh3aGVyZSB0aGUgSVAgaGVhZGVyIGlzIGJl aW5nIG1hcmtlZC9hcHBlbmRlZCBieSBhbiB1cHN0cmVhbQ0KPiBNUCB0byBjb29yZGluYXRlIHdp dGggdGhlIGRvd25zdHJlYW0gTVAgZm9yIG1lYXN1cmVtZW50IG9uIGV4aXN0aW5nDQo+IHRyYWZm aWMgYW5kIG5vIHRyYWZmaWMgaXMgaW5qZWN0ZWQgZm9yIHRoZSBwdXJwb3NlIG9mIG1lYXN1cmVt ZW50DQo+IHRoZXJlZm9yZSBubyBwcmlvciBrbm93bGVkZ2Ugb3RoZXIgdGhhbiB0aGUgYXBwZW5k ZWQvbWFya2RlZCBpbmZvcm1hdGlvbg0KPiBwaWdneWJhY2tlZCB0byB0aGUgdGFyZ2V0ZWQgdHJh ZmZpYyBjYW4gYmUgYXNzdW1lZCBmb3IgYW55IHBhcnRpY2lwYXRpbmcNCj4gTVApLg0KPiA+DQo+ ID4gT25jZSB3ZSBhcmUgc2F0aXNmaWVkIHRoYXQgdGhlIEluZm9ybWF0aW9uIE1vZGVsIGFsbG93 cyB0aGUgbmVlZGVkDQo+IGZsZXhpYmlsaXR5DQo+ID4gZm9yIGNvbnRyb2wsIGl0IHdvdWxkIGJl IGdvb2QgdG8gdGFrZSBhbm90aGVyIHN0ZXA6IFRoZSBJbmZvcm1hdGlvbg0KPiBNb2RlbA0KPiA+ IGRlcGVuZHMgb24gdGhlIFBlcmZvcm1hbmNlIE1ldHJpY3MgUmVnaXN0cnksIHdoaWNoIHdlIGhh dmUgc3BsaXQgaW50bw0KPiA+IGFjdGl2ZSBhbmQgcGFzc2l2ZSBzdWItcmVnaXN0cmllcy4gSWYg dGhlIG9ic2VydmF0aW9ucyB5b3Ugd2FudCB0byBtYWtlDQo+IGF0DQo+ID4gbWlkLXBvaW50ICJD IiBjYW4gYmUgc3VwcG9ydGVkIHdpdGggYSBtZXRyaWMgZnJvbSB0aGUgcGFzc2l2ZSByZWdpc3Ry eSwNCj4gPiB0aGF0J3MgaW5wdXQgdG8gdGhlIG1lYXN1cmVtZW50IGNhdGVnb3JpemF0aW9uLiBJ ZiBub3QsIHRyeSB0aGUgYWN0aXZlDQo+IHJlZ2lzdHJ5Lg0KPiA+IElmIHRoZSBhY3RpdmUgYW5k L29yIHBhc3NpdmUgcmVnaXN0cmllcyBzdXBwb3J0IHNvbWUgaW1wb3J0YW50DQo+IHNjZW5hcmlv cywNCj4gPiB0aGVuIHdlJ3ZlIGNvbWUgYSBsb25nIHdheS4NCj4gW+mCk+eBteiOiS9MaW5nbGkg RGVuZ10gSSB3b3VsZCBsaWtlIGl0IG1vcmUgaWYgdGhlIHdvcmQgIm9ic2VydmF0aW9uIiBpcw0K PiByZXBsYWNlZCBieSAibWVhc3VyZW1lbnQiLg0KPiBJdCBnaXZlcyB0d28gaW1wbGljYXRpb25z IHdoaWNoIEkgdGhpbmsgVmVybyBhbmQgTmFsaW5pIHdhbnRlZCB0byBhdm9pZCBieQ0KPiByYWlz aW5nIHRoZSBkaXNjdXNzaW9uIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4gMSwgSXQgZ2l2ZXMgb25l IHRoZSBpbXByZXNzaW9uIHRoYXQgYSBwYXNzaXZlIG1lYXN1cmVtZW50IHRhc2sgaXMgYWx3YXlz DQo+IHBlcmZvcm1lZCBieSBhbiBpbmRpdmlkdWFsIE1QIGFuZCBkb2VzIG5vdCBuZWVkIGFueSBj b29yZGluYXRpb24gZnJvbQ0KPiBvdXRzaWRlLg0KPiAyLCBBbiBNUCBkb2luZyBwYXNzaXZlIG1l YXN1cmVtZW50IGlzIG5vdCBzdXBwb3NlZCB0byAidG91Y2giIHRoZSB0cmFmZmljLA0KPiBidXQg b25seSAib2JzZXJ2ZXMiIHRoZW0sIGluIHdoaWNoIGNhc2UgcGFja2V0IGxvc3MgY2FuIGhhcmRs eSBiZQ0KPiBtZWFzdXJlZC4NCj4gPg0KPiANCj4gR2l2ZW4gdGhlIGZhY3QgdGhhdCAicGFzc2l2 ZSBtZWFzdXJlbWVudCIgaGFzIGEgbG90IG9mIHBvc3NpYmlsaXRpZXMgbW9yZQ0KPiB0aGFuIHB1 cmUgb2JzZXJ2YXRpb24sIEkgZWNobyBWZXJvIGFuZCBOYWxpbmkgdGhhdCBvbmUgc2hvdWxkIGNl YXNlIHVzaW5nDQo+ICJvYnNlcnZhdGlvbiIgYXMgYW4gc3lub255bSBmb3IgcGFzc2l2ZSBtZWFz dXJlbWVudC4NCj4gDQo+IExpbmdsaQ0KPiANCj4gDQo+IA0KDQo= From nobody Fri May 30 07:21: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 D18A51A0911; Fri, 30 May 2014 07:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 nIoDX--namZR; Fri, 30 May 2014 07:21:33 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8621A08FB; Fri, 30 May 2014 07:21:32 -0700 (PDT) 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 9e398835.2ae632cbd940.5722995.00-2410.15951439.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 30 May 2014 14:21:29 +0000 (UTC) X-MXL-Hash: 538893e958cb10a8-a687124db27a842c7bfd616b4aad922aaa3db8ee 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 5e398835.0.5722954.00-2277.15951282.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 30 May 2014 14:21:26 +0000 (UTC) X-MXL-Hash: 538893e63c78e880-6d755142c5b2f170467ce3db6b3f0fb5bbc6adc5 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 s4UELO5g031010; Fri, 30 May 2014 10:21:25 -0400 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 s4UELIDs030890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2014 10:21:19 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 30 May 2014 14:21:05 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; Fri, 30 May 2014 10:21:05 -0400 From: "STARK, BARBARA H" To: "Romascanu, Dan (Dan)" Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe19g7JlyMC2zj0SiwX4AAU19WZtXynkggABV6gD//99KoIABAGmAgAALQRCAACJcIA== Date: Fri, 30 May 2014 14:21:05 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113043DF99@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113043DB82@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C7F4DB3@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.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=Kpj6LxqN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=in1mFPvdBZUA:10 a=ofMgfj31e3cA:10 a=uXQnFqASuNsA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=P5pQeOyxOs79eoNs9xAA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ZQLT9Oc0UWhJ_Kr8kxq0GDjJ8Ow Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 30 May 2014 14:21:39 -0000 [resending with fewer To recipients.] > > Doesn't become too complicated? What is the difference between the > > Measurement Method Role and Measurement Task and why do we need > the > > two distinct terms? Maybe it would help if you can provide a > > definition of Measurement Method Role because I frankly cannot compile > > ' Measurement Task is an instantiation of a Measurement Method Role', > > in other words why do we need a generic term and an instantiation? >=20 > The information model says: > The Measurement Task Configuration will include ... a registry > entry [I-D....-ippm-...] that defines the Measurement > Task. The MA itself will resolve the registry entry to a local > executable program. In addition the Measurement Task is specialised > through a set of configuration Options. The nature and number of > these Options will depend upon the Measurement Task and will be > defined in the Measurement Task Registry. >=20 > So the information-model makes the Measurement Task an instantiation of a > local executable program. But how does the Controller learn about what > registry entries the MA is capable of resolving to local executable progr= ams? > That is, how does the Controller know what local executable programs exis= t > on the MA? I had thought this would be part of the capabilities that get > reported to the Controller by the MA. Bu the ma-capability object has som= e > distinct other undefined measurement-id urn and doesn't provide the > Controller with any list of registry entries that the MA is capable of re= solving. > Hopefully, this is just something that needs to be fixed in the informati= on- > model, and not an intentional lack of relationship between ma-capability = and > ma-task (or ma-task-registry). >=20 > Anyway, information-model says (wrt capability reporting) that "Capabilit= ies > include ... the set of Measurement Tasks that are actually installed or > available on the MA." This, to me, is a problematic statement. Now, not o= nly > is the term Measurement Task being used to describe an instantiation of a > local executable program with a specific set of values for input paramete= rs > (ma-task-options<0..*>) and perhaps a particular cycle id (ma-task-cycle-= id) > with a pointer to the local executable program (ma-task-registry), the te= rm is > also being used as synonymous with the local executable program. >=20 > I do not think that "Measurement Task" should be used as another name for > the local executable program. I would like to see this fixed. It would al= so > appear that the ma-capability object is supposed to be the object that > provides the information regarding these local executable programs that a= re > installed/available on the MA. But the word "capabilities" is also said t= o > include interface details. So "local executable programs" is a subset of > "capabilities" (which means "capabilities" is also not an appropriate wor= d to > use to just mean "local executable programs"). >=20 > So do these "local executable programs" need a better name, so we aren't > tempted to call them "Measurement Task"? Or maybe we can just call them > "Local Executable Programs" and define them as functionality in a MA that > allows the MA to perform a specific role of a Measurement Method. And > Measurement Task is an instantiation of a Local Executable Program. Becau= se > Measurement Task is definitely not an instantiation of the holistic > Measurement Method. The ping initiator Local Executable Program can be > completely distinct from the ping responder Local Executable Program. And= it > often is. > Barbara From nobody Fri May 30 08:03: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 41C0D1A0901; Fri, 30 May 2014 07:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 1bqoG7bGID_3; Fri, 30 May 2014 07:16:47 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DA861A08F6; Fri, 30 May 2014 07:16:47 -0700 (PDT) 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 bc298835.2ae60166e940.5719177.00-2458.15941211.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 30 May 2014 14:16:43 +0000 (UTC) X-MXL-Hash: 538892cb156d0eb2-5ee07d1a32e67ac7ee6e9c451d9c28adfa271669 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 76298835.0.5717972.00-1988.15937742.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 30 May 2014 14:15:04 +0000 (UTC) X-MXL-Hash: 53889268386a533f-11bcf55205bd2fe56d334e6b08fdff87557ace41 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 s4UEF2Ss024083; Fri, 30 May 2014 10:15:02 -0400 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 s4UEEw2u024060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2014 10:14:59 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 30 May 2014 14:14:40 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; Fri, 30 May 2014 10:14:39 -0400 From: "STARK, BARBARA H" To: "Romascanu, Dan (Dan)" , KEN KO , "marc.ibrahim" , Nalini Elkins , Juergen Schoenwaelder , Vero Zheng , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe19g7JlyMC2zj0SiwX4AAU19WZtXynkggABV6gD//99KoIABAGmAgAALQRA= Date: Fri, 30 May 2014 14:14:38 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113043DF53@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113043DB82@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C7F4DB3@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C7F4DB3@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.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=Kpj6LxqN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=in1mFPvdBZUA:10 a=ofMgfj31e3cA:10 a=uXQnFqASuNsA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=XwYO4xUe1mojkYmAmnEA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/I5kOfNvBFSTGNY3hga_AO-2o4kE X-Mailman-Approved-At: Fri, 30 May 2014 08:03:14 -0700 Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 30 May 2014 14:16:49 -0000 > Doesn't become too complicated? What is the difference between the > Measurement Method Role and Measurement Task and why do we need > the two distinct terms? Maybe it would help if you can provide a definiti= on of > Measurement Method Role because I frankly cannot compile ' Measurement > Task is an instantiation of a Measurement Method Role', in other words wh= y > do we need a generic term and an instantiation? The information model says: The Measurement Task Configuration will include ... a registry entry [I-D....-ippm-...] that defines the Measurement Task. The MA itself will resolve the registry entry to a local executable program. In addition the Measurement Task is specialised through a set of configuration Options. The nature and number of these Options will depend upon the Measurement Task and will be defined in the Measurement Task Registry. So the information-model makes the Measurement Task an instantiation of a l= ocal executable program. But how does the Controller learn about what regis= try entries the MA is capable of resolving to local executable programs? Th= at is, how does the Controller know what local executable programs exist on= the MA? I had thought this would be part of the capabilities that get repo= rted to the Controller by the MA. Bu the ma-capability object has some dist= inct other undefined measurement-id urn and doesn't provide the Controller = with any list of registry entries that the MA is capable of resolving. Hope= fully, this is just something that needs to be fixed in the information-mod= el, and not an intentional lack of relationship between ma-capability and m= a-task (or ma-task-registry).=20 Anyway, information-model says (wrt capability reporting) that "Capabilitie= s include ... the set of Measurement Tasks that are actually installed or a= vailable on the MA." This, to me, is a problematic statement. Now, not only= is the term Measurement Task being used to describe an instantiation of a = local executable program with a specific set of values for input parameters= (ma-task-options<0..*>) and perhaps a particular cycle id (ma-task-cycle-i= d) with a pointer to the local executable program (ma-task-registry), the t= erm is also being used as synonymous with the local executable program.=20 I do not think that "Measurement Task" should be used as another name for t= he local executable program. I would like to see this fixed. It would also = appear that the ma-capability object is supposed to be the object that prov= ides the information regarding these local executable programs that are ins= talled/available on the MA. But the word "capabilities" is also said to inc= lude interface details. So "local executable programs" is a subset of "capa= bilities" (which means "capabilities" is also not an appropriate word to us= e to just mean "local executable programs").=20 So do these "local executable programs" need a better name, so we aren't te= mpted to call them "Measurement Task"? Or maybe we can just call them "Loca= l Executable Programs" and define them as functionality in a MA that allows= the MA to perform a specific role of a Measurement Method. And Measurement= Task is an instantiation of a Local Executable Program. Because Measuremen= t Task is definitely not an instantiation of the holistic Measurement Metho= d. The ping initiator Local Executable Program can be completely distinct f= rom the ping responder Local Executable Program. And it often is. Barbara From nobody Fri May 30 08:54: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 720C71A096E; Fri, 30 May 2014 08:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 qWHtoP1ef5Du; Fri, 30 May 2014 08:42:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163CB1A0A23; Fri, 30 May 2014 08:42:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D4A86FBE; Fri, 30 May 2014 17:42:21 +0200 (CEST) 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 Tib39vxPWwlg; Fri, 30 May 2014 17:42:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 30 May 2014 17:42:20 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0440420017; Fri, 30 May 2014 17:42:22 +0200 (CEST) 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 2tg9ibGK4ffa; Fri, 30 May 2014 17:42:20 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas03.jacobs.jacobs-university.de [10.70.0.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (not verified)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 2457320013; Fri, 30 May 2014 17:42:19 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS05.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0181.006; Fri, 30 May 2014 17:42:18 +0200 From: "Bajpai, Vaibhav" To: "STARK, BARBARA H" Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe4SyEJR6w5z5NkWIeISBck/YzZtYmzaAgABvNACAABh9gA== Date: Fri, 30 May 2014 15:42:18 +0000 Message-ID: <83C976BD-9ADB-45D8-BAF4-7C4B01856C97@jacobs-university.de> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113043DB82@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C7F4DB3@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E6113043DF53@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043DF53@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: multipart/signed; boundary="Apple-Mail=_EA1A364C-784D-48E0-8D5E-15095C6B22D5"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/gXGCkM720kgbkt2Q_wl4YePXlTI X-Mailman-Approved-At: Fri, 30 May 2014 08:53:54 -0700 Cc: "marc.ibrahim" , Nalini Elkins , Trevor Burbridge , "lmap@ietf.org" , =?Windows-1252?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= , "ippm@ietf.org" , "Bajpai, Vaibhav" , Dan Romascanu , KEN KO , Vero Zheng , Philip Eardley Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 30 May 2014 15:42:34 -0000 --Apple-Mail=_EA1A364C-784D-48E0-8D5E-15095C6B22D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 30 May 2014, at 16:14, STARK, BARBARA H wrote: >> Doesn't become too complicated? What is the difference between the >> Measurement Method Role and Measurement Task and why do we need >> the two distinct terms? Maybe it would help if you can provide a = definition of >> Measurement Method Role because I frankly cannot compile ' = Measurement >> Task is an instantiation of a Measurement Method Role', in other = words why >> do we need a generic term and an instantiation? >=20 > The information model says: > The Measurement Task Configuration will include ... a registry > entry [I-D....-ippm-...] that defines the Measurement > Task. The MA itself will resolve the registry entry to a local > executable program. In addition the Measurement Task is specialised > through a set of configuration Options. The nature and number of > these Options will depend upon the Measurement Task and will be > defined in the Measurement Task Registry. The framework document [1] makes the measurement method refer to the = IPPM metrics registries. The information model (IM) [2] on the other hand, makes the measurement = task refer to the=20 IPPM metrics registries. If we really want to use both Measurement = Method and Measurement Task=20 terminologies, perhaps we need to update the IM to adhere better to the = framework document: object { string ma-method-name; urn ma-method-registry; ma-task-obj ma-task-obj<0..*>; } ma-method-obj;=20 object { string ma-task-name; string ma-task-options<0..*>; [string ma-task-cycle-id;] } ma-task-obj;=20 > So the information-model makes the Measurement Task an instantiation = of a local executable program. But how does the Controller learn about = what registry entries the MA is capable of resolving to local executable = programs? That is, how does the Controller know what local executable = programs exist on the MA? I had thought this would be part of the = capabilities that get reported to the Controller by the MA. Bu the = ma-capability object has some distinct other undefined measurement-id = urn and doesn't provide the Controller with any list of registry entries = that the MA is capable of resolving. Hopefully, this is just something = that needs to be fixed in the information-model, and not an intentional = lack of relationship between ma-capability and ma-task (or = ma-task-registry).=20 I also think so: object { urn ma-measurement-id; [string ma-measurement-version;] ma-task-obj ma-task-obj<0..*>; } ma-capability-obj; The ma-tasks<0...*> objects sent in the instruction object will now be = subset of the the ma-tasks<0=85*> objects sent by the MA. > Anyway, information-model says (wrt capability reporting) that = "Capabilities include ... the set of Measurement Tasks that are actually = installed or available on the MA." This, to me, is a problematic = statement. Now, not only is the term Measurement Task being used to = describe an instantiation of a local executable program with a specific = set of values for input parameters (ma-task-options<0..*>) and perhaps a = particular cycle id (ma-task-cycle-id) with a pointer to the local = executable program (ma-task-registry), the term is also being used as = synonymous with the local executable program.=20 >=20 > I do not think that "Measurement Task" should be used as another name = for the local executable program. I would like to see this fixed. It = would also appear that the ma-capability object is supposed to be the = object that provides the information regarding these local executable = programs that are installed/available on the MA. But the word = "capabilities" is also said to include interface details. So "local = executable programs" is a subset of "capabilities" (which means = "capabilities" is also not an appropriate word to use to just mean = "local executable programs").=20 >=20 > So do these "local executable programs" need a better name, so we = aren't tempted to call them "Measurement Task"? Or maybe we can just = call them "Local Executable Programs=94 A locally executable program can be any program (for e.g. ls) within the = MA, no?=20 Shouldn=92t we restrict the terminology to programs that do = measurements? > and define them as functionality in a MA that allows the MA to perform = a specific role of a Measurement Method. And Measurement Task is an = instantiation of a Local Executable Program. Because Measurement Task is = definitely not an instantiation of the holistic Measurement Method. The = ping initiator Local Executable Program can be completely distinct from = the ping responder Local Executable Program. And it often is. > Barbara [1] http://tools.ietf.org/html/draft-ietf-lmap-framework-05 [2] http://tools.ietf.org/html/draft-ietf-lmap-information-model-00 Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com --Apple-Mail=_EA1A364C-784D-48E0-8D5E-15095C6B22D5 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 iQEcBAEBCgAGBQJTiKbZAAoJEHR3XKwTWKOZOcMIAJYFVPUNvVfxBwU8gllyl0Ru z6VHTOjD1XHDCN3f62r68JeyU9HqG9VK+ETpm2SivP+UQLj6mQ5Oo1588rAV857h itLZxicv1mN15QfkfFep+k5r+FNlvv5WxaAOA3LLWVjOAtzC9vhinGsqMgGL+0r/ 8T2XC5+1pZX0gac9qpKFi5yg1pUQ84irP/U2EKDva9b2HaOqs0DLkDuRRWR/MONW agzzG6ArorxMAxXE02k8VFC2Gh124w9CPTaHa4+1Yac4Ckt0BpGxlQTGdLf8LKLY g944MmHC1YDOykuKeulmAfILKUAbbSGI21I0Rh9FMSWM1awLIbTpr+SvP3qalNY= =XqN/ -----END PGP SIGNATURE----- --Apple-Mail=_EA1A364C-784D-48E0-8D5E-15095C6B22D5-- From nobody Fri May 30 09:17: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 468271A08F1 for ; Fri, 30 May 2014 09:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 hRJdnDveayND for ; Fri, 30 May 2014 09:17:19 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 353F81A0441 for ; Fri, 30 May 2014 09:17:19 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id 457BB554C0A; Fri, 30 May 2014 12:19:35 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id F03EFF03C5; Fri, 30 May 2014 12:17:14 -0400 (EDT) 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, 30 May 2014 12:17:14 -0400 From: "MORTON, ALFRED C (AL)" To: "Bajpai, Vaibhav" , "STARK, BARBARA H" Date: Fri, 30 May 2014 12:17:13 -0400 Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt Thread-Index: AQHPe4SyEJR6w5z5NkWIeISBck/YzZtYmzaAgABvNACAABh9gIAAKGzQ Message-ID: <2845723087023D4CB5114223779FA9C8017992C984@njfpsrvexg8.research.att.com> References: <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113043DB82@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C7F4DB3@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E6113043DF53@GAALPA1MSGUSR9L.ITServices.sbc.com> <83C976BD-9ADB-45D8-BAF4-7C4B01856C97@jacobs-university.de> In-Reply-To: <83C976BD-9ADB-45D8-BAF4-7C4B01856C97@jacobs-university.de> 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/cmvvKd2LI95KWl0Bz-lF3b2W_lQ Cc: "lmap@ietf.org" Subject: Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.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, 30 May 2014 16:17:20 -0000 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bajpai, Vaibhav > Sent: Friday, May 30, 2014 11:42 AM >=20 ... >=20 > The framework document [1] makes the measurement method refer to the IPPM > metrics registries. > The information model (IM) [2] on the other hand, makes the measurement > task refer to the > IPPM metrics registries. If we really want to use both Measurement Method > and Measurement Task > terminologies, perhaps we need to update the IM to adhere better to the > framework document: >=20 > object { > string ma-method-name; > urn ma-method-registry; > ma-task-obj ma-task-obj<0..*>; > } ma-method-obj; >=20 > object { > string ma-task-name; > string ma-task-options<0..*>; > [string ma-task-cycle-id;] > } ma-task-obj; >=20 The new IPPM registry entries are called "Registered Performance Metrics", or "Registered Metrics" for simplicity, and entries contain references to metric definitions, references to methods of measurement, and lots of information not found in references such=20 as input parameter settings. Also, we have confirmation that IANA will support a full URI =3D URL + URN for each entry. If we true-up names, let's try to accommodate the registry aspect, too. regards, Al From nobody Fri May 30 10:20: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 1E64B1A6F8C; Fri, 30 May 2014 10:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 CE1q-HID8NkM; Fri, 30 May 2014 10:20:33 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E5F1A6F9A; Fri, 30 May 2014 10:20:29 -0700 (PDT) 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 9ddb8835.0.5707047.00-2319.14684546.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 30 May 2014 17:20:26 +0000 (UTC) X-MXL-Hash: 5388bdda5c0def40-edf7e99b639007c3faf4dbdee8dd80a9feda01ff 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 s4UHKOfK009695; Fri, 30 May 2014 13:20:25 -0400 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 s4UHKIZl009617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2014 13:20:19 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 30 May 2014 17:20:07 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; Fri, 30 May 2014 13:20:06 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" , "ippm@ietf.org" Thread-Topic: UDP Echo example Thread-Index: Ac98K1bDE55jP69ZSSGwaSKZ6wgxvA== Date: Fri, 30 May 2014 17:20:05 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113043E070@GAALPA1MSGUSR9L.ITServices.sbc.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=HL104PRv 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=mYPrF8hoA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=dxjE0AsNVqagKUDOkjQA:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=CJI8S6gGpEqlBxrD:21 a=qzoPiFl0iRYSxltN:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/J2K8iG4F3M-eftZe2qEa_XVlD_8 Subject: [lmap] UDP Echo example 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, 30 May 2014 17:20:39 -0000 Getting away from ping, I'd like to use UDP Echo "Measurement Method" as an= example to perhaps back into what would be needed in an LMAP information m= odel and an IPPM registry to make UDP Echo usable in an LMAP context. I'm u= sing it because there exists a data model related to the UDP Echo server fu= nction, and this modeled UDP Echo server is interesting in that it does *no= t* initiate the test, has input parameters, and reports collected informati= on. UDP Echo is defined (barely) in [RFC 862]. A UDP Echo server listens for UD= P datagrams. When a datagram is received, the data from it is sent back in= an answering datagram. That's pretty much all that the RFC says. BBF [TR-143] describes implementing a UDP Echo server in a piece of CPE and= how to configure this via TR-069. It does not describe the UDP Echo client= , other than to say that such a thing exists in an element in the ISP netwo= rk and it sends the UDP packets (that the server is expected to listen for)= . For mapping to LMAP/IPPM, let's call the CPE with the UDP Echo server funct= ion MA1, and the element sending UDP packets is MA2. UDP Echo is a Measurem= ent Method. The UDP Echo server functionality on MA1 is a locally executabl= e program. If we look at the TR-069 data model in [TR-143], we see that MA1's UDP Echo= server functionality has input parameters of (1) a port to listen on and (= 2) a source IP address (MA1 will only respond to UDP packets from this sour= ce IP address). In an LMAP world, I think these would be the information-mo= del ma-task-options<0..*>. There is also an input of the network interface = to listen on. [I see that while information-model lets the MA tell the Cont= roller what its interfaces are, there's no current linkage to allow an inte= rface to be specified for a ma-task-obj. I think this is probably just an o= versight and needs to be added.] The functionality can be enabled. I think = in information-model this would be represented by using a schedule to indic= ate when this function is supposed to be up and running. [TR-143] also desc= ribes some collected measurements (packets and bytes received, packets and = bytes sent) that I would expect to be sent out in a report (ma-sched-report= -obj). [TR-143] doesn't describe the nebulous UDP Echo client configuration, but I= think that some input parameters associated with such a configuration migh= t be UDP packet size, destination IP address, time interval between UDP pac= kets, and number of UDP packets. It could be scheduled to run. It could rep= ort on average/max elapsed time between a sent UDP packet and the response,= jitter, etc. The main take-away from this is that the inputs and outputs a= re different than those of the UDP Echo server. Currently, there is no expe= ctation for CPE that support UDP Echo server to also support the client, or= for the network elements with the client to support the server, although t= here is nothing that precludes both of these from being supported on a sing= le device. These are very distinct locally executable program capabilities. Now I need to back into the registry (ma-task-registry). The registry entry= is supposed to let the MA identify which locally executable program to run= (the UDP Echo server). The Controller is also supposed to know, via the re= gistry entry, what the allowed set of input parameters are. So there is no = ambiguity, the registry therefore has to list a distinct set of inputs and = outputs for UDPEcho.server and for UDPEcho.client, with a different urn for= each of these roles. The Controller has to know which endpoint is performi= ng which role, and how to appropriately configure that particular role.=20 A registry entry that attempts to describe Measurement Method inputs and ou= tputs as components of the holistic Measurement Method and not as component= s of specific roles is not very useful, except in cases where all MAs takin= g part in a Measurement Method are expected to have identical functionality= and behavior, or where there is only a single MA involved. Barbara [TR-143] http://www.broadband-forum.org/technical/download/TR-143_Corrigend= um-1.pdf [RFC 862] http://www.ietf.org/rfc/rfc862.txt=20 From nobody Fri May 30 15: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 9DF4A1A0429; Fri, 30 May 2014 15:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 OuLd9BVPFSj7; Fri, 30 May 2014 15:56:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4916B1A094C; Fri, 30 May 2014 15:56:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2B8C5FDE; Sat, 31 May 2014 00:56:22 +0200 (CEST) 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 ernTb4dIcQLM; Sat, 31 May 2014 00:56:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 31 May 2014 00:56:21 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF8302002C; Sat, 31 May 2014 00:56:22 +0200 (CEST) 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 zVwBf-acVh0R; Sat, 31 May 2014 00:56:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26A6B20017; Sat, 31 May 2014 00:56:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4AD952D13842; Sat, 31 May 2014 00:56:21 +0200 (CEST) Date: Sat, 31 May 2014 00:56:20 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140530225620.GA86358@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "lmap@ietf.org" , "ippm@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E6113043E070@GAALPA1MSGUSR9L.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113043E070@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/loy7UmCyfcNm5HCtyZ0kq0W7Apc Cc: "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] UDP Echo example 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, 30 May 2014 22:56:31 -0000 On Fri, May 30, 2014 at 05:20:05PM +0000, STARK, BARBARA H wrote: > > If we look at the TR-069 data model in [TR-143], we see that MA1's UDP Echo server functionality has input parameters of (1) a port to listen on and (2) a source IP address (MA1 will only respond to UDP packets from this source IP address). In an LMAP world, I think these would be the information-model ma-task-options<0..*>. There is also an input of the network interface to listen on. [I see that while information-model lets the MA tell the Controller what its interfaces are, there's no current linkage to allow an interface to be specified for a ma-task-obj. I think this is probably just an oversight and needs to be added.] The interface is just another task option. /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 Sat May 31 12:10: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 377AF1A007D; Sat, 31 May 2014 12:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 uBdwzvpFWidN; Sat, 31 May 2014 12:10:28 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFD51A0063; Sat, 31 May 2014 12:10:28 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4VJAL68027806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 31 May 2014 14:10:21 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s4VJAKel021424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 31 May 2014 15:10:21 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.107]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Sat, 31 May 2014 15:10:20 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder , "STARK, BARBARA H" Thread-Topic: [lmap] UDP Echo example Thread-Index: AQHPfQKkc2v75TjvIE66yFOkP96V4JtbDKCw Date: Sat, 31 May 2014 19:10:19 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734EBC8BF@US70UWXCHMBA02.zam.alcatel-lucent.com> References: <2D09D61DDFA73D4C884805CC7865E6113043E070@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140530225620.GA86358@elstar.local> In-Reply-To: <20140530225620.GA86358@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] 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/xbL473bF4dvX_GnJakR-kX8lhBI Cc: "lmap@ietf.org" , "ippm@ietf.org" Subject: Re: [lmap] UDP Echo example 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: Sat, 31 May 2014 19:10:35 -0000 Juergen, Wouldn't the selected interface for the UDP test instance be part of the op= tions for the task. The options have the "parameters" for the test which is= specific for each test, right? As for a MA telling the controller its capabilities - wouldn't it be part o= f the ma-interface-obj? BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, May 30, 2014 5:56 PM To: STARK, BARBARA H Cc: ippm@ietf.org; lmap@ietf.org Subject: Re: [lmap] UDP Echo example On Fri, May 30, 2014 at 05:20:05PM +0000, STARK, BARBARA H wrote: >=20 > If we look at the TR-069 data model in [TR-143], we see that MA1's UDP Ec= ho server functionality has input parameters of (1) a port to listen on and= (2) a source IP address (MA1 will only respond to UDP packets from this so= urce IP address). In an LMAP world, I think these would be the information-= model ma-task-options<0..*>. There is also an input of the network interfac= e to listen on. [I see that while information-model lets the MA tell the Co= ntroller what its interfaces are, there's no current linkage to allow an in= terface to be specified for a ma-task-obj. I think this is probably just an= oversight and needs to be added.]=20 The interface is just another task option. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103