From nobody Tue Apr 1 02:17: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 7B5A21A702D for ; Tue, 1 Apr 2014 02:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, T_RP_MATCHES_RCVD=-0.01] 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 bK5B3c-nTnMT for ; Tue, 1 Apr 2014 02:17:47 -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 9F16B1A702B for ; Tue, 1 Apr 2014 02:17:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYFANSDOlPGmAcV/2dsb2JhbABZgmUhO1EGgwq4VRuHNRmBAhZ0giUBAQEBAQIBAQEPERE6CQ4EAgEIDQQBAwEBAwIGHQMCAgIlCxQBAgUBCAEBBAESCAEZh1cBBwWkJIpGolwXgSmMcyM4BoJpNYEUBJoJhUSLQoMwgis X-IronPort-AV: E=Sophos;i="4.97,771,1389762000"; d="scan'208";a="56114842" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 01 Apr 2014 05:17:12 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 01 Apr 2014 05:03:01 -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; Tue, 1 Apr 2014 05:17:10 -0400 From: "Romascanu, Dan (Dan)" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: Ac9M96SrT9ch1Dy9RLWkPnyMnGdYkAAABTHgACTOrWA= Date: Tue, 1 Apr 2014 09:17:09 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E46D197@AZ-FFEXMB04.global.avaya.com> References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/SmGk0zlH-ULnEMhft7mFkfVaOeQ 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, 01 Apr 2014 09:17:49 -0000 VGhhbmtzIHRvIFBoaWwgJiBmcmllbmRzLiANCg0KSSB3aWxsIGlzc3VlIGEgc2Vjb25kIExhc3Qg Q2FsbCB0byBtYWtlIHN1cmUgdGhhdCBldmVyeWJvZHkgaXMgaGFwcHkgd2l0aCB0aGlzIG5ldyB2 ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBiZWZvcmUgd2Ugc2VuZCBpdCB0byB0aGUgSUVTRy4gDQoN ClJlZ2FyZHMsDQoNCkRhbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogbG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IHBo aWxpcC5lYXJkbGV5QGJ0LmNvbQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDMxLCAyMDE0IDY6NDUg UE0NCj4gVG86IGxtYXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2xtYXBdIEZXOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstDQo+IDA0LnR4dA0K PiANCj4gV2UndmUgY3JlYXRlZCBhIG5ldyB2ZXJzaW9uIC0wNCBvZiB0aGUgZnJhbWV3b3JrIGRv Yy4gVGhpcyByZXNvbHZlcyAod2UNCj4gYmVsaWV2ZSkgYWxsIHRoZSBXRyBsYXN0IGNhbGwgaXNz dWVzIGFjY29yZGluZyB0byB0aGUgY29uc2Vuc3VzIGFncmVlZCBpbg0KPiBMb25kb24uDQo+IFRo YW5rcw0KPiBQaGlsICYgZnJpZW5kcw0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWxtYXAtZnJhbWV3b3JrDQo+IA0KPiAtLQ0KPiBGcm9tOiBsbWFwIFttYWlsdG86bG1h cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gcGhpbGlwLmVhcmRsZXlAYnQuY29t DQo+IFNlbnQ6IDEzIE1hcmNoIDIwMTQgMTU6MjkNCj4gVG86IGxtYXBAaWV0Zi5vcmcNCj4gU3Vi amVjdDogW2xtYXBdIFByb2dyZXNzIG9uIEZyYW1ld29yaw0KPiANCj4gSeKAmW0gdHJ5aW5nIHRv IHJlc29sdmUgdGhlIGlzc3VlcyByYWlzZWQgaW4gV0cgTGFzdCBjYWxsIGFib3V0IHRoZSBmcmFt ZXdvcmsNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sbWFwLWZyYW1l d29yay0wMw0KPiANCj4gMS4JRXNwZWNpYWxseSBpZiB5b3Ugd2VyZW7igJl0IGluIExvbmRvbiwg cGxlYXNlIGNhbiB5b3UgY2hlY2sgdGhlIHNsaWRlcyB0bw0KPiBtYWtlIHN1cmUgeW914oCZcmUg aGFwcHkgd2l0aCB0aGUgcHJvcG9zZWQgY29uc2Vuc3VzIG9uIHRoZSB2YXJpb3VzIGlzc3Vlcy4N Cj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2FnZW5kYS84OS9zbGlkZXMvc2xpZGVzLTg5LWxtYXAt Mi5wZGYgICAgKGlnbm9yZSBzbGlkZXMgNSwNCj4gNiwgNyDigJMgc2VlIGxpbmsgYmVsb3cgaW5z dGVhZCkNCj4gMi4JSSBwcmVwYXJlZCBzb21lIHNsaWRlcyBhYm91dCB0aGUgTUEgdnMgTVAgdGVy bWlub2xvZ3kgaW4gYWN0aW9uLiBEbw0KPiB0aGVzZSBleGFtcGxlcyBoZWxwIGNsYXJpZnkgdGhp bmdzPyBUaGV5IGNvdWxkIGJlIHR1cm5lZCBpbnRvIHNvbWUgdGV4dCBmb3INCj4gdGhlIG5leHQg dmVyc2lvbiBvZiB0aGUgZnJhbWV3b3JrICBodHRwOi8vd3d3Lmxlb25lLQ0KPiBwcm9qZWN0LmV1 L2RydXBhbC9zaXRlcy9kZWZhdWx0L2ZpbGVzL3B1YmxpY19kb3dubG9hZHMvbG1hcC1mcmFtZXdv cmstDQo+IGV4YW1wbGVzLTEzbWFyY2gyMDE0LnBkZg0KPiANCj4gSSBwbGFuIHRvIHdvcmsgb24g dGhlIGZyYW1ld29yayBpLWQgbmV4dCB3ZWVrLCBzbyBwbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91 DQo+IGhhdmUgYW55IGNvbW1lbnRzLg0KPiANCj4gQmFja2dyb3VuZDogQSBncm91cCBvZiB1cyBt ZXQgZm9yIGEgc2lkZSBtZWV0aW5nIGluIExvbmRvbiBhbmQgKHdlIHRoaW5rKQ0KPiByZWFjaGVk IGNvbnNlbnN1cyBvbiBhbGwgdGhlIG9wZW4gaXNzdWVzLiBJIHByZXNlbnRlZCB0aGUgcHJvcG9z YWxzIGR1cmluZw0KPiB0aGUgV0cgbWVldGluZyBpbiBMb25kb24uIFdlIGhhZCBzb21lIGdvb2Qg ZGlzY3Vzc2lvbiwgZXNwZWNpYWxseSBhYm91dA0KPiB0aGUgdGVybWlub2xvZ3kgZm9yIE1lYXN1 cmVtZW50IFBlZXIsIHdoaWNoIGxlZCB0byBjb25zZW5zdXMgcm91bmQgYQ0KPiBzbGlnaHRseSBy ZXZpc2VkIHdvcmRpbmcsIGFuZCB0aGUgc3VnZ2VzdGlvbiB0aGF0IHRoZSBpLWQgc2hvdWxkIGlu Y2x1ZGUgc29tZQ0KPiBleHBsYW5hdG9yeSBleGFtcGxlcywgdG8gaWxsdXN0cmF0ZSB0aGUgTUEg dnMgTVAgdGVybWlub2xvZ3kgaW4gYWN0aW9uLg0KPiANCj4gVGhhbmtzIQ0KPiBCZXN0IHdpc2hl cw0KPiBwaGlsDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ IFNlbnQ6IDMxIE1hcmNoIDIwMTQgMTY6NDENCj4gVG86IEFhbWVyIEFraHRlcjsgQWwgQy4gTW9y dG9uOyBBbCBNb3J0b247IEVhcmRsZXksUEwsUGhpbGlwLFRVQjggUjsgUGF1bA0KPiBBaXRrZW47 IFBhdWwgQWl0a2VuOyBNYXJjZWxvIEJhZ251bG87IEVhcmRsZXksUEwsUGhpbGlwLFRVQjggUjsg TWFyY2Vsbw0KPiBCYWdudWxvOyBCdXJicmlkZ2UsVCxUcmV2b3IsVFVCOCBSOyBBYW1lciBBa2h0 ZXI7IEJ1cmJyaWRnZSxULFRyZXZvcixUVUI4DQo+IFINCj4gU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA0LnR4dA0KPiANCj4g DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA0LnR4 dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBoaWxpcCBFYXJkbGV5IGFu ZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1p ZXRmLWxtYXAtZnJhbWV3b3JrDQo+IFJldmlzaW9uOgkwNA0KPiBUaXRsZToJCUEgZnJhbWV3b3Jr IGZvciBsYXJnZS1zY2FsZSBtZWFzdXJlbWVudCBwbGF0Zm9ybXMgKExNQVApDQo+IERvY3VtZW50 IGRhdGU6CTIwMTQtMDMtMzENCj4gR3JvdXA6CQlsbWFwDQo+IFBhZ2VzOgkJNTINCj4gVVJMOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt bG1hcC1mcmFtZXdvcmstDQo+IDA0LnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay8NCj4gSHRtbGl6 ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbG1hcC1mcmFt ZXdvcmstMDQNCj4gRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDQNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBN ZWFzdXJpbmcgYnJvYWRiYW5kIHNlcnZpY2Ugb24gYSBsYXJnZSBzY2FsZSByZXF1aXJlcyBhIGRl c2NyaXB0aW9uDQo+ICAgIG9mIHRoZSBsb2dpY2FsIGFyY2hpdGVjdHVyZSBhbmQgc3RhbmRhcmRp c2F0aW9uIG9mIHRoZSBrZXkgcHJvdG9jb2xzDQo+ICAgIHRoYXQgY29vcmRpbmF0ZSBpbnRlcmFj dGlvbnMgYmV0d2VlbiB0aGUgY29tcG9uZW50cy4gIFRoZSBkb2N1bWVudA0KPiAgICBwcmVzZW50 cyBhbiBvdmVyYWxsIGZyYW1ld29yayBmb3IgbGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnRzLiAgSXQg YWxzbw0KPiAgICBkZWZpbmVzIHRlcm1pbm9sb2d5IGZvciBMTUFQIChsYXJnZS1zY2FsZSBtZWFz dXJlbWVudCBwbGF0Zm9ybXMpLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGxtYXAgbWFpbGlu ZyBsaXN0DQo+IGxtYXBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sbWFwDQo= From nobody Tue Apr 1 06: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 BBC0E1A0748 for ; Tue, 1 Apr 2014 06:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 52LAZ16XRP3d for ; Tue, 1 Apr 2014 06:29:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 42BAD1A071E for ; Tue, 1 Apr 2014 06:29:00 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8A050FD9; Tue, 1 Apr 2014 15:28:56 +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 WnYi_PRScF6U; Tue, 1 Apr 2014 15:28:55 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 1 Apr 2014 15:28:55 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDEC12002F; Tue, 1 Apr 2014 15:28:55 +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 iTiMHiUt3_Zw; Tue, 1 Apr 2014 15:28:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71D4E2002C; Tue, 1 Apr 2014 15:28:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B11E42C1ECEA; Tue, 1 Apr 2014 15:28:52 +0200 (CEST) Date: Tue, 1 Apr 2014 15:28:52 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20140401132852.GA74000@elstar.local> Mail-Followup-To: philip.eardley@bt.com, lmap@ietf.org References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_yX84RHqtkXWx0iGDYXeda394wI Cc: 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: Tue, 01 Apr 2014 13:29:04 -0000 On Mon, Mar 31, 2014 at 04:45:03PM +0100, philip.eardley@bt.com wrote: > We've created a new version -04 of the framework doc. This resolves (we believe) all the WG last call issues according to the consensus agreed in London. Thanks. I have gone through the changes and below are some comments. Overall I like the many improvements very much. a) s/(the MA observes user traffic)/(the MA observes traffic)/ I do not think it needs to be 'user traffic' nor do we have a definition of the term 'user traffic'. b) The suppression text says: Suppression: the temporary cessation of Active Measurement Tasks. Should we not remove 'Active' from this definition? Why would it be illegal to suppress a passive measurement task? Is it not simpler to remove this restriction so that we do not have classify all measurement tasks? (I can imagine a passive measurement task that generates tons of reports and by suppressing the task, I may as a consequence suppress the reports.) c) It is somewhat unclear to me why the framework likes to decide how capabilities, failure information and logging information is transferred. For example, why does it mandate that logging information is only sent when requested by the controller? (I could very well see a solution where logging information transfer is controlled by a schedule as well). Unless there is a very clear and strong reason, I think we should leave these details to the protocol work and not regulate them in the framework. d) In section 10, s/just another customer/just another client/ e) I find this text somewhat irritating: Another case that is slightly different than this would be the one of a ping responder. This is also an MP, with a helper function, the ping server, which is specially deployed to assist the MAs that perform pings. At least for conventional ICMP-based pings, the 'ping server' is the MP's IP implementation and as such it is not "specially deployed to assist the MAs". /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 Apr 1 06:55: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 351DB1A070F for ; Tue, 1 Apr 2014 06:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.211 X-Spam-Level: X-Spam-Status: No, score=-104.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 66_7Di43gn1r for ; Tue, 1 Apr 2014 06:55:40 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id F346B1A06DE for ; Tue, 1 Apr 2014 06:55:37 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5E132CD6512 for ; Tue, 1 Apr 2014 15:55:33 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.144.102] (dozen.neclab.eu [195.37.70.136]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 41FBDCD548A for ; Tue, 1 Apr 2014 15:55:33 +0200 (CEST) Message-ID: <533AC554.1060404@it.uc3m.es> Date: Tue, 01 Apr 2014 15:55:32 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: lmap@ietf.org References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> In-Reply-To: <20140401132852.GA74000@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20602.007 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/uO7DIFOd_2h7LV8tvMoEEKAw7yE 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, 01 Apr 2014 13:55:43 -0000 El 01/04/14 15:28, Juergen Schoenwaelder escribió: > e) I find this text somewhat irritating: > > Another case that is slightly different than this would be the one of > a ping responder. This is also an MP, with a helper function, the > ping server, which is specially deployed to assist the MAs that > perform pings. > > At least for conventional ICMP-based pings, the 'ping server' is > the MP's IP implementation and as such it is not "specially > deployed to assist the MAs". Right. What we meant is that ping responder is something deployed with the intention of testing as oposed to a web server for exmaple that serves an application. It is clearer with the TWAMP case, since ping is widely available. Do you think it is better to change the ping case for a TWAMP example? Regards, marcelo > /js > From nobody Tue Apr 1 07:04: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 C562A1A084C for ; Tue, 1 Apr 2014 07:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 mR6HFZNsZ4vb for ; Tue, 1 Apr 2014 07:04:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6AE1A083B for ; Tue, 1 Apr 2014 07:04:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DE80CA8E; Tue, 1 Apr 2014 16:04:17 +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 PNbBP4qu-hU0; Tue, 1 Apr 2014 16:04:17 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 1 Apr 2014 16:04:17 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 491EA2002F; Tue, 1 Apr 2014 16:04:17 +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 SWI2LO4bhmIr; Tue, 1 Apr 2014 16:04:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73FF22002C; Tue, 1 Apr 2014 16:04:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6B7AD2C1EF9C; Tue, 1 Apr 2014 16:04:13 +0200 (CEST) Date: Tue, 1 Apr 2014 16:04:13 +0200 From: Juergen Schoenwaelder To: marcelo bagnulo braun Message-ID: <20140401140413.GA74213@elstar.local> Mail-Followup-To: marcelo bagnulo braun , lmap@ietf.org References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> <533AC554.1060404@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <533AC554.1060404@it.uc3m.es> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/UyEGO23LH0zy7BqrhKsr_3N6zBM Cc: 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: Tue, 01 Apr 2014 14:04:23 -0000 On Tue, Apr 01, 2014 at 03:55:32PM +0200, marcelo bagnulo braun wrote: > El 01/04/14 15:28, Juergen Schoenwaelder escribió: > >e) I find this text somewhat irritating: > > > > Another case that is slightly different than this would be the one of > > a ping responder. This is also an MP, with a helper function, the > > ping server, which is specially deployed to assist the MAs that > > perform pings. > > > > At least for conventional ICMP-based pings, the 'ping server' is > > the MP's IP implementation and as such it is not "specially > > deployed to assist the MAs". > > Right. What we meant is that ping responder is something deployed > with the intention of testing as oposed to a web server for exmaple > that serves an application. It is clearer with the TWAMP case, since > ping is widely available. Do you think it is better to change the > ping case for a TWAMP example? Yes, I think that would be clearer. /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 Apr 1 07:15:26 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5221A06FF for ; Tue, 1 Apr 2014 07:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 GMugARWKOF8n for ; Tue, 1 Apr 2014 07:15:21 -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 075BD1A06DB for ; Tue, 1 Apr 2014 07:15:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAErIOlOHCzIm/2dsb2JhbABWA4JlITtXu3wdhzWBGhZ0giUBAQEBAwEBAQ8oNAkCDAICAgEIDQECAQQBAQEKFAkHGwwLFAgBCAIEAQkEBQgTB4dXAQykK602FwSOGCMhEAcGC4MTgRQEn02LQoMwgWkkHg X-IronPort-AV: E=Sophos;i="4.97,772,1389762000"; d="scan'208";a="56054907" 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 Apr 2014 10:15:17 -0400 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; 01 Apr 2014 10:00: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; Tue, 1 Apr 2014 16:15:15 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "philip.eardley@bt.com" Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: AQHPTa5dInSbOsaayUma6cwj64nlTJr8zdpg Date: Tue, 1 Apr 2014 14:15:14 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E46D9B6@AZ-FFEXMB04.global.avaya.com> References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> In-Reply-To: <20140401132852.GA74000@elstar.local> 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/FZ16swhtq5dCzj96bnBeRuI3owo Cc: "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, 01 Apr 2014 14:15:23 -0000 Philip,=20 Do you want to address immediately the comments made by Juergen, or would y= ou rather have the second WGLC issued and consider these as LC comments?=20 Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, April 01, 2014 4:29 PM > To: philip.eardley@bt.com > Cc: lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- > framework-04.txt >=20 > On Mon, Mar 31, 2014 at 04:45:03PM +0100, philip.eardley@bt.com wrote: > > We've created a new version -04 of the framework doc. This resolves (we > believe) all the WG last call issues according to the consensus agreed in > London. >=20 > Thanks. >=20 > I have gone through the changes and below are some comments. Overall I > like the many improvements very much. >=20 > a) s/(the MA observes user traffic)/(the MA observes traffic)/ >=20 > I do not think it needs to be 'user traffic' nor do we have a > definition of the term 'user traffic'. >=20 > b) The suppression text says: >=20 > Suppression: the temporary cessation of Active Measurement Tasks. >=20 > Should we not remove 'Active' from this definition? Why would it be > illegal to suppress a passive measurement task? Is it not simpler > to remove this restriction so that we do not have classify all > measurement tasks? (I can imagine a passive measurement task that > generates tons of reports and by suppressing the task, I may as a > consequence suppress the reports.) >=20 > c) It is somewhat unclear to me why the framework likes to decide how > capabilities, failure information and logging information is > transferred. For example, why does it mandate that logging > information is only sent when requested by the controller? (I could > very well see a solution where logging information transfer is > controlled by a schedule as well). Unless there is a very clear and > strong reason, I think we should leave these details to the > protocol work and not regulate them in the framework. >=20 > d) In section 10, s/just another customer/just another client/ >=20 > e) I find this text somewhat irritating: >=20 > Another case that is slightly different than this would be the one o= f > a ping responder. This is also an MP, with a helper function, the > ping server, which is specially deployed to assist the MAs that > perform pings. >=20 > At least for conventional ICMP-based pings, the 'ping server' is > the MP's IP implementation and as such it is not "specially > deployed to assist the MAs". >=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 Tue Apr 1 08:31:34 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051A41A0871 for ; Tue, 1 Apr 2014 08:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 mrw3RP1dINzh for ; Tue, 1 Apr 2014 08:31:31 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0C01A06F4 for ; Tue, 1 Apr 2014 08:31:31 -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 0dbda335.2b29e181b940.5466353.00-2468.15241422.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 01 Apr 2014 15:31:28 +0000 (UTC) X-MXL-Hash: 533adbd064d15511-a323c85e2b6855e1b97f722feac94fb21255ffd6 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 2cbda335.0.5466190.00-2285.15240948.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 01 Apr 2014 15:31:21 +0000 (UTC) X-MXL-Hash: 533adbc95d2ffc6c-bca7fdce258d7e5c734c02f163a01396cb40548d 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 s31FVDqr006271; Tue, 1 Apr 2014 11:31:14 -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 s31FV64p006106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Apr 2014 11:31:10 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 1 Apr 2014 15:30:48 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0174.001; Tue, 1 Apr 2014 11:30:48 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , "philip.eardley@bt.com" Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: AQHPTa5oNbL2T7afa0y+RLVxrVkjW5r82qXw Date: Tue, 1 Apr 2014 15:30:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> In-Reply-To: <20140401132852.GA74000@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.153.63] 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=LaqLHEji c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=jB7aAHWnCvcA:10 a=ofMgfj31e3cA:10 a=V8jVI7omBTkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=PTF0u-3AjI2km69XOxEA:9 a=CjuIK1q_8ugA:10 a=60gGXB] X-AnalysisOut: [Ef-huKUlX5:21 a=zxJX7N0RTdtpWEit:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/177MSS5IYscS9Rz9f9-1j89g0Fg Cc: "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, 01 Apr 2014 15:31:33 -0000 > b) The suppression text says: >=20 > Suppression: the temporary cessation of Active Measurement Tasks. >=20 > Should we not remove 'Active' from this definition? Why would it be > illegal to suppress a passive measurement task? Is it not simpler > to remove this restriction so that we do not have classify all > measurement tasks? (I can imagine a passive measurement task that > generates tons of reports and by suppressing the task, I may as a > consequence suppress the reports.) What I had lobbied for was that Suppression caused the cessation of measure= ment traffic originated by the MA. Suppression was proposed as a blunt hammer that would stop measurement traf= fic. I would like to keep it as proposed, and not expand the breadth of its= bluntness. It may have side effects of stopping other processes not directly related t= o cessation of originated measurement traffic, but this cannot be assumed. = For a generic MA, it cannot be assumed that passive measuring will or won't= continue, or that reporting will or won't continue. If someone designs the= ir particular MA to shut down all activities as a result of Suppression, th= at's ok (as long as there is no originated measurement traffic). If someone= designs their particular MA to only prevent originated measurement traffic= , that's ok, too. =20 If someone wants to suppress a report, they can send updated Instruction to= change details regarding that report (or all reports).=20 One of the use cases is "service providers collecting measurements from the= ir managed devices". Service provider operations systems are often on a dis= tinct management network, so it's unnecessary to force everyone with this s= ort of separation of Internet traffic and management traffic to always use = the "only suppress these specific measurement tasks/schedules" in order to = avoid having their devices (that they procure and supply design requirement= s for) suppress reporting or other Report and Control activities. Those who design devices intended for other use cases are free to shut down= all activities on those devices. So long as the primary goal of preventing= originated measurement traffic is met, IMO, it's ok to allow flexibility i= n design of what else gets impacted by Suppression. Barbara From nobody Tue Apr 1 08:38: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 C4A301A06F4 for ; Tue, 1 Apr 2014 08:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 mJZs_kFYte7n for ; Tue, 1 Apr 2014 08:38:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC941A0990 for ; Tue, 1 Apr 2014 08:38: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 9B870834; Tue, 1 Apr 2014 17:38:12 +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 gTNtuZCzgnRG; Tue, 1 Apr 2014 17:38:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 1 Apr 2014 17:38:11 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D47CC20033; Tue, 1 Apr 2014 17:38:11 +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 WWZXZr5Eiun2; Tue, 1 Apr 2014 17:38:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B9592002C; Tue, 1 Apr 2014 17:38:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3F3542C1FB7A; Tue, 1 Apr 2014 17:38:09 +0200 (CEST) Date: Tue, 1 Apr 2014 17:38:08 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140401153808.GA74655@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/NWdfigDhMgLwcdPq-YdvLcyCtSg Cc: "philip.eardley@bt.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: Tue, 01 Apr 2014 15:38:19 -0000 Barbara, do you agree with the current text, with my change, or do you propose something different? I fail to get this our of your text. /js On Tue, Apr 01, 2014 at 03:30:47PM +0000, STARK, BARBARA H wrote: > > b) The suppression text says: > > > > Suppression: the temporary cessation of Active Measurement Tasks. > > > > Should we not remove 'Active' from this definition? Why would it be > > illegal to suppress a passive measurement task? Is it not simpler > > to remove this restriction so that we do not have classify all > > measurement tasks? (I can imagine a passive measurement task that > > generates tons of reports and by suppressing the task, I may as a > > consequence suppress the reports.) > > What I had lobbied for was that Suppression caused the cessation of measurement traffic originated by the MA. > Suppression was proposed as a blunt hammer that would stop measurement traffic. I would like to keep it as proposed, and not expand the breadth of its bluntness. > > It may have side effects of stopping other processes not directly related to cessation of originated measurement traffic, but this cannot be assumed. For a generic MA, it cannot be assumed that passive measuring will or won't continue, or that reporting will or won't continue. If someone designs their particular MA to shut down all activities as a result of Suppression, that's ok (as long as there is no originated measurement traffic). If someone designs their particular MA to only prevent originated measurement traffic, that's ok, too. > > If someone wants to suppress a report, they can send updated Instruction to change details regarding that report (or all reports). > > One of the use cases is "service providers collecting measurements from their managed devices". Service provider operations systems are often on a distinct management network, so it's unnecessary to force everyone with this sort of separation of Internet traffic and management traffic to always use the "only suppress these specific measurement tasks/schedules" in order to avoid having their devices (that they procure and supply design requirements for) suppress reporting or other Report and Control activities. > > Those who design devices intended for other use cases are free to shut down all activities on those devices. So long as the primary goal of preventing originated measurement traffic is met, IMO, it's ok to allow flexibility in design of what else gets impacted by Suppression. > Barbara > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Apr 1 08:59: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 C7F141A0991 for ; Tue, 1 Apr 2014 08:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 zbVqJ9BnuR0b for ; Tue, 1 Apr 2014 08:59:53 -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 5E10B1A0996 for ; Tue, 1 Apr 2014 08:59:53 -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 672ea335.2ac23b2f6940.357673.00-2472.1011439.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 01 Apr 2014 15:59:50 +0000 (UTC) X-MXL-Hash: 533ae276296652ea-7dabf26d12ef20659b8ee215210077990a45e0b0 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 372ea335.0.357629.00-2371.1011317.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 01 Apr 2014 15:59:48 +0000 (UTC) X-MXL-Hash: 533ae2747f761f91-da2722edf9a3afe25093525ca2f48f0acf0e3fd0 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 s31FxjtQ011202; Tue, 1 Apr 2014 11:59:46 -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 s31Fxcla010882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Apr 2014 11:59:41 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (GAALPA1MSGHUB9D.itservices.sbc.com [130.8.36.90]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 1 Apr 2014 15:59:22 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; Tue, 1 Apr 2014 11:59:21 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: AQHPTa5oNbL2T7afa0y+RLVxrVkjW5r82qXwgABNzwD//7/HIA== Date: Tue, 1 Apr 2014 15:59:21 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611304167DE@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140401153808.GA74655@elstar.local> In-Reply-To: <20140401153808.GA74655@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.153.63] 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=JtRGWrEC c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=jB7aAHWnCvcA:10 a=ofMgfj31e3cA:10 a=V8jVI7omBTkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=LKukZUxn4EFxlvd] X-AnalysisOut: [x6BsA:9 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=xy2VSB_LWxR7ifCW:21 a=aChkHl1CLc40] X-AnalysisOut: [RzFm:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/fQm6rboXgk1wJCnuoRQCD2WZUX4 Cc: "philip.eardley@bt.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, 01 Apr 2014 15:59:56 -0000 > Barbara, >=20 > do you agree with the current text, with my change, or do you propose > something different? I fail to get this our of your text. >=20 > /js I propose something different. Suppression: the cessation of measurement traffic originated by the MA. [I'm ok with "temporary" but find it awkward since there's actually nothing= in the Suppression mechanism that ensures it's always temporary.] I agree with you that "Active" does not belong in the definition. I disagre= e that internal collection of passive measurements must cease, or that repo= rting must cease. They may cease in a particular implementation, but all im= plementations are not required to cause them to cease. Only originated meas= urement traffic must cease. Barbara =20 > On Tue, Apr 01, 2014 at 03:30:47PM +0000, STARK, BARBARA H wrote: > > > b) The suppression text says: > > > > > > Suppression: the temporary cessation of Active Measurement Tasks= . > > > > > > Should we not remove 'Active' from this definition? Why would it b= e > > > illegal to suppress a passive measurement task? Is it not simpler > > > to remove this restriction so that we do not have classify all > > > measurement tasks? (I can imagine a passive measurement task that > > > generates tons of reports and by suppressing the task, I may as a > > > consequence suppress the reports.) > > > > What I had lobbied for was that Suppression caused the cessation of > measurement traffic originated by the MA. > > Suppression was proposed as a blunt hammer that would stop > measurement traffic. I would like to keep it as proposed, and not expand = the > breadth of its bluntness. > > > > It may have side effects of stopping other processes not directly relat= ed to > cessation of originated measurement traffic, but this cannot be assumed. = For > a generic MA, it cannot be assumed that passive measuring will or won't > continue, or that reporting will or won't continue. If someone designs th= eir > particular MA to shut down all activities as a result of Suppression, tha= t's ok > (as long as there is no originated measurement traffic). If someone desig= ns > their particular MA to only prevent originated measurement traffic, that'= s ok, > too. > > > > If someone wants to suppress a report, they can send updated Instructio= n > to change details regarding that report (or all reports). > > > > One of the use cases is "service providers collecting measurements from > their managed devices". Service provider operations systems are often on = a > distinct management network, so it's unnecessary to force everyone with > this sort of separation of Internet traffic and management traffic to alw= ays > use the "only suppress these specific measurement tasks/schedules" in > order to avoid having their devices (that they procure and supply design > requirements for) suppress reporting or other Report and Control activiti= es. > > > > Those who design devices intended for other use cases are free to shut > down all activities on those devices. So long as the primary goal of prev= enting > originated measurement traffic is met, IMO, it's ok to allow flexibility = in > design of what else gets impacted by Suppression. > > Barbara > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From nobody Tue Apr 1 09:27:12 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66801A09A9 for ; Tue, 1 Apr 2014 09:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 aoA5NRwNOlrM for ; Tue, 1 Apr 2014 09:27:08 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 796631A0852 for ; Tue, 1 Apr 2014 09:27: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 A3FA2FC6; Tue, 1 Apr 2014 18:27:04 +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 0tdV_GzQhReR; Tue, 1 Apr 2014 18:27:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 1 Apr 2014 18:27:03 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CECA420033; Tue, 1 Apr 2014 18:27:03 +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 IabejW7YTSGA; Tue, 1 Apr 2014 18:27:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C230A2002F; Tue, 1 Apr 2014 18:27:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E41E22C1FCC7; Tue, 1 Apr 2014 18:27:00 +0200 (CEST) Date: Tue, 1 Apr 2014 18:27:00 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140401162700.GA74749@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140401153808.GA74655@elstar.local> <2D09D61DDFA73D4C884805CC7865E611304167DE@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611304167DE@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/viCg2Ntfl8DaY4wyU-okpZUHPxU Cc: "philip.eardley@bt.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: Tue, 01 Apr 2014 16:27:10 -0000 On Tue, Apr 01, 2014 at 03:59:21PM +0000, STARK, BARBARA H wrote: > > Barbara, > > > > do you agree with the current text, with my change, or do you propose > > something different? I fail to get this our of your text. > > > > /js > > I propose something different. > Suppression: the cessation of measurement traffic originated by the MA. > > [I'm ok with "temporary" but find it awkward since there's actually nothing in the Suppression mechanism that ensures it's always temporary.] > > I agree with you that "Active" does not belong in the definition. I disagree that internal collection of passive measurements must cease, or that reporting must cease. They may cease in a particular implementation, but all implementations are not required to cause them to cease. Only originated measurement traffic must cease. I am having a problem with 'may in some implementations'. This is not interoperable. /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 Apr 1 11:34: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 CEA4F1A08BB for ; Tue, 1 Apr 2014 11:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 p7P7H4zekrgi for ; Tue, 1 Apr 2014 11:34:24 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2057A1A08AC for ; Tue, 1 Apr 2014 11:34:24 -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 ca60b335.2b2a03e52940.5607636.00-2407.15640447.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 01 Apr 2014 18:34:20 +0000 (UTC) X-MXL-Hash: 533b06ac725f3f8a-7087c737064c112eae5489601acfdf0ec143dd7b 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 7a60b335.0.5607562.00-2216.15640250.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 01 Apr 2014 18:34:16 +0000 (UTC) X-MXL-Hash: 533b06a85e326821-e1d9e6e16e1cf7666b9e801d3cb59f781135bdf6 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 s31IYDe3017947; Tue, 1 Apr 2014 14:34:14 -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 s31IY98f017813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Apr 2014 14:34:10 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 1 Apr 2014 18:34:01 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0174.001; Tue, 1 Apr 2014 14:34:01 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: AQHPTa5oNbL2T7afa0y+RLVxrVkjW5r82qXwgABNzwD//7/HIIAATeAA//++EYA= Date: Tue, 1 Apr 2014 18:34:00 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130416931@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140401153808.GA74655@elstar.local> <2D09D61DDFA73D4C884805CC7865E611304167DE@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140401162700.GA74749@elstar.local> In-Reply-To: <20140401162700.GA74749@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.153.63] 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=LaqLHEji c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=jB7aAHWnCvcA:10 a=ofMgfj31e3cA:10 a=V8jVI7omBTkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=_Cr_fAkB6NPc9npqnIQA: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/PY4Smdd9gta7bQTkyQypWeoINiI Cc: "philip.eardley@bt.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, 01 Apr 2014 18:34:26 -0000 > > I agree with you that "Active" does not belong in the definition. I dis= agree > that internal collection of passive measurements must cease, or that > reporting must cease. They may cease in a particular implementation, but = all > implementations are not required to cause them to cease. Only originated > measurement traffic must cease. >=20 > I am having a problem with 'may in some implementations'. This is not > interoperable. In my experience, it's impossible to define a function so thoroughly that t= here are no unknowns about what it will do in a certain situation, and no d= ecisions left up to the implementer.=20 But let's say hypothetically that all collection of passive measurements *a= re* "stopped". We've defined internal measuring of CPU utilization and memo= ry resources and general device health checking as "passive measurements". = So this means they all have to stop. Firewall logging is a passive measurem= ent. It must stop. Link resource utilization to be used in active queue man= agement is a passive measurement. It must stop. But why is it an interopera= bility "issue" whether these passive measurement processes continue to run = or not? I really don't understand how they impact interoperability. As for reporting, we've defined sending log info (e.g. measurement tasks su= ccessfully run, suppressed, etc.) to the Controller as a report. Let's say = we expect Suppression to stop all reports. That means it must not send the = Controller any logs.=20 Anyway, I was illustrating just a few examples of unknowns wrt impacts of S= uppression. There are many more unknowns. My proposed definition of Suppres= sion has no 'may' statements. Suppression: the cessation of measurement traffic originated by the MA. If we wanted to explicitly say that suppression shall not impact collection= of passive measurements or reporting, I would be fine with that, since I t= hink that's the better design and I think it's easily achieved. But others = thought it would be complex to do and that it would be simpler for them to = "kill all measurement tasks". As long as I'm not obliged to implement Suppr= ession as "kill all tasks" I'm fine with giving others the freedom to do so= in their implementations. Barbara From nobody Tue Apr 1 22:56: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 306F41A013D for ; Tue, 1 Apr 2014 22:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 fGCH1wGWL8_z for ; Tue, 1 Apr 2014 22:55:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA091A013F for ; Tue, 1 Apr 2014 22:55:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F2274FD7; Wed, 2 Apr 2014 07:55:47 +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 6ak65w-bfEut; Wed, 2 Apr 2014 07:55:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 2 Apr 2014 07:55:47 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2232C2002F; Wed, 2 Apr 2014 07:55:47 +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 NRIUXJvgaWVk; Wed, 2 Apr 2014 07:55:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87C0E2002C; Wed, 2 Apr 2014 07:55:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ABD9C2C2075A; Wed, 2 Apr 2014 07:55:43 +0200 (CEST) Date: Wed, 2 Apr 2014 07:55:42 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140402055542.GA75833@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140401153808.GA74655@elstar.local> <2D09D61DDFA73D4C884805CC7865E611304167DE@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140401162700.GA74749@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416931@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130416931@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/YhNKWyVneklB6nQ3QiAVTikLa1s Cc: "philip.eardley@bt.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: Wed, 02 Apr 2014 05:55:59 -0000 Barbara, I disagree. If I hit the supression button, I like to know what the consequence of this is. Leaving this partially up to implementations is in my view the worst of all choices. Looking at the current ID, my understanding is that a suppression without parameters suppresses a certain set of measurement tasks, takes effect immediately, and supression ends when the unsuppress button is hit. I assume the suppress ongoing task bit defaults to false (but this is less clearly spelled out). To define the set of measurement tasks that is affected if no set is specified, we can either introduce a classification of all measurement tasks (where is this coming from?) or we could make this explicit config (this way I know which tasks will be stopped if someone hits the button). Both could work for me. But, a definition of 'a certain set of measurement tasks plus additional tasks that are implementation specific' is in my view not a desirable outcome. /js On Tue, Apr 01, 2014 at 06:34:00PM +0000, STARK, BARBARA H wrote: > > > I agree with you that "Active" does not belong in the definition. I disagree > > that internal collection of passive measurements must cease, or that > > reporting must cease. They may cease in a particular implementation, but all > > implementations are not required to cause them to cease. Only originated > > measurement traffic must cease. > > > > I am having a problem with 'may in some implementations'. This is not > > interoperable. > > In my experience, it's impossible to define a function so thoroughly that there are no unknowns about what it will do in a certain situation, and no decisions left up to the implementer. > > But let's say hypothetically that all collection of passive measurements *are* "stopped". We've defined internal measuring of CPU utilization and memory resources and general device health checking as "passive measurements". So this means they all have to stop. Firewall logging is a passive measurement. It must stop. Link resource utilization to be used in active queue management is a passive measurement. It must stop. But why is it an interoperability "issue" whether these passive measurement processes continue to run or not? I really don't understand how they impact interoperability. > > As for reporting, we've defined sending log info (e.g. measurement tasks successfully run, suppressed, etc.) to the Controller as a report. Let's say we expect Suppression to stop all reports. That means it must not send the Controller any logs. > > Anyway, I was illustrating just a few examples of unknowns wrt impacts of Suppression. There are many more unknowns. My proposed definition of Suppression has no 'may' statements. > > Suppression: the cessation of measurement traffic originated by the MA. > > If we wanted to explicitly say that suppression shall not impact collection of passive measurements or reporting, I would be fine with that, since I think that's the better design and I think it's easily achieved. But others thought it would be complex to do and that it would be simpler for them to "kill all measurement tasks". As long as I'm not obliged to implement Suppression as "kill all tasks" I'm fine with giving others the freedom to do so in their implementations. > Barbara -- 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 Apr 2 02:07:50 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1AD1A017A for ; Wed, 2 Apr 2014 02:07:48 -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 h81QEJUt-XlU for ; Wed, 2 Apr 2014 02:07:42 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5707C1A017D for ; Wed, 2 Apr 2014 02:07:34 -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; Wed, 2 Apr 2014 10:07:39 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.149]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Wed, 2 Apr 2014 10:06:46 +0100 From: To: , Date: Wed, 2 Apr 2014 10:06:45 +0100 Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: Ac9OODL4v2POHRd6QmWq10rbRxeeKQAFF4/Q Message-ID: References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140401153808.GA74655@elstar.local> <2D09D61DDFA73D4C884805CC7865E611304167DE@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140401162700.GA74749@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416931@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140402055542.GA75833@elstar.local> In-Reply-To: <20140402055542.GA75833@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/Vd5o2XeC_VmuEqOBuAUAe0Of_ec Cc: 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: Wed, 02 Apr 2014 09:07:49 -0000 Can I suggest we discuss S5.2.1.1 first and get the definition of Suppressi= on right after that. Just to confirm what the current 5.2.1.1 is intended to mean: Suppression must stop new active measurement tasks from starting. The impact is undefined (left to the implementer /deployer) on other things= like passive measurement tasks and on-going active tasks. Suppression is intended to be temporary - if you want to stop all the activ= e tasks permanently, then it's suggested you send a new schedule [but I gue= ss there's nothing to stop you 'abusing' suppression as a permanent stop] 5.2.1.1 doesn't talk about the impact on Data Transfer Tasks. Not sure we'v= e discussed this. I suppose at the moment the implication is that Data Tran= sfer Tasks (including reporting) continues to run.=20 -- In terms of implementation, the way I thought about it is that the MA would= have a mini-firewall that would block all outgoing traffic associated with= a measurement task; there's at least some traffic it mustn't block, such a= s capabilities & logging info sent in response to a request from the contro= ller. Is this easy to implement?=20 I don't think the MA needs to understand any classification of different me= asurement tasks. However, the measurement system would probably like to und= erstand the impact of this mini-firewall function for non-obvious cases lik= e a measurement task that simply modifies the header of end-user traffic. -- > we can either introduce a classification of all measurement > tasks (where is this coming from?) or we could make this explicit > config (this way I know which tasks will be stopped if someone hits the > button).=20 I don't like classification. This is work, requires extra state in controll= er and MA, and what happens if there's a classification mistake. Explicit config. This basically means 'send a new schedule' (actually my pe= rsonal view but not the consensus) Phil > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: 02 April 2014 06:56 > To: STARK, BARBARA H > Cc: Eardley,PL,Philip,TUB8 R; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- > framework-04.txt >=20 > Barbara, >=20 > I disagree. If I hit the supression button, I like to know what the > consequence of this is. Leaving this partially up to implementations is > in my view the worst of all choices. Looking at the current ID, my > understanding is that a suppression without parameters suppresses a > certain set of measurement tasks, takes effect immediately, and > supression ends when the unsuppress button is hit. I assume the > suppress ongoing task bit defaults to false (but this is less clearly > spelled out). >=20 > To define the set of measurement tasks that is affected if no set is > specified, we can either introduce a classification of all measurement > tasks (where is this coming from?) or we could make this explicit > config (this way I know which tasks will be stopped if someone hits the > button). Both could work for me. But, a definition of 'a certain set of > measurement tasks plus additional tasks that are implementation > specific' is in my view not a desirable outcome. >=20 > /js >=20 > On Tue, Apr 01, 2014 at 06:34:00PM +0000, STARK, BARBARA H wrote: > > > > I agree with you that "Active" does not belong in the definition. > > > > I disagree > > > that internal collection of passive measurements must cease, or > that > > > reporting must cease. They may cease in a particular > implementation, > > > but all implementations are not required to cause them to cease. > > > Only originated measurement traffic must cease. > > > > > > I am having a problem with 'may in some implementations'. This is > > > not interoperable. > > > > In my experience, it's impossible to define a function so thoroughly > that there are no unknowns about what it will do in a certain > situation, and no decisions left up to the implementer. > > > > But let's say hypothetically that all collection of passive > measurements *are* "stopped". We've defined internal measuring of CPU > utilization and memory resources and general device health checking as > "passive measurements". So this means they all have to stop. Firewall > logging is a passive measurement. It must stop. Link resource > utilization to be used in active queue management is a passive > measurement. It must stop. But why is it an interoperability "issue" > whether these passive measurement processes continue to run or not? I > really don't understand how they impact interoperability. > > > > As for reporting, we've defined sending log info (e.g. measurement > tasks successfully run, suppressed, etc.) to the Controller as a > report. Let's say we expect Suppression to stop all reports. That means > it must not send the Controller any logs. > > > > Anyway, I was illustrating just a few examples of unknowns wrt > impacts of Suppression. There are many more unknowns. My proposed > definition of Suppression has no 'may' statements. > > > > Suppression: the cessation of measurement traffic originated by the > MA. > > > > If we wanted to explicitly say that suppression shall not impact > collection of passive measurements or reporting, I would be fine with > that, since I think that's the better design and I think it's easily > achieved. But others thought it would be complex to do and that it > would be simpler for them to "kill all measurement tasks". As long as > I'm not obliged to implement Suppression as "kill all tasks" I'm fine > with giving others the freedom to do so in their implementations. > > Barbara >=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 Apr 2 02:29: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 B5FCE1A016F for ; Wed, 2 Apr 2014 02:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, T_RP_MATCHES_RCVD=-0.01] 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 BTX5HoweSEdX for ; Wed, 2 Apr 2014 02:29: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 E88911A0132 for ; Wed, 2 Apr 2014 02:29: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 E2432E7B; Wed, 2 Apr 2014 11:29:04 +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 ItjHAO1Jx6FV; Wed, 2 Apr 2014 11:29:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 2 Apr 2014 11:29:03 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7189920035; Wed, 2 Apr 2014 11:29:03 +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 ayzTCiBO02L7; Wed, 2 Apr 2014 11:29:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C94F2002F; Wed, 2 Apr 2014 11:29:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 932892C21131; Wed, 2 Apr 2014 11:28:59 +0200 (CEST) Date: Wed, 2 Apr 2014 11:28:59 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20140402092859.GA76386@elstar.local> Mail-Followup-To: philip.eardley@bt.com, bs7652@att.com, lmap@ietf.org References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140401153808.GA74655@elstar.local> <2D09D61DDFA73D4C884805CC7865E611304167DE@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140401162700.GA74749@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416931@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140402055542.GA75833@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/b6KvXuYfVgBE74S9_h-qyBfYHRo Cc: 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: Wed, 02 Apr 2014 09:29:13 -0000 Phil, I think what you have in mind (the mini firewall) is not exactly what I would understand from "must stop new active measurement tasks from starting". Your notion of suppressiong is blocking measurement traffic, you are not starting or stopping or not starting anything. If this is what suppression is meant to be (and I think this is close to Barbara's ideas), then we need to spell this out more clearly I think. Is it simple to implement? I think one would need for each measurement task a filter that can be injected and removed and the filters would have to be designed such that they do not cause side effects affecting other things going on. In other words, this sets up a requirement for measurement task implementations, not so much for the generic infrastructure (that would simply inject and remove such filters). Anyway, as useful as this might be, the current text seems to say something different. /js On Wed, Apr 02, 2014 at 10:06:45AM +0100, philip.eardley@bt.com wrote: > Can I suggest we discuss S5.2.1.1 first and get the definition of Suppression right after that. > > Just to confirm what the current 5.2.1.1 is intended to mean: > Suppression must stop new active measurement tasks from starting. > The impact is undefined (left to the implementer /deployer) on other things like passive measurement tasks and on-going active tasks. > Suppression is intended to be temporary - if you want to stop all the active tasks permanently, then it's suggested you send a new schedule [but I guess there's nothing to stop you 'abusing' suppression as a permanent stop] > > 5.2.1.1 doesn't talk about the impact on Data Transfer Tasks. Not sure we've discussed this. I suppose at the moment the implication is that Data Transfer Tasks (including reporting) continues to run. > > -- > > In terms of implementation, the way I thought about it is that the MA would have a mini-firewall that would block all outgoing traffic associated with a measurement task; there's at least some traffic it mustn't block, such as capabilities & logging info sent in response to a request from the controller. Is this easy to implement? > I don't think the MA needs to understand any classification of different measurement tasks. However, the measurement system would probably like to understand the impact of this mini-firewall function for non-obvious cases like a measurement task that simply modifies the header of end-user traffic. > > -- > > > we can either introduce a classification of all measurement > > tasks (where is this coming from?) or we could make this explicit > > config (this way I know which tasks will be stopped if someone hits the > > button). > I don't like classification. This is work, requires extra state in controller and MA, and what happens if there's a classification mistake. > Explicit config. This basically means 'send a new schedule' (actually my personal view but not the consensus) > > Phil > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: 02 April 2014 06:56 > > To: STARK, BARBARA H > > Cc: Eardley,PL,Philip,TUB8 R; lmap@ietf.org > > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- > > framework-04.txt > > > > Barbara, > > > > I disagree. If I hit the supression button, I like to know what the > > consequence of this is. Leaving this partially up to implementations is > > in my view the worst of all choices. Looking at the current ID, my > > understanding is that a suppression without parameters suppresses a > > certain set of measurement tasks, takes effect immediately, and > > supression ends when the unsuppress button is hit. I assume the > > suppress ongoing task bit defaults to false (but this is less clearly > > spelled out). > > > > To define the set of measurement tasks that is affected if no set is > > specified, we can either introduce a classification of all measurement > > tasks (where is this coming from?) or we could make this explicit > > config (this way I know which tasks will be stopped if someone hits the > > button). Both could work for me. But, a definition of 'a certain set of > > measurement tasks plus additional tasks that are implementation > > specific' is in my view not a desirable outcome. > > > > /js > > > > On Tue, Apr 01, 2014 at 06:34:00PM +0000, STARK, BARBARA H wrote: > > > > > I agree with you that "Active" does not belong in the definition. > > > > > I disagree > > > > that internal collection of passive measurements must cease, or > > that > > > > reporting must cease. They may cease in a particular > > implementation, > > > > but all implementations are not required to cause them to cease. > > > > Only originated measurement traffic must cease. > > > > > > > > I am having a problem with 'may in some implementations'. This is > > > > not interoperable. > > > > > > In my experience, it's impossible to define a function so thoroughly > > that there are no unknowns about what it will do in a certain > > situation, and no decisions left up to the implementer. > > > > > > But let's say hypothetically that all collection of passive > > measurements *are* "stopped". We've defined internal measuring of CPU > > utilization and memory resources and general device health checking as > > "passive measurements". So this means they all have to stop. Firewall > > logging is a passive measurement. It must stop. Link resource > > utilization to be used in active queue management is a passive > > measurement. It must stop. But why is it an interoperability "issue" > > whether these passive measurement processes continue to run or not? I > > really don't understand how they impact interoperability. > > > > > > As for reporting, we've defined sending log info (e.g. measurement > > tasks successfully run, suppressed, etc.) to the Controller as a > > report. Let's say we expect Suppression to stop all reports. That means > > it must not send the Controller any logs. > > > > > > Anyway, I was illustrating just a few examples of unknowns wrt > > impacts of Suppression. There are many more unknowns. My proposed > > definition of Suppression has no 'may' statements. > > > > > > Suppression: the cessation of measurement traffic originated by the > > MA. > > > > > > If we wanted to explicitly say that suppression shall not impact > > collection of passive measurements or reporting, I would be fine with > > that, since I think that's the better design and I think it's easily > > achieved. But others thought it would be complex to do and that it > > would be simpler for them to "kill all measurement tasks". As long as > > I'm not obliged to implement Suppression as "kill all tasks" I'm fine > > with giving others the freedom to do so in their implementations. > > > Barbara > > > > -- > > 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 Apr 2 02:30: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 1576D1A016F for ; Wed, 2 Apr 2014 02:30:17 -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 IzAfUJcfWqR2 for ; Wed, 2 Apr 2014 02:30:12 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 103421A0132 for ; Wed, 2 Apr 2014 02:30:11 -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; Wed, 2 Apr 2014 10:27:48 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.149]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Wed, 2 Apr 2014 10:30:06 +0100 From: To: Date: Wed, 2 Apr 2014 10:30:05 +0100 Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: Ac9NrlYjl/Mel03mQqmr+u5b6eA1IQApI/yg Message-ID: References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> In-Reply-To: <20140401132852.GA74000@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/2BpAbjtxtJXmDRGBbmbdLZNHXSY Cc: 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: Wed, 02 Apr 2014 09:30:17 -0000 Juergen - thanks for the comments! > c) It is somewhat unclear to me why the framework likes to decide how > capabilities, failure information and logging information is > transferred. For example, why does it mandate that logging > information is only sent when requested by the controller? (I could > very well see a solution where logging information transfer is > controlled by a schedule as well). Unless there is a very clear and > strong reason, I think we should leave these details to the > protocol work and not regulate them in the framework. Ok, will modify so it describes the different sorts of info and then says t= hey may be sent in response to a request by the controller, or by the MA on= its own initiative.=20 Also, I'll modify the picture as I think "Capabilities request" suggests th= ere's a special message, whereas really this is an Instruction with a Data = Transfer Task (that is effectively a request to send capabilities info). Suppression - discussing separately Other changes - will make. phil From nobody Wed Apr 2 02:32: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 00FD01A018A for ; Wed, 2 Apr 2014 02:32:16 -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 MeK266_hHWuT for ; Wed, 2 Apr 2014 02:32:07 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id AF9011A016F for ; Wed, 2 Apr 2014 02:32:06 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 2 Apr 2014 10:32:07 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.149]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 2 Apr 2014 10:32:01 +0100 From: To: , Date: Wed, 2 Apr 2014 10:32:00 +0100 Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: AQHPTa5dInSbOsaayUma6cwj64nlTJr8zdpggAFDHqA= Message-ID: References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA2E46D9B6@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E46D9B6@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/yFL5CNq4jzq1EGwYlen69qcG8Hs Cc: 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: Wed, 02 Apr 2014 09:32:16 -0000 I'm happy for the WGLC to be issued.=20 I think the one issue to resolve is about suppression, which I think we can= do as part of LC. Phil/ > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: 01 April 2014 15:15 > To: Juergen Schoenwaelder; Eardley,PL,Philip,TUB8 R > Cc: lmap@ietf.org > Subject: RE: [lmap] FW: New Version Notification for draft-ietf-lmap- > framework-04.txt >=20 > Philip, >=20 > Do you want to address immediately the comments made by Juergen, or > would you rather have the second WGLC issued and consider these as LC > comments? >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Tuesday, April 01, 2014 4:29 PM > > To: philip.eardley@bt.com > > Cc: lmap@ietf.org > > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- > > framework-04.txt > > > > On Mon, Mar 31, 2014 at 04:45:03PM +0100, philip.eardley@bt.com > wrote: > > > We've created a new version -04 of the framework doc. This resolves > > > (we > > believe) all the WG last call issues according to the consensus > agreed > > in London. > > > > Thanks. > > > > I have gone through the changes and below are some comments. Overall > I > > like the many improvements very much. > > > > a) s/(the MA observes user traffic)/(the MA observes traffic)/ > > > > I do not think it needs to be 'user traffic' nor do we have a > > definition of the term 'user traffic'. > > > > b) The suppression text says: > > > > Suppression: the temporary cessation of Active Measurement > Tasks. > > > > Should we not remove 'Active' from this definition? Why would it > be > > illegal to suppress a passive measurement task? Is it not simpler > > to remove this restriction so that we do not have classify all > > measurement tasks? (I can imagine a passive measurement task that > > generates tons of reports and by suppressing the task, I may as a > > consequence suppress the reports.) > > > > c) It is somewhat unclear to me why the framework likes to decide how > > capabilities, failure information and logging information is > > transferred. For example, why does it mandate that logging > > information is only sent when requested by the controller? (I > could > > very well see a solution where logging information transfer is > > controlled by a schedule as well). Unless there is a very clear > and > > strong reason, I think we should leave these details to the > > protocol work and not regulate them in the framework. > > > > d) In section 10, s/just another customer/just another client/ > > > > e) I find this text somewhat irritating: > > > > Another case that is slightly different than this would be the > one of > > a ping responder. This is also an MP, with a helper function, > the > > ping server, which is specially deployed to assist the MAs that > > perform pings. > > > > At least for conventional ICMP-based pings, the 'ping server' is > > the MP's IP implementation and as such it is not "specially > > deployed to assist the MAs". > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Apr 2 03:24: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 CAD0F1A01B1 for ; Wed, 2 Apr 2014 03:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 kFRkYgtF_lVb for ; Wed, 2 Apr 2014 03:24:00 -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 878161A01AA for ; Wed, 2 Apr 2014 03:24:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoKAJvkO1PGmAcV/2dsb2JhbABZgkIjITtXqkORVxmHNYEdFnSCJwEBAxIbXgEMCRVWJgEEGwEZh1cBDJ17hFatBBeOHwEBHoJmD2eBFASfTYtCgzCBcjk X-IronPort-AV: E=Sophos; i="4.97,779,1389762000"; d="scan'208,217"; a="48931350" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Apr 2014 06:23:55 -0400 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; 02 Apr 2014 06:09:40 -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; Wed, 2 Apr 2014 12:23:53 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: 2nd WGLC for draft-ietf-lmap-framework Thread-Index: Ac9OXaS8TURPW7PmQTCg0fi3LQcdJQ== Date: Wed, 2 Apr 2014 10:23:52 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E46EBD1@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_9904FB1B0159DA42B0B887B7FA8119CA2E46EBD1AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/KlEFPHpNjuVZNnHBFDq5K8-bmg0 Subject: [lmap] 2nd WGLC for 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: Wed, 02 Apr 2014 10:24:05 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E46EBD1AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a 2nd WGLC for the LMAP Framework I-D. Please send your comments to= the WG mail list until Thursday 4/16. If you believe that the document is = ready for submission to the IESG as Informational RC a short message statin= g this will also be welcome. The document is available at http://www.ietf.org/id/draft-ietf-lmap-framewo= rk-04.txt. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E46EBD1AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This is a 2nd WGLC for the LMAP Framework= I-D. Please send your comments to the WG mail list until Thursday 4/16. If= you believe that the document is ready for submission to the IESG as Infor= mational RC a short message stating this will also be welcome.

 

The document is available at http://www.ietf.org/id/draft-ietf-lmap-framework-04.txt.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E46EBD1AZFFEXMB04globa_-- From nobody Wed Apr 2 04:58:42 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F961A01F9 for ; Wed, 2 Apr 2014 04:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 P397pArIHObv for ; Wed, 2 Apr 2014 04:58:25 -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 935EE1A01F5 for ; Wed, 2 Apr 2014 04:58:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYKAJv6O1OHCzIm/2dsb2JhbABZgkIjITtXqkKZJYEdFnSCJwEBAxIbXgEMCRVWJgEEGwEZh1cBDJ1ZhFasfBeOHwEBHoNcgRQEn02LQoMwgXI5 X-IronPort-AV: E=Sophos; i="4.97,780,1389762000"; d="scan'208,217"; a="56219143" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Apr 2014 07:58:21 -0400 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; 02 Apr 2014 07:43:59 -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; Wed, 2 Apr 2014 07:58:20 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) Thread-Index: Ac9Oata2Fqx14mW5RqyxeWUMKab+0g== Date: Wed, 2 Apr 2014 11:58:19 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@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_9904FB1B0159DA42B0B887B7FA8119CA2E46EF03AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/wlaNsihK74zPy5rNhslsddz1BT8 Subject: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 02 Apr 2014 11:58:32 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E46EF03AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a 2nd WGLC for the LMAP Framework I-D. Please send your comments to= the WG mail list until Wednesday 4/16. If you believe that the document is= ready for submission to the IESG as Informational RC a short message stati= ng this will also be welcome. The document is available at http://www.ietf.org/id/draft-ietf-lmap-framewo= rk-04.txt. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E46EF03AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This is a 2nd WGLC for the LMAP Framework= I-D. Please send your comments to the WG mail list until Wednesday 4/16. I= f you believe that the document is ready for submission to the IESG as Info= rmational RC a short message stating this will also be welcome.

 

The document is available at http://www.ietf.org/id/draft-ietf-lmap-framework-04.txt.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E46EF03AZFFEXMB04globa_-- From nobody Wed Apr 2 05:18: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 EDE281A01FF for ; Wed, 2 Apr 2014 05:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 R5BxC_FI3Ir2 for ; Wed, 2 Apr 2014 05:18:37 -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 0F1381A01F7 for ; Wed, 2 Apr 2014 05:18:37 -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 B5E6D55442A; Wed, 2 Apr 2014 08:24:28 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id 3F9F1E2B3B; Wed, 2 Apr 2014 08:17:05 -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; Wed, 2 Apr 2014 08:18:32 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "philip.eardley@bt.com" Date: Wed, 2 Apr 2014 08:18:31 -0400 Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: Ac9OVgb8eTj1cFvOQW6fVxOBgUjZvQAFauHg Message-ID: <2845723087023D4CB5114223779FA9C801792B76E0@njfpsrvexg8.research.att.com> References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> <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> In-Reply-To: <20140402092859.GA76386@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ueje2rDmTBp7KnfzK9jkMr5GuoM Cc: "STARK, BARBARA H" , "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: Wed, 02 Apr 2014 12:18:41 -0000 So, keeping the firewall/filter analogy, the "suppress" action is to grab a list of filters and remove or modify them to block=20 the measurement traffic. This means the suppress process needs a=20 list of measurement tasks to act on, even if the intent is=20 "suppress all" or "suppress active". the active type we can distinguish from the metric registry assignment (if it's in the active registry, suppress). And as Juergen points out, tasks that aren't started yet are not so easily handled, the firewall doesn't have a filter for un-started tasks so we really need to take action on the scheduler, too. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, April 02, 2014 5:29 AM > To: philip.eardley@bt.com > Cc: STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- > framework-04.txt >=20 > Phil, >=20 > I think what you have in mind (the mini firewall) is not exactly what > I would understand from "must stop new active measurement tasks from > starting". Your notion of suppressiong is blocking measurement > traffic, you are not starting or stopping or not starting anything. >=20 > If this is what suppression is meant to be (and I think this is close > to Barbara's ideas), then we need to spell this out more clearly I > think. >=20 > Is it simple to implement? I think one would need for each measurement > task a filter that can be injected and removed and the filters would > have to be designed such that they do not cause side effects affecting > other things going on. In other words, this sets up a requirement for > measurement task implementations, not so much for the generic > infrastructure (that would simply inject and remove such filters). >=20 > Anyway, as useful as this might be, the current text seems to say > something different. >=20 > /js >=20 > On Wed, Apr 02, 2014 at 10:06:45AM +0100, philip.eardley@bt.com wrote: > > Can I suggest we discuss S5.2.1.1 first and get the definition of > Suppression right after that. > > > > Just to confirm what the current 5.2.1.1 is intended to mean: > > Suppression must stop new active measurement tasks from starting. > > The impact is undefined (left to the implementer /deployer) on other > things like passive measurement tasks and on-going active tasks. > > Suppression is intended to be temporary - if you want to stop all the > active tasks permanently, then it's suggested you send a new schedule [bu= t > I guess there's nothing to stop you 'abusing' suppression as a permanent > stop] > > > > 5.2.1.1 doesn't talk about the impact on Data Transfer Tasks. Not sure > we've discussed this. I suppose at the moment the implication is that Dat= a > Transfer Tasks (including reporting) continues to run. > > > > -- > > > > In terms of implementation, the way I thought about it is that the MA > would have a mini-firewall that would block all outgoing traffic > associated with a measurement task; there's at least some traffic it > mustn't block, such as capabilities & logging info sent in response to a > request from the controller. Is this easy to implement? > > I don't think the MA needs to understand any classification of differen= t > measurement tasks. However, the measurement system would probably like to > understand the impact of this mini-firewall function for non-obvious case= s > like a measurement task that simply modifies the header of end-user > traffic. > > > > -- > > > > > we can either introduce a classification of all measurement > > > tasks (where is this coming from?) or we could make this explicit > > > config (this way I know which tasks will be stopped if someone hits > the > > > button). > > I don't like classification. This is work, requires extra state in > controller and MA, and what happens if there's a classification mistake. > > Explicit config. This basically means 'send a new schedule' (actually m= y > personal view but not the consensus) > > > > Phil > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: 02 April 2014 06:56 > > > To: STARK, BARBARA H > > > Cc: Eardley,PL,Philip,TUB8 R; lmap@ietf.org > > > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- > > > framework-04.txt > > > > > > Barbara, > > > > > > I disagree. If I hit the supression button, I like to know what the > > > consequence of this is. Leaving this partially up to implementations > is > > > in my view the worst of all choices. Looking at the current ID, my > > > understanding is that a suppression without parameters suppresses a > > > certain set of measurement tasks, takes effect immediately, and > > > supression ends when the unsuppress button is hit. I assume the > > > suppress ongoing task bit defaults to false (but this is less clearly > > > spelled out). > > > > > > To define the set of measurement tasks that is affected if no set is > > > specified, we can either introduce a classification of all measuremen= t > > > tasks (where is this coming from?) or we could make this explicit > > > config (this way I know which tasks will be stopped if someone hits > the > > > button). Both could work for me. But, a definition of 'a certain set > of > > > measurement tasks plus additional tasks that are implementation > > > specific' is in my view not a desirable outcome. > > > > > > /js > > > > > > On Tue, Apr 01, 2014 at 06:34:00PM +0000, STARK, BARBARA H wrote: > > > > > > I agree with you that "Active" does not belong in the > definition. > > > > > > I disagree > > > > > that internal collection of passive measurements must cease, or > > > that > > > > > reporting must cease. They may cease in a particular > > > implementation, > > > > > but all implementations are not required to cause them to cease. > > > > > Only originated measurement traffic must cease. > > > > > > > > > > I am having a problem with 'may in some implementations'. This is > > > > > not interoperable. > > > > > > > > In my experience, it's impossible to define a function so thoroughl= y > > > that there are no unknowns about what it will do in a certain > > > situation, and no decisions left up to the implementer. > > > > > > > > But let's say hypothetically that all collection of passive > > > measurements *are* "stopped". We've defined internal measuring of CPU > > > utilization and memory resources and general device health checking a= s > > > "passive measurements". So this means they all have to stop. Firewall > > > logging is a passive measurement. It must stop. Link resource > > > utilization to be used in active queue management is a passive > > > measurement. It must stop. But why is it an interoperability "issue" > > > whether these passive measurement processes continue to run or not? I > > > really don't understand how they impact interoperability. > > > > > > > > As for reporting, we've defined sending log info (e.g. measurement > > > tasks successfully run, suppressed, etc.) to the Controller as a > > > report. Let's say we expect Suppression to stop all reports. That > means > > > it must not send the Controller any logs. > > > > > > > > Anyway, I was illustrating just a few examples of unknowns wrt > > > impacts of Suppression. There are many more unknowns. My proposed > > > definition of Suppression has no 'may' statements. > > > > > > > > Suppression: the cessation of measurement traffic originated by the > > > MA. > > > > > > > > If we wanted to explicitly say that suppression shall not impact > > > collection of passive measurements or reporting, I would be fine with > > > that, since I think that's the better design and I think it's easily > > > achieved. But others thought it would be complex to do and that it > > > would be simpler for them to "kill all measurement tasks". As long as > > > I'm not obliged to implement Suppression as "kill all tasks" I'm fine > > > with giving others the freedom to do so in their implementations. > > > > Barbara > > > > > > -- > > > 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 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Apr 2 06:21: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 2166D1A01D5 for ; Wed, 2 Apr 2014 06:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 t66iYjpcTHtS for ; Wed, 2 Apr 2014 06:21:29 -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 1A9BD1A01CE for ; Wed, 2 Apr 2014 06:21:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkKAJYNPFOHCzIm/2dsb2JhbABZgkIjITtXqkIMkUsZhzWBHhZ0gicBAQMSG14BDAkVViYBBBsBGYdXAQydSoRWrQEXjj+CZg9ngRQEn02LQoMwgis X-IronPort-AV: E=Sophos; i="4.97,780,1389762000"; d="scan'208,217"; a="56233573" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Apr 2014 09:21:24 -0400 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; 02 Apr 2014 09:07:02 -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; Wed, 2 Apr 2014 09:21:23 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: ietf-89 lmap draft minutes uploaded Thread-Index: Ac9OdnDgz9Nu7zQ/RgeJ3qGIo4FkCw== Date: Wed, 2 Apr 2014 13:21:22 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E46F116@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_9904FB1B0159DA42B0B887B7FA8119CA2E46F116AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Rzc02wOsvLUjeoaZLwQDn9teID4 Subject: [lmap] ietf-89 lmap draft minutes uploaded 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, 02 Apr 2014 13:21:33 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E46F116AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have uploaded the draft minutes of the IETF-89 LMAP meeting at http://www= .ietf.org/proceedings/89/minutes/minutes-89-lmap. Thanks to Barbara and Fro= de for the excellent notes. Please read and let me know if anything is miss= ing or inaccurate. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E46F116AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have uploaded the draft minutes of the IETF-89 LMA= P meeting at http= ://www.ietf.org/proceedings/89/minutes/minutes-89-lmap. Thanks to Barba= ra and Frode for the excellent notes. Please read and let me know if anythi= ng is missing or inaccurate.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E46F116AZFFEXMB04globa_-- From nobody Wed Apr 2 10:44: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 847FF1A0393; Wed, 2 Apr 2014 10:44:06 -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 MC6ClS6NjFSw; Wed, 2 Apr 2014 10:44:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D057E1A037B; Wed, 2 Apr 2014 10:43:58 -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.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140402174358.3678.31510.idtracker@ietfa.amsl.com> Date: Wed, 02 Apr 2014 10:43:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/nNHVUby1Eij9RMc93iPk24ANN7A Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-use-cases-03.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: Wed, 02 Apr 2014 17:44:06 -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 : Large-Scale Broadband Measurement Use Cases Authors : Marc Linsner Philip Eardley Trevor Burbridge Frode Sorensen Filename : draft-ietf-lmap-use-cases-03.txt Pages : 16 Date : 2014-04-02 Abstract: Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. Understanding the various scenarios and users of measuring broadband performance is essential to development of the framework, information model and protocol. This document details two use cases that can assist to developing that framework. The details of the measurement metrics themselves are beyond the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-use-cases-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-use-cases-03 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 Wed Apr 2 10:50: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 71D841A039C for ; Wed, 2 Apr 2014 10:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX3I8z6Sa8Gh for ; Wed, 2 Apr 2014 10:50:08 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 718721A039A for ; Wed, 2 Apr 2014 10:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2474; q=dns/txt; s=iport; t=1396461000; x=1397670600; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PHWAG2QhX/fhPQxXz+g3FjZnQ/X9ZKt14xwlVXog0zc=; b=XVVAM/XB2LoWi0vRIJ3LkudX6geygkb9FAO8bdFWUGymKHGARF3P9XFo DmhZ7RL3qQL5Bc+EEnAxkuku7ZvvQ0AQgc278jmXNEVCcFSoKQp3AfeUy /4XV48OQtr7FGjFVT5yW8wXF5b9rvBxNIO2wQg5CpJ7WG+xWKX3y1utgU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFACRNPFOtJA2K/2dsb2JhbABZgwY7UQa8Moc1gSAWdIIlAQEBBAEBATc0FwQCAQgRAwECHxAnCxsBAQUDAgQTCYdwCAXPKxeOdwaEMgSYVoEzkQaDMIIr X-IronPort-AV: E=Sophos;i="4.97,781,1389744000"; d="scan'208";a="32344676" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 02 Apr 2014 17:50:00 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s32Ho0Nl022661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Apr 2014 17:50:00 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.10]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 2 Apr 2014 12:50:00 -0500 From: "Marc Linsner (mlinsner)" To: "lmap@ietf.org" Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-use-cases-03.txt Thread-Index: AQHPTpsz3Y1dJh4yvUSQ+5Oyg3wIepr+q3oA Date: Wed, 2 Apr 2014 17:49:59 +0000 Message-ID: References: <20140402174358.3678.31510.idtracker@ietfa.amsl.com> In-Reply-To: <20140402174358.3678.31510.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.148.98] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/L7asA2XhY8JEkv_MDMG84B_r-u4 Subject: [lmap] FW: I-D Action: draft-ietf-lmap-use-cases-03.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 17:50:12 -0000 We submitted a new version containing suggestions/changes from the wglc. We believe that all comments are accounted for, but are asking for all to read and send comments to the list. We are also suggesting the chairs may start an abbreviated wglc to make sure we catch all concerns prior to sending to the IESG. Thanks, Marc, Philip, Frode, Trevor -----Original Message----- From: "internet-drafts@ietf.org" Date: Wednesday, April 2, 2014 at 1:43 PM To: "i-d-announce@ietf.org" Cc: "lmap@ietf.org" Subject: [lmap] I-D Action: draft-ietf-lmap-use-cases-03.txt > >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 : Large-Scale Broadband Measurement Use Cases > Authors : Marc Linsner > Philip Eardley > Trevor Burbridge > Frode Sorensen > Filename : draft-ietf-lmap-use-cases-03.txt > Pages : 16 > Date : 2014-04-02 > >Abstract: > Measuring broadband performance on a large scale is important for > network diagnostics by providers and users, as well as for public > policy. Understanding the various scenarios and users of measuring > broadband performance is essential to development of the framework, > information model and protocol. This document details two use cases > that can assist to developing that framework. The details of the > measurement metrics themselves are beyond the scope of this document. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-lmap-use-cases-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-use-cases-03 > > >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 From nobody Thu Apr 3 00:52: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 D773F1A0085 for ; Thu, 3 Apr 2014 00:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 YJoERvW9X1t6 for ; Thu, 3 Apr 2014 00:52:11 -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 6A6DF1A0021 for ; Thu, 3 Apr 2014 00:52:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0KAJISPVPGmAcV/2dsb2JhbABZgkIjITtXqkcBB5FVGYc1gRsWdIInAQEDEhteAQwJFVYmAQQbARmHVwEMnVWEVq04F44gAQEegmYPZ4EUBJ9Si0WDMIFyOQ X-IronPort-AV: E=Sophos; i="4.97,785,1389762000"; d="scan'208,217"; a="49090428" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Apr 2014 03:52:05 -0400 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; 03 Apr 2014 03:37:47 -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; Thu, 3 Apr 2014 09:52:04 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: 2nd WGLC for draft-ietf-lmap-use-cases Thread-Index: Ac9PEZliChVvYyknQcO2+vs+Z1Xmdw== Date: Thu, 3 Apr 2014 07:52:02 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E46FCBC@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E46FCBCAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/xgDpXLkX61SonywX6pjLOt1zCSE Subject: [lmap] 2nd WGLC for 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, 03 Apr 2014 07:52:16 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E46FCBCAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a 2nd WGLC for the LMAP Use Cases I-D. Please send your comments to= the WG mail list until Thursday 4/17. If you believe that the document is = ready for submission to the IESG as Informational RC a short message statin= g this will also be welcome. The document is available at http://www.ietf.org/id/draft-ietf-lmap-use-cas= es-03.txt . Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E46FCBCAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This is a 2nd WGLC for the LMAP Use Cases= I-D. Please send your comments to the WG mail list until Thursday 4/17. If= you believe that the document is ready for submission to the IESG as Infor= mational RC a short message stating this will also be welcome.

 

The document is available at http://www.ietf.org/id/draft-ietf-lmap-use-cases-03.txt .

 

Thanks and Regards,

 

Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E46FCBCAZFFEXMB04globa_-- From nobody Fri Apr 11 16:57: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 9F30C1A027D for ; Fri, 11 Apr 2014 16:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 g3echp3cbH3m for ; Fri, 11 Apr 2014 16:57:29 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 67A021A02D9 for ; Fri, 11 Apr 2014 16:57:29 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db11so5328604veb.21 for ; Fri, 11 Apr 2014 16:57:27 -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=LzJ2VmPxFq5h4AIYbtPIF0k7HfgoWd1kbUgtsNvtEAg=; b=v4mRoMWEuQbTwVhClwnpC+YUGfVph1WUZmXNohP7hptQYxv/0QnogTYXOm3KxB0ba2 +AFSOV0TdgNYh5VECRe7Hw3IjaLyylDHd7URaPM6EzV+RSaBFYLPodnVHiVpHWwxhjWS 4Ta8kjzwHRMnYUNb6QP6RLiqwR7zbjFaOR3W0l0SO5mBJq9uSGYpwGJoem6x2DQ0K599 ADAQMQMfURA4flVSHH30HhelkefavKbXJG4yCM24mqIOFw1cAoFGGPJoZ/aajFNnD4OA Eza4bAFD4HlENRXg7m5wNaIgn9wg+2dQq0SDsx9dcTGdaezy/eTfA0S4IjumLKhqxQCh Gklw== MIME-Version: 1.0 X-Received: by 10.220.162.6 with SMTP id t6mr22664828vcx.12.1397260647740; Fri, 11 Apr 2014 16:57:27 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Fri, 11 Apr 2014 16:57:27 -0700 (PDT) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> Date: Fri, 11 Apr 2014 16:57:27 -0700 Message-ID: From: Greg Mirsky To: draft-ietf-lmap-framework@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c214ec913a2004f6cd18ab Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/CCFxZnT--_UYIoBASHPsDmGO-E4 Cc: "lmap@ietf.org" Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 11 Apr 2014 23:57:33 -0000 --001a11c214ec913a2004f6cd18ab Content-Type: text/plain; charset=UTF-8 Dear Authors, et. al, please kindly consider my notes to the -04 version as WGLC comments below: - Section 2 - "The main work of the LMAP working group is to define the Control Protocol between the Controller and MA, and the Report Protocol between the MA and Collector." But the LMAP WG charter puts it differently: The LMAP working group is chartered to specify an information model, the associated data models, and select/extend one or more protocols for the secure communication: 1. 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, 2. A Report Protocol, for a Measurement Agent to report the results to the Collector. The data models should be extensible for new and additional measurements. LMAP will consider re-use of existing data models languages. As I read the charter, the LMAP WG defines informational models, not the protocols themselves. - "Measurement Tasks may be Active (the MA generates Active Measurement Traffic and measures some metric associated with its transfer), Passive (the MA observes user traffic), or some hybrid form of the two." Usually active and passive distinction being drawn at the level of measurement methods that is more generic than measurement task. And I think that term "Active Measurement Traffic" is ambiguous if you're trying to characterize test traffic. In addition, a performance metric may be not limited to only transfer of the test packets, but their processing as well. - "The MA is managed by a Controller using the Control Protocol." Perhaps "A Controller manages the MA through use of the Control Protocol." - "The MA receives Instructions from the Controller about which Measurement Tasks it should perform and when." I think that it is premature to be so specific about what information the MA would receive from its Controller. I can imagine that MA receives schedule with references to Measurement Methods that are in Performance Registry and necessary Measurement Task parameters. - s/The Measurement chedule/The Measurement schedule/ - "... or a Measurement Peer (or another Measurement Agent) sending Active Measurement Traffic to a MA." Does that imply that MP can generate test traffic without instructions from the Controller? Or this is to describe one-sided two-way active measurements when MP reflects or responds to test packets? - Section 3 "Active Measurement Method (Task)" should be split into two separate topics because Measurement Task is an instance of a Measurement Method. "Active Measurement Traffic" suggest to change to "Measurement Traffic" because there cannot be "Passive Measurement Traffic". "Capabilities: Information about the Measurement Methods that the MA can perform ..." is perhaps too specific without informational model of Control Protocol being finalized. Could we say "Capabilities: Information that characterizes performance measurement capabilities of the MA ... - Section 5.1 As a result of the bootstrapping process the MA learns the following information: That reads as part of MA informational model and probably not required in the LMAP Framework document. Can we delete the list? "... transferred via a protocol like TR-069" - needs reference - Section 5.2.1 "The Instruction defines the following:" list that follows is too specific for the framework document and may be more appropriate in specification of the informational model or control protocol itself. - Section 5.2.2 "Capabilities are information about the MA that the Controller needs to know in order to correctly instruct the MA, such as:" I think that the list that follows and "such as" are more in place in the informational model document or use "for example" clause. - Section 5.4 "The Report contains:' How about "The Report may contain:" then "perhaps" can be removed from the last bullet Regards, Greg On Wed, Apr 2, 2014 at 4:58 AM, Romascanu, Dan (Dan) wrote: > Hi, > > > > This is a 2nd WGLC for the LMAP Framework I-D. Please send your comments > to the WG mail list until Wednesday 4/16. If you believe that the document > is ready for submission to the IESG as Informational RC a short message > stating this will also be welcome. > > > > The document is available at > http://www.ietf.org/id/draft-ietf-lmap-framework-04.txt. > > > > Thanks and Regards, > > > > Dan > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > --001a11c214ec913a2004f6cd18ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors, et. al,
pl= ease kindly consider my notes to the -04 version as WGLC comments below:
  • Section 2
  • &q= uot;The main work of the LMAP working group is to define the Control Protocol between the Controller and MA, and the Report Protocol between the MA and Collector." But the LMAP WG charter puts it diff= erently:
The LMAP work= ing group is chartered to specify an information model, the associated data models, and select/extend one or more protocols for the secure communication:
1. A Control Protocol, from a Controller to instruct Measurement Agents=20 what performance metrics to measure, when to measure them, how/when to=20 report the measurement results to a Collector,
2. A Report Protocol, for a Measurement Agent to report the results to the = Collector.
The data models should be extensible for new and additional=20 measurements. LMAP will consider re-use of existing data models=20 languages.

As I read the chart= er, the LMAP WG defines informational models, not the protocols themselves.=

  • "Measurement Tas= ks may be Active (the MA generates Active Measurement Traffic and measures some metric associated with its transfer), Passive (the MA observes user traffic), or some hybrid form of the two."
Usually active= and passive distinction being drawn at the level of measurement methods th= at is more generic than measurement task. And I think that term "Activ= e Measurement Traffic" is ambiguous if you're trying to characteri= ze test traffic. In addition, a performance metric may be not limited to on= ly transfer of the test packets, but their processing as well.

  • "The MA is managed b= y a Controller using the Control Protocol."
Perhaps "A Controller manages the MA through use= of the Control Protocol."

  • "The MA receives Instructions from the Controller about which Measurement Tasks it should perform and when."
I think that it is premature to be so specific about what in= formation the MA would receive from its Controller. I can imagine that MA r= eceives schedule with references to Measurement Methods that are in Perform= ance Registry and necessary Measurement Task parameters.
  • s/The Measurement chedule/The= Measurement schedule/
  • "... or a Measurement Peer (or another Measurement Agent) sending Active Measurement Traffic to a MA."
Does that imply that MP can gen= erate test traffic without instructions from the Controller? Or this is to = describe one-sided two-way active measurements when MP reflects or responds= to test packets?
  • Section 3=C2=A0
&quo= t;Active Measurement Method (Task)" should be split into two separate = topics because Measurement Task is an instance of a Measurement Method.
=
"Active Measurement Traffic" suggest to change to "Measureme= nt Traffic" because there cannot be "Passive Measurement Traffic&= quot;.

"Capabilities: Information about the Measurement Methods= that the MA can perform ..." is perhaps too specific without informational mode= l of Control Protocol being finalized. Could we say "Capabilities: Inf= ormation that characterizes performance measurement capabilities of the MA = ...
  • Section 5.1
As a res= ult of the bootstrapping process the MA learns the following information:
That reads as part= of MA informational model and probably not required in the LMAP Framework = document. Can we delete the list?

"... transferred via a protoc= ol like TR-069" - needs reference
  • Section 5.2.1
= "The Instruction defines the following:"=C2=A0 list that follows = is too specific for the framework document and may be more appropriate in s= pecification of the informational model or control protocol itself.
  • Section 5.2.2
= "Capabilities are information about the MA that the Controller needs to know in order to correctly instruct the MA, such as:"
<= div style=3D"margin-left:40px">I think that the list that follows and "= ;such as" are more in place in the informational model document or use= "for example" clause.
  • Section 5.4
&q= uot;The Report contains:'
How = about "The Report may contain:" then "perhaps" can be r= emoved from the last bullet

Regards,
Greg


O= n Wed, Apr 2, 2014 at 4:58 AM, Romascanu, Dan (Dan) <<= a href=3D"mailto:dromasca@avaya.com" target=3D"_blank">dromasca@avaya.com> wrote:

Hi,

=C2=A0

This is a 2nd WGLC for the LMAP Framework= I-D. Please send your comments to the WG mail list until Wednesday 4/16. I= f you believe that the document is ready for submission to the IESG as Info= rmational RC a short message stating this will also be welcome.

=C2=A0

The document is available at http://www.ietf.org/id/draft-ietf-lmap-framework-04.txt. =

=C2=A0

Thanks and Regards,

=C2=A0

Dan

=C2=A0


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


--001a11c214ec913a2004f6cd18ab-- From nobody Mon Apr 14 02:13: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 93F4C1A0298 for ; Mon, 14 Apr 2014 02:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 rXMmNDzAxtPN for ; Mon, 14 Apr 2014 02:13:01 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id CDCA41A0106 for ; Mon, 14 Apr 2014 02:13:00 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 14 Apr 2014 10:10:51 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.149]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 14 Apr 2014 10:12:56 +0100 From: To: , Date: Mon, 14 Apr 2014 10:12:55 +0100 Thread-Topic: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) Thread-Index: Ac9Oata2Fqx14mW5RqyxeWUMKab+0gJVbadQ Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@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_A2E337CDB7BC4145B018B9BEE8EB3E0D40F368C866EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/4I4aabr9ZGDEcigPeBjfB5fCrNw Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 14 Apr 2014 09:13:04 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F368C866EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There's a slight inconsistency between the framework and info model docs. T= he info model has the idea of configuration information, as well as "pre-co= nfiguration" information. Pre-configuration maps to the "bootstrap process"= (S5.1) in the framework, but configuration is missing. This suggests that we should add a new protocol exchange to the framework, = something like: Section 5.2 Configuration protocol The Configuration Protocol allows the Controller to update the MA about inf= ormation that it obtained during the bootstrapping process: the MA-ID, the = (optional) Group-ID and the Control Channel. The measurement system might u= se Configuration for several reasons. For example, the bootstrapping proces= s could 'hard code' the MA with details of an initial Controller, and then = the initial Controller could configure the MA with details about the Contro= ller that sends Instruction Messages. Note that an implementation may choose to combine Configuration information= and an Instruction into a single message. Note also that the MA only has o= ne Control Channel (and so is associated with only one Controller) at any m= oment. +-----------------+ +-------------+ | | | Measurement | | Controller |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| Agent | +-----------------+ +-------------+ Configuration information: -> (MA-ID), (Group-ID), (Control Channel) <- Response(details) Hopefully this makes sense - I discussed this with the framework & info mod= el authors, who are ok with this change. Thanks phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 02 April 2014 12:58 To: lmap@ietf.org Subject: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-th= e-week) Hi, This is a 2nd WGLC for the LMAP Framework I-D. Please send your comments to= the WG mail list until Wednesday 4/16. If you believe that the document is= ready for submission to the IESG as Informational RC a short message stati= ng this will also be welcome. The document is available at http://www.ietf.org/id/draft-ietf-lmap-framewo= rk-04.txt. Thanks and Regards, Dan --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F368C866EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

There̵= 7;s a slight inconsistency between the framework and info model docs. The i= nfo model has the idea of configuration information, as well as “pre-= configuration” information. Pre-configuration maps to the “boot= strap process”  (S5.1) in the framework, but configuration is mi= ssing.

This suggests that we should add= a new protocol exchange to the framework, something like:

 

Section 5.2

Configuration protocol

The Configuration Protocol allows the Controller to update = the MA about information that it obtained during the bootstrapping process:= the MA-ID, the (optional) Group-ID and the Control Channel. The measuremen= t system might use Configuration for several reasons. For example, the boot= strapping process could ‘hard code’ the MA with details of an i= nitial Controller, and then the initial Controller could configure the MA w= ith details about the Controller that sends Instruction Messages.

Note that an implementation may choose to combin= e Configuration information and an Instruction into a single message. Note = also that the MA only has one Control Channel (and so is associated with on= ly one Controller) at any moment.

+-----------------+     &n= bsp;            = ;            &n= bsp;       +-------------+<= /p>

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

|  Controller     |=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D|  Agent      |

+-----------= ------+           &n= bsp;            = ;            &n= bsp; +-------------+

 

Configuration information:     = ;          ->

(MA-ID),

(Group-ID),=

(Co= ntrol Channel)

       &= nbsp;           &nbs= p;            &= nbsp;        <-   = ;       Response(details)

&nbs= p;

Hopefully this makes sense - I discussed this with the frame= work & info model authors, who are ok with this change.

<= p class=3DMsoNormal> 

Thanks

phil

 

= From: lmap [mailto:lmap-bounces@ietf.org] On Beh= alf Of Romascanu, Dan (Dan)
Sent: 02 April 2014 12:58
T= o: lmap@ietf.org
Subject: [lmap] 2nd WGLC for draft-ietf-lmap= -framework (corrected day-of-the-week)

 

Hi,

&= nbsp;

This is a 2nd WGLC for the LMAP Framework I-D. Please send your comments to t= he WG mail list until Wednesday 4/16. If you believe that the document is r= eady for submission to the IESG as Informational RC a short message stating= this will also be welcome.

 

The document is available at http://www.ietf.org/id/draft-ietf-lmap-frame= work-04.txt.

 

Tha= nks and Regards,

 

Dan<= o:p>

 

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F368C866EMV67UKRDdoma_-- From nobody Mon Apr 14 03:46: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 1DBF41A03D1 for ; Mon, 14 Apr 2014 03:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-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 Tcj6S5UaAy3U for ; Mon, 14 Apr 2014 03:46:20 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 921341A03CF for ; Mon, 14 Apr 2014 03:46:18 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 14 Apr 2014 11:46:18 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.149]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 14 Apr 2014 11:45:52 +0100 From: To: , Date: Mon, 14 Apr 2014 11:45:51 +0100 Thread-Topic: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) Thread-Index: Ac9V4dCpRtJccRNBRb6IRzHNJgQYWAB4FqnwAAAFqGA= Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/pzhO9waO7F7hygGqRjwj936rx2o Cc: lmap@ietf.org Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 14 Apr 2014 10:46:25 -0000 R3JlZw0KDQpUaGFuay15b3UgdmVyeSBtdWNoIGZvciB0aGUgY29tbWVudHMuDQpTb21lIGZvbGxv dy11cHMgaW4gbGluZQ0KDQpCZXN0IHdpc2hlcw0KcGhpbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBHcmVnIE1pcnNreQ0KPiBTZW50OiAxMiBBcHJpbCAyMDE0IDAwOjU3DQo+IFRv OiBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnDQo+IENjOiBsbWFwQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbG1hcF0gMm5kIFdHTEMgZm9yIGRyYWZ0LWlldGYtbG1h cC1mcmFtZXdvcmsgKGNvcnJlY3RlZA0KPiBkYXktb2YtdGhlLXdlZWspDQo+IA0KPiBEZWFyIEF1 dGhvcnMsIGV0LiBhbCwNCj4gcGxlYXNlIGtpbmRseSBjb25zaWRlciBteSBub3RlcyB0byB0aGUg LTA0IHZlcnNpb24gYXMgV0dMQyBjb21tZW50cw0KPiBiZWxvdzoNCj4g4oCiIFNlY3Rpb24gMg0K PiDigKIgIlRoZSBtYWluIHdvcmsgb2YgdGhlIExNQVAgd29ya2luZyBncm91cCBpcyB0byBkZWZp bmUgdGhlIENvbnRyb2wNCj4gUHJvdG9jb2wgYmV0d2VlbiB0aGUgQ29udHJvbGxlciBhbmQgTUEs IGFuZCB0aGUgUmVwb3J0IFByb3RvY29sIGJldHdlZW4NCj4gdGhlIE1BIGFuZCBDb2xsZWN0b3Iu IiBCdXQgdGhlIExNQVAgV0cgY2hhcnRlciBwdXRzIGl0IGRpZmZlcmVudGx5Og0KPiBUaGUgTE1B UCB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBzcGVjaWZ5IGFuIGluZm9ybWF0aW9uIG1v ZGVsLA0KPiB0aGUgYXNzb2NpYXRlZCBkYXRhIG1vZGVscywgYW5kIHNlbGVjdC9leHRlbmQgb25l IG9yIG1vcmUgcHJvdG9jb2xzIGZvcg0KPiB0aGUgc2VjdXJlIGNvbW11bmljYXRpb246DQo+IDEu IEEgQ29udHJvbCBQcm90b2NvbCwgZnJvbSBhIENvbnRyb2xsZXIgdG8gaW5zdHJ1Y3QgTWVhc3Vy ZW1lbnQgQWdlbnRzDQo+IHdoYXQgcGVyZm9ybWFuY2UgbWV0cmljcyB0byBtZWFzdXJlLCB3aGVu IHRvIG1lYXN1cmUgdGhlbSwgaG93L3doZW4gdG8NCj4gcmVwb3J0IHRoZSBtZWFzdXJlbWVudCBy ZXN1bHRzIHRvIGEgQ29sbGVjdG9yLCAyLiBBIFJlcG9ydCBQcm90b2NvbCwNCj4gZm9yIGEgTWVh c3VyZW1lbnQgQWdlbnQgdG8gcmVwb3J0IHRoZSByZXN1bHRzIHRvIHRoZSBDb2xsZWN0b3IuDQo+ IFRoZSBkYXRhIG1vZGVscyBzaG91bGQgYmUgZXh0ZW5zaWJsZSBmb3IgbmV3IGFuZCBhZGRpdGlv bmFsDQo+IG1lYXN1cmVtZW50cy4gTE1BUCB3aWxsIGNvbnNpZGVyIHJlLXVzZSBvZiBleGlzdGlu ZyBkYXRhIG1vZGVscw0KPiBsYW5ndWFnZXMuDQo+IEFzIEkgcmVhZCB0aGUgY2hhcnRlciwgdGhl IExNQVAgV0cgZGVmaW5lcyBpbmZvcm1hdGlvbmFsIG1vZGVscywgbm90DQo+IHRoZSBwcm90b2Nv bHMgdGhlbXNlbHZlcy4NCg0KW3BoaWxdIA0KSSB3aWxsIGluc2VydCBtZW50aW9uIG9mIEluZm9y bWF0aW9uIG1vZGVsIC0geW91J3JlIHJpZ2h0LCB0aGF0J3MgaW1wb3J0YW50IHdvcmsgaXRlbS4g DQoNClRoZSBDaGFydGVyIGdvZXMgb24gdG8gbGlzdCB0aGUgd29yayBpdGVtcywgaW5jbHVkaW5n Og0KPDw0LiBUaGUgQ29udHJvbCBwcm90b2NvbCBhbmQgdGhlIGFzc29jaWF0ZWQgZGF0YSBtb2Rl bDogVGhlIGRlZmluaXRpb24gb2YgaG93IGluc3RydWN0aW9ucyBhcmUgZGVsaXZlcmVkIGZyb20g YSBDb250cm9sbGVyIHRvIGEgTUE7IHRoaXMgaW5jbHVkZXMgYSBEYXRhIE1vZGVsIGNvbnNpc3Rl bnQgd2l0aCB0aGUgSW5mb3JtYXRpb24gTW9kZWwgcGx1cyBhIHRyYW5zcG9ydCBwcm90b2NvbC4g VGhpcyBtYXkgYmUgYSBzaW1wbGUgaW5zdHJ1Y3Rpb24gLSByZXNwb25zZSBwcm90b2NvbCwgYW5k IExNQVAgd2lsbCBzcGVjaWZ5IGhvdyBpdCBvcGVyYXRlcyBvdmVyIGFuIGV4aXN0aW5nIHByb3Rv Y29sICh0byBiZSBzZWxlY3RlZCwgcGVyaGFwcyBSRVNULXN0eWxlIEhUVFAocykgb3IgTkVUQ09O RikuDQogNS4gVGhlIFJlcG9ydCBwcm90b2NvbCBhbmQgdGhlIGFzc29jaWF0ZWQgZGF0YSBtb2Rl bDouLi4+Pg0KDQpJIHN1c3BlY3Qgd2UncmUgYWN0dWFsbHkgaW4gYWdyZWVtZW50IG9uIHRoZSBi YXNpYyBwb2ludCAtIHRoZSBwcm90b2NvbHMgd2lsbCBiZSBkZWZpbmVkIGFzIGV4dGVuc2lvbnMg L3JlLXVzZSBvZiBleGlzdGluZyBwcm90b2NvbChzKSAobm90IGEgY29tcGxldGVseSBuZXcgcHJv dG9jb2wpLg0KDQo+IA0KPiDigKIgIk1lYXN1cmVtZW50IFRhc2tzIG1heSBiZSBBY3RpdmUgKHRo ZSBNQSBnZW5lcmF0ZXMgQWN0aXZlIE1lYXN1cmVtZW50DQo+IFRyYWZmaWMgYW5kIG1lYXN1cmVz IHNvbWUgbWV0cmljIGFzc29jaWF0ZWQgd2l0aCBpdHMgdHJhbnNmZXIpLCBQYXNzaXZlDQo+ICh0 aGUgTUEgb2JzZXJ2ZXMgdXNlciB0cmFmZmljKSwgb3Igc29tZSBoeWJyaWQgZm9ybSBvZiB0aGUg dHdvLiINCj4gVXN1YWxseSBhY3RpdmUgYW5kIHBhc3NpdmUgZGlzdGluY3Rpb24gYmVpbmcgZHJh d24gYXQgdGhlIGxldmVsIG9mDQo+IG1lYXN1cmVtZW50IG1ldGhvZHMgdGhhdCBpcyBtb3JlIGdl bmVyaWMgdGhhbiBtZWFzdXJlbWVudCB0YXNrLiBBbmQgSQ0KPiB0aGluayB0aGF0IHRlcm0gIkFj dGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIiBpcyBhbWJpZ3VvdXMgaWYgeW91J3JlDQo+IHRyeWlu ZyB0byBjaGFyYWN0ZXJpemUgdGVzdCB0cmFmZmljLiBJbiBhZGRpdGlvbiwgYSBwZXJmb3JtYW5j ZSBtZXRyaWMNCj4gbWF5IGJlIG5vdCBsaW1pdGVkIHRvIG9ubHkgdHJhbnNmZXIgb2YgdGhlIHRl c3QgcGFja2V0cywgYnV0IHRoZWlyDQo+IHByb2Nlc3NpbmcgYXMgd2VsbC4NCg0KVGhpcyBpcyBv bmx5IHRoZSAzcmQgcGFyYSBvZiB0aGUgaW50cm9kdWN0b3J5IG91dGxpbmUgc2VjdGlvbiwgdG8g Z2l2ZSB0aGUgcmVhZGVyIHRoZSBpbXByZXNzaW9uIHdoYXQgbG1hcCBpcyBhYm91dC4gSSBkb27i gJl0IHRoaW5rIHdlIGhhdmUgdG8gaW5jbHVkZSBhbGwgdGhlIGRldGFpbHMgYW5kIHBvc3NpYmxl IHZhcmlhbnRzLCB3aGljaCBjb3VsZCBldmVuIGJlIGNvbmZ1c2luZyBhdCB0aGlzIGVhcmx5IHN0 YWdlLg0KSSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IHRoZSB0ZXJtICJBY3RpdmUgTWVhc3VyZW1l bnQgVHJhZmZpYyIgbWF5IGJlIGFtYmlndW91cy4NCg0KPiANCj4g4oCiICJUaGUgTUEgaXMgbWFu YWdlZCBieSBhIENvbnRyb2xsZXIgdXNpbmcgdGhlIENvbnRyb2wgUHJvdG9jb2wuIg0KPiBQZXJo YXBzICJBIENvbnRyb2xsZXIgbWFuYWdlcyB0aGUgTUEgdGhyb3VnaCB1c2Ugb2YgdGhlIENvbnRy b2wNCj4gUHJvdG9jb2wuIg0KPiDigKIgIlRoZSBNQSByZWNlaXZlcyBJbnN0cnVjdGlvbnMgZnJv bSB0aGUgQ29udHJvbGxlciBhYm91dCB3aGljaA0KPiBNZWFzdXJlbWVudCBUYXNrcyBpdCBzaG91 bGQgcGVyZm9ybSBhbmQgd2hlbi4iDQo+IEkgdGhpbmsgdGhhdCBpdCBpcyBwcmVtYXR1cmUgdG8g YmUgc28gc3BlY2lmaWMgYWJvdXQgd2hhdCBpbmZvcm1hdGlvbg0KPiB0aGUgTUEgd291bGQgcmVj ZWl2ZSBmcm9tIGl0cyBDb250cm9sbGVyLiBJIGNhbiBpbWFnaW5lIHRoYXQgTUENCj4gcmVjZWl2 ZXMgc2NoZWR1bGUgd2l0aCByZWZlcmVuY2VzIHRvIE1lYXN1cmVtZW50IE1ldGhvZHMgdGhhdCBh cmUgaW4NCj4gUGVyZm9ybWFuY2UgUmVnaXN0cnkgYW5kIG5lY2Vzc2FyeSBNZWFzdXJlbWVudCBU YXNrIHBhcmFtZXRlcnMuDQoNClllcywgdGhpcyBjb3VsZCBiZSBiZXR0ZXIgcGhyYXNlZC4gSG93 IGFib3V0Og0KDQpBIENvbnRyb2xsZXIgbWFuYWdlcyB0aGUgTUEgdGhyb3VnaCB1c2Ugb2YgdGhl IENvbnRyb2wgUHJvdG9jb2wuIEl0IHNlbmRzIGFuIEluc3RydWN0aW9uIE1lc3NhZ2UgdG8gdGhl IE1BLCB3aGljaCBkZXNjcmliZXMgdGhlIE1lYXN1cmVtZW50IFRhc2tzIGl0IHNob3VsZCBwZXJm b3JtIGFuZCB3aGVuLg0KDQo+IOKAoiBzL1RoZSBNZWFzdXJlbWVudCBjaGVkdWxlL1RoZSBNZWFz dXJlbWVudCBzY2hlZHVsZS8g4oCiICIuLi4gb3IgYQ0KPiBNZWFzdXJlbWVudCBQZWVyIChvciBh bm90aGVyIE1lYXN1cmVtZW50IEFnZW50KSBzZW5kaW5nIEFjdGl2ZQ0KPiBNZWFzdXJlbWVudCBU cmFmZmljIHRvIGEgTUEuIg0KPiBEb2VzIHRoYXQgaW1wbHkgdGhhdCBNUCBjYW4gZ2VuZXJhdGUg dGVzdCB0cmFmZmljIHdpdGhvdXQgaW5zdHJ1Y3Rpb25zDQo+IGZyb20gdGhlIENvbnRyb2xsZXI/ IE9yIHRoaXMgaXMgdG8gZGVzY3JpYmUgb25lLXNpZGVkIHR3by13YXkgYWN0aXZlDQo+IG1lYXN1 cmVtZW50cyB3aGVuIE1QIHJlZmxlY3RzIG9yIHJlc3BvbmRzIHRvIHRlc3QgcGFja2V0cz8NCg0K WWVzLCBNUCByZXNwb25kaW5nIHRvIHRlc3QgcGFja2V0KHMpIGZyb20gdGhlIE1BLiBpcyB0aGlz IHJlLXBocmFzZSBjbGVhcmVyPw0KDQo8PGFuZC9vciBhbm90aGVyIE1lYXN1cmVtZW50IEFnZW50 IChvciBhIE1lYXN1cmVtZW50IFBlZXIsIGluIHJlc3BvbnNlIHRvIHBhY2tldChzKSBmcm9tIGEg TUEpIHNlbmRpbmcgQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMgdG8gYSBNQT4+DQoNCg0KPiDi gKIgU2VjdGlvbiAzDQo+ICJBY3RpdmUgTWVhc3VyZW1lbnQgTWV0aG9kIChUYXNrKSIgc2hvdWxk IGJlIHNwbGl0IGludG8gdHdvIHNlcGFyYXRlDQo+IHRvcGljcyBiZWNhdXNlIE1lYXN1cmVtZW50 IFRhc2sgaXMgYW4gaW5zdGFuY2Ugb2YgYSBNZWFzdXJlbWVudCBNZXRob2QuDQoNCk9rDQoNCj4g DQo+ICJBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyIgc3VnZ2VzdCB0byBjaGFuZ2UgdG8gIk1l YXN1cmVtZW50IFRyYWZmaWMiDQo+IGJlY2F1c2UgdGhlcmUgY2Fubm90IGJlICJQYXNzaXZlIE1l YXN1cmVtZW50IFRyYWZmaWMiLg0KDQpJIHByZWZlciB0byBoYXZlIHRoZSByZW1pbmRlciB0aGF0 IGl0J3MgQWN0aXZlLiANCg0KPiANCj4gIkNhcGFiaWxpdGllczogSW5mb3JtYXRpb24gYWJvdXQg dGhlIE1lYXN1cmVtZW50IE1ldGhvZHMgdGhhdCB0aGUgTUENCj4gY2FuIHBlcmZvcm0gLi4uIiBp cyBwZXJoYXBzIHRvbyBzcGVjaWZpYyB3aXRob3V0IGluZm9ybWF0aW9uYWwgbW9kZWwgb2YNCj4g Q29udHJvbCBQcm90b2NvbCBiZWluZyBmaW5hbGl6ZWQuIENvdWxkIHdlIHNheSAiQ2FwYWJpbGl0 aWVzOg0KPiBJbmZvcm1hdGlvbiB0aGF0IGNoYXJhY3Rlcml6ZXMgcGVyZm9ybWFuY2UgbWVhc3Vy ZW1lbnQgY2FwYWJpbGl0aWVzIG9mDQo+IHRoZSBNQSAuLi4NCg0KSG93IGFib3V0Og0KQ2FwYWJp bGl0aWVzOiBJbmZvcm1hdGlvbiBhYm91dCB0aGUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgY2Fw YWJpbGl0aWVzIG9mIHRoZSBNQSwgaW4gcGFydGljdWxhciB0aGUgTWVhc3VyZW1lbnQgTWV0aG9k cyB0aGF0IGl0IGNhbiBwZXJmb3JtLCBhbmQgdGhlIGRldmljZSBob3N0aW5nIHRoZSBNQSwgZm9y IGV4YW1wbGUgaXRzIGludGVyZmFjZSB0eXBlIGFuZCBzcGVlZCwgYnV0IG5vdCBkeW5hbWljIGlu Zm9ybWF0aW9uLg0KDQo+IOKAoiBTZWN0aW9uIDUuMQ0KPiBBcyBhIHJlc3VsdCBvZiB0aGUgYm9v dHN0cmFwcGluZyBwcm9jZXNzIHRoZSBNQSBsZWFybnMgdGhlIGZvbGxvd2luZw0KPiBpbmZvcm1h dGlvbjoNCj4gVGhhdCByZWFkcyBhcyBwYXJ0IG9mIE1BIGluZm9ybWF0aW9uYWwgbW9kZWwgYW5k IHByb2JhYmx5IG5vdCByZXF1aXJlZA0KPiBpbiB0aGUgTE1BUCBGcmFtZXdvcmsgZG9jdW1lbnQu IENhbiB3ZSBkZWxldGUgdGhlIGxpc3Q/DQo+IA0KPiAiLi4uIHRyYW5zZmVycmVkIHZpYSBhIHBy b3RvY29sIGxpa2UgVFItMDY5IiAtIG5lZWRzIHJlZmVyZW5jZSANCg0KT2sNCg0K4oCiDQo+IFNl Y3Rpb24gNS4yLjEgIlRoZSBJbnN0cnVjdGlvbiBkZWZpbmVzIHRoZSBmb2xsb3dpbmc6IsKgIGxp c3QgdGhhdA0KPiBmb2xsb3dzIGlzIHRvbyBzcGVjaWZpYyBmb3IgdGhlIGZyYW1ld29yayBkb2N1 bWVudCBhbmQgbWF5IGJlIG1vcmUNCj4gYXBwcm9wcmlhdGUgaW4gc3BlY2lmaWNhdGlvbiBvZiB0 aGUgaW5mb3JtYXRpb25hbCBtb2RlbCBvciBjb250cm9sDQo+IHByb3RvY29sIGl0c2VsZi4NCj4g 4oCiIFNlY3Rpb24gNS4yLjINCj4gIkNhcGFiaWxpdGllcyBhcmUgaW5mb3JtYXRpb24gYWJvdXQg dGhlIE1BIHRoYXQgdGhlIENvbnRyb2xsZXIgbmVlZHMgdG8NCj4ga25vdyBpbiBvcmRlciB0byBj b3JyZWN0bHkgaW5zdHJ1Y3QgdGhlIE1BLCBzdWNoIGFzOiINCj4gSSB0aGluayB0aGF0IHRoZSBs aXN0IHRoYXQgZm9sbG93cyBhbmQgInN1Y2ggYXMiIGFyZSBtb3JlIGluIHBsYWNlIGluDQo+IHRo ZSBpbmZvcm1hdGlvbmFsIG1vZGVsIGRvY3VtZW50IG9yIHVzZSAiZm9yIGV4YW1wbGUiIGNsYXVz ZS4NCj4g4oCiIFNlY3Rpb24gNS40DQo+ICJUaGUgUmVwb3J0IGNvbnRhaW5zOicNCj4gSG93IGFi b3V0ICJUaGUgUmVwb3J0IG1heSBjb250YWluOiIgdGhlbiAicGVyaGFwcyIgY2FuIGJlIHJlbW92 ZWQgZnJvbQ0KPiB0aGUgbGFzdCBidWxsZXQgDQoNCkkgcmF0aGVyIGFncmVlIHdpdGggeW91ciBj b21tZW50cyBhYm91dCB0aGUgdmFyaW91cyBsaXN0cyBiZWluZyB0b28gc3BlY2lmaWMgZm9yIHRo ZSBmcmFtZXdvcmsuIFdpbGwgdGhpbmsgYWJvdXQuIA0KDQoNCg0KUmVnYXJkcywgR3JlZw0KPiAN Cj4gT24gV2VkLCBBcHIgMiwgMjAxNCBhdCA0OjU4IEFNLCBSb21hc2NhbnUsIERhbiAoRGFuKQ0K PiA8ZHJvbWFzY2FAYXZheWEuY29tPiB3cm90ZToNCj4gSGksDQo+IA0KPiBUaGlzIGlzIGEgMm5k IFdHTEMgZm9yIHRoZSBMTUFQIEZyYW1ld29yayBJLUQuIFBsZWFzZSBzZW5kIHlvdXINCj4gY29t bWVudHMgdG8gdGhlIFdHIG1haWwgbGlzdCB1bnRpbCBXZWRuZXNkYXkgNC8xNi4gSWYgeW91IGJl bGlldmUgdGhhdA0KPiB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHN1Ym1pc3Npb24gdG8gdGhl IElFU0cgYXMgSW5mb3JtYXRpb25hbCBSQyBhDQo+IHNob3J0IG1lc3NhZ2Ugc3RhdGluZyB0aGlz IHdpbGwgYWxzbyBiZSB3ZWxjb21lLg0KPiANCj4gVGhlIGRvY3VtZW50IGlzIGF2YWlsYWJsZSBh dCBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtbG1hcC0NCj4gZnJhbWV3b3JrLTA0 LnR4dC4NCj4gDQo+IFRoYW5rcyBhbmQgUmVnYXJkcywNCj4gDQo+IERhbg0KPiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGxtYXAgbWFp bGluZyBsaXN0DQo+IGxtYXBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sbWFwDQoNCg== From nobody Mon Apr 14 04:01: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 E2ECC1A02AF for ; Mon, 14 Apr 2014 04:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.878 X-Spam-Level: X-Spam-Status: No, score=0.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] 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 ciVxzftupMc7 for ; Mon, 14 Apr 2014 04:00:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id C67201A03CF for ; Mon, 14 Apr 2014 04:00: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 CE73B8B7; Mon, 14 Apr 2014 13:00:48 +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 MsuAgetQvlrd; Mon, 14 Apr 2014 13:00:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 14 Apr 2014 13:00:47 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BA0120017; Mon, 14 Apr 2014 13:00:47 +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 4jYyB-sq0DuJ; Mon, 14 Apr 2014 13:00:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19D3F20013; Mon, 14 Apr 2014 13:00:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C92B42C5EAB3; Mon, 14 Apr 2014 13:00:45 +0200 (CEST) Date: Mon, 14 Apr 2014 13:00:45 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20140414110045.GA7847@elstar.local> Mail-Followup-To: philip.eardley@bt.com, gregimirsky@gmail.com, draft-ietf-lmap-framework@tools.ietf.org, lmap@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/PfUloUN5JcPCB7d7bAzZPLvVx0Q Cc: gregimirsky@gmail.com, lmap@ietf.org, draft-ietf-lmap-framework@tools.ietf.org Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 14 Apr 2014 11:00:57 -0000 On Mon, Apr 14, 2014 at 11:45:51AM +0100, philip.eardley@bt.com wrote: > > • "The MA is managed by a Controller using the Control Protocol." > > Perhaps "A Controller manages the MA through use of the Control > > Protocol." > > • "The MA receives Instructions from the Controller about which > > Measurement Tasks it should perform and when." > > I think that it is premature to be so specific about what information > > the MA would receive from its Controller. I can imagine that MA > > receives schedule with references to Measurement Methods that are in > > Performance Registry and necessary Measurement Task parameters. > > Yes, this could be better phrased. How about: > > A Controller manages the MA through use of the Control Protocol. It sends an Instruction Message to the MA, which describes the Measurement Tasks it should perform and when. > Instruction Message is defined as the "message that carries an Instruction from a Controller to a Measurement Agent." As such, it should be plural: ... It sends Instruction Messages to the MA, ... Or even better, get rid of "Messages" since this does not matter at this level of abstraction. A Controller manages the MA through use of the Control Protocol. It sends Instructions to the MA, which describe the Measurement Tasks it should perform and when. /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 Apr 14 05:27: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 716161A0437 for ; Mon, 14 Apr 2014 05:27:19 -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 6quIEBBSgwUB for ; Mon, 14 Apr 2014 05:27:15 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id AECCC1A0402 for ; Mon, 14 Apr 2014 05:27:14 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 14 Apr 2014 13:25:04 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.149]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 14 Apr 2014 13:27:10 +0100 From: To: Date: Mon, 14 Apr 2014 13:27:09 +0100 Thread-Topic: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) Thread-Index: Ac9X0M52LlycRfUSQbajEhIZD/6oHwAC8/Ew Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> <20140414110045.GA7847@elstar.local> In-Reply-To: <20140414110045.GA7847@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/cSyebqd4tHfwFeeX0EtGuzrl5WE Cc: gregimirsky@gmail.com, lmap@ietf.org, draft-ietf-lmap-framework@tools.ietf.org Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 14 Apr 2014 12:27:19 -0000 V2ZtLCB3aXRoIHRoZSBkZWx0YSB0aGF0IHRoZSBJbnN0cnVjdGlvbiBpcyBzaW5ndWxhciAoaXQg aXMgdGhlIGNvbGxlY3Rpb24gb2YgaW5mbyBhYm91dCBUYXNrcyB0byBwZXJmb3JtIGV0YykNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLQ0KPiB1bml2ZXJzaXR5LmRlXQ0KPiBT ZW50OiAxNCBBcHJpbCAyMDE0IDEyOjAxDQo+IFRvOiBFYXJkbGV5LFBMLFBoaWxpcCxUVUI4IFIN Cj4gQ2M6IGdyZWdpbWlyc2t5QGdtYWlsLmNvbTsgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29ya0B0 b29scy5pZXRmLm9yZzsNCj4gbG1hcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2xtYXBdIDJu ZCBXR0xDIGZvciBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrIChjb3JyZWN0ZWQNCj4gZGF5LW9m LXRoZS13ZWVrKQ0KPiANCj4gT24gTW9uLCBBcHIgMTQsIDIwMTQgYXQgMTE6NDU6NTFBTSArMDEw MCwgcGhpbGlwLmVhcmRsZXlAYnQuY29tIHdyb3RlOg0KPiA+ID4g4oCiICJUaGUgTUEgaXMgbWFu YWdlZCBieSBhIENvbnRyb2xsZXIgdXNpbmcgdGhlIENvbnRyb2wgUHJvdG9jb2wuIg0KPiA+ID4g UGVyaGFwcyAiQSBDb250cm9sbGVyIG1hbmFnZXMgdGhlIE1BIHRocm91Z2ggdXNlIG9mIHRoZSBD b250cm9sDQo+ID4gPiBQcm90b2NvbC4iDQo+ID4gPiDigKIgIlRoZSBNQSByZWNlaXZlcyBJbnN0 cnVjdGlvbnMgZnJvbSB0aGUgQ29udHJvbGxlciBhYm91dCB3aGljaA0KPiA+ID4gTWVhc3VyZW1l bnQgVGFza3MgaXQgc2hvdWxkIHBlcmZvcm0gYW5kIHdoZW4uIg0KPiA+ID4gSSB0aGluayB0aGF0 IGl0IGlzIHByZW1hdHVyZSB0byBiZSBzbyBzcGVjaWZpYyBhYm91dCB3aGF0DQo+ID4gPiBpbmZv cm1hdGlvbiB0aGUgTUEgd291bGQgcmVjZWl2ZSBmcm9tIGl0cyBDb250cm9sbGVyLiBJIGNhbiBp bWFnaW5lDQo+ID4gPiB0aGF0IE1BIHJlY2VpdmVzIHNjaGVkdWxlIHdpdGggcmVmZXJlbmNlcyB0 byBNZWFzdXJlbWVudCBNZXRob2RzDQo+ID4gPiB0aGF0IGFyZSBpbiBQZXJmb3JtYW5jZSBSZWdp c3RyeSBhbmQgbmVjZXNzYXJ5IE1lYXN1cmVtZW50IFRhc2sNCj4gcGFyYW1ldGVycy4NCj4gPg0K PiA+IFllcywgdGhpcyBjb3VsZCBiZSBiZXR0ZXIgcGhyYXNlZC4gSG93IGFib3V0Og0KPiA+DQo+ ID4gQSBDb250cm9sbGVyIG1hbmFnZXMgdGhlIE1BIHRocm91Z2ggdXNlIG9mIHRoZSBDb250cm9s IFByb3RvY29sLiBJdA0KPiBzZW5kcyBhbiBJbnN0cnVjdGlvbiBNZXNzYWdlIHRvIHRoZSBNQSwg d2hpY2ggZGVzY3JpYmVzIHRoZSBNZWFzdXJlbWVudA0KPiBUYXNrcyBpdCBzaG91bGQgcGVyZm9y bSBhbmQgd2hlbi4NCj4gPg0KPiANCj4gSW5zdHJ1Y3Rpb24gTWVzc2FnZSBpcyBkZWZpbmVkIGFz IHRoZSAibWVzc2FnZSB0aGF0IGNhcnJpZXMgYW4NCj4gSW5zdHJ1Y3Rpb24gZnJvbSBhIENvbnRy b2xsZXIgdG8gYSBNZWFzdXJlbWVudCBBZ2VudC4iIEFzIHN1Y2gsIGl0DQo+IHNob3VsZCBiZSBw bHVyYWw6IC4uLiBJdCBzZW5kcyBJbnN0cnVjdGlvbiBNZXNzYWdlcyB0byB0aGUgTUEsIC4uLg0K PiBPciBldmVuIGJldHRlciwgZ2V0IHJpZCBvZiAiTWVzc2FnZXMiIHNpbmNlIHRoaXMgZG9lcyBu b3QgbWF0dGVyIGF0DQo+IHRoaXMgbGV2ZWwgb2YgYWJzdHJhY3Rpb24uDQo+IA0KPiAgIEEgQ29u dHJvbGxlciBtYW5hZ2VzIHRoZSBNQSB0aHJvdWdoIHVzZSBvZiB0aGUgQ29udHJvbCBQcm90b2Nv bC4gSXQNCj4gICBzZW5kcyBJbnN0cnVjdGlvbnMgdG8gdGhlIE1BLCB3aGljaCBkZXNjcmliZSB0 aGUgTWVhc3VyZW1lbnQgVGFza3MNCj4gICBpdCBzaG91bGQgcGVyZm9ybSBhbmQgd2hlbi4NCj4g DQo+IC9qcw0KPiANCj4gLS0NCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNv YnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAg ICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0 MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo= From nobody Mon Apr 14 07:19: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 C49091A011A for ; Mon, 14 Apr 2014 07:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 G-RsL4m-Em4S for ; Mon, 14 Apr 2014 07:19:17 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id A03471A02F5 for ; Mon, 14 Apr 2014 07:19:16 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 14 Apr 2014 15:19:14 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.149]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Mon, 14 Apr 2014 15:19:12 +0100 From: To: , Date: Mon, 14 Apr 2014 15:19:10 +0100 Thread-Topic: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) Thread-Index: Ac9Oata2Fqx14mW5RqyxeWUMKab+0gJcsx5A Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@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_A2E337CDB7BC4145B018B9BEE8EB3E0D40F368C9ECEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/w5y_gBDaemssrHIYZWzhsvZ8Nig Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 14 Apr 2014 14:19:20 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F368C9ECEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Several of Greg's comments on Section 5 were on the lines "the list that fo= llows is too specific for the framework document and may be more appropriat= e in specification of the informational model" I agree with this. In particular, the relationship between the different it= ems seems much more appropriate for the information model i-d. For example,= things like "a name for this Measurement Task configuration" seem more app= ropriate for the info model i-d - the "name" stuff really explains how the = different information elements link together, and it seems better to define= this once (in the info model). However, we need a certain level of detail= in the framework, in order to show what lmap is doing. So, we could introduce the list of the bullets with a comment something lik= e:- This is the list of the aims about the types of information in the Instruct= ion. It is not a list of information elements (these will be defined in dra= ft-ietf-information-model). In London, we agreed to add the stuff about Data Transfer Tasks, which appe= ar in -04. For consistency with the split between Measurement Schedules, Ta= sks and Methods, we should have a similar split between Data Transfer Sched= ules, Tasks and Methods. Side-note: Section 2 (Outline of lmap) should also mention the Data Transfe= r stuff. -- So we might end up with something like:- As a result of the bootstrapping process the MA learns information with the= following aims ([draft-ietf-information-model] defines the consequent list= of information elements): o its identifier, MA-ID o (optionally) a Group-ID. A Group-ID would be shared by several MAs and could be useful for privacy reasons. For instance, reporting = the Group-ID and not the MA-ID could hinder tracking of a mobile device o the Control Channel, which is defined by: * the address of the Controller (such as its FQDN (Fully Qualified Domain Name) [RFC1035]) * security information (for example to enable the MA to decrypt the Instruction Message and encrypt messages sent to the Controller) ... The Instruction defines information with the following aims ([draft-ietf-in= formation-model] defines the consequent list of information elements): o the Measurement Task configurations, each of which needs: * the Measurement Method, specified as a URN to a registry entry. The registry could be defined by the IETF [I-D.manyfolks-ippm-metric-registry], locally= by the operator of the measurement system or perhaps by another standards organisation. * any Input Parameters that need to be set for the Measurement Method, such as the address of the Measurement Peer (or other Measurement Agent) that are involved in an Active Measurement Task * if the device with the MA has multiple interfaces, then the interface to use (if not defined, then the default interface is used) o configuration of the Measurement Schedules, each of which needs: * the timing of when the Measurement Tasks are to be performed. Possible types of timing are periodic, calendar-based periodic, one-off immediate and one-off at a future time o configuration of the Report Channels, each of which needs: * the address of the Collector, for instance its URL * security for this Report Channel, for example the X.509 certificate o configuration of the Data Transfer Tasks, each of which needs: * the Data Transfer Method, and any information it needs about Input= Parameters or interface selection o configuration of the Data Transfer Schedules, each of which needs: * the timing of when the Data Transfer Tasks are to be performed. A Data Transfer Task may concern the reporting of Measurement Results (when the timing could be every hour or immediately, for instance). Alternatively, a Data Transfer Task may concern the MA informing the Controller about its Capabilities or any Failures. o Suppression information, if any (see Section 5.2.1.1) do you think this gets the balance better between what should appear in the= framework vs in the information model? thanks, phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 02 April 2014 12:58 To: lmap@ietf.org Subject: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-th= e-week) Hi, This is a 2nd WGLC for the LMAP Framework I-D. Please send your comments to= the WG mail list until Wednesday 4/16. If you believe that the document is= ready for submission to the IESG as Informational RC a short message stati= ng this will also be welcome. The document is available at http://www.ietf.org/id/draft-ietf-lmap-framewo= rk-04.txt. Thanks and Regards, Dan --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F368C9ECEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Several of Greg’s comments= on Section 5 were on the lines “the list that follows is too specifi= c for the framework document and may be more appropriate in specification o= f the informational model”

=  

I agre= e with this. In particular, the relationship between the different items se= ems much more appropriate for the information model i-d. For example, thing= s like "a name for this Measurement Task configuration" seem more= appropriate for the info model i-d - the “name” stuff really e= xplains how the different information elements link together, and it seems = better to define this once (in the info model).  However, we need a ce= rtain level of detail in the framework, in order to show what lmap is doing= .

 

So, we could introduce the list of t= he bullets with a comment something like:-

This is the list of the ai= ms about the types of information in the Instruction. It is not a list of i= nformation elements (these will be defined in draft-ietf-information-model)= .

 

In London, we agreed to add the stuff= about Data Transfer Tasks, which appear in -04. For consistency with the s= plit between Measurement Schedules, Tasks and Methods, we should have a sim= ilar split between Data Transfer Schedules, Tasks and Methods.

 

Side-note: Section 2 (Outli= ne of lmap) should also mention the Data Transfer stuff.<= /p>

 

--

 

So we might end up with something like:-=

 

As a result of th=
e bootstrapping process the MA learns information with the following aims ([draft-ietf-information-model] defi=
nes the consequent list of information elements):
 
   o  its identifier, MA-ID
 
   o =
; (optionally) a Group-ID.  A Group-ID would be shared by several=

      MAs and could be =
useful for privacy reasons. For instance, reporting the Group-ID and not th=
e MA-ID could hinder tracking of a mobile device
 
=
   o  the Control=
 Channel, which is defined by:
 
      *  the address=
 of the Controller (such as its FQDN (Fully
=
         Qualified Domain Name) [RF=
C1035])
 <=
/pre>
      *  security information (f=
or example to enable the MA to decrypt
 =
;        the Instruction Message and enc=
rypt messages sent to the
   =
      Controller)     &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
     
 <=
/span>
...
The Instruction de=
fines information with the followin=
g aims ([draft-ietf-information-model] defines the consequent list of infor=
mation elements):
 
   =
o  the Measurement Task configurations, each of which needs:
 
  &nb=
sp;   *  the Measurement Method, specified as a URN to a reg=
istry entry.
     &=
nbsp;   The registry could be defined by the IETF
         [I-D.manyfolks-ipp=
m-metric-registry], locally by the operator
         of the measurem=
ent system or perhaps by another standards
&=
nbsp;        organisation.
 
   &=
nbsp;  *  any Input Parameters that need to be set for the Measur=
ement
      &n=
bsp;  Method, such as the address of the Measurement Peer (or other
       &nbs=
p; Measurement Agent) that are involved in an Active Measurement=

         Task=

 
&n=
bsp;     *  if the device with the MA has multiple=
 interfaces, then the
   &nbs=
p;     interface to use (if not defined, then the defau=
lt interface is
    &nbs=
p;    used)
 =

   o  configuration of the Measurement=
 Schedules, each of which needs:
 =

      *  the timin=
g of when the Measurement Tasks are to be performed.
         Possible types of=
 timing are periodic, calendar-based periodic,
         one-off immediate and o=
ne-off at a future time
 
   o  configuration of the Report Channels=
, each of which needs:
 
      *  the address of the =
Collector, for instance its URL
 <=
/o:p>
      *  security f=
or this Report Channel, for example the X.509
         certificate
 
   o&nbs=
p; configuration of the Data Transfer Tasks, each of which needs:
 
  &nb=
sp;   *  the Data Transfer Method, and any information it ne=
eds about Input Parameters or interface selection 
<=
pre style=3D'page-break-before:always'> 
   o  configuration of the Data Transfer Schedul=
es, each of which needs:
 
   =
   *  the timing of when the Data Transfer Tasks are to be p=
erformed.
 
      A Data Transfer Task may concern the rep=
orting of Measurement
   &nbs=
p;  Results (when the timing could be every hour or immediately, for
      instance).&nbs=
p; Alternatively, a Data Transfer Task may concern the MA=

      informing the Controller about=
 its Capabilities or any Failures.
&nbs=
p;
   o  Suppression information, =
if any (see Section 5.2.1.1)
 
thanks,
phil
<=
p class=3DMsoNormal> 
 
 
 
<=
div>
From: lmap [mailto:lmap-bounces@=
ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: 02 April=
 2014 12:58
To: lmap@ietf.org
Subject: [lmap] 2nd WGLC =
for draft-ietf-lmap-framework (corrected day-of-the-week)=

 
Hi,=

 
This is a 2nd WGLC for the LMAP Framework I-D. Please send=
 your comments to the WG mail list until Wednesday 4/16. If you believe tha=
t the document is ready for submission to the IESG as Informational RC a sh=
ort message stating this will also be welcome. 
 
The document is a=
vailable at http://www.ietf.org/id/draft-ietf-lma=
p-framework-04.txt. 
<=
span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New"'> 
Thanks and Regards,
 
=
Dan=

 
<= /div>= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F368C9ECEMV67UKRDdoma_-- From nobody Mon Apr 14 07:50:28 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61BD1A04A3 for ; Mon, 14 Apr 2014 07:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.773 X-Spam-Level: X-Spam-Status: No, score=-101.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 NEo4v1o84Rqh for ; Mon, 14 Apr 2014 07:50:21 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD121A0489 for ; Mon, 14 Apr 2014 07:50:18 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7D1FC8B6FA1 for ; Mon, 14 Apr 2014 16:50:14 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 715FA76B3DB for ; Mon, 14 Apr 2014 16:50:14 +0200 (CEST) Received: from bdv75-2-81-57-250-123.fbx.proxad.net (bdv75-2-81-57-250-123.fbx.proxad.net [81.57.250.123]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Mon, 14 Apr 2014 16:50:14 +0200 Message-ID: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 16:50:14 +0200 From: MARCELO BAGNULO BRAUN To: lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Mon, 14 Apr 2014 16:50:14 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.000 X-TM-AS-Result: No--2.496-7.0-31-1 X-imss-scan-details: No--2.496-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/iLicA5qwjML2wZ_K29G-rq7q-ZM Subject: [lmap] lmap framework and IPPM registries. 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, 14 Apr 2014 14:50:27 -0000 Hi, One issue i realized is that the current lmap framework states the the measurement method is specified as a URN to a registry entry, while the current IPPM registry draft do not have a URN as metric identifier but a name and a metric identifier. I think it is very important that these two efforts are aligned so i suggest that we discuss whether a URN is the proper way to go or the current flat identifier proposed in the ippm registry drafts. I am uncertain what is the benefit of an URN versus a flat identifier. Regards, marcelo -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Mon Apr 14 10:58: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 D4AD51A01F8 for ; Mon, 14 Apr 2014 10:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] 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 0hgTyY-IanYR for ; Mon, 14 Apr 2014 10:57:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3391A01FC for ; Mon, 14 Apr 2014 10:57: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 1FDB8ABA; Mon, 14 Apr 2014 19:57:52 +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 LBZl8tEfbaZo; Mon, 14 Apr 2014 19:57:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 14 Apr 2014 19:57:51 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F23B20017; Mon, 14 Apr 2014 19:57:51 +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 wZ20xOOtIEDT; Mon, 14 Apr 2014 19:57:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44C6B20013; Mon, 14 Apr 2014 19:57:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 05AFE2C5F973; Mon, 14 Apr 2014 19:57:47 +0200 (CEST) Date: Mon, 14 Apr 2014 19:57:47 +0200 From: Juergen Schoenwaelder To: MARCELO BAGNULO BRAUN Message-ID: <20140414175747.GA8673@elstar.local> Mail-Followup-To: MARCELO BAGNULO BRAUN , lmap@ietf.org References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/WxZh9SvETeZxB4FDCQfleYkybCI Cc: lmap@ietf.org Subject: Re: [lmap] lmap framework and IPPM registries. 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, 14 Apr 2014 17:58:01 -0000 On Mon, Apr 14, 2014 at 04:50:14PM +0200, MARCELO BAGNULO BRAUN wrote: > Hi, > > One issue i realized is that the current lmap framework states the > the measurement method is specified as a URN to a registry entry, > while the current IPPM registry draft do not have a URN as metric > identifier but a name and a metric identifier. So according to IPPM, which one is the "native" unique thing to refer to, the name or the metric identifier (a 16-bit number if I understand right)? > I think it is very important that these two efforts are aligned so i > suggest that we discuss whether a URN is the proper way to go or the > current flat identifier proposed in the ippm registry drafts. > > I am uncertain what is the benefit of an URN versus a flat > identifier. Regards, marcelo It should be a URI. Standard metrics can have their own URN space, e.g., derived from their unique "thing" (the name or the metric, I can't tell). Or IPPM even makes their native "identifier" simply a URN. Making this reference a URI within LMAP makes things easily extensible without requiring to go through a central registry or to work with potential clashes in number spaces reserved for private use. Using URIs also seems rather natural in a web-based world. /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 Apr 14 11:41: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 619C51A06CE for ; Mon, 14 Apr 2014 11:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.473 X-Spam-Level: X-Spam-Status: No, score=-104.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 5aH2IA9QjZk8 for ; Mon, 14 Apr 2014 11:41:13 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7641A06AC for ; Mon, 14 Apr 2014 11:41:13 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 08301CD72ED; Mon, 14 Apr 2014 20:41:10 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id EECF9CD72E6; Mon, 14 Apr 2014 20:41:09 +0200 (CEST) Received: from bdv75-2-81-57-250-123.fbx.proxad.net (bdv75-2-81-57-250-123.fbx.proxad.net [81.57.250.123]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Mon, 14 Apr 2014 20:41:09 +0200 Message-ID: <20140414204109.3p5s75qggoc4scc8@webcartero01.uc3m.es> Date: Mon, 14 Apr 2014 20:41:09 +0200 From: MARCELO BAGNULO BRAUN To: Juergen Schoenwaelder References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <20140414175747.GA8673@elstar.local> In-Reply-To: <20140414175747.GA8673@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Mon, 14 Apr 2014 20:41:09 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20632.001 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/MEvdalQthrJv8jruDvnfN_YpPVo Cc: lmap@ietf.org Subject: Re: [lmap] lmap framework and IPPM registries. 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, 14 Apr 2014 18:41:18 -0000 Juergen Schoenwaelder dijo: > On Mon, Apr 14, 2014 at 04:50:14PM +0200, MARCELO BAGNULO BRAUN wrote: >> Hi, >> >> One issue i realized is that the current lmap framework states the >> the measurement method is specified as a URN to a registry entry, >> while the current IPPM registry draft do not have a URN as metric >> identifier but a name and a metric identifier. > > So according to IPPM, which one is the "native" unique thing to refer > to, the name or the metric identifier (a 16-bit number if I understand > right)? the identifier is the unique identifier metrics names should be unique, but not must be > >> I think it is very important that these two efforts are aligned so i >> suggest that we discuss whether a URN is the proper way to go or the >> current flat identifier proposed in the ippm registry drafts. >> >> I am uncertain what is the benefit of an URN versus a flat >> identifier. Regards, marcelo > > It should be a URI. > > Standard metrics can have their own URN space, e.g., derived from > their unique "thing" (the name or the metric, I can't tell). Or IPPM > even makes their native "identifier" simply a URN. Making this > reference a URI within LMAP makes things easily extensible without > requiring to go through a central registry or to work with potential > clashes in number spaces reserved for private use. Using URIs also > seems rather natural in a web-based world. > It is perfectrly possible to reserve a range of identifiers for private use so a manager of a measurement domain can locally assign values for metrics without going through the registry. I still dont understand how does the IANA manages a well know set of metric identifiers using URN/URIs. I am not saying this is not feasible, just that i fail to understand it yet. Regards, marcelo > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Tue Apr 15 07:28: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 DC03C1A049D for ; Tue, 15 Apr 2014 07:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 zVJkichKWPQM for ; Tue, 15 Apr 2014 07:28:11 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9752F1A0310 for ; Tue, 15 Apr 2014 07:28:11 -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 s3FES5Vg016595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2014 08:28:06 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 7263F1E006C; Tue, 15 Apr 2014 09:28:00 -0500 (CDT) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 4C4EF1E0059; Tue, 15 Apr 2014 09:28:00 -0500 (CDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s3FERxg1011434; Tue, 15 Apr 2014 09:27:59 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s3FERxaX011411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Apr 2014 09:27:59 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Tue, 15 Apr 2014 09:27:59 -0500 From: "Bugenhagen, Michael K" To: "'MARCELO BAGNULO BRAUN'" , "'Juergen Schoenwaelder'" Thread-Topic: [lmap] lmap framework and IPPM registries. Thread-Index: AQHPV/EOB5WK3snlxk28YEUSrOuMq5sRugWAgAAMHoCAAPYfwA== Date: Tue, 15 Apr 2014 14:27:58 +0000 Message-ID: References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <20140414175747.GA8673@elstar.local> <20140414204109.3p5s75qggoc4scc8@webcartero01.uc3m.es> In-Reply-To: <20140414204109.3p5s75qggoc4scc8@webcartero01.uc3m.es> 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/gN98swDPKQPF30HRiHMwL-8h09w Cc: "'MORTON, ALFRED C \(AL\)'" , "'lmap@ietf.org'" Subject: Re: [lmap] lmap framework and IPPM registries. 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, 15 Apr 2014 14:28:16 -0000 Marcelo, Juergen, Al Just for clarity - and my making sure I'm tracking this correctly - and= we're all on the same page - The tests conducted by most of the regulators (the one's they are reporting= ) are modifications of the standard testing methods. i.e. - the Throughput test results use a delay window or stability window t= o negate the influence of "burst" or buffering - and report the stable thro= ughput after x seconds, or y seconds of stability. Question - Given the Registry method we've described requires a Standard t= est MIB to become a registry entry Assumption - Does it follow that we need to write a standalone test standar= d (RFC) for each unique test method... I think this is true, if not please correct me. At the moment we have very few tests that use that modified method, which i= nfers we have more work to do on the IPPM side with new test RFC's? Thanks, Mike =09 =20 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MARCELO BAGNULO BRAU= N Sent: Monday, April 14, 2014 1:41 PM To: Juergen Schoenwaelder Cc: lmap@ietf.org Subject: Re: [lmap] lmap framework and IPPM registries. Juergen Schoenwaelder dijo: > On Mon, Apr 14, 2014 at 04:50:14PM +0200, MARCELO BAGNULO BRAUN wrote: >> Hi, >> >> One issue i realized is that the current lmap framework states the=20 >> the measurement method is specified as a URN to a registry entry,=20 >> while the current IPPM registry draft do not have a URN as metric=20 >> identifier but a name and a metric identifier. > > So according to IPPM, which one is the "native" unique thing to refer=20 > to, the name or the metric identifier (a 16-bit number if I understand=20 > right)? the identifier is the unique identifier metrics names should be unique, but not must be > >> I think it is very important that these two efforts are aligned so i=20 >> suggest that we discuss whether a URN is the proper way to go or the=20 >> current flat identifier proposed in the ippm registry drafts. >> >> I am uncertain what is the benefit of an URN versus a flat=20 >> identifier. Regards, marcelo > > It should be a URI. > > Standard metrics can have their own URN space, e.g., derived from=20 > their unique "thing" (the name or the metric, I can't tell). Or IPPM=20 > even makes their native "identifier" simply a URN. Making this=20 > reference a URI within LMAP makes things easily extensible without=20 > requiring to go through a central registry or to work with potential=20 > clashes in number spaces reserved for private use. Using URIs also=20 > seems rather natural in a web-based world. > It is perfectrly possible to reserve a range of identifiers for private use= so a manager of a measurement domain can locally assign values for metrics= without going through the registry. I still dont understand how does the IANA manages a well know set of metric= identifiers using URN/URIs. I am not saying this is not feasible, just tha= t i fail to understand it yet. Regards, marcelo > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Apr 15 07: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 CF8E71A077C for ; Tue, 15 Apr 2014 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 eaOXhVRlWR1F for ; Tue, 15 Apr 2014 07:45:18 -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 A87801A069B for ; Tue, 15 Apr 2014 07:45:18 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 646371207E6; Tue, 15 Apr 2014 10:45:17 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id CCFC0F026E; Tue, 15 Apr 2014 10:45:15 -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; Tue, 15 Apr 2014 10:45:15 -0400 From: "MORTON, ALFRED C (AL)" To: "Bugenhagen, Michael K" , 'MARCELO BAGNULO BRAUN' , 'Juergen Schoenwaelder' Date: Tue, 15 Apr 2014 10:45:13 -0400 Thread-Topic: [lmap] lmap framework and IPPM registries. Thread-Index: AQHPV/EOB5WK3snlxk28YEUSrOuMq5sRugWAgAAMHoCAAPYfwIAAA0kA Message-ID: <2845723087023D4CB5114223779FA9C8017944A468@njfpsrvexg8.research.att.com> References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <20140414175747.GA8673@elstar.local> <20140414204109.3p5s75qggoc4scc8@webcartero01.uc3m.es> 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/QZ9B1jTDiMSgA8YV9iNBjTkRujo Cc: "'lmap@ietf.org'" Subject: Re: [lmap] lmap framework and IPPM registries. 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, 15 Apr 2014 14:45:26 -0000 Mike, I won't be able to expand on details with you, but see my reply below: > -----Original Message----- > From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com] > Sent: Tuesday, April 15, 2014 10:28 AM ... >=20 > Marcelo, Juergen, Al >=20 > Just for clarity - and my making sure I'm tracking this correctly - > and we're all on the same page - >=20 We are not, we have yet to achieve that state in many cases,=20 unfortunately. >=20 > The tests conducted by most of the regulators (the one's they are > reporting) are modifications of the standard testing methods. > i.e. - the Throughput test results use a delay window or stability window > to negate the influence of "burst" or buffering - and report the stable > throughput after x seconds, or y seconds of stability. Real bad example, because IPPM does not yet have a solid metric and method = RFC for Throughput or Capacity. Work is in-progress here, of course. >=20 > Question - Given the Registry method we've described requires a Standard > test MIB to become a registry entry > Assumption - Does it follow that we need to write a standalone test > standard (RFC) for each unique test method... >=20 > I think this is true, if not please correct me. We considered this possibility, but practicality caused us to choose the alternative where one or more existing RFCs are references for a Registered= Metric, and the registry entry itself MUST provide all the details to specify the m= etric=20 and methods *exactly*, without ambiguity. So, not true about lots of new RFCs. We simply don't see this happening to support the registry - there's barely enough review energy to get the=20 the registry design memos adopted and to consensus. This is clearly overhe= ad work and though essential to LMAP, not exciting =3D=3D few volunteers. Some RFCs are needed (Throughput) and many very good Registry Entries are n= eeded. Al >=20 > At the moment we have very few tests that use that modified method, which > infers we have more work to do on the IPPM side with new test RFC's? >=20 > Thanks, > Mike >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MARCELO BAGNULO > BRAUN > Sent: Monday, April 14, 2014 1:41 PM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] lmap framework and IPPM registries. >=20 > Juergen Schoenwaelder dijo: >=20 > > On Mon, Apr 14, 2014 at 04:50:14PM +0200, MARCELO BAGNULO BRAUN wrote: > >> Hi, > >> > >> One issue i realized is that the current lmap framework states the > >> the measurement method is specified as a URN to a registry entry, > >> while the current IPPM registry draft do not have a URN as metric > >> identifier but a name and a metric identifier. > > > > So according to IPPM, which one is the "native" unique thing to refer > > to, the name or the metric identifier (a 16-bit number if I understand > > right)? >=20 > the identifier is the unique identifier >=20 > metrics names should be unique, but not must be >=20 >=20 > > > >> I think it is very important that these two efforts are aligned so i > >> suggest that we discuss whether a URN is the proper way to go or the > >> current flat identifier proposed in the ippm registry drafts. > >> > >> I am uncertain what is the benefit of an URN versus a flat > >> identifier. Regards, marcelo > > > > It should be a URI. > > > > Standard metrics can have their own URN space, e.g., derived from > > their unique "thing" (the name or the metric, I can't tell). Or IPPM > > even makes their native "identifier" simply a URN. Making this > > reference a URI within LMAP makes things easily extensible without > > requiring to go through a central registry or to work with potential > > clashes in number spaces reserved for private use. Using URIs also > > seems rather natural in a web-based world. > > >=20 > It is perfectrly possible to reserve a range of identifiers for private > use so a manager of a measurement domain can locally assign values for > metrics without going through the registry. >=20 > I still dont understand how does the IANA manages a well know set of > metric identifiers using URN/URIs. I am not saying this is not feasible, > just that i fail to understand it yet. >=20 > Regards, marcelo >=20 >=20 >=20 > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > >=20 >=20 >=20 > -- > ---- > MARCELO BAGNULO BRAUN > WebCartero > Universidad Carlos III de Madrid >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Apr 15 07:55: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 2F5AC1A03E5 for ; Tue, 15 Apr 2014 07:55:46 -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 BOb-xwPPDOLA for ; Tue, 15 Apr 2014 07:55:44 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id E3BCF1A02CB for ; Tue, 15 Apr 2014 07:55:43 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s3FEtcc5001254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2014 09:55:38 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id D95A21E0086; Tue, 15 Apr 2014 08:55:32 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id A208D1E0076; Tue, 15 Apr 2014 08:55:32 -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 s3FEtVbP022385; Tue, 15 Apr 2014 09:55:31 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s3FEtUAt022281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Apr 2014 09:55:30 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Tue, 15 Apr 2014 09:55:29 -0500 From: "Bugenhagen, Michael K" To: "'MORTON, ALFRED C (AL)'" , "'MARCELO BAGNULO BRAUN'" , "'Juergen Schoenwaelder'" Thread-Topic: [lmap] lmap framework and IPPM registries. Thread-Index: AQHPV/EOB5WK3snlxk28YEUSrOuMq5sRugWAgAAMHoCAAPYfwIAAA0kAgAAEyAA= Date: Tue, 15 Apr 2014 14:55:28 +0000 Message-ID: References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <20140414175747.GA8673@elstar.local> <20140414204109.3p5s75qggoc4scc8@webcartero01.uc3m.es> <2845723087023D4CB5114223779FA9C8017944A468@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017944A468@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/O3CkDhlxg6FqcoYft210XOBN1M8 Cc: "'lmap@ietf.org'" Subject: Re: [lmap] lmap framework and IPPM registries. 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, 15 Apr 2014 14:55:46 -0000 Al -=20 Thanks! =20 In the BBF meeting we were discussing how to move forward with documenting = the tests for some of the U.S. based tests that are currently being reporte= d so we had some apples to apples reference tests. We agreed that going through the IETF IPPM / registry group was the way = to go- so I wanted to make sure what that process might look like. I thought it would require new RFC work for defining a special test without= ambiguity.... as you indicate. So we'll point anyone wanting to standardize tests to the IPPM - Excellen= t. BTW - The BBF has some WT-143 broadband tests already defined on throughput= testing, I'll discuss getting those converted to RFC's with the original e= ditors of those tests.. that seems a logical first step. Cheers, Mike=20 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Tuesday, April 15, 2014 9:45 AM To: Bugenhagen, Michael K; 'MARCELO BAGNULO BRAUN'; 'Juergen Schoenwaelder' Cc: 'lmap@ietf.org' Subject: Re: [lmap] lmap framework and IPPM registries. Mike, I won't be able to expand on details with you, but see my reply belo= w: > -----Original Message----- > From: Bugenhagen, Michael K=20 > [mailto:Michael.K.Bugenhagen@centurylink.com] > Sent: Tuesday, April 15, 2014 10:28 AM ... >=20 > Marcelo, Juergen, Al >=20 > Just for clarity - and my making sure I'm tracking this correctly=20 > - and we're all on the same page - >=20 We are not, we have yet to achieve that state in many cases, unfortunately. >=20 > The tests conducted by most of the regulators (the one's they are > reporting) are modifications of the standard testing methods. > i.e. - the Throughput test results use a delay window or stability window > to negate the influence of "burst" or buffering - and report the stable > throughput after x seconds, or y seconds of stability. Real bad example, because IPPM does not yet have a solid metric and method = RFC for Throughput or Capacity. Work is in-progress here, of course. >=20 > Question - Given the Registry method we've described requires a Standard > test MIB to become a registry entry > Assumption - Does it follow that we need to write a standalone test > standard (RFC) for each unique test method... >=20 > I think this is true, if not please correct me. We considered this possibility, but practicality caused us to choose the alternative where one or more existing RFCs are references for a Registered= Metric, and the registry entry itself MUST provide all the details to specify the m= etric=20 and methods *exactly*, without ambiguity. So, not true about lots of new RFCs. We simply don't see this happening to support the registry - there's barely enough review energy to get the=20 the registry design memos adopted and to consensus. This is clearly overhe= ad work and though essential to LMAP, not exciting =3D=3D few volunteers. Some RFCs are needed (Throughput) and many very good Registry Entries are n= eeded. Al >=20 > At the moment we have very few tests that use that modified method, which > infers we have more work to do on the IPPM side with new test RFC's? >=20 > Thanks, > Mike >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MARCELO BAGNULO > BRAUN > Sent: Monday, April 14, 2014 1:41 PM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] lmap framework and IPPM registries. >=20 > Juergen Schoenwaelder dijo: >=20 > > On Mon, Apr 14, 2014 at 04:50:14PM +0200, MARCELO BAGNULO BRAUN wrote: > >> Hi, > >> > >> One issue i realized is that the current lmap framework states the > >> the measurement method is specified as a URN to a registry entry, > >> while the current IPPM registry draft do not have a URN as metric > >> identifier but a name and a metric identifier. > > > > So according to IPPM, which one is the "native" unique thing to refer > > to, the name or the metric identifier (a 16-bit number if I understand > > right)? >=20 > the identifier is the unique identifier >=20 > metrics names should be unique, but not must be >=20 >=20 > > > >> I think it is very important that these two efforts are aligned so i > >> suggest that we discuss whether a URN is the proper way to go or the > >> current flat identifier proposed in the ippm registry drafts. > >> > >> I am uncertain what is the benefit of an URN versus a flat > >> identifier. Regards, marcelo > > > > It should be a URI. > > > > Standard metrics can have their own URN space, e.g., derived from > > their unique "thing" (the name or the metric, I can't tell). Or IPPM > > even makes their native "identifier" simply a URN. Making this > > reference a URI within LMAP makes things easily extensible without > > requiring to go through a central registry or to work with potential > > clashes in number spaces reserved for private use. Using URIs also > > seems rather natural in a web-based world. > > >=20 > It is perfectrly possible to reserve a range of identifiers for private > use so a manager of a measurement domain can locally assign values for > metrics without going through the registry. >=20 > I still dont understand how does the IANA manages a well know set of > metric identifiers using URN/URIs. I am not saying this is not feasible, > just that i fail to understand it yet. >=20 > Regards, marcelo >=20 >=20 >=20 > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > >=20 >=20 >=20 > -- > ---- > MARCELO BAGNULO BRAUN > WebCartero > Universidad Carlos III de Madrid >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Apr 15 09:03: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 BA4E31A07BA for ; Tue, 15 Apr 2014 09:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 XyJ-lBjSxSgW for ; Tue, 15 Apr 2014 09:03:28 -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 93CEE1A0783 for ; Tue, 15 Apr 2014 09:03:28 -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 8A956554831; Tue, 15 Apr 2014 12:03:27 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id 48BE2E01E6; Tue, 15 Apr 2014 12:03:25 -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; Tue, 15 Apr 2014 12:03:25 -0400 From: "MORTON, ALFRED C (AL)" To: "Bugenhagen, Michael K" , 'MARCELO BAGNULO BRAUN' , 'Juergen Schoenwaelder' Date: Tue, 15 Apr 2014 12:03:25 -0400 Thread-Topic: [lmap] lmap framework and IPPM registries. Thread-Index: AQHPV/EOB5WK3snlxk28YEUSrOuMq5sRugWAgAAMHoCAAPYfwIAAA0kAgAAEyACAABFfQA== Message-ID: <2845723087023D4CB5114223779FA9C8017944A4AF@njfpsrvexg8.research.att.com> References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <20140414175747.GA8673@elstar.local> <20140414204109.3p5s75qggoc4scc8@webcartero01.uc3m.es> <2845723087023D4CB5114223779FA9C8017944A468@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ATNR5jf1Dd0aTN_D9OeJkinMp_A Cc: "'lmap@ietf.org'" Subject: Re: [lmap] lmap framework and IPPM registries. 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, 15 Apr 2014 16:03:45 -0000 Mike, > -----Original Message----- > From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com] ... >=20 > So we'll point anyone wanting to standardize tests to the IPPM - > Excellent. They should start by reviewing http://tools.ietf.org/html/draft-ietf-ippm-registry-active-00 and the core registry memo it references. (This is what I asked at the last IPPM session, that future *users* of the registry, those preparing entries, implementing metrics and methods, or both, should see if what we have designed will be sufficient for their needs. >=20 > BTW - The BBF has some WT-143 broadband tests already defined on > throughput testing, I'll discuss getting those converted to RFC's with th= e > original editors of those tests.. that seems a logical first step. > There is an Informational RFC on TCP Throughput testing (not a std metric) http://tools.ietf.org/html/rfc6349 Diagnostic throughput testing is useful, but again this is=20 work-already-in-progress in IPPM. I doubt anything will be rubber-stamped. Al From nobody Tue Apr 15 13:14: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 CD3C21A04A3 for ; Tue, 15 Apr 2014 13:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 qgiNOH8yPsTB for ; Tue, 15 Apr 2014 13:14:20 -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 EA64B1A049C for ; Tue, 15 Apr 2014 13:14:19 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 226C81206B7; Tue, 15 Apr 2014 16:14:19 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-azure.research.att.com (Postfix) with ESMTP id D962CE01E9; Tue, 15 Apr 2014 16:14:16 -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; Tue, 15 Apr 2014 16:14:16 -0400 From: "MORTON, ALFRED C (AL)" To: MARCELO BAGNULO BRAUN , "lmap@ietf.org" Date: Tue, 15 Apr 2014 16:14:15 -0400 Thread-Topic: [lmap] lmap framework and IPPM registries. Thread-Index: Ac9X8Oh5VL/RVt88QY+/g/MJr+rMCgA5XEBw Message-ID: <2845723087023D4CB5114223779FA9C8017944A577@njfpsrvexg8.research.att.com> References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> In-Reply-To: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> 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/SVq6KAImZFqapE4Efj2Zakaoh7o Subject: Re: [lmap] lmap framework and IPPM registries. 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, 15 Apr 2014 20:14:22 -0000 For me and those whose needs I understand, a URI for metrics seems useful. I would guess that IANA has already been asked for some form of ID persistence, and if they agree to provide when re= quested,=20 then it would be a (new) requirement in the IANA section. Also, we need both a metric and a method of measurement, these are both present in our current version of the metric registry. >From Framework 5.2.1 Instruction o the Measurement Task configurations, each of which needs: * the Measurement Method, specified as a URN to a registry entry. The registry could be defined by the IETF [I-D.manyfolks-ippm-metric-registry], locally by the operator of the measurement system or perhaps by another standards organisation. So let's fix this as follows: o the Measurement Task configurations, each of which needs: * the Registered Metric, specified as a URI to a registry entry, and which includes the specification of a Measurement Method. The registry could be defined by the IETF [I-D.manyfolks-ippm-metric-registry], locally by the operator of the measurement system or perhaps by another standards organisation. (off-list discussion contributed to this suggestion),=20 Al Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MARCELO BAGNULO > BRAUN > Sent: Monday, April 14, 2014 10:50 AM > To: lmap@ietf.org > Subject: [lmap] lmap framework and IPPM registries. >=20 > Hi, >=20 > One issue i realized is that the current lmap framework states the the > measurement method is specified as a URN to a registry entry, while the > current IPPM registry draft do not have a URN as metric identifier but > a name and a metric identifier. >=20 > I think it is very important that these two efforts are aligned so i > suggest that we discuss whether a URN is the proper way to go or the > current flat identifier proposed in the ippm registry drafts. >=20 > I am uncertain what is the benefit of an URN versus a flat identifier. > Regards, marcelo >=20 >=20 > -- > ---- > MARCELO BAGNULO BRAUN > WebCartero > Universidad Carlos III de Madrid >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Apr 15 13:16: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 9A6DD1A04A8 for ; Tue, 15 Apr 2014 13:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 Y9Oa4w7Jd9vu for ; Tue, 15 Apr 2014 13:16:04 -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 3BD421A04A3 for ; Tue, 15 Apr 2014 13:16:04 -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 92B521206C3; Tue, 15 Apr 2014 16:16:03 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id AEB45E01E6; Tue, 15 Apr 2014 16:16:00 -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; Tue, 15 Apr 2014 16:16:01 -0400 From: "MORTON, ALFRED C (AL)" To: MARCELO BAGNULO BRAUN , "lmap@ietf.org" Date: Tue, 15 Apr 2014 16:16:00 -0400 Thread-Topic: [lmap] lmap framework and IPPM registries. Thread-Index: Ac9X8Oh5VL/RVt88QY+/g/MJr+rMCgA5XEBwAAQ+P1A= Message-ID: <2845723087023D4CB5114223779FA9C8017944A57A@njfpsrvexg8.research.att.com> References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> 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/I4P3lXIloe2ZnGKsEnyfOkD4G2A Subject: Re: [lmap] lmap framework and IPPM registries. 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, 15 Apr 2014 20:16:08 -0000 it seems (from digging around) that this text with URN first appeared in=20 Framework 03, and possibly was suggested by Trevor since the Info model uses URNs extensively. > -----Original Message----- > From: MORTON, ALFRED C (AL) > Sent: Tuesday, April 15, 2014 4:14 PM > To: 'MARCELO BAGNULO BRAUN'; lmap@ietf.org > Subject: RE: [lmap] lmap framework and IPPM registries. >=20 > For me and those whose needs I understand, > a URI for metrics seems useful. I would guess that IANA has already been > asked for some form of ID persistence, and if they agree to provide when > requested, > then it would be a (new) requirement in the IANA section. >=20 > Also, we need both a metric and a method of measurement, these are > both present in our current version of the metric registry. >=20 > From Framework 5.2.1 Instruction >=20 > o the Measurement Task configurations, each of which needs: >=20 > * the Measurement Method, specified as a URN to a registry entry. > The registry could be defined by the IETF > [I-D.manyfolks-ippm-metric-registry], locally by the operator > of the measurement system or perhaps by another standards > organisation. >=20 > So let's fix this as follows: >=20 > o the Measurement Task configurations, each of which needs: >=20 > * the Registered Metric, specified as a URI to a registry entry, > and which includes the specification of a Measurement Method. > The registry could be defined by the IETF > [I-D.manyfolks-ippm-metric-registry], locally by the operator > of the measurement system or perhaps by another standards > organisation. >=20 > (off-list discussion contributed to this suggestion), > Al >=20 >=20 > Al >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MARCELO BAGNULO > > BRAUN > > Sent: Monday, April 14, 2014 10:50 AM > > To: lmap@ietf.org > > Subject: [lmap] lmap framework and IPPM registries. > > > > Hi, > > > > One issue i realized is that the current lmap framework states the the > > measurement method is specified as a URN to a registry entry, while the > > current IPPM registry draft do not have a URN as metric identifier but > > a name and a metric identifier. > > > > I think it is very important that these two efforts are aligned so i > > suggest that we discuss whether a URN is the proper way to go or the > > current flat identifier proposed in the ippm registry drafts. > > > > I am uncertain what is the benefit of an URN versus a flat identifier. > > Regards, marcelo > > > > > > -- > > ---- > > MARCELO BAGNULO BRAUN > > WebCartero > > Universidad Carlos III de Madrid > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Apr 15 14:34: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 BD7641A06A6 for ; Tue, 15 Apr 2014 14:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.473 X-Spam-Level: X-Spam-Status: No, score=-104.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 cxx1a5cQYGL8 for ; Tue, 15 Apr 2014 14:34:40 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0740D1A0503 for ; Tue, 15 Apr 2014 14:34:40 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9B6978AD78D; Tue, 15 Apr 2014 23:34:36 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 8C660766CB3; Tue, 15 Apr 2014 23:34:36 +0200 (CEST) Received: from bdv75-2-81-57-250-123.fbx.proxad.net (bdv75-2-81-57-250-123.fbx.proxad.net [81.57.250.123]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Tue, 15 Apr 2014 23:34:36 +0200 Message-ID: <20140415233436.sfay4k84j4s4w8o0@webcartero01.uc3m.es> Date: Tue, 15 Apr 2014 23:34:36 +0200 From: MARCELO BAGNULO BRAUN To: "MORTON, ALFRED C (AL)" References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <2845723087023D4CB5114223779FA9C8017944A577@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017944A577@njfpsrvexg8.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Tue, 15 Apr 2014 23:34:36 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20634.002 X-TM-AS-Result: No--16.718-7.0-31-1 X-imss-scan-details: No--16.718-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/UweI-hGdgdjp6GXEmjXXbg6RKGo Cc: "lmap@ietf.org" Subject: Re: [lmap] lmap framework and IPPM registries. 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, 15 Apr 2014 21:34:44 -0000 So, the question I have is whether IANA can handle URI allocations. I dont know the answer to this question. If they can, then i think we are ok. If they cant, i think we have a problem. Let me expand. I understnad that we want the controller to be able to tell the MA using the lmap protocol(s) to execute a measurement task using a given metric X. Metric X can be a locally defined metric or it can be a well know metric registered in the IANA registry. The reason for having registered metrics is so that for instace if an isp buys a CPE that is implementing an lmap MA, it can also be implementing a set of well defined metrics registered in the IANA registry for performance metrics. If that is the case, then we can have a CPE that off the shelf can be integrated into an lmap measurement system and the controller can use the lmap protocol so that the MA can execute well know metric X. So, the lmap control protocol will need to carry a metric identifer to identify the metric that the controller is asking the MA to use. This identifier must be registered in the iana registry for performance metrics (for the case of the well known metrics). Now, i know how to ask iana to create a registry for performance metrics and include a metric identifier field in the registry that can be used in the control protocol to identify the different metrics. What i dont know is whether the metric identifier in the iana registry can be an URI. That i understand would imply that iana would be able to hand over identifiers that would look like something like this: http://www.iana.org/ietf/ippm/metrics/37897 or http://www.iana.org/ietf/ippm/metrics/udp_latency_95th_mean If iana can handle this, then we are ok. If iana doesnt do this, then we have a problem because we wouldnt be able to create the registry for well known metrics that is compatible with lmap. Anyone knows if iana has done this before? Can you provide a pointer? I apologize in advance if this is obvious. Regards, marcelo "MORTON, ALFRED C (AL)" dijo: > For me and those whose needs I understand, > a URI for metrics seems useful. I would guess that IANA has already been > asked for some form of ID persistence, and if they agree to provide > when requested, > then it would be a (new) requirement in the IANA section. > > Also, we need both a metric and a method of measurement, these are > both present in our current version of the metric registry. > >> From Framework 5.2.1 Instruction > > o the Measurement Task configurations, each of which needs: > > * the Measurement Method, specified as a URN to a registry entry. > The registry could be defined by the IETF > [I-D.manyfolks-ippm-metric-registry], locally by the operator > of the measurement system or perhaps by another standards > organisation. > > So let's fix this as follows: > > o the Measurement Task configurations, each of which needs: > > * the Registered Metric, specified as a URI to a registry entry, > and which includes the specification of a Measurement Method. > The registry could be defined by the IETF > [I-D.manyfolks-ippm-metric-registry], locally by the operator > of the measurement system or perhaps by another standards > organisation. > > (off-list discussion contributed to this suggestion), > Al > > > Al > >> -----Original Message----- >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MARCELO BAGNULO >> BRAUN >> Sent: Monday, April 14, 2014 10:50 AM >> To: lmap@ietf.org >> Subject: [lmap] lmap framework and IPPM registries. >> >> Hi, >> >> One issue i realized is that the current lmap framework states the the >> measurement method is specified as a URN to a registry entry, while the >> current IPPM registry draft do not have a URN as metric identifier but >> a name and a metric identifier. >> >> I think it is very important that these two efforts are aligned so i >> suggest that we discuss whether a URN is the proper way to go or the >> current flat identifier proposed in the ippm registry drafts. >> >> I am uncertain what is the benefit of an URN versus a flat identifier. >> Regards, marcelo >> >> >> -- >> ---- >> MARCELO BAGNULO BRAUN >> WebCartero >> Universidad Carlos III de Madrid >> >> _______________________________________________ >> 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 > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nobody Tue Apr 15 22:29: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 4E49E1A0027 for ; Tue, 15 Apr 2014 22:29:12 -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 4YtZnkoTmoKs for ; Tue, 15 Apr 2014 22:29:09 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id D90F61A001C for ; Tue, 15 Apr 2014 22:29:08 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so10016653veb.41 for ; Tue, 15 Apr 2014 22:29:05 -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=SluAgEiieiqgPE5N1BQZ1bSKgEK2UiDR1Te6Uqjwng0=; b=ryE4M9oyWYIqGJ6bwU8a71d4SJOpWNO+kmslLqks5gQ46FJp8hPMgk8q069l3zbM/9 IgrjRhQ47a4Y2qZ/OOq2KrbqLv8qo+fl9qQJBZJrjI7aaOIe2/WyXezaiZo0v4/IW2SK nxIEuhAPJDUJIDNTZfe1wWQazNto0g3qYnAtAPeQa7T6kNFnGvwN21tl24BJA+LiwIGR LIDuPvWma9JfC5ux9tg4DOlDdR3g0+UPDFMwN8gu4k6PC+vR4AW0qhgUBJvJRseN4wSW WOuRqSbl7kjASH/xeEe6al6usUrcOe9pJ8nPJcC5KtRkVE2/N6jZhztCLdyaF/VaGaP7 i/QA== MIME-Version: 1.0 X-Received: by 10.52.183.228 with SMTP id ep4mr181157vdc.30.1397626145507; Tue, 15 Apr 2014 22:29:05 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Tue, 15 Apr 2014 22:29:05 -0700 (PDT) In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> Date: Tue, 15 Apr 2014 22:29:05 -0700 Message-ID: From: Greg Mirsky To: philip.eardley@bt.com Content-Type: multipart/alternative; boundary=bcaec547ca39ee911304f7223198 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/4EurJr3-AQitPagC1lmBgK4_H9Q Cc: "lmap@ietf.org" , draft-ietf-lmap-framework@tools.ietf.org Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 16 Apr 2014 05:29:12 -0000 --bcaec547ca39ee911304f7223198 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Phil, thank you for your kind consideration of my comments. I've clipped ones we've agreed on already. Please find couple follow ups in-lined and tagged by GIM>>. Regards, Greg On Mon, Apr 14, 2014 at 3:45 AM, wrote: > Greg > > Thank-you very much for the comments. > Some follow-ups in line > > Best wishes > phil > [...] > > > I suspect we're actually in agreement on the basic point - the protocols > will be defined as extensions /re-use of existing protocol(s) (not a > completely new protocol). > GIM>> Yes, agree. It might be good to state that in the framework document explicitly. > > > > > =E2=80=A2 "Measurement Tasks may be Active (the MA generates Active Mea= surement > > Traffic and measures some metric associated with its transfer), Passive > > (the MA observes user traffic), or some hybrid form of the two." > > Usually active and passive distinction being drawn at the level of > > measurement methods that is more generic than measurement task. And I > > think that term "Active Measurement Traffic" is ambiguous if you're > > trying to characterize test traffic. In addition, a performance metric > > may be not limited to only transfer of the test packets, but their > > processing as well. > > This is only the 3rd para of the introductory outline section, to give th= e > reader the impression what lmap is about. I don=E2=80=99t think we have t= o include > all the details and possible variants, which could even be confusing at > this early stage. > I don=E2=80=99t understand why the term "Active Measurement Traffic" may = be > ambiguous. > > GIM>> To me "Measurement Traffic" is what Active Performance Measurement inserts and measures on, what actually differentiates Active Measurement methods from Passive Measurement. Saying "Active Measurement Traffic", for me, non-native English speaker, implies that there may be such thing as "Passive Measurement Traffic". > > > > =E2=80=A2 "The MA is managed by a Controller using the Control Protocol= ." > > Perhaps "A Controller manages the MA through use of the Control > > Protocol." > > =E2=80=A2 "The MA receives Instructions from the Controller about which > > Measurement Tasks it should perform and when." > > I think that it is premature to be so specific about what information > > the MA would receive from its Controller. I can imagine that MA > > receives schedule with references to Measurement Methods that are in > > Performance Registry and necessary Measurement Task parameters. > > Yes, this could be better phrased. How about: > > A Controller manages the MA through use of the Control Protocol. It sends > an Instruction Message to the MA, which describes the Measurement Tasks i= t > should perform and when. > GIM>> Yes, agree. Perhaps can use plural in "Instruction Messages". > > > =E2=80=A2 "... or a > > Measurement Peer (or another Measurement Agent) sending Active > > Measurement Traffic to a MA." > > Does that imply that MP can generate test traffic without instructions > > from the Controller? Or this is to describe one-sided two-way active > > measurements when MP reflects or responds to test packets? > > Yes, MP responding to test packet(s) from the MA. is this re-phrase > clearer? > GIM>> "responding to" definitely clarifies things here. > > < packet(s) from a MA) sending Active Measurement Traffic to a MA>> > > > > > "Active Measurement Traffic" suggest to change to "Measurement Traffic" > > because there cannot be "Passive Measurement Traffic". > > I prefer to have the reminder that it's Active. > GIM>> M-m-m > > > > > "Capabilities: Information about the Measurement Methods that the MA > > can perform ..." is perhaps too specific without informational model of > > Control Protocol being finalized. Could we say "Capabilities: > > Information that characterizes performance measurement capabilities of > > the MA ... > > How about: > Capabilities: Information about the performance measurement capabilities > of the MA, in particular the Measurement Methods that it can perform, and > the device hosting the MA, for example its interface type and speed, but > not dynamic information. > GIM>> Would " the device hosting the MA, for example its interface type and speed, but not dynamic information" be capacity of the MA rather than capability in regard to performance measurement? > [...] > =E2=80=A2 > > Section 5.2.1 "The Instruction defines the following:" list that > > follows is too specific for the framework document and may be more > > appropriate in specification of the informational model or control > > protocol itself. > > =E2=80=A2 Section 5.2.2 > > "Capabilities are information about the MA that the Controller needs to > > know in order to correctly instruct the MA, such as:" > > I think that the list that follows and "such as" are more in place in > > the informational model document or use "for example" clause. > > =E2=80=A2 Section 5.4 > > "The Report contains:' > > How about "The Report may contain:" then "perhaps" can be removed from > > the last bullet > > I rather agree with your comments about the various lists being too > specific for the framework. Will think about. > > > > Regards, Greg > > > > On Wed, Apr 2, 2014 at 4:58 AM, Romascanu, Dan (Dan) > > wrote: > > Hi, > > > > This is a 2nd WGLC for the LMAP Framework I-D. Please send your > > comments to the WG mail list until Wednesday 4/16. If you believe that > > the document is ready for submission to the IESG as Informational RC a > > short message stating this will also be welcome. > > > > The document is available at http://www.ietf.org/id/draft-ietf-lmap- > > framework-04.txt. > > > > Thanks and Regards, > > > > Dan > > > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > --bcaec547ca39ee911304f7223198 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,
thank you for your kind c= onsideration of my comments. I've clipped ones we've agreed on alre= ady. Please find couple follow ups in-lined and tagged by GIM>>.

Regards,
Greg


On Mon, Apr 14, 2014 at 3:45 AM,= <philip.eardley@bt.com> wrote:
Greg

Thank-you very much for the comments.
Some follow-ups in line

Best wishes
phil
[...]
=C2=A0

I suspect we're actually in agreement on the basic point - the protocol= s will be defined as extensions /re-use of existing protocol(s) (not a comp= letely new protocol).

GIM>> Yes, = agree. It might be good to state that in the framework document explicitly.=

>
> =E2=80=A2 "Measurement Tasks may be Active (the MA generates Acti= ve Measurement
> Traffic and measures some metric associated with its transfer), P= assive
> (the MA observes user traffic), or some hybrid form of the two."<= br> > Usually active and passive distinction being drawn at the level of
> measurement methods that is more generic than measurement task. And I<= br> > think that term "Active Measurement Traffic" is ambiguous if= you're
> trying to characterize test traffic. In addition, a performance metric=
> may be not limited to only transfer of the test packets, but their
> processing as well.

This is only the 3rd para of the introductory outline section, to giv= e the reader the impression what lmap is about. I don=E2=80=99t think we ha= ve to include all the details and possible variants, which could even be co= nfusing at this early stage.
I don=E2=80=99t understand why the term "Active Measurement Traffic&qu= ot; may be ambiguous.

GIM>> To me "Measurement Traffic" is = what Active Performance Measurement inserts and measures on, what actually = differentiates Active Measurement methods from Passive Measurement. Saying = "Active Measurement Traffic", for me, non-native English speaker,= implies that there may be such thing as "Passive Measurement Traffic&= quot;.
>
> =E2=80=A2 "The MA is managed by a Controller using the Control Pr= otocol."
> Perhaps "A Controller manages the MA through use of the Cont= rol
> Protocol."
> =E2=80=A2 "The MA receives Instructions from the Controller about= which
> Measurement Tasks it should perform and when."
> I think that it is premature to be so specific about what information<= br> > the MA would receive from its Controller. I can imagine that MA
> receives schedule with references to Measurement Methods that are in > Performance Registry and necessary Measurement Task parameters.

Yes, this could be better phrased. How about:

A Controller manages the MA through use of the Control Protocol. It sends a= n Instruction Message to the MA, which describes the Measurement Tasks it s= hould perform and when.

GIM>> Yes= , agree. Perhaps can use plural in "Instruction Messages".

> =E2=80=A2 "... or a
> Measurement Peer (or another Measurement Agent) sending Active > Measurement Traffic to a MA."
> Does that imply that MP can generate test traffic without instructions=
> from the Controller? Or this is to describe one-sided two-way active > measurements when MP reflects or responds to test packets?

Yes, MP responding to test packet(s) from the MA. is this re-phrase c= learer?
GIM>> "responding to" definite= ly clarifies things here.=C2=A0

<<and/or another Measurement Agent (or a Measurement Peer, in respons= e to packet(s) from a MA) sending Active Measurement Traffic to a MA>>= ;

>
> "Active Measurement Traffic" suggest to change to "Meas= urement Traffic"
> because there cannot be "Passive Measurement Traffic".

I prefer to have the reminder that it's Active.
<= div>GIM>> M-m-m

>
> "Capabilities: Information about the Measurement Methods that the= MA
> can perform ..." is perhaps too specific without informational mo= del of
> Control Protocol being finalized. Could we say "Capabilities:
> Information that characterizes performance measurement capabilities of=
> the MA ...

How about:
Capabilities: Information about the performance measurement capabilities of= the MA, in particular the Measurement Methods that it can perform, and the= device hosting the MA, for example its interface type and speed, but not d= ynamic information.
GIM>> Would " the device hosting the MA, for e= xample its interface type and speed, but not dynamic information" be c= apacity of the MA rather than capability in regard to performance measureme= nt?
[...]
=E2=80=A2
> Section 5.2.1 "The Instruction defines the following:"=C2=A0= list that
> follows is too specific for the framework document and may be more
> appropriate in specification of the informational model or control
> protocol itself.
> =E2=80=A2 Section 5.2.2
> "Capabilities are information about the MA that the Controller ne= eds to
> know in order to correctly instruct the MA, such as:"
> I think that the list that follows and "such as" are more in= place in
> the informational model document or use "for example" clause= .
> =E2=80=A2 Section 5.4
> "The Report contains:'
> How about "The Report may contain:" then "perhaps"= can be removed from
> the last bullet

I rather agree with your comments about the various lists being too s= pecific for the framework. Will think about.



Regards, Greg
>
> On Wed, Apr 2, 2014 at 4:58 AM, Romascanu, Dan (Dan)
> <dromasca@a= vaya.com> wrote:
> Hi,
>
> This is a 2nd WGLC for the LMAP Framework I-D. Please send your
> comments to the WG mail list until Wednesday 4/16. If you believe that=
> the document is ready for submission to the IESG as Informational RC a=
> short message stating this will also be welcome.
>
> The document is available at http://www.ietf.org/id/draft-ietf-lmap- > framework-04.txt.
>
> Thanks and Regards,
>
> Dan
>
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap


--bcaec547ca39ee911304f7223198-- From nobody Tue Apr 15 22:47: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 0E18B1A003D for ; Tue, 15 Apr 2014 22:47:15 -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 JGtdBI7KJ0AL for ; Tue, 15 Apr 2014 22:47:12 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B42631A0025 for ; Tue, 15 Apr 2014 22:47:11 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ib6so10443466vcb.13 for ; Tue, 15 Apr 2014 22:47:08 -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=6z3e4rdtaLlLaT4os8DfM2WZnsK/1rhqnFGN8PV6rlQ=; b=alkO0KCMdJS+d8HdjNH9NKDMdqpoVJV4LzBEU3MSY4cs3TFeB/V4b4SZZ/e/EGvtcW C+l7xx6KOlvMYQu+zO+8X8iZen5372RBZlFJ1F0tESshe3eI7k3wfwRArM+hr9GQmFkx 98q1GbxCAPw2RB/4v00dEj4Ya5r9qmTxZIaxHrlZvd4OIFUP/wdNIMQbVkP4jHPapUev 1C+h1ab6fm3gQbsC+zS614Sdjl5EHDS9kHCbfQO94VJDzdxURlJCBq3IJ7mo9Trw0B78 nunL7C78bSfnhnVz21TUrgpYJXe6J9uA6BY1qeNjhPkpMMTfn5hknCDqAxwKnCyhnaMQ zl8A== MIME-Version: 1.0 X-Received: by 10.58.111.163 with SMTP id ij3mr294474veb.26.1397627228302; Tue, 15 Apr 2014 22:47:08 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Tue, 15 Apr 2014 22:47:08 -0700 (PDT) In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> Date: Tue, 15 Apr 2014 22:47:08 -0700 Message-ID: From: Greg Mirsky To: philip.eardley@bt.com Content-Type: multipart/alternative; boundary=047d7b2e548a78b3c504f72272f0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/XPoYUvJFZc_44SNpaEQzTvp3ejU Cc: "Romascanu, Dan \(Dan\)" , "lmap@ietf.org" Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 16 Apr 2014 05:47:15 -0000 --047d7b2e548a78b3c504f72272f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Phil, and again, appreciate your thoughtful consideration of my notes to the document. I agree with the your proposed way of handling lists that will be specified in the informational model(s). I think that providing examples and references to possible solutions in the framework will be informative and not too restrictive at the same time. Regards, Greg On Mon, Apr 14, 2014 at 7:19 AM, wrote: > Several of Greg=E2=80=99s comments on Section 5 were on the lines =E2=80= =9Cthe list that > follows is too specific for the framework document and may be more > appropriate in specification of the informational model=E2=80=9D > > > > I agree with this. In particular, the relationship between the different > items seems much more appropriate for the information model i-d. For > example, things like "a name for this Measurement Task configuration" see= m > more appropriate for the info model i-d - the =E2=80=9Cname=E2=80=9D stuf= f really explains > how the different information elements link together, and it seems better > to define this once (in the info model). However, we need a certain leve= l > of detail in the framework, in order to show what lmap is doing. > > > > So, we could introduce the list of the bullets with a comment something > like:- > > This is the list of the aims about the types of information in the > Instruction. It is not a list of information elements (these will be > defined in draft-ietf-information-model). > > > > In London, we agreed to add the stuff about Data Transfer Tasks, which > appear in -04. For consistency with the split between Measurement > Schedules, Tasks and Methods, we should have a similar split between Data > Transfer Schedules, Tasks and Methods. > > > > Side-note: Section 2 (Outline of lmap) should also mention the Data > Transfer stuff. > > > > -- > > > > So we might end up with something like:- > > > > As a result of the bootstrapping process the MA learns information with t= he following aims ([draft-ietf-information-model] defines the consequent li= st of information elements): > > > > o its identifier, MA-ID > > > > o (optionally) a Group-ID. A Group-ID would be shared by several > > MAs and could be useful for privacy reasons. For instance, reportin= g the Group-ID and not the MA-ID could hinder tracking of a mobile device > > > > o the Control Channel, which is defined by: > > > > * the address of the Controller (such as its FQDN (Fully > > Qualified Domain Name) [RFC1035 ]) > > > > * security information (for example to enable the MA to decrypt > > the Instruction Message and encrypt messages sent to the > > Controller) > > > > ... > > The Instruction defines information with the following aims ([draft-ietf-= information-model] defines the consequent list of information elements): > > > > o the Measurement Task configurations, each of which needs: > > > > * the Measurement Method, specified as a URN to a registry entry. > > The registry could be defined by the IETF > > [I-D.manyfolks-ippm-metric-registry ], loca= lly by the operator > > of the measurement system or perhaps by another standards > > organisation. > > > > * any Input Parameters that need to be set for the Measurement > > Method, such as the address of the Measurement Peer (or other > > Measurement Agent) that are involved in an Active Measurement > > Task > > > > * if the device with the MA has multiple interfaces, then the > > interface to use (if not defined, then the default interface is > > used) > > > > o configuration of the Measurement Schedules, each of which needs: > > > > * the timing of when the Measurement Tasks are to be performed. > > Possible types of timing are periodic, calendar-based periodic, > > one-off immediate and one-off at a future time > > > > o configuration of the Report Channels, each of which needs: > > > > * the address of the Collector, for instance its URL > > > > * security for this Report Channel, for example the X.509 > > certificate > > > > o configuration of the Data Transfer Tasks, each of which needs: > > > > * the Data Transfer Method, and any information it needs about Inp= ut Parameters or interface selection > > > > o configuration of the Data Transfer Schedules, each of which needs: > > > > * the timing of when the Data Transfer Tasks are to be performed. > > > > A Data Transfer Task may concern the reporting of Measurement > > Results (when the timing could be every hour or immediately, for > > instance). Alternatively, a Data Transfer Task may concern the MA > > informing the Controller about its Capabilities or any Failures. > > > > o Suppression information, if any (see Section 5.2.1.1 ) > > > > do you think this gets the balance better between what should appear in > the framework vs in the information model? > > thanks, > > phil > > > > > > > > > > *From:* lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of *Romascanu, Dan > (Dan) > > *Sent:* 02 April 2014 12:58 > *To:* lmap@ietf.org > *Subject:* [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected > day-of-the-week) > > > > Hi, > > > > This is a 2nd WGLC for the LMAP Framework I-D. Please send your comments > to the WG mail list until Wednesday 4/16. If you believe that the documen= t > is ready for submission to the IESG as Informational RC a short message > stating this will also be welcome. > > > > The document is available at > http://www.ietf.org/id/draft-ietf-lmap-framework-04.txt. > > > > Thanks and Regards, > > > > Dan > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > --047d7b2e548a78b3c504f72272f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,
and again, appreciat= e your thoughtful consideration of my notes to the document.
I agr= ee with the your proposed way of handling lists that will be specified in t= he informational model(s). I think that providing examples and references t= o possible solutions in the framework will be informative and not too restr= ictive at the same time.

Regards,
Greg

On Mon, Apr 14, 2014 at 7:19 AM, <philip= .eardley@bt.com> wrote:

Several of Greg=E2=80=99s comments on Section = 5 were on the lines =E2=80=9Cthe list that follows is too specific for the = framework document and may be more appropriate in specification of the info= rmational model=E2=80=9D

=C2=A0

I agree with this. In particular, the relationship between the dif= ferent items seems much more appropriate for the information model i-d. For= example, things like "a name for this Measurement Task configuration&= quot; seem more appropriate for the info model i-d - the =E2=80=9Cname=E2= =80=9D stuff really explains how the different information elements link to= gether, and it seems better to define this once (in the info model).=C2=A0 = However, we need a certain level of detail in the framework, in order to sh= ow what lmap is doing.

=C2=A0

So, we could introduce the list of the bullets with a comment some= thing like:-

This is the list of the aims about the = types of information in the Instruction. It is not a list of information el= ements (these will be defined in draft-ietf-information-model).

=C2=A0

In London, we agreed to add the stuff about Data Transfer Tasks, w= hich appear in -04. For consistency with the split between Measurement Sche= dules, Tasks and Methods, we should have a similar split between Data Trans= fer Schedules, Tasks and Methods.

=C2=A0

Side-note:= Section 2 (Outline of lmap) should also mention the Data Transfer stuff.

=C2=A0

--<= u>

=C2=A0

So we migh= t end up with something like:-

=C2=A0

As a result of the bootstrapping process the MA lear=
ns information with the following a=
ims ([draft-ietf-information-model] defines the consequent list of informat=
ion elements):
=C2=A0
=C2=A0=C2=A0 o=C2=
=A0 its identifier, MA-ID
=C2=A0
=C2=A0=C2=A0 o=C2=A0 (opt=
ionally) a Group-ID.=C2=A0 A Group-ID would be shared by several<=
/u>
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 MAs and could be useful for privacy reasons. For inst=
ance, reporting the Group-ID and not the MA-ID could hinder tracking of a m=
obile device
=C2=A0
=C2=A0=C2=A0 o=C2=
=A0 the Control Channel, which is defined by:
=C2=A0<= /pre> 
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 *=C2=A0 the address of the Controller (such as its FQDN (Fully
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Qualified Domain Name) [RFC1035])
=C2=A0
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 *=C2=A0 security information (for example to enable the MA =
to decrypt
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 the Instruction Message and encrypt messages sent to the=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Controller)=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
=C2=A0
...=

The Instruct=
ion defines information with the fo=
llowing aims ([draft-ietf-information-model] defines the consequent list of=
 information elements):=

=C2=A0
=C2=A0=C2=A0 o=C2=
=A0 the Measurement Task configurations, each of which needs:=

=C2=
=A0
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 *=C2=A0 the Measurement Method, specified as a URN to a registry ent=
ry.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The registry could be=
 defined by the IETF
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 [I-D.manyfolks-ippm-metric-registry=
], locally by the operator
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 of the measurement system or perhaps by another st=
andards
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 organisation.<=
/u>
=C2=A0
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 *=C2=A0 any Input Parameters that need to be set for the Me=
asurement
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Method, such as the address of the Measurement Peer (or =
other
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Measurement Agent)=
 that are involved in an Active Measurement
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 Task
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=
=A0 if the device with the MA has multiple interfaces, then the
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 interface to use (if not defined, then the default=
 interface is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 used)
=C2=A0
=C2=A0=C2=A0 o=C2=
=A0 configuration of the Measurement Schedules, each of which needs:=

=C2=A0
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 *=C2=A0 the timing of when the Measurement Tasks are to be perfor=
med.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Possible types of =
timing are periodic, calendar-based periodic,


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 one-off immediate and one-off at a future time<=
/u>
=C2=A0
=C2=A0=C2=A0 o=C2=A0 configuration of the Report Channels, each of =
which needs:


=C2=A0
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 *=C2=A0 the address of the Collector, for instance its URL<=
u>
=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 *=C2=A0 security for this Report Channel, for example the X.509
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 certificate


=C2=A0
=C2=A0=C2=A0 o=C2=
=A0 configuration of the Data Transfer Tasks, each of which needs:
=
=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 *=C2=A0 the Data Transfer Method, and any information it needs about=
 Input Parameters or interface selection 
=C2=A0

=C2=A0=C2=A0 o=C2=A0 configuration of the Data=
 Transfer Schedules, each of which needs:
=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 *=C2=A0 the timing of when the Data Transfer Tasks are to be perform=
ed.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 A Data Transfer Task may concern the reporting of Measurement
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 Results (when the timing could be every hour or immed=
iately, for


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 instance).=C2=A0 Alternatively, a Data Transfer Task may concern the=
 MA
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 informing the Controller about its Capa=
bilities or any Failures.


=C2=A0
=C2=A0=C2=A0 o=C2=
=A0 Suppression information, if any (see Section 5.2.1.1)<=
/pre>

=C2=A0
do you think this gets the balance better between what should appear in t=
he framework vs in the information model?


thanks,
phil


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


From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)



Sent: 02 April 2014 12:58
To: lmap@ietf.org
S=
ubject: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of=
-the-week)


=C2=A0<=
/u>
Hi,


=C2=A0
This is a 2nd WGLC for the LMAP Framework I-=
D. Please send your comments to the WG mail list until Wednesday 4/16. If y=
ou believe that the document is ready for submission to the IESG as Informa=
tional RC a short message stating this will also be welcome. =



=C2=A0
The document is available at http://www.ietf.org/id/draft-ietf-lmap-framework-04.txt. 


=C2=A0
Thanks and Regards,


=C2=A0
Dan


=C2=A0
=

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


--047d7b2e548a78b3c504f72272f0-- From nobody Wed Apr 16 00:33: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 5D2621A00E6 for ; Wed, 16 Apr 2014 00:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] 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 0BHbw7Xg8cGW for ; Wed, 16 Apr 2014 00:33:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 539361A00E4 for ; Wed, 16 Apr 2014 00:33:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BD93410EA; Wed, 16 Apr 2014 09:33: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 Vajg79ZokohT; Wed, 16 Apr 2014 09:33:35 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 16 Apr 2014 09:33:35 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AAC6520017; Wed, 16 Apr 2014 09:33:34 +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 EmthVmN1gm6n; Wed, 16 Apr 2014 09:33:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8D3920013; Wed, 16 Apr 2014 09:33:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C6D722C620A7; Wed, 16 Apr 2014 09:33:32 +0200 (CEST) Date: Wed, 16 Apr 2014 09:33:32 +0200 From: Juergen Schoenwaelder To: MARCELO BAGNULO BRAUN Message-ID: <20140416073332.GA12252@elstar.local> Mail-Followup-To: MARCELO BAGNULO BRAUN , "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <2845723087023D4CB5114223779FA9C8017944A577@njfpsrvexg8.research.att.com> <20140415233436.sfay4k84j4s4w8o0@webcartero01.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140415233436.sfay4k84j4s4w8o0@webcartero01.uc3m.es> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/a_n8hAKD1zOY99Earj750lNwkkE Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] lmap framework and IPPM registries. 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, 16 Apr 2014 07:33:42 -0000 On Tue, Apr 15, 2014 at 11:34:36PM +0200, MARCELO BAGNULO BRAUN wrote: > So, the question I have is whether IANA can handle URI allocations. > I dont know the answer to this question. If they can, then i think > we are ok. If they cant, i think we have a problem. IANA already manages URNs for several protocols. I guess they won't have a problem doing one more. See RFC 3553 (BCP 73) for a starting point. /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 Apr 16 00:36: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 EFEAE1A00F4 for ; Wed, 16 Apr 2014 00:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] 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 HlJxTspkWDPr for ; Wed, 16 Apr 2014 00:36:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC651A00F7 for ; Wed, 16 Apr 2014 00:36:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 406996DA; Wed, 16 Apr 2014 09:35:58 +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 eNjhzJTDQBN1; Wed, 16 Apr 2014 09:35:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 16 Apr 2014 09:35:57 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B2DC20017; Wed, 16 Apr 2014 09:35:57 +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 xNjYI36Zijas; Wed, 16 Apr 2014 09:35:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6708420013; Wed, 16 Apr 2014 09:35:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5FA2D2C620EF; Wed, 16 Apr 2014 09:35:56 +0200 (CEST) Date: Wed, 16 Apr 2014 09:35:56 +0200 From: Juergen Schoenwaelder To: MARCELO BAGNULO BRAUN Message-ID: <20140416073556.GB12252@elstar.local> Mail-Followup-To: MARCELO BAGNULO BRAUN , lmap@ietf.org References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <20140414175747.GA8673@elstar.local> <20140414204109.3p5s75qggoc4scc8@webcartero01.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140414204109.3p5s75qggoc4scc8@webcartero01.uc3m.es> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/sUWMiL6eK2lTyC4YIVex4DyUYHg Cc: lmap@ietf.org Subject: Re: [lmap] lmap framework and IPPM registries. 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, 16 Apr 2014 07:36:03 -0000 On Mon, Apr 14, 2014 at 08:41:09PM +0200, MARCELO BAGNULO BRAUN wrote: > > It is perfectrly possible to reserve a range of identifiers for > private use so a manager of a measurement domain can locally assign > values for metrics without going through the registry. > A set of values reserved for private use means the values will not be unique and clash. If I have an LMAP installation with MA provided by different vendors, there is a reasonable chance that private use identifiers shipped with their products clash. By moving to URIs, this risk can be minimized. /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 Apr 16 05:35: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 B2BE21A0127 for ; Wed, 16 Apr 2014 05:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 gryQ0sLTHZn2 for ; Wed, 16 Apr 2014 05:35:16 -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 2E9F21A015A for ; Wed, 16 Apr 2014 05:35:16 -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 556D5120630; Wed, 16 Apr 2014 08:35:17 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id DDF13E01E5; Wed, 16 Apr 2014 08:35:11 -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; Wed, 16 Apr 2014 08:35:12 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , MARCELO BAGNULO BRAUN Date: Wed, 16 Apr 2014 08:35:12 -0400 Thread-Topic: [lmap] lmap framework and IPPM registries. Thread-Index: Ac9ZRonZkgcJdjY7SY6ABnM4vRsM+AAKVGiA Message-ID: <2845723087023D4CB5114223779FA9C8017944A5F2@njfpsrvexg8.research.att.com> References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <20140414175747.GA8673@elstar.local> <20140414204109.3p5s75qggoc4scc8@webcartero01.uc3m.es> <20140416073556.GB12252@elstar.local> In-Reply-To: <20140416073556.GB12252@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9WDUF3aqWKSKo9Armz_qGOP2wic Cc: "lmap@ietf.org" Subject: Re: [lmap] lmap framework and IPPM registries. 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, 16 Apr 2014 12:35:17 -0000 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, April 16, 2014 3:36 AM ... >=20 > On Mon, Apr 14, 2014 at 08:41:09PM +0200, MARCELO BAGNULO BRAUN wrote: > > > > It is perfectrly possible to reserve a range of identifiers for > > private use so a manager of a measurement domain can locally assign > > values for metrics without going through the registry. > > >=20 > A set of values reserved for private use means the values will not be > unique and clash. If I have an LMAP installation with MA provided by > different vendors, there is a reasonable chance that private use > identifiers shipped with their products clash. By moving to URIs, this > risk can be minimized. >=20 > /js I've asked IANA if support for URIs is possible, on their general contact=20 e-mail address (which has spawned a ticket number, etc.). It may take a few iterations on the question & answer, but I'll report back when the loop=20 closes. Al From nobody Wed Apr 16 06:55: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 5CBA41A01AC for ; Wed, 16 Apr 2014 06:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 lI64-05nvDbu for ; Wed, 16 Apr 2014 06:55:34 -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 213C91A019B for ; Wed, 16 Apr 2014 06:55:34 -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 3B984554778; Wed, 16 Apr 2014 09:55:35 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id 72734E01E5; Wed, 16 Apr 2014 09:55:29 -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; Wed, 16 Apr 2014 09:55:30 -0400 From: "MORTON, ALFRED C (AL)" To: Greg Mirsky , "philip.eardley@bt.com" Date: Wed, 16 Apr 2014 09:55:29 -0400 Thread-Topic: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) Thread-Index: Ac9ZNNJNVzBHvbtqTqqMvVh7z5YyKAARasXw Message-ID: <2845723087023D4CB5114223779FA9C8017944A625@njfpsrvexg8.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.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: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8017944A625njfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/hLfRRslSrT2qeM77G1_hHnztJp8 Cc: "draft-ietf-lmap-framework@tools.ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 16 Apr 2014 13:55:38 -0000 --_000_2845723087023D4CB5114223779FA9C8017944A625njfpsrvexg8re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KVGhlcmUncyBvbmUgY2FzZSB3aGVyZSBJIGFncmVlIHdpdGggeW91LCB0aGUg d29yZCAiQWN0aXZlIiBpbiB0aGUNCmRlc2NyaXB0aW9uIGluIHBhcmVudGhlc2lzIGlzIHJlZHVu ZGFudCBpbiB0aGUgY2FzZSBiZWxvdzoNCg0KPiDigKIgIk1lYXN1cmVtZW50IFRhc2tzIG1heSBi ZSBBY3RpdmUgKHRoZSBNQSBnZW5lcmF0ZXMgQWN0aXZlIE1lYXN1cmVtZW50DQo+IFRyYWZmaWMg YW5kIG1lYXN1cmVzIHNvbWUgbWV0cmljIGFzc29jaWF0ZWQgd2l0aCBpdHMgdHJhbnNmZXIpLCBQ YXNzaXZlDQo+ICh0aGUgTUEgb2JzZXJ2ZXMgdXNlciB0cmFmZmljKSwgb3Igc29tZSBoeWJyaWQg Zm9ybSBvZiB0aGUgdHdvLiINCg0KDQpCdXQgaGVyZSAoYW5kIHByb2JhYmx5IG90aGVyIHBsYWNl cykNCj4gIkFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIiBzdWdnZXN0IHRvIGNoYW5nZSB0byAi TWVhc3VyZW1lbnQgVHJhZmZpYyINCj4gYmVjYXVzZSB0aGVyZSBjYW5ub3QgYmUgIlBhc3NpdmUg TWVhc3VyZW1lbnQgVHJhZmZpYyIuDQpbcGhpbF0gSSBwcmVmZXIgdG8gaGF2ZSB0aGUgcmVtaW5k ZXIgdGhhdCBpdCdzIEFjdGl2ZS4NCkdJTT4+IE0tbS1tDQoNCkkgYWdyZWUgd2l0aCBQaGlsLCB0 aGUgYWRqZWN0aXZlIGlzIGEgdXNlZnVsIGZvciBjbGFyaXR5Lg0KDQpBbA0KDQoNCg0KRnJvbTog bG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWcgTWly c2t5DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE2LCAyMDE0IDE6MjkgQU0NClRvOiBwaGlsaXAu ZWFyZGxleUBidC5jb20NCkNjOiBsbWFwQGlldGYub3JnOyBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3 b3JrQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW2xtYXBdIDJuZCBXR0xDIGZvciBkcmFm dC1pZXRmLWxtYXAtZnJhbWV3b3JrIChjb3JyZWN0ZWQgZGF5LW9mLXRoZS13ZWVrKQ0KDQpIaSBQ aGlsLA0KdGhhbmsgeW91IGZvciB5b3VyIGtpbmQgY29uc2lkZXJhdGlvbiBvZiBteSBjb21tZW50 cy4gSSd2ZSBjbGlwcGVkIG9uZXMgd2UndmUgYWdyZWVkIG9uIGFscmVhZHkuIFBsZWFzZSBmaW5k IGNvdXBsZSBmb2xsb3cgdXBzIGluLWxpbmVkIGFuZCB0YWdnZWQgYnkgR0lNPj4uDQpSZWdhcmRz LA0KR3JlZw0KDQpPbiBNb24sIEFwciAxNCwgMjAxNCBhdCAzOjQ1IEFNLCA8cGhpbGlwLmVhcmRs ZXlAYnQuY29tPG1haWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb20+PiB3cm90ZToNCkdyZWcNCg0K VGhhbmsteW91IHZlcnkgbXVjaCBmb3IgdGhlIGNvbW1lbnRzLg0KU29tZSBmb2xsb3ctdXBzIGlu IGxpbmUNCg0KQmVzdCB3aXNoZXMNCnBoaWwNClsuLi5dDQoNCg0KSSBzdXNwZWN0IHdlJ3JlIGFj dHVhbGx5IGluIGFncmVlbWVudCBvbiB0aGUgYmFzaWMgcG9pbnQgLSB0aGUgcHJvdG9jb2xzIHdp bGwgYmUgZGVmaW5lZCBhcyBleHRlbnNpb25zIC9yZS11c2Ugb2YgZXhpc3RpbmcgcHJvdG9jb2wo cykgKG5vdCBhIGNvbXBsZXRlbHkgbmV3IHByb3RvY29sKS4NCg0KR0lNPj4gWWVzLCBhZ3JlZS4g SXQgbWlnaHQgYmUgZ29vZCB0byBzdGF0ZSB0aGF0IGluIHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQg ZXhwbGljaXRseS4NCg0KPg0KPiDigKIgIk1lYXN1cmVtZW50IFRhc2tzIG1heSBiZSBBY3RpdmUg KHRoZSBNQSBnZW5lcmF0ZXMgQWN0aXZlIE1lYXN1cmVtZW50DQo+IFRyYWZmaWMgYW5kIG1lYXN1 cmVzIHNvbWUgbWV0cmljIGFzc29jaWF0ZWQgd2l0aCBpdHMgdHJhbnNmZXIpLCBQYXNzaXZlDQo+ ICh0aGUgTUEgb2JzZXJ2ZXMgdXNlciB0cmFmZmljKSwgb3Igc29tZSBoeWJyaWQgZm9ybSBvZiB0 aGUgdHdvLiINCj4gVXN1YWxseSBhY3RpdmUgYW5kIHBhc3NpdmUgZGlzdGluY3Rpb24gYmVpbmcg ZHJhd24gYXQgdGhlIGxldmVsIG9mDQo+IG1lYXN1cmVtZW50IG1ldGhvZHMgdGhhdCBpcyBtb3Jl IGdlbmVyaWMgdGhhbiBtZWFzdXJlbWVudCB0YXNrLiBBbmQgSQ0KPiB0aGluayB0aGF0IHRlcm0g IkFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIiBpcyBhbWJpZ3VvdXMgaWYgeW91J3JlDQo+IHRy eWluZyB0byBjaGFyYWN0ZXJpemUgdGVzdCB0cmFmZmljLiBJbiBhZGRpdGlvbiwgYSBwZXJmb3Jt YW5jZSBtZXRyaWMNCj4gbWF5IGJlIG5vdCBsaW1pdGVkIHRvIG9ubHkgdHJhbnNmZXIgb2YgdGhl IHRlc3QgcGFja2V0cywgYnV0IHRoZWlyDQo+IHByb2Nlc3NpbmcgYXMgd2VsbC4NClRoaXMgaXMg b25seSB0aGUgM3JkIHBhcmEgb2YgdGhlIGludHJvZHVjdG9yeSBvdXRsaW5lIHNlY3Rpb24sIHRv IGdpdmUgdGhlIHJlYWRlciB0aGUgaW1wcmVzc2lvbiB3aGF0IGxtYXAgaXMgYWJvdXQuIEkgZG9u 4oCZdCB0aGluayB3ZSBoYXZlIHRvIGluY2x1ZGUgYWxsIHRoZSBkZXRhaWxzIGFuZCBwb3NzaWJs ZSB2YXJpYW50cywgd2hpY2ggY291bGQgZXZlbiBiZSBjb25mdXNpbmcgYXQgdGhpcyBlYXJseSBz dGFnZS4NCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB0aGUgdGVybSAiQWN0aXZlIE1lYXN1cmVt ZW50IFRyYWZmaWMiIG1heSBiZSBhbWJpZ3VvdXMuDQpHSU0+PiBUbyBtZSAiTWVhc3VyZW1lbnQg VHJhZmZpYyIgaXMgd2hhdCBBY3RpdmUgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgaW5zZXJ0cyBh bmQgbWVhc3VyZXMgb24sIHdoYXQgYWN0dWFsbHkgZGlmZmVyZW50aWF0ZXMgQWN0aXZlIE1lYXN1 cmVtZW50IG1ldGhvZHMgZnJvbSBQYXNzaXZlIE1lYXN1cmVtZW50LiBTYXlpbmcgIkFjdGl2ZSBN ZWFzdXJlbWVudCBUcmFmZmljIiwgZm9yIG1lLCBub24tbmF0aXZlIEVuZ2xpc2ggc3BlYWtlciwg aW1wbGllcyB0aGF0IHRoZXJlIG1heSBiZSBzdWNoIHRoaW5nIGFzICJQYXNzaXZlIE1lYXN1cmVt ZW50IFRyYWZmaWMiLg0KPg0KPiDigKIgIlRoZSBNQSBpcyBtYW5hZ2VkIGJ5IGEgQ29udHJvbGxl ciB1c2luZyB0aGUgQ29udHJvbCBQcm90b2NvbC4iDQo+IFBlcmhhcHMgIkEgQ29udHJvbGxlciBt YW5hZ2VzIHRoZSBNQSB0aHJvdWdoIHVzZSBvZiB0aGUgQ29udHJvbA0KPiBQcm90b2NvbC4iDQo+ IOKAoiAiVGhlIE1BIHJlY2VpdmVzIEluc3RydWN0aW9ucyBmcm9tIHRoZSBDb250cm9sbGVyIGFi b3V0IHdoaWNoDQo+IE1lYXN1cmVtZW50IFRhc2tzIGl0IHNob3VsZCBwZXJmb3JtIGFuZCB3aGVu LiINCj4gSSB0aGluayB0aGF0IGl0IGlzIHByZW1hdHVyZSB0byBiZSBzbyBzcGVjaWZpYyBhYm91 dCB3aGF0IGluZm9ybWF0aW9uDQo+IHRoZSBNQSB3b3VsZCByZWNlaXZlIGZyb20gaXRzIENvbnRy b2xsZXIuIEkgY2FuIGltYWdpbmUgdGhhdCBNQQ0KPiByZWNlaXZlcyBzY2hlZHVsZSB3aXRoIHJl ZmVyZW5jZXMgdG8gTWVhc3VyZW1lbnQgTWV0aG9kcyB0aGF0IGFyZSBpbg0KPiBQZXJmb3JtYW5j ZSBSZWdpc3RyeSBhbmQgbmVjZXNzYXJ5IE1lYXN1cmVtZW50IFRhc2sgcGFyYW1ldGVycy4NClll cywgdGhpcyBjb3VsZCBiZSBiZXR0ZXIgcGhyYXNlZC4gSG93IGFib3V0Og0KDQpBIENvbnRyb2xs ZXIgbWFuYWdlcyB0aGUgTUEgdGhyb3VnaCB1c2Ugb2YgdGhlIENvbnRyb2wgUHJvdG9jb2wuIEl0 IHNlbmRzIGFuIEluc3RydWN0aW9uIE1lc3NhZ2UgdG8gdGhlIE1BLCB3aGljaCBkZXNjcmliZXMg dGhlIE1lYXN1cmVtZW50IFRhc2tzIGl0IHNob3VsZCBwZXJmb3JtIGFuZCB3aGVuLg0KDQpHSU0+ PiBZZXMsIGFncmVlLiBQZXJoYXBzIGNhbiB1c2UgcGx1cmFsIGluICJJbnN0cnVjdGlvbiBNZXNz YWdlcyIuDQoNCj4g4oCiICIuLi4gb3IgYQ0KPiBNZWFzdXJlbWVudCBQZWVyIChvciBhbm90aGVy IE1lYXN1cmVtZW50IEFnZW50KSBzZW5kaW5nIEFjdGl2ZQ0KPiBNZWFzdXJlbWVudCBUcmFmZmlj IHRvIGEgTUEuIg0KPiBEb2VzIHRoYXQgaW1wbHkgdGhhdCBNUCBjYW4gZ2VuZXJhdGUgdGVzdCB0 cmFmZmljIHdpdGhvdXQgaW5zdHJ1Y3Rpb25zDQo+IGZyb20gdGhlIENvbnRyb2xsZXI/IE9yIHRo aXMgaXMgdG8gZGVzY3JpYmUgb25lLXNpZGVkIHR3by13YXkgYWN0aXZlDQo+IG1lYXN1cmVtZW50 cyB3aGVuIE1QIHJlZmxlY3RzIG9yIHJlc3BvbmRzIHRvIHRlc3QgcGFja2V0cz8NClllcywgTVAg cmVzcG9uZGluZyB0byB0ZXN0IHBhY2tldChzKSBmcm9tIHRoZSBNQS4gaXMgdGhpcyByZS1waHJh c2UgY2xlYXJlcj8NCkdJTT4+ICJyZXNwb25kaW5nIHRvIiBkZWZpbml0ZWx5IGNsYXJpZmllcyB0 aGluZ3MgaGVyZS4NCg0KPDxhbmQvb3IgYW5vdGhlciBNZWFzdXJlbWVudCBBZ2VudCAob3IgYSBN ZWFzdXJlbWVudCBQZWVyLCBpbiByZXNwb25zZSB0byBwYWNrZXQocykgZnJvbSBhIE1BKSBzZW5k aW5nIEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIHRvIGEgTUE+Pg0KPg0KPiAiQWN0aXZlIE1l YXN1cmVtZW50IFRyYWZmaWMiIHN1Z2dlc3QgdG8gY2hhbmdlIHRvICJNZWFzdXJlbWVudCBUcmFm ZmljIg0KPiBiZWNhdXNlIHRoZXJlIGNhbm5vdCBiZSAiUGFzc2l2ZSBNZWFzdXJlbWVudCBUcmFm ZmljIi4NCkkgcHJlZmVyIHRvIGhhdmUgdGhlIHJlbWluZGVyIHRoYXQgaXQncyBBY3RpdmUuDQpH SU0+PiBNLW0tbQ0KDQo+DQo+ICJDYXBhYmlsaXRpZXM6IEluZm9ybWF0aW9uIGFib3V0IHRoZSBN ZWFzdXJlbWVudCBNZXRob2RzIHRoYXQgdGhlIE1BDQo+IGNhbiBwZXJmb3JtIC4uLiIgaXMgcGVy aGFwcyB0b28gc3BlY2lmaWMgd2l0aG91dCBpbmZvcm1hdGlvbmFsIG1vZGVsIG9mDQo+IENvbnRy b2wgUHJvdG9jb2wgYmVpbmcgZmluYWxpemVkLiBDb3VsZCB3ZSBzYXkgIkNhcGFiaWxpdGllczoN Cj4gSW5mb3JtYXRpb24gdGhhdCBjaGFyYWN0ZXJpemVzIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50 IGNhcGFiaWxpdGllcyBvZg0KPiB0aGUgTUEgLi4uDQpIb3cgYWJvdXQ6DQpDYXBhYmlsaXRpZXM6 IEluZm9ybWF0aW9uIGFib3V0IHRoZSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBjYXBhYmlsaXRp ZXMgb2YgdGhlIE1BLCBpbiBwYXJ0aWN1bGFyIHRoZSBNZWFzdXJlbWVudCBNZXRob2RzIHRoYXQg aXQgY2FuIHBlcmZvcm0sIGFuZCB0aGUgZGV2aWNlIGhvc3RpbmcgdGhlIE1BLCBmb3IgZXhhbXBs ZSBpdHMgaW50ZXJmYWNlIHR5cGUgYW5kIHNwZWVkLCBidXQgbm90IGR5bmFtaWMgaW5mb3JtYXRp b24uDQpHSU0+PiBXb3VsZCAiIHRoZSBkZXZpY2UgaG9zdGluZyB0aGUgTUEsIGZvciBleGFtcGxl IGl0cyBpbnRlcmZhY2UgdHlwZSBhbmQgc3BlZWQsIGJ1dCBub3QgZHluYW1pYyBpbmZvcm1hdGlv biIgYmUgY2FwYWNpdHkgb2YgdGhlIE1BIHJhdGhlciB0aGFuIGNhcGFiaWxpdHkgaW4gcmVnYXJk IHRvIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50Pw0KWy4uLl0NCuKAog0KPiBTZWN0aW9uIDUuMi4x ICJUaGUgSW5zdHJ1Y3Rpb24gZGVmaW5lcyB0aGUgZm9sbG93aW5nOiIgIGxpc3QgdGhhdA0KPiBm b2xsb3dzIGlzIHRvbyBzcGVjaWZpYyBmb3IgdGhlIGZyYW1ld29yayBkb2N1bWVudCBhbmQgbWF5 IGJlIG1vcmUNCj4gYXBwcm9wcmlhdGUgaW4gc3BlY2lmaWNhdGlvbiBvZiB0aGUgaW5mb3JtYXRp b25hbCBtb2RlbCBvciBjb250cm9sDQo+IHByb3RvY29sIGl0c2VsZi4NCj4g4oCiIFNlY3Rpb24g NS4yLjINCj4gIkNhcGFiaWxpdGllcyBhcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIE1BIHRoYXQg dGhlIENvbnRyb2xsZXIgbmVlZHMgdG8NCj4ga25vdyBpbiBvcmRlciB0byBjb3JyZWN0bHkgaW5z dHJ1Y3QgdGhlIE1BLCBzdWNoIGFzOiINCj4gSSB0aGluayB0aGF0IHRoZSBsaXN0IHRoYXQgZm9s bG93cyBhbmQgInN1Y2ggYXMiIGFyZSBtb3JlIGluIHBsYWNlIGluDQo+IHRoZSBpbmZvcm1hdGlv bmFsIG1vZGVsIGRvY3VtZW50IG9yIHVzZSAiZm9yIGV4YW1wbGUiIGNsYXVzZS4NCj4g4oCiIFNl Y3Rpb24gNS40DQo+ICJUaGUgUmVwb3J0IGNvbnRhaW5zOicNCj4gSG93IGFib3V0ICJUaGUgUmVw b3J0IG1heSBjb250YWluOiIgdGhlbiAicGVyaGFwcyIgY2FuIGJlIHJlbW92ZWQgZnJvbQ0KPiB0 aGUgbGFzdCBidWxsZXQNCkkgcmF0aGVyIGFncmVlIHdpdGggeW91ciBjb21tZW50cyBhYm91dCB0 aGUgdmFyaW91cyBsaXN0cyBiZWluZyB0b28gc3BlY2lmaWMgZm9yIHRoZSBmcmFtZXdvcmsuIFdp bGwgdGhpbmsgYWJvdXQuDQoNCg0KDQpSZWdhcmRzLCBHcmVnDQo+DQo+IE9uIFdlZCwgQXByIDIs IDIwMTQgYXQgNDo1OCBBTSwgUm9tYXNjYW51LCBEYW4gKERhbikNCj4gPGRyb21hc2NhQGF2YXlh LmNvbTxtYWlsdG86ZHJvbWFzY2FAYXZheWEuY29tPj4gd3JvdGU6DQo+IEhpLA0KPg0KPiBUaGlz IGlzIGEgMm5kIFdHTEMgZm9yIHRoZSBMTUFQIEZyYW1ld29yayBJLUQuIFBsZWFzZSBzZW5kIHlv dXINCj4gY29tbWVudHMgdG8gdGhlIFdHIG1haWwgbGlzdCB1bnRpbCBXZWRuZXNkYXkgNC8xNi4g SWYgeW91IGJlbGlldmUgdGhhdA0KPiB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHN1Ym1pc3Np b24gdG8gdGhlIElFU0cgYXMgSW5mb3JtYXRpb25hbCBSQyBhDQo+IHNob3J0IG1lc3NhZ2Ugc3Rh dGluZyB0aGlzIHdpbGwgYWxzbyBiZSB3ZWxjb21lLg0KPg0KPiBUaGUgZG9jdW1lbnQgaXMgYXZh aWxhYmxlIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1sbWFwLQ0KPiBmcmFt ZXdvcmstMDQudHh0Lg0KPg0KPiBUaGFua3MgYW5kIFJlZ2FyZHMsDQo+DQo+IERhbg0KPg0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBsbWFw IG1haWxpbmcgbGlzdA0KPiBsbWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYub3JnPg0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCg0K --_000_2845723087023D4CB5114223779FA9C8017944A625njfpsrvexg8re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkg bGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24x PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz5IaSBHcmVnLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz5UaGVyZSdzIG9uZSBjYXNlIHdoZXJlIEkgYWdyZWUgd2l0aCB5b3UsIHRoZSB3b3JkICZxdW90 O0FjdGl2ZSZxdW90OyBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPmRlc2NyaXB0aW9uIGluIHBhcmVudGhlc2lzIGlzIHJlZHVuZGFudCBpbiB0aGUgY2FzZSBi ZWxvdzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyDigKIgJnF1b3Q7TWVhc3Vy ZW1lbnQgVGFza3MgbWF5IGJlIEFjdGl2ZSAodGhlIE1BIGdlbmVyYXRlcyA8Yj5BY3RpdmU8L2I+ IE1lYXN1cmVtZW50PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsgVHJhZmZp YyBhbmQgbWVhc3VyZXMgc29tZSBtZXRyaWMgYXNzb2NpYXRlZCB3aXRoIGl0cyB0cmFuc2Zlciks IFBhc3NpdmU8YnI+Jmd0OyAodGhlIE1BIG9ic2VydmVzIHVzZXIgdHJhZmZpYyksIG9yIHNvbWUg aHlicmlkIGZvcm0gb2YgdGhlIHR3by4mcXVvdDs8YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz5CdXQgaGVyZSAoYW5kIHByb2JhYmx5IG90aGVyIHBsYWNlcyk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBw dCc+Jmd0OyAmcXVvdDtBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyZxdW90OyBzdWdnZXN0IHRv IGNoYW5nZSB0byAmcXVvdDtNZWFzdXJlbWVudCBUcmFmZmljJnF1b3Q7PGJyPiZndDsgYmVjYXVz ZSB0aGVyZSBjYW5ub3QgYmUgJnF1b3Q7UGFzc2l2ZSBNZWFzdXJlbWVudCBUcmFmZmljJnF1b3Q7 LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5bcGhpbF0gSSBwcmVmZXIgdG8gaGF2 ZSB0aGUgcmVtaW5kZXIgdGhhdCBpdCdzIEFjdGl2ZS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+R0lNJmd0OyZndDsgTS1tLW0gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+SSBhZ3Jl ZSB3aXRoIFBoaWwsIHRoZSBhZGplY3RpdmUgaXMgYSB1c2VmdWwgZm9yIGNsYXJpdHkuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkFsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJl aGFsZiBPZiA8L2I+R3JlZyBNaXJza3k8YnI+PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwg MTYsIDIwMTQgMToyOSBBTTxicj48Yj5Ubzo8L2I+IHBoaWxpcC5lYXJkbGV5QGJ0LmNvbTxicj48 Yj5DYzo8L2I+IGxtYXBAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmtAdG9vbHMu aWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbbG1hcF0gMm5kIFdHTEMgZm9yIGRyYWZ0 LWlldGYtbG1hcC1mcmFtZXdvcmsgKGNvcnJlY3RlZCBkYXktb2YtdGhlLXdlZWspPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48ZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5IaSBQaGlsLDxv OnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRv bToxMi4wcHQnPnRoYW5rIHlvdSBmb3IgeW91ciBraW5kIGNvbnNpZGVyYXRpb24gb2YgbXkgY29t bWVudHMuIEkndmUgY2xpcHBlZCBvbmVzIHdlJ3ZlIGFncmVlZCBvbiBhbHJlYWR5LiBQbGVhc2Ug ZmluZCBjb3VwbGUgZm9sbG93IHVwcyBpbi1saW5lZCBhbmQgdGFnZ2VkIGJ5IEdJTSZndDsmZ3Q7 LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5SZWdhcmRzLDxvOnA+PC9v OnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5HcmVnPG86cD48L286cD48L3A+PGRpdj48 ZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRv bToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9u IE1vbiwgQXByIDE0LCAyMDE0IGF0IDM6NDUgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbGlw LmVhcmRsZXlAYnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbGlwLmVhcmRsZXlAYnQuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkdyZWc8YnI+PGJy PlRoYW5rLXlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBjb21tZW50cy48YnI+U29tZSBmb2xsb3ctdXBz IGluIGxpbmU8YnI+PGJyPkJlc3Qgd2lzaGVzPGJyPnBoaWw8bzpwPjwvbzpwPjwvcD48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5bLi4uXTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbic+PHAgY2xhc3M9 TXNvTm9ybWFsPjxicj5JIHN1c3BlY3Qgd2UncmUgYWN0dWFsbHkgaW4gYWdyZWVtZW50IG9uIHRo ZSBiYXNpYyBwb2ludCAtIHRoZSBwcm90b2NvbHMgd2lsbCBiZSBkZWZpbmVkIGFzIGV4dGVuc2lv bnMgL3JlLXVzZSBvZiBleGlzdGluZyBwcm90b2NvbChzKSAobm90IGEgY29tcGxldGVseSBuZXcg cHJvdG9jb2wpLjxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5H SU0mZ3Q7Jmd0OyBZZXMsIGFncmVlLiBJdCBtaWdodCBiZSBnb29kIHRvIHN0YXRlIHRoYXQgaW4g dGhlIGZyYW1ld29yayBkb2N1bWVudCBleHBsaWNpdGx5LiA8bzpwPjwvbzpwPjwvcD48L2Rpdj48 YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48YnI+Jmd0Ozxicj4mZ3Q7IOKAoiAmcXVvdDtN ZWFzdXJlbWVudCBUYXNrcyBtYXkgYmUgQWN0aXZlICh0aGUgTUEgZ2VuZXJhdGVzIEFjdGl2ZSBN ZWFzdXJlbWVudDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tYm90dG9tOjEyLjBwdCc+Jmd0OyBUcmFmZmljIGFuZCBtZWFzdXJlcyBzb21lIG1ldHJp YyBhc3NvY2lhdGVkIHdpdGggaXRzIHRyYW5zZmVyKSwgUGFzc2l2ZTxicj4mZ3Q7ICh0aGUgTUEg b2JzZXJ2ZXMgdXNlciB0cmFmZmljKSwgb3Igc29tZSBoeWJyaWQgZm9ybSBvZiB0aGUgdHdvLiZx dW90Ozxicj4mZ3Q7IFVzdWFsbHkgYWN0aXZlIGFuZCBwYXNzaXZlIGRpc3RpbmN0aW9uIGJlaW5n IGRyYXduIGF0IHRoZSBsZXZlbCBvZjxicj4mZ3Q7IG1lYXN1cmVtZW50IG1ldGhvZHMgdGhhdCBp cyBtb3JlIGdlbmVyaWMgdGhhbiBtZWFzdXJlbWVudCB0YXNrLiBBbmQgSTxicj4mZ3Q7IHRoaW5r IHRoYXQgdGVybSAmcXVvdDtBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyZxdW90OyBpcyBhbWJp Z3VvdXMgaWYgeW91J3JlPGJyPiZndDsgdHJ5aW5nIHRvIGNoYXJhY3Rlcml6ZSB0ZXN0IHRyYWZm aWMuIEluIGFkZGl0aW9uLCBhIHBlcmZvcm1hbmNlIG1ldHJpYzxicj4mZ3Q7IG1heSBiZSBub3Qg bGltaXRlZCB0byBvbmx5IHRyYW5zZmVyIG9mIHRoZSB0ZXN0IHBhY2tldHMsIGJ1dCB0aGVpcjxi cj4mZ3Q7IHByb2Nlc3NpbmcgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5UaGlzIGlzIG9ubHkgdGhlIDNy ZCBwYXJhIG9mIHRoZSBpbnRyb2R1Y3Rvcnkgb3V0bGluZSBzZWN0aW9uLCB0byBnaXZlIHRoZSBy ZWFkZXIgdGhlIGltcHJlc3Npb24gd2hhdCBsbWFwIGlzIGFib3V0LiBJIGRvbuKAmXQgdGhpbmsg d2UgaGF2ZSB0byBpbmNsdWRlIGFsbCB0aGUgZGV0YWlscyBhbmQgcG9zc2libGUgdmFyaWFudHMs IHdoaWNoIGNvdWxkIGV2ZW4gYmUgY29uZnVzaW5nIGF0IHRoaXMgZWFybHkgc3RhZ2UuPGJyPkkg ZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB0aGUgdGVybSAmcXVvdDtBY3RpdmUgTWVhc3VyZW1lbnQg VHJhZmZpYyZxdW90OyBtYXkgYmUgYW1iaWd1b3VzLjxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90 ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5HSU0mZ3Q7Jmd0OyBUbyBtZSAmcXVvdDtNZWFzdXJl bWVudCBUcmFmZmljJnF1b3Q7IGlzIHdoYXQgQWN0aXZlIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50 IGluc2VydHMgYW5kIG1lYXN1cmVzIG9uLCB3aGF0IGFjdHVhbGx5IGRpZmZlcmVudGlhdGVzIEFj dGl2ZSBNZWFzdXJlbWVudCBtZXRob2RzIGZyb20gUGFzc2l2ZSBNZWFzdXJlbWVudC4gU2F5aW5n ICZxdW90O0FjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljJnF1b3Q7LCBmb3IgbWUsIG5vbi1uYXRp dmUgRW5nbGlzaCBzcGVha2VyLCBpbXBsaWVzIHRoYXQgdGhlcmUgbWF5IGJlIHN1Y2ggdGhpbmcg YXMgJnF1b3Q7UGFzc2l2ZSBNZWFzdXJlbWVudCBUcmFmZmljJnF1b3Q7LiA8bzpwPjwvbzpwPjwv cD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4nPjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7PGJyPiZndDsg4oCiICZx dW90O1RoZSBNQSBpcyBtYW5hZ2VkIGJ5IGEgQ29udHJvbGxlciB1c2luZyB0aGUgQ29udHJvbCBQ cm90b2NvbC4mcXVvdDs8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPiZndDsgUGVyaGFwcyAmcXVvdDtBIENvbnRyb2xsZXIg bWFuYWdlcyB0aGUgTUEgdGhyb3VnaCB1c2Ugb2YgdGhlIENvbnRyb2w8YnI+Jmd0OyBQcm90b2Nv bC4mcXVvdDs8YnI+Jmd0OyDigKIgJnF1b3Q7VGhlIE1BIHJlY2VpdmVzIEluc3RydWN0aW9ucyBm cm9tIHRoZSBDb250cm9sbGVyIGFib3V0IHdoaWNoPGJyPiZndDsgTWVhc3VyZW1lbnQgVGFza3Mg aXQgc2hvdWxkIHBlcmZvcm0gYW5kIHdoZW4uJnF1b3Q7PGJyPiZndDsgSSB0aGluayB0aGF0IGl0 IGlzIHByZW1hdHVyZSB0byBiZSBzbyBzcGVjaWZpYyBhYm91dCB3aGF0IGluZm9ybWF0aW9uPGJy PiZndDsgdGhlIE1BIHdvdWxkIHJlY2VpdmUgZnJvbSBpdHMgQ29udHJvbGxlci4gSSBjYW4gaW1h Z2luZSB0aGF0IE1BPGJyPiZndDsgcmVjZWl2ZXMgc2NoZWR1bGUgd2l0aCByZWZlcmVuY2VzIHRv IE1lYXN1cmVtZW50IE1ldGhvZHMgdGhhdCBhcmUgaW48YnI+Jmd0OyBQZXJmb3JtYW5jZSBSZWdp c3RyeSBhbmQgbmVjZXNzYXJ5IE1lYXN1cmVtZW50IFRhc2sgcGFyYW1ldGVycy48bzpwPjwvbzpw PjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+WWVzLCB0aGlzIGNvdWxkIGJlIGJldHRlciBw aHJhc2VkLiBIb3cgYWJvdXQ6PGJyPjxicj5BIENvbnRyb2xsZXIgbWFuYWdlcyB0aGUgTUEgdGhy b3VnaCB1c2Ugb2YgdGhlIENvbnRyb2wgUHJvdG9jb2wuIEl0IHNlbmRzIGFuIEluc3RydWN0aW9u IE1lc3NhZ2UgdG8gdGhlIE1BLCB3aGljaCBkZXNjcmliZXMgdGhlIE1lYXN1cmVtZW50IFRhc2tz IGl0IHNob3VsZCBwZXJmb3JtIGFuZCB3aGVuLjxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5HSU0mZ3Q7Jmd0OyBZZXMsIGFncmVlLiBQZXJoYXBzIGNhbiB1c2Ug cGx1cmFsIGluICZxdW90O0luc3RydWN0aW9uIE1lc3NhZ2VzJnF1b3Q7LiA8bzpwPjwvbzpwPjwv cD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48YnI+Jmd0OyDigKIgJnF1b3Q7 Li4uIG9yIGE8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWJvdHRvbToxMi4wcHQnPiZndDsgTWVhc3VyZW1lbnQgUGVlciAob3IgYW5vdGhlciBNZWFz dXJlbWVudCBBZ2VudCkgc2VuZGluZyBBY3RpdmU8YnI+Jmd0OyBNZWFzdXJlbWVudCBUcmFmZmlj IHRvIGEgTUEuJnF1b3Q7PGJyPiZndDsgRG9lcyB0aGF0IGltcGx5IHRoYXQgTVAgY2FuIGdlbmVy YXRlIHRlc3QgdHJhZmZpYyB3aXRob3V0IGluc3RydWN0aW9uczxicj4mZ3Q7IGZyb20gdGhlIENv bnRyb2xsZXI/IE9yIHRoaXMgaXMgdG8gZGVzY3JpYmUgb25lLXNpZGVkIHR3by13YXkgYWN0aXZl PGJyPiZndDsgbWVhc3VyZW1lbnRzIHdoZW4gTVAgcmVmbGVjdHMgb3IgcmVzcG9uZHMgdG8gdGVz dCBwYWNrZXRzPzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5ZZXMsIE1Q IHJlc3BvbmRpbmcgdG8gdGVzdCBwYWNrZXQocykgZnJvbSB0aGUgTUEuIGlzIHRoaXMgcmUtcGhy YXNlIGNsZWFyZXI/PG86cD48L286cD48L3A+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPkdJTSZndDsmZ3Q7ICZxdW90O3Jlc3BvbmRpbmcgdG8mcXVvdDsgZGVmaW5pdGVseSBj bGFyaWZpZXMgdGhpbmdzIGhlcmUuJm5ic3A7IDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1 b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp bic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPiZs dDsmbHQ7YW5kL29yIGFub3RoZXIgTWVhc3VyZW1lbnQgQWdlbnQgKG9yIGEgTWVhc3VyZW1lbnQg UGVlciwgaW4gcmVzcG9uc2UgdG8gcGFja2V0KHMpIGZyb20gYSBNQSkgc2VuZGluZyBBY3RpdmUg TWVhc3VyZW1lbnQgVHJhZmZpYyB0byBhIE1BJmd0OyZndDs8bzpwPjwvbzpwPjwvcD48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPiZndDs8YnI+Jmd0 OyAmcXVvdDtBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyZxdW90OyBzdWdnZXN0IHRvIGNoYW5n ZSB0byAmcXVvdDtNZWFzdXJlbWVudCBUcmFmZmljJnF1b3Q7PGJyPiZndDsgYmVjYXVzZSB0aGVy ZSBjYW5ub3QgYmUgJnF1b3Q7UGFzc2l2ZSBNZWFzdXJlbWVudCBUcmFmZmljJnF1b3Q7LjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIHByZWZlciB0byBoYXZlIHRoZSBy ZW1pbmRlciB0aGF0IGl0J3MgQWN0aXZlLjxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5HSU0mZ3Q7Jmd0OyBNLW0tbSA8bzpwPjwvbzpwPjwvcD48L2Rp dj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4nPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+PGJyPiZndDs8YnI+Jmd0OyAmcXVvdDtDYXBhYmlsaXRpZXM6IEluZm9ybWF0aW9u IGFib3V0IHRoZSBNZWFzdXJlbWVudCBNZXRob2RzIHRoYXQgdGhlIE1BPGJyPiZndDsgY2FuIHBl cmZvcm0gLi4uJnF1b3Q7IGlzIHBlcmhhcHMgdG9vIHNwZWNpZmljIHdpdGhvdXQgaW5mb3JtYXRp b25hbCBtb2RlbCBvZjxicj4mZ3Q7IENvbnRyb2wgUHJvdG9jb2wgYmVpbmcgZmluYWxpemVkLiBD b3VsZCB3ZSBzYXkgJnF1b3Q7Q2FwYWJpbGl0aWVzOjxicj4mZ3Q7IEluZm9ybWF0aW9uIHRoYXQg Y2hhcmFjdGVyaXplcyBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBjYXBhYmlsaXRpZXMgb2Y8YnI+ Jmd0OyB0aGUgTUEgLi4uPG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkhv dyBhYm91dDo8YnI+Q2FwYWJpbGl0aWVzOiBJbmZvcm1hdGlvbiBhYm91dCB0aGUgcGVyZm9ybWFu Y2UgbWVhc3VyZW1lbnQgY2FwYWJpbGl0aWVzIG9mIHRoZSBNQSwgaW4gcGFydGljdWxhciB0aGUg TWVhc3VyZW1lbnQgTWV0aG9kcyB0aGF0IGl0IGNhbiBwZXJmb3JtLCBhbmQgdGhlIGRldmljZSBo b3N0aW5nIHRoZSBNQSwgZm9yIGV4YW1wbGUgaXRzIGludGVyZmFjZSB0eXBlIGFuZCBzcGVlZCwg YnV0IG5vdCBkeW5hbWljIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5HSU0mZ3Q7Jmd0OyBXb3VsZCAmcXVvdDsgdGhlIGRldmlj ZSBob3N0aW5nIHRoZSBNQSwgZm9yIGV4YW1wbGUgaXRzIGludGVyZmFjZSB0eXBlIGFuZCBzcGVl ZCwgYnV0IG5vdCBkeW5hbWljIGluZm9ybWF0aW9uJnF1b3Q7IGJlIGNhcGFjaXR5IG9mIHRoZSBN QSByYXRoZXIgdGhhbiBjYXBhYmlsaXR5IGluIHJlZ2FyZCB0byBwZXJmb3JtYW5jZSBtZWFzdXJl bWVudD88bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4nPjxwIGNsYXNzPU1zb05vcm1hbD5b Li4uXTxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjEyLjBwdCc+4oCiPGJyPiZndDsgU2VjdGlvbiA1LjIuMSAmcXVvdDtUaGUgSW5zdHJ1 Y3Rpb24gZGVmaW5lcyB0aGUgZm9sbG93aW5nOiZxdW90OyZuYnNwOyBsaXN0IHRoYXQ8YnI+Jmd0 OyBmb2xsb3dzIGlzIHRvbyBzcGVjaWZpYyBmb3IgdGhlIGZyYW1ld29yayBkb2N1bWVudCBhbmQg bWF5IGJlIG1vcmU8YnI+Jmd0OyBhcHByb3ByaWF0ZSBpbiBzcGVjaWZpY2F0aW9uIG9mIHRoZSBp bmZvcm1hdGlvbmFsIG1vZGVsIG9yIGNvbnRyb2w8YnI+Jmd0OyBwcm90b2NvbCBpdHNlbGYuPGJy PiZndDsg4oCiIFNlY3Rpb24gNS4yLjI8YnI+Jmd0OyAmcXVvdDtDYXBhYmlsaXRpZXMgYXJlIGlu Zm9ybWF0aW9uIGFib3V0IHRoZSBNQSB0aGF0IHRoZSBDb250cm9sbGVyIG5lZWRzIHRvPGJyPiZn dDsga25vdyBpbiBvcmRlciB0byBjb3JyZWN0bHkgaW5zdHJ1Y3QgdGhlIE1BLCBzdWNoIGFzOiZx dW90Ozxicj4mZ3Q7IEkgdGhpbmsgdGhhdCB0aGUgbGlzdCB0aGF0IGZvbGxvd3MgYW5kICZxdW90 O3N1Y2ggYXMmcXVvdDsgYXJlIG1vcmUgaW4gcGxhY2UgaW48YnI+Jmd0OyB0aGUgaW5mb3JtYXRp b25hbCBtb2RlbCBkb2N1bWVudCBvciB1c2UgJnF1b3Q7Zm9yIGV4YW1wbGUmcXVvdDsgY2xhdXNl Ljxicj4mZ3Q7IOKAoiBTZWN0aW9uIDUuNDxicj4mZ3Q7ICZxdW90O1RoZSBSZXBvcnQgY29udGFp bnM6Jzxicj4mZ3Q7IEhvdyBhYm91dCAmcXVvdDtUaGUgUmVwb3J0IG1heSBjb250YWluOiZxdW90 OyB0aGVuICZxdW90O3BlcmhhcHMmcXVvdDsgY2FuIGJlIHJlbW92ZWQgZnJvbTxicj4mZ3Q7IHRo ZSBsYXN0IGJ1bGxldDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIHJh dGhlciBhZ3JlZSB3aXRoIHlvdXIgY29tbWVudHMgYWJvdXQgdGhlIHZhcmlvdXMgbGlzdHMgYmVp bmcgdG9vIHNwZWNpZmljIGZvciB0aGUgZnJhbWV3b3JrLiBXaWxsIHRoaW5rIGFib3V0LjxvOnA+ PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz48YnI+PGJyPjxicj5SZWdhcmRzLCBHcmVnPGJyPiZndDs8YnI+Jmd0OyBPbiBX ZWQsIEFwciAyLCAyMDE0IGF0IDQ6NTggQU0sIFJvbWFzY2FudSwgRGFuIChEYW4pPGJyPiZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpkcm9tYXNjYUBhdmF5YS5jb20iIHRhcmdldD0iX2JsYW5rIj5k cm9tYXNjYUBhdmF5YS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+Jmd0OyBIaSw8YnI+Jmd0Ozxicj4m Z3Q7IFRoaXMgaXMgYSAybmQgV0dMQyBmb3IgdGhlIExNQVAgRnJhbWV3b3JrIEktRC4gUGxlYXNl IHNlbmQgeW91cjxicj4mZ3Q7IGNvbW1lbnRzIHRvIHRoZSBXRyBtYWlsIGxpc3QgdW50aWwgV2Vk bmVzZGF5IDQvMTYuIElmIHlvdSBiZWxpZXZlIHRoYXQ8YnI+Jmd0OyB0aGUgZG9jdW1lbnQgaXMg cmVhZHkgZm9yIHN1Ym1pc3Npb24gdG8gdGhlIElFU0cgYXMgSW5mb3JtYXRpb25hbCBSQyBhPGJy PiZndDsgc2hvcnQgbWVzc2FnZSBzdGF0aW5nIHRoaXMgd2lsbCBhbHNvIGJlIHdlbGNvbWUuPGJy PiZndDs8YnI+Jmd0OyBUaGUgZG9jdW1lbnQgaXMgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1sbWFwLSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1sbWFwLTwvYT48YnI+Jmd0OyBmcmFtZXdvcmst MDQudHh0Ljxicj4mZ3Q7PGJyPiZndDsgVGhhbmtzIGFuZCBSZWdhcmRzLDxicj4mZ3Q7PGJyPiZn dDsgRGFuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgbG1hcCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyA8 YSBocmVmPSJtYWlsdG86bG1hcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxtYXBAaWV0Zi5v cmc8L2E+PGJyPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sbWFwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sbWFwPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_2845723087023D4CB5114223779FA9C8017944A625njfpsrvexg8re_-- From nobody Wed Apr 16 10:55: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 057231A01AC for ; Wed, 16 Apr 2014 10:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] 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 2djCQz_rqcRc for ; Wed, 16 Apr 2014 10:55:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7B72B1A0165 for ; Wed, 16 Apr 2014 10:55:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A91401117; Wed, 16 Apr 2014 19:54:58 +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 AnBU6L81c2CJ; Wed, 16 Apr 2014 19:54:58 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 16 Apr 2014 19:54:58 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A17E2002C; Wed, 16 Apr 2014 19:54:57 +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 8gv2DDBoBnRW; Wed, 16 Apr 2014 19:54:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3324520017; Wed, 16 Apr 2014 19:54:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8A9792C634EB; Wed, 16 Apr 2014 19:54:55 +0200 (CEST) Date: Wed, 16 Apr 2014 19:54:55 +0200 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20140416175455.GB13363@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , Greg Mirsky , "philip.eardley@bt.com" , "draft-ietf-lmap-framework@tools.ietf.org" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C8017944A625@njfpsrvexg8.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2845723087023D4CB5114223779FA9C8017944A625@njfpsrvexg8.research.att.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/lqjuE-QNDB3eySGmVape9dKqTgA Cc: Greg Mirsky , "philip.eardley@bt.com" , "lmap@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 16 Apr 2014 17:55:07 -0000 On Wed, Apr 16, 2014 at 09:55:29AM -0400, MORTON, ALFRED C (AL) wrote: > Hi Greg, > > There's one case where I agree with you, the word "Active" in the > description in parenthesis is redundant in the case below: > > > • "Measurement Tasks may be Active (the MA generates Active Measurement > > Traffic and measures some metric associated with its transfer), Passive > > (the MA observes user traffic), or some hybrid form of the two." > > > But here (and probably other places) > > "Active Measurement Traffic" suggest to change to "Measurement Traffic" > > because there cannot be "Passive Measurement Traffic". > [phil] I prefer to have the reminder that it's Active. > GIM>> M-m-m > > I agree with Phil, the adjective is a useful for clarity. > Suppose a function A is marking certain frames in a video stream (or a multmedia stream to be more general) and another functions B derives statistics from the observed marked stream(s). Is this active of passive measurement? Are A and/or B active of passive? Note that the stream may be originated by a regular application (controller by a human user). Is the marked stream measurement traffic (because it is marked)? I believe there can be valid things may not clearly active or passive and we should be careful to not over constrain things. /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 Apr 16 11:17: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 425351A01F2 for ; Wed, 16 Apr 2014 11:17:23 -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 xmTUqhB0Yxxs for ; Wed, 16 Apr 2014 11:17:18 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id ADF3D1A01B7 for ; Wed, 16 Apr 2014 11:17:18 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ld13so10952372vcb.5 for ; Wed, 16 Apr 2014 11:17:15 -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=kCwm2M2vIPXXTcg5+ahHUtGwG6htrcRyODyYvNPiv2U=; b=AuhGWAudhgiSiWfK5oqAn3XEJ4HUp3yPgrvAQarCOxZi42CDmJBHkeAl807tb2wdMx m8DPAjv7lcjynPbjFzXM/nTRlLKlTFshm+UFjjKPC0O+d8gVmFusxNBVy+7K8M2q4wbS 8d+fAez6yN1sEcD38nRl2uJD7Rng4uklcB+X/ShEwrPTQSNIKz278oL3oxxz/gC4XlxH USMTD5STUi6wKNSlyo2tqEvQrKk9bssD9Da5aTfcOST+9AB5nQH3u1HYpvfuLPB5q2fp rC56Xgzk/LE/XBAgafMFo+afipZrK7/DfaELPQ/Axm6gv+UPQmL8W2rh65Ox3tCIZj+p WH+Q== MIME-Version: 1.0 X-Received: by 10.220.95.204 with SMTP id e12mr1149865vcn.37.1397672235239; Wed, 16 Apr 2014 11:17:15 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Wed, 16 Apr 2014 11:17:15 -0700 (PDT) In-Reply-To: <20140416175455.GB13363@elstar.local> References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C8017944A625@njfpsrvexg8.research.att.com> <20140416175455.GB13363@elstar.local> Date: Wed, 16 Apr 2014 11:17:15 -0700 Message-ID: From: Greg Mirsky To: Juergen Schoenwaelder , "MORTON, ALFRED C (AL)" , Greg Mirsky , "philip.eardley@bt.com" , "draft-ietf-lmap-framework@tools.ietf.org" , "lmap@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1f3ec181bb404f72ced79 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/jhBkKMMyEFgGsYdF5j8W28du-n4 Cc: Mach Chen Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 16 Apr 2014 18:17:23 -0000 --001a11c1f3ec181bb404f72ced79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jurgen, this is very interesting scenario. I believe that marking or coloring of data traffic will still be considered as passive measurement method. The Coloring based IP Flow Performance Measurement Frameworkbeen discussed by IPPM WG as passive PM. Regards, Greg On Wed, Apr 16, 2014 at 10:54 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Apr 16, 2014 at 09:55:29AM -0400, MORTON, ALFRED C (AL) wrote: > > Hi Greg, > > > > There's one case where I agree with you, the word "Active" in the > > description in parenthesis is redundant in the case below: > > > > > =E2=80=A2 "Measurement Tasks may be Active (the MA generates Active M= easurement > > > Traffic and measures some metric associated with its transfer), Passi= ve > > > (the MA observes user traffic), or some hybrid form of the two." > > > > > > But here (and probably other places) > > > "Active Measurement Traffic" suggest to change to "Measurement Traffi= c" > > > because there cannot be "Passive Measurement Traffic". > > [phil] I prefer to have the reminder that it's Active. > > GIM>> M-m-m > > > > I agree with Phil, the adjective is a useful for clarity. > > > > Suppose a function A is marking certain frames in a video stream (or a > multmedia stream to be more general) and another functions B derives > statistics from the observed marked stream(s). Is this active of > passive measurement? Are A and/or B active of passive? Note that the > stream may be originated by a regular application (controller by a > human user). Is the marked stream measurement traffic (because it > is marked)? > > I believe there can be valid things may not clearly active or passive > and we should be careful to not over constrain things. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c1f3ec181bb404f72ced79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jurgen,
this is very interesting scenario= . I believe that marking or coloring of data traffic will still be consider= ed as passive measurement method. The Coloring based IP Flow = Performance Measurement Framework been discusse= d by IPPM WG as passive PM.

Regards,
Greg

On Wed, Apr 16, 2014 at 10:54 AM, Juergen Sc= hoenwaelder <j.schoenwaelder@jacobs-university.de&g= t; wrote:
On Wed, Apr 16, 2014 at 09:5= 5:29AM -0400, MORTON, ALFRED C (AL) wrote:
> Hi Greg,
>
> There's one case where I agree with you, the word "Active&quo= t; in the
> description in parenthesis is redundant in the case below:
>
> > =E2=80=A2 "Measurement Tasks may be Active (the MA generates= Active Measurement
> > Traffic and measures some metric associated with its transfer), P= assive
> > (the MA observes user traffic), or some hybrid form of the two.&q= uot;
>
>
> But here (and probably other places)
> > "Active Measurement Traffic" suggest to change to "= ;Measurement Traffic"
> > because there cannot be "Passive Measurement Traffic".<= br> > [phil] I prefer to have the reminder that it's Active.
> GIM>> M-m-m
>
> I agree with Phil, the adjective is a useful for clarity.
>

Suppose a function A is marking certain frames in a video stream (or = a
multmedia stream to be more general) and another functions B derives
statistics from the observed marked stream(s). Is this active of
passive measurement? Are A and/or B active of passive? Note that the
stream may be originated by a regular application (controller by a
human user). Is the marked stream measurement traffic (because it
is marked)?

I believe there can be valid things may not clearly active or passive
and we should be careful to not over constrain things.

/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/= >

--001a11c1f3ec181bb404f72ced79-- From nobody Wed Apr 16 11:41: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 9105B1A02A8 for ; Wed, 16 Apr 2014 11:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] 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 zyh2HhtNoV2y for ; Wed, 16 Apr 2014 11:41:50 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id EB91D1A02AF for ; Wed, 16 Apr 2014 11:41:41 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 01655A0532; Wed, 16 Apr 2014 14:41:38 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id AC52CA053B; Wed, 16 Apr 2014 14:41: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; Wed, 16 Apr 2014 14:41:37 -0400 From: Sharam Hakimi To: Greg Mirsky , Juergen Schoenwaelder , "MORTON, ALFRED C (AL)" , "philip.eardley@bt.com" , "draft-ietf-lmap-framework@tools.ietf.org" , "lmap@ietf.org" Thread-Topic: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) Thread-Index: AQHPVeHQAxRH3P/qJEeeYrIvAbV7FgB4FqnwAAAFqGCbED/4gIAAjX2AgABC5YCAAAY+gP//wjPQ Date: Wed, 16 Apr 2014 18:41:36 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B703F56E@SPQCMBX02.exfo.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C8017944A625@njfpsrvexg8.research.att.com> <20140416175455.GB13363@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: multipart/alternative; boundary="_000_89294A6F3C6C91459E52E4128C4B02B703F56ESPQCMBX02exfocom_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20636.001 X-TM-AS-Result: No--40.258-5.0-31-10 X-imss-scan-details: No--40.258-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20636.001 X-TMASE-Result: 10--40.258400-5.000000 X-TMASE-MatchedRID: Bc0mRW5ole+1k1cDolfKcmYQJPSPOa+99GbSSaq0f4Ozt581RJuJjjHI 1pZ73L7IwEfaqp0O2ZrNRsyOiZyYypZ6zKu0q4rtpzPA3TKVblixdSEXl3A98ToJopYIBpMcsfJ 5vKZeu+hEnh8FeYne0O9VsdrlGzy3yfU1Q7XTnmRrRM6wvXgDaUene5ELSwGv1Fc61VCGvh07uv k6QO/AI42WQSzu3zX3mlaAItiONP1l0qH7/7HRjhBVEcLcHoVg7W77TXnsTTsT/RLASEHM5o0pf ouzkP9TnEpyfsnNrVLAJnGRMfFxyX5ErfRqpilVf7RPWCFK8GJDRSQugtjx5kBYpG41WHMFEBJg M+7lfPWFmMEVwi+q3YD9LizgRBhQ/qWl+m17jWFdyvHnunOio4doJ48qeu9Ej7tE2dXz/ueDawG ArWYMM3QvYvS2EELjBltLYABgX+/zntDOT82LMxhaPDHak0t0cYHt6o8WLQftrOUgP2EDLIFaNa PuEIbSo5RUoF1j1rj1NV6ZtjddkoJLRBMDwnOkSf6CBl8sl/LUwFANvZQmQvdN82ulzP0CFCOLN e0Jd9NZiostRfaYC7iMC5wdwKqddwX/SSKrKHgPGMG6AkHPPKBDB389eXAYzAxLg4NeYKxaTYT7 jtOnD5J+pRMlvKpCIj0zFI5DoJItUSMDHceMrqTsE8Z/jrr+zdlo26al4KGW00p9LWWxDyhiPa9 5Af6o7FxgpZHLiQcOsNNBnlgRWn0tCKdnhB58r10pknZXGJqy5/tFZu9S3D+pcdR2EjjbH8208X iWi2Ij80Za3RRg8JmlEElD+43gByCYlbiKR/lxnxJFIjigoEOg/fe7m87j1X+AIG3Y6X8= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/yZY-FMCO_pG1eW7lOKNzdU6Swu0 Cc: Mach Chen Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 16 Apr 2014 18:41:55 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B703F56ESPQCMBX02exfocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBBY3RpdmUgaXMgd2hlbiB0aGUgdGVzdCBkZXZpY2UgKCBpbiB0aGlzIGNhc2UgTUEg b3IgTUEgd2l0aCBpdHMgcGVlcikgZ2VuZXJhdGVzIHRyYWZmaWMgaW4gb3JkZXIgdG8gbWFrZSB0 aGUgbWVhc3VyZW1lbnQuIFdoZW4gYW5vdGhlciBkZXZpY2Ugb3RoZXIgdGhhbiB0aGUgbWVhc3Vy ZW1lbnQgZGV2aWNlIGdlbmVyYXRlcyB0cmFmZmljIGFuZCB0aGUgbWVhc3VyZW1lbnQgZGV2aWNl IGlzIGp1c3QgbGlzdGVuaW5nIG9uIHRoZSBuZXR3b3JrIHRoZW4gaXQgd291bGQgYmUgYSBwYXNz aXZlIG1lYXN1cmVtZW50LiBUaGlzIGlzIHJlZ2FyZGxlc3Mgb2YgdGhlIHByb2Nlc3NpbmcgdGhl IHBhc3NpdmUgZGV2aWNlIGRvZXMgb24gdGhlIGNhcHR1cmVkIGRhdGEuDQoNClRoYW5rcywNClNo YXJhbQ0KDQpGcm9tOiBsbWFwIFttYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgR3JlZyBNaXJza3kNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTYsIDIwMTQgMjoxNyBQ TQ0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgTU9SVE9OLCBBTEZSRUQgQyAoQUwpOyBHcmVn IE1pcnNreTsgcGhpbGlwLmVhcmRsZXlAYnQuY29tOyBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3Jr QHRvb2xzLmlldGYub3JnOyBsbWFwQGlldGYub3JnDQpDYzogTWFjaCBDaGVuDQpTdWJqZWN0OiBS ZTogW2xtYXBdIDJuZCBXR0xDIGZvciBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrIChjb3JyZWN0 ZWQgZGF5LW9mLXRoZS13ZWVrKQ0KDQpIaSBKdXJnZW4sDQp0aGlzIGlzIHZlcnkgaW50ZXJlc3Rp bmcgc2NlbmFyaW8uIEkgYmVsaWV2ZSB0aGF0IG1hcmtpbmcgb3IgY29sb3Jpbmcgb2YgZGF0YSB0 cmFmZmljIHdpbGwgc3RpbGwgYmUgY29uc2lkZXJlZCBhcyBwYXNzaXZlIG1lYXN1cmVtZW50IG1l dGhvZC4gVGhlIENvbG9yaW5nIGJhc2VkIElQIEZsb3cgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQg RnJhbWV3b3JrPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4taXBwbS1jb2xv cmluZy1iYXNlZC1pcGZwbS1mcmFtZXdvcmstMDE+IGJlZW4gZGlzY3Vzc2VkIGJ5IElQUE0gV0cg YXMgcGFzc2l2ZSBQTS4NCg0KUmVnYXJkcywNCkdyZWcNCk9uIFdlZCwgQXByIDE2LCAyMDE0IGF0 IDEwOjU0IEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMt dW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl Pj4gd3JvdGU6DQpPbiBXZWQsIEFwciAxNiwgMjAxNCBhdCAwOTo1NToyOUFNIC0wNDAwLCBNT1JU T04sIEFMRlJFRCBDIChBTCkgd3JvdGU6DQo+IEhpIEdyZWcsDQo+DQo+IFRoZXJlJ3Mgb25lIGNh c2Ugd2hlcmUgSSBhZ3JlZSB3aXRoIHlvdSwgdGhlIHdvcmQgIkFjdGl2ZSIgaW4gdGhlDQo+IGRl c2NyaXB0aW9uIGluIHBhcmVudGhlc2lzIGlzIHJlZHVuZGFudCBpbiB0aGUgY2FzZSBiZWxvdzoN Cj4NCj4gPiDigKIgIk1lYXN1cmVtZW50IFRhc2tzIG1heSBiZSBBY3RpdmUgKHRoZSBNQSBnZW5l cmF0ZXMgQWN0aXZlIE1lYXN1cmVtZW50DQo+ID4gVHJhZmZpYyBhbmQgbWVhc3VyZXMgc29tZSBt ZXRyaWMgYXNzb2NpYXRlZCB3aXRoIGl0cyB0cmFuc2ZlciksIFBhc3NpdmUNCj4gPiAodGhlIE1B IG9ic2VydmVzIHVzZXIgdHJhZmZpYyksIG9yIHNvbWUgaHlicmlkIGZvcm0gb2YgdGhlIHR3by4i DQo+DQo+DQo+IEJ1dCBoZXJlIChhbmQgcHJvYmFibHkgb3RoZXIgcGxhY2VzKQ0KPiA+ICJBY3Rp dmUgTWVhc3VyZW1lbnQgVHJhZmZpYyIgc3VnZ2VzdCB0byBjaGFuZ2UgdG8gIk1lYXN1cmVtZW50 IFRyYWZmaWMiDQo+ID4gYmVjYXVzZSB0aGVyZSBjYW5ub3QgYmUgIlBhc3NpdmUgTWVhc3VyZW1l bnQgVHJhZmZpYyIuDQo+IFtwaGlsXSBJIHByZWZlciB0byBoYXZlIHRoZSByZW1pbmRlciB0aGF0 IGl0J3MgQWN0aXZlLg0KPiBHSU0+PiBNLW0tbQ0KPg0KPiBJIGFncmVlIHdpdGggUGhpbCwgdGhl IGFkamVjdGl2ZSBpcyBhIHVzZWZ1bCBmb3IgY2xhcml0eS4NCj4NClN1cHBvc2UgYSBmdW5jdGlv biBBIGlzIG1hcmtpbmcgY2VydGFpbiBmcmFtZXMgaW4gYSB2aWRlbyBzdHJlYW0gKG9yIGENCm11 bHRtZWRpYSBzdHJlYW0gdG8gYmUgbW9yZSBnZW5lcmFsKSBhbmQgYW5vdGhlciBmdW5jdGlvbnMg QiBkZXJpdmVzDQpzdGF0aXN0aWNzIGZyb20gdGhlIG9ic2VydmVkIG1hcmtlZCBzdHJlYW0ocyku IElzIHRoaXMgYWN0aXZlIG9mDQpwYXNzaXZlIG1lYXN1cmVtZW50PyBBcmUgQSBhbmQvb3IgQiBh Y3RpdmUgb2YgcGFzc2l2ZT8gTm90ZSB0aGF0IHRoZQ0Kc3RyZWFtIG1heSBiZSBvcmlnaW5hdGVk IGJ5IGEgcmVndWxhciBhcHBsaWNhdGlvbiAoY29udHJvbGxlciBieSBhDQpodW1hbiB1c2VyKS4g SXMgdGhlIG1hcmtlZCBzdHJlYW0gbWVhc3VyZW1lbnQgdHJhZmZpYyAoYmVjYXVzZSBpdA0KaXMg bWFya2VkKT8NCg0KSSBiZWxpZXZlIHRoZXJlIGNhbiBiZSB2YWxpZCB0aGluZ3MgbWF5IG5vdCBj bGVhcmx5IGFjdGl2ZSBvciBwYXNzaXZlDQphbmQgd2Ugc2hvdWxkIGJlIGNhcmVmdWwgdG8gbm90 IG92ZXIgY29uc3RyYWluIHRoaW5ncy4NCg0KL2pzDQoNCi0tDQpKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0 MjEgMjAwIDM1ODc8dGVsOiUyQjQ5JTIwNDIxJTIwMjAwJTIwMzU4Nz4gICAgICAgICBDYW1wdXMg UmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzPHRl bDolMkI0OSUyMDQyMSUyMDIwMCUyMDMxMDM+ICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVu aXZlcnNpdHkuZGUvPg0KDQo= --_000_89294A6F3C6C91459E52E4128C4B02B703F56ESPQCMBX02exfocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQog cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdl IFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SSB0aGluayBBY3RpdmUgaXMgd2hlbiB0aGUg dGVzdCBkZXZpY2UgKCBpbiB0aGlzIGNhc2UgTUEgb3IgTUEgd2l0aCBpdHMgcGVlcikgZ2VuZXJh dGVzIHRyYWZmaWMgaW4gb3JkZXIgdG8gbWFrZSB0aGUgbWVhc3VyZW1lbnQuIFdoZW4gYW5vdGhl ciBkZXZpY2Ugb3RoZXINCiB0aGFuIHRoZSBtZWFzdXJlbWVudCBkZXZpY2UgZ2VuZXJhdGVzIHRy YWZmaWMgYW5kIHRoZSBtZWFzdXJlbWVudCBkZXZpY2UgaXMganVzdCBsaXN0ZW5pbmcgb24gdGhl IG5ldHdvcmsgdGhlbiBpdCB3b3VsZCBiZSBhIHBhc3NpdmUgbWVhc3VyZW1lbnQuIFRoaXMgaXMg cmVnYXJkbGVzcyBvZiB0aGUgcHJvY2Vzc2luZyB0aGUgcGFzc2l2ZSBkZXZpY2UgZG9lcyBvbiB0 aGUgY2FwdHVyZWQgZGF0YS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+U2hhcmFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGxtYXAgW21haWx0bzpsbWFwLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdyZWcgTWlyc2t5PGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMTYsIDIwMTQgMjoxNyBQTTxicj4NCjxiPlRvOjwv Yj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBNT1JUT04sIEFMRlJFRCBDIChBTCk7IEdyZWcgTWly c2t5OyBwaGlsaXAuZWFyZGxleUBidC5jb207IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmtAdG9v bHMuaWV0Zi5vcmc7IGxtYXBAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IE1hY2ggQ2hlbjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW2xtYXBdIDJuZCBXR0xDIGZvciBkcmFmdC1pZXRmLWxtYXAt ZnJhbWV3b3JrIChjb3JyZWN0ZWQgZGF5LW9mLXRoZS13ZWVrKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEp1cmdlbiw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhpcyBpcyB2ZXJ5IGludGVyZXN0aW5n IHNjZW5hcmlvLiBJIGJlbGlldmUgdGhhdCBtYXJraW5nIG9yIGNvbG9yaW5nIG9mIGRhdGEgdHJh ZmZpYyB3aWxsIHN0aWxsIGJlIGNvbnNpZGVyZWQgYXMgcGFzc2l2ZSBtZWFzdXJlbWVudCBtZXRo b2QuIFRoZQ0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1p cHBtLWNvbG9yaW5nLWJhc2VkLWlwZnBtLWZyYW1ld29yay0wMSI+DQpDb2xvcmluZyBiYXNlZCBJ UCBGbG93IFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IEZyYW1ld29yazwvYT4gYmVlbiBkaXNjdXNz ZWQgYnkgSVBQTSBXRyBhcyBwYXNzaXZlIFBNLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+R3JlZzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFdlZCwgQXByIDE2LCAyMDE0IGF0IDEwOjU0IEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg Jmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUi IHRhcmdldD0iX2JsYW5rIj5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIFdlZCwgQXByIDE2LCAyMDE0IGF0IDA5OjU1 OjI5QU0gLTA0MDAsIE1PUlRPTiwgQUxGUkVEIEMgKEFMKSB3cm90ZTo8YnI+DQomZ3Q7IEhpIEdy ZWcsPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlcmUncyBvbmUgY2FzZSB3aGVyZSBJIGFncmVlIHdp dGggeW91LCB0aGUgd29yZCAmcXVvdDtBY3RpdmUmcXVvdDsgaW4gdGhlPGJyPg0KJmd0OyBkZXNj cmlwdGlvbiBpbiBwYXJlbnRoZXNpcyBpcyByZWR1bmRhbnQgaW4gdGhlIGNhc2UgYmVsb3c6PGJy Pg0KJmd0Ozxicj4NCiZndDsgJmd0OyDigKIgJnF1b3Q7TWVhc3VyZW1lbnQgVGFza3MgbWF5IGJl IEFjdGl2ZSAodGhlIE1BIGdlbmVyYXRlcyBBY3RpdmUgTWVhc3VyZW1lbnQ8YnI+DQomZ3Q7ICZn dDsgVHJhZmZpYyBhbmQgbWVhc3VyZXMgc29tZSBtZXRyaWMgYXNzb2NpYXRlZCB3aXRoIGl0cyB0 cmFuc2ZlciksIFBhc3NpdmU8YnI+DQomZ3Q7ICZndDsgKHRoZSBNQSBvYnNlcnZlcyB1c2VyIHRy YWZmaWMpLCBvciBzb21lIGh5YnJpZCBmb3JtIG9mIHRoZSB0d28uJnF1b3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IEJ1dCBoZXJlIChhbmQgcHJvYmFibHkgb3RoZXIgcGxhY2VzKTxi cj4NCiZndDsgJmd0OyAmcXVvdDtBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyZxdW90OyBzdWdn ZXN0IHRvIGNoYW5nZSB0byAmcXVvdDtNZWFzdXJlbWVudCBUcmFmZmljJnF1b3Q7PGJyPg0KJmd0 OyAmZ3Q7IGJlY2F1c2UgdGhlcmUgY2Fubm90IGJlICZxdW90O1Bhc3NpdmUgTWVhc3VyZW1lbnQg VHJhZmZpYyZxdW90Oy48YnI+DQomZ3Q7IFtwaGlsXSBJIHByZWZlciB0byBoYXZlIHRoZSByZW1p bmRlciB0aGF0IGl0J3MgQWN0aXZlLjxicj4NCiZndDsgR0lNJmd0OyZndDsgTS1tLW08YnI+DQom Z3Q7PGJyPg0KJmd0OyBJIGFncmVlIHdpdGggUGhpbCwgdGhlIGFkamVjdGl2ZSBpcyBhIHVzZWZ1 bCBmb3IgY2xhcml0eS48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlN1cHBvc2UgYSBmdW5jdGlvbiBBIGlzIG1hcmtpbmcgY2VydGFpbiBmcmFt ZXMgaW4gYSB2aWRlbyBzdHJlYW0gKG9yIGE8YnI+DQptdWx0bWVkaWEgc3RyZWFtIHRvIGJlIG1v cmUgZ2VuZXJhbCkgYW5kIGFub3RoZXIgZnVuY3Rpb25zIEIgZGVyaXZlczxicj4NCnN0YXRpc3Rp Y3MgZnJvbSB0aGUgb2JzZXJ2ZWQgbWFya2VkIHN0cmVhbShzKS4gSXMgdGhpcyBhY3RpdmUgb2Y8 YnI+DQpwYXNzaXZlIG1lYXN1cmVtZW50PyBBcmUgQSBhbmQvb3IgQiBhY3RpdmUgb2YgcGFzc2l2 ZT8gTm90ZSB0aGF0IHRoZTxicj4NCnN0cmVhbSBtYXkgYmUgb3JpZ2luYXRlZCBieSBhIHJlZ3Vs YXIgYXBwbGljYXRpb24gKGNvbnRyb2xsZXIgYnkgYTxicj4NCmh1bWFuIHVzZXIpLiBJcyB0aGUg bWFya2VkIHN0cmVhbSBtZWFzdXJlbWVudCB0cmFmZmljIChiZWNhdXNlIGl0PGJyPg0KaXMgbWFy a2VkKT88YnI+DQo8YnI+DQpJIGJlbGlldmUgdGhlcmUgY2FuIGJlIHZhbGlkIHRoaW5ncyBtYXkg bm90IGNsZWFybHkgYWN0aXZlIG9yIHBhc3NpdmU8YnI+DQphbmQgd2Ugc2hvdWxkIGJlIGNhcmVm dWwgdG8gbm90IG92ZXIgY29uc3RyYWluIHRoaW5ncy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KL2pzPGJyPg0KPGJyPg0KLS08YnI+DQpK dWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBK YWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8YnI+DQpQaG9uZTogPGEgaHJlZj0idGVsOiUy QjQ5JTIwNDIxJTIwMjAwJTIwMzU4NyI+JiM0Mzs0OSA0MjEgMjAwIDM1ODc8L2E+ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnk8 YnI+DQpGYXg6ICZuYnNwOyA8YSBocmVmPSJ0ZWw6JTJCNDklMjA0MjElMjAyMDAlMjAzMTAzIj4m IzQzOzQ5IDQyMSAyMDAgMzEwMzwvYT4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8 YSBocmVmPSJodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_89294A6F3C6C91459E52E4128C4B02B703F56ESPQCMBX02exfocom_-- From nobody Wed Apr 16 11:46:28 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA84A1A0213 for ; Wed, 16 Apr 2014 11:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 TIN9UJX0jxeT for ; Wed, 16 Apr 2014 11:46:23 -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 7589E1A01E5 for ; Wed, 16 Apr 2014 11:46:23 -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 6BF4755476D; Wed, 16 Apr 2014 14:46:25 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id D8E33E01E5; Wed, 16 Apr 2014 14:46:18 -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; Wed, 16 Apr 2014 14:46:19 -0400 From: "MORTON, ALFRED C (AL)" To: Greg Mirsky , Juergen Schoenwaelder , "philip.eardley@bt.com" , "draft-ietf-lmap-framework@tools.ietf.org" , "lmap@ietf.org" Date: Wed, 16 Apr 2014 14:46:18 -0400 Thread-Topic: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) Thread-Index: Ac9ZoB9acArwJqsdSc+HVwYl8XWuYgAAlvCg Message-ID: <2845723087023D4CB5114223779FA9C8017944A713@njfpsrvexg8.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E46EF03@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C8017944A625@njfpsrvexg8.research.att.com> <20140416175455.GB13363@elstar.local> In-Reply-To: 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_2845723087023D4CB5114223779FA9C8017944A713njfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/cWzCXsNISQsWNIKTEwOiphScCZE Cc: Mach Chen Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week) 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, 16 Apr 2014 18:46:27 -0000 --_000_2845723087023D4CB5114223779FA9C8017944A713njfpsrvexg8re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KQWx0aG91Z2ggdGhpcyBtYXkgaGF2ZSBiZWVuIGRpc2N1c3NlZCBhcyBhIHBhc3Np dmUgdGVjaG5pcXVlLA0KY29sb3JpbmcgKG1hcmtpbmcgdXNlciB0cmFmZmljKSBpcyBub3QgcHVy ZWx5IHBhc3NpdmUsIGFuZCB0aGlzIGZhbGxzDQppbiB0aGUgaHlicmlkIGNhdGVnb3J5IChwYXJ0 IG9mIHRoZSBzdHJlYW0gaXMgZGVkaWNhdGVkIHRvIG1lYXN1cmVtZW50KS4NClRoZSB2NlBETSBw cm9wb3NhbCBmYWxscyBpbiB0aGlzIGNhdGVnb3J5LCB0b28uDQoNCkkgZHVnIHVwIElQUE0ncyBw cmV2aW91cyBkaXNjdXNzaW9uIG9mIHRoZSB0YXhvbm9teSBvZiBoeWJyaWQgdHlwZXMsDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lwcG0vY3VycmVudC9tc2cwMjk1Mi5o dG1sDQphbmQgdGhpcyAoY29sb3JpbmcvUERNKSB3b3VsZCBiZSBhbm90aGVyIHR5cGUgdG8gYWRk Lg0KDQpBbA0KDQpGcm9tOiBHcmVnIE1pcnNreSBbbWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNv bV0NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTYsIDIwMTQgMjoxNyBQTQ0KVG86IEp1ZXJnZW4g U2Nob2Vud2FlbGRlcjsgTU9SVE9OLCBBTEZSRUQgQyAoQUwpOyBHcmVnIE1pcnNreTsgcGhpbGlw LmVhcmRsZXlAYnQuY29tOyBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrQHRvb2xzLmlldGYub3Jn OyBsbWFwQGlldGYub3JnDQpDYzogTWFjaCBDaGVuDQpTdWJqZWN0OiBSZTogW2xtYXBdIDJuZCBX R0xDIGZvciBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrIChjb3JyZWN0ZWQgZGF5LW9mLXRoZS13 ZWVrKQ0KDQpIaSBKdXJnZW4sDQp0aGlzIGlzIHZlcnkgaW50ZXJlc3Rpbmcgc2NlbmFyaW8uIEkg YmVsaWV2ZSB0aGF0IG1hcmtpbmcgb3IgY29sb3Jpbmcgb2YgZGF0YSB0cmFmZmljIHdpbGwgc3Rp bGwgYmUgY29uc2lkZXJlZCBhcyBwYXNzaXZlIG1lYXN1cmVtZW50IG1ldGhvZC4gVGhlIENvbG9y aW5nIGJhc2VkIElQIEZsb3cgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgRnJhbWV3b3JrPGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4taXBwbS1jb2xvcmluZy1iYXNlZC1pcGZw bS1mcmFtZXdvcmstMDE+IGJlZW4gZGlzY3Vzc2VkIGJ5IElQUE0gV0cgYXMgcGFzc2l2ZSBQTS4N Cg0KUmVnYXJkcywNCkdyZWcNCk9uIFdlZCwgQXByIDE2LCAyMDE0IGF0IDEwOjU0IEFNLCBKdWVy Z2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxt YWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQpPbiBX ZWQsIEFwciAxNiwgMjAxNCBhdCAwOTo1NToyOUFNIC0wNDAwLCBNT1JUT04sIEFMRlJFRCBDIChB TCkgd3JvdGU6DQo+IEhpIEdyZWcsDQo+DQo+IFRoZXJlJ3Mgb25lIGNhc2Ugd2hlcmUgSSBhZ3Jl ZSB3aXRoIHlvdSwgdGhlIHdvcmQgIkFjdGl2ZSIgaW4gdGhlDQo+IGRlc2NyaXB0aW9uIGluIHBh cmVudGhlc2lzIGlzIHJlZHVuZGFudCBpbiB0aGUgY2FzZSBiZWxvdzoNCj4NCj4gPiDigKIgIk1l YXN1cmVtZW50IFRhc2tzIG1heSBiZSBBY3RpdmUgKHRoZSBNQSBnZW5lcmF0ZXMgQWN0aXZlIE1l YXN1cmVtZW50DQo+ID4gVHJhZmZpYyBhbmQgbWVhc3VyZXMgc29tZSBtZXRyaWMgYXNzb2NpYXRl ZCB3aXRoIGl0cyB0cmFuc2ZlciksIFBhc3NpdmUNCj4gPiAodGhlIE1BIG9ic2VydmVzIHVzZXIg dHJhZmZpYyksIG9yIHNvbWUgaHlicmlkIGZvcm0gb2YgdGhlIHR3by4iDQo+DQo+DQo+IEJ1dCBo ZXJlIChhbmQgcHJvYmFibHkgb3RoZXIgcGxhY2VzKQ0KPiA+ICJBY3RpdmUgTWVhc3VyZW1lbnQg VHJhZmZpYyIgc3VnZ2VzdCB0byBjaGFuZ2UgdG8gIk1lYXN1cmVtZW50IFRyYWZmaWMiDQo+ID4g YmVjYXVzZSB0aGVyZSBjYW5ub3QgYmUgIlBhc3NpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyIuDQo+ IFtwaGlsXSBJIHByZWZlciB0byBoYXZlIHRoZSByZW1pbmRlciB0aGF0IGl0J3MgQWN0aXZlLg0K PiBHSU0+PiBNLW0tbQ0KPg0KPiBJIGFncmVlIHdpdGggUGhpbCwgdGhlIGFkamVjdGl2ZSBpcyBh IHVzZWZ1bCBmb3IgY2xhcml0eS4NCj4NClN1cHBvc2UgYSBmdW5jdGlvbiBBIGlzIG1hcmtpbmcg Y2VydGFpbiBmcmFtZXMgaW4gYSB2aWRlbyBzdHJlYW0gKG9yIGENCm11bHRtZWRpYSBzdHJlYW0g dG8gYmUgbW9yZSBnZW5lcmFsKSBhbmQgYW5vdGhlciBmdW5jdGlvbnMgQiBkZXJpdmVzDQpzdGF0 aXN0aWNzIGZyb20gdGhlIG9ic2VydmVkIG1hcmtlZCBzdHJlYW0ocykuIElzIHRoaXMgYWN0aXZl IG9mDQpwYXNzaXZlIG1lYXN1cmVtZW50PyBBcmUgQSBhbmQvb3IgQiBhY3RpdmUgb2YgcGFzc2l2 ZT8gTm90ZSB0aGF0IHRoZQ0Kc3RyZWFtIG1heSBiZSBvcmlnaW5hdGVkIGJ5IGEgcmVndWxhciBh cHBsaWNhdGlvbiAoY29udHJvbGxlciBieSBhDQpodW1hbiB1c2VyKS4gSXMgdGhlIG1hcmtlZCBz dHJlYW0gbWVhc3VyZW1lbnQgdHJhZmZpYyAoYmVjYXVzZSBpdA0KaXMgbWFya2VkKT8NCg0KSSBi ZWxpZXZlIHRoZXJlIGNhbiBiZSB2YWxpZCB0aGluZ3MgbWF5IG5vdCBjbGVhcmx5IGFjdGl2ZSBv ciBwYXNzaXZlDQphbmQgd2Ugc2hvdWxkIGJlIGNhcmVmdWwgdG8gbm90IG92ZXIgY29uc3RyYWlu IHRoaW5ncy4NCg0KL2pzDQoNCi0tDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEph Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODc8dGVs OiUyQjQ5JTIwNDIxJTIwMjAwJTIwMzU4Nz4gICAgICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBC cmVtZW4sIEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzPHRlbDolMkI0OSUyMDQyMSUy MDIwMCUyMDMxMDM+ICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K DQo= --_000_2845723087023D4CB5114223779FA9C8017944A713njfpsrvexg8re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkg bGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24x PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz5HcmVnLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ QWx0aG91Z2ggdGhpcyBtYXkgaGF2ZSBiZWVuIGRpc2N1c3NlZCBhcyBhIHBhc3NpdmUgdGVjaG5p cXVlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Y29sb3JpbmcgKG1h cmtpbmcgdXNlciB0cmFmZmljKSBpcyBub3QgcHVyZWx5IHBhc3NpdmUsIGFuZCB0aGlzIGZhbGxz PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5pbiB0aGUgaHlicmlkIGNh dGVnb3J5IChwYXJ0IG9mIHRoZSBzdHJlYW0gaXMgZGVkaWNhdGVkIHRvIG1lYXN1cmVtZW50KS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlRoZSB2NlBETSBwcm9wb3Nh bCBmYWxscyBpbiB0aGlzIGNhdGVnb3J5LCB0b28uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPkkgZHVnIHVwIElQUE0ncyBwcmV2aW91cyBkaXNjdXNzaW9uIG9mIHRoZSB0YXhvbm9teSBv ZiBoeWJyaWQgdHlwZXMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lwcG0vY3VycmVudC9tc2cwMjk1 Mi5odG1sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5hbmQgdGhpcyAo Y29sb3JpbmcvUERNKSB3b3VsZCBiZSBhbm90aGVyIHR5cGUgdG8gYWRkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz5BbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRp dj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IEdyZWcgTWlyc2t5IFttYWlsdG86Z3JlZ2ltaXJza3lA Z21haWwuY29tXSA8YnI+PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMTYsIDIwMTQgMjox NyBQTTxicj48Yj5Ubzo8L2I+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgTU9SVE9OLCBBTEZSRUQg QyAoQUwpOyBHcmVnIE1pcnNreTsgcGhpbGlwLmVhcmRsZXlAYnQuY29tOyBkcmFmdC1pZXRmLWxt YXAtZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnOyBsbWFwQGlldGYub3JnPGJyPjxiPkNjOjwvYj4g TWFjaCBDaGVuPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2xtYXBdIDJuZCBXR0xDIGZvciBkcmFm dC1pZXRmLWxtYXAtZnJhbWV3b3JrIChjb3JyZWN0ZWQgZGF5LW9mLXRoZS13ZWVrKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5IaSBKdXJnZW4sPG86cD48L286 cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRoaXMgaXMgdmVyeSBpbnRlcmVzdGluZyBz Y2VuYXJpby4gSSBiZWxpZXZlIHRoYXQgbWFya2luZyBvciBjb2xvcmluZyBvZiBkYXRhIHRyYWZm aWMgd2lsbCBzdGlsbCBiZSBjb25zaWRlcmVkIGFzIHBhc3NpdmUgbWVhc3VyZW1lbnQgbWV0aG9k LiBUaGUgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1pcHBt LWNvbG9yaW5nLWJhc2VkLWlwZnBtLWZyYW1ld29yay0wMSI+Q29sb3JpbmcgYmFzZWQgSVAgRmxv dyBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBGcmFtZXdvcms8L2E+IGJlZW4gZGlzY3Vzc2VkIGJ5 IElQUE0gV0cgYXMgcGFzc2l2ZSBQTS48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+R3JlZzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gV2VkLCBBcHIgMTYsIDIwMTQgYXQgMTA6NTQgQU0sIEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBq YWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxhbmsiPmouc2Nob2Vud2FlbGRlckBqYWNv YnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+T24gV2VkLCBBcHIgMTYs IDIwMTQgYXQgMDk6NTU6MjlBTSAtMDQwMCwgTU9SVE9OLCBBTEZSRUQgQyAoQUwpIHdyb3RlOjxi cj4mZ3Q7IEhpIEdyZWcsPGJyPiZndDs8YnI+Jmd0OyBUaGVyZSdzIG9uZSBjYXNlIHdoZXJlIEkg YWdyZWUgd2l0aCB5b3UsIHRoZSB3b3JkICZxdW90O0FjdGl2ZSZxdW90OyBpbiB0aGU8YnI+Jmd0 OyBkZXNjcmlwdGlvbiBpbiBwYXJlbnRoZXNpcyBpcyByZWR1bmRhbnQgaW4gdGhlIGNhc2UgYmVs b3c6PGJyPiZndDs8YnI+Jmd0OyAmZ3Q7IOKAoiAmcXVvdDtNZWFzdXJlbWVudCBUYXNrcyBtYXkg YmUgQWN0aXZlICh0aGUgTUEgZ2VuZXJhdGVzIEFjdGl2ZSBNZWFzdXJlbWVudDxicj4mZ3Q7ICZn dDsgVHJhZmZpYyBhbmQgbWVhc3VyZXMgc29tZSBtZXRyaWMgYXNzb2NpYXRlZCB3aXRoIGl0cyB0 cmFuc2ZlciksIFBhc3NpdmU8YnI+Jmd0OyAmZ3Q7ICh0aGUgTUEgb2JzZXJ2ZXMgdXNlciB0cmFm ZmljKSwgb3Igc29tZSBoeWJyaWQgZm9ybSBvZiB0aGUgdHdvLiZxdW90Ozxicj4mZ3Q7PGJyPiZn dDs8YnI+Jmd0OyBCdXQgaGVyZSAoYW5kIHByb2JhYmx5IG90aGVyIHBsYWNlcyk8YnI+Jmd0OyAm Z3Q7ICZxdW90O0FjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljJnF1b3Q7IHN1Z2dlc3QgdG8gY2hh bmdlIHRvICZxdW90O01lYXN1cmVtZW50IFRyYWZmaWMmcXVvdDs8YnI+Jmd0OyAmZ3Q7IGJlY2F1 c2UgdGhlcmUgY2Fubm90IGJlICZxdW90O1Bhc3NpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyZxdW90 Oy48YnI+Jmd0OyBbcGhpbF0gSSBwcmVmZXIgdG8gaGF2ZSB0aGUgcmVtaW5kZXIgdGhhdCBpdCdz IEFjdGl2ZS48YnI+Jmd0OyBHSU0mZ3Q7Jmd0OyBNLW0tbTxicj4mZ3Q7PGJyPiZndDsgSSBhZ3Jl ZSB3aXRoIFBoaWwsIHRoZSBhZGplY3RpdmUgaXMgYSB1c2VmdWwgZm9yIGNsYXJpdHkuPGJyPiZn dDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U3VwcG9zZSBhIGZ1bmN0 aW9uIEEgaXMgbWFya2luZyBjZXJ0YWluIGZyYW1lcyBpbiBhIHZpZGVvIHN0cmVhbSAob3IgYTxi cj5tdWx0bWVkaWEgc3RyZWFtIHRvIGJlIG1vcmUgZ2VuZXJhbCkgYW5kIGFub3RoZXIgZnVuY3Rp b25zIEIgZGVyaXZlczxicj5zdGF0aXN0aWNzIGZyb20gdGhlIG9ic2VydmVkIG1hcmtlZCBzdHJl YW0ocykuIElzIHRoaXMgYWN0aXZlIG9mPGJyPnBhc3NpdmUgbWVhc3VyZW1lbnQ/IEFyZSBBIGFu ZC9vciBCIGFjdGl2ZSBvZiBwYXNzaXZlPyBOb3RlIHRoYXQgdGhlPGJyPnN0cmVhbSBtYXkgYmUg b3JpZ2luYXRlZCBieSBhIHJlZ3VsYXIgYXBwbGljYXRpb24gKGNvbnRyb2xsZXIgYnkgYTxicj5o dW1hbiB1c2VyKS4gSXMgdGhlIG1hcmtlZCBzdHJlYW0gbWVhc3VyZW1lbnQgdHJhZmZpYyAoYmVj YXVzZSBpdDxicj5pcyBtYXJrZWQpPzxicj48YnI+SSBiZWxpZXZlIHRoZXJlIGNhbiBiZSB2YWxp ZCB0aGluZ3MgbWF5IG5vdCBjbGVhcmx5IGFjdGl2ZSBvciBwYXNzaXZlPGJyPmFuZCB3ZSBzaG91 bGQgYmUgY2FyZWZ1bCB0byBub3Qgb3ZlciBjb25zdHJhaW4gdGhpbmdzLjxvOnA+PC9vOnA+PC9w PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPi9qczxicj48YnI+LS08YnI+SnVlcmdl biBTY2hvZW53YWVsZGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSmFjb2Jz IFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPGJyPlBob25lOiA8YSBocmVmPSJ0ZWw6JTJCNDklMjA0 MjElMjAyMDAlMjAzNTg3Ij4rNDkgNDIxIDIwMCAzNTg3PC9hPiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55PGJyPkZheDogJm5i c3A7IDxhIGhyZWY9InRlbDolMkI0OSUyMDQyMSUyMDIwMCUyMDMxMDMiPis0OSA0MjEgMjAwIDMx MDM8L2E+ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cDovL3d3 dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmphY29i cy11bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2 PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_2845723087023D4CB5114223779FA9C8017944A713njfpsrvexg8re_-- From nobody Wed Apr 16 12:49: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 D20641A02CF for ; Wed, 16 Apr 2014 12:49:47 -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 Rl7TbA_ZFlK4 for ; Wed, 16 Apr 2014 12:49:45 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id DA1B91A030E for ; Wed, 16 Apr 2014 12:49:45 -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 s3GJnenX011518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Apr 2014 13:49:40 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 610791E0049; Wed, 16 Apr 2014 14:49:35 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 46F671E0077; Wed, 16 Apr 2014 14:49:35 -0500 (CDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s3GJnYhj025868; Wed, 16 Apr 2014 14:49:34 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s3GJnYgr025857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 14:49:34 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Wed, 16 Apr 2014 14:49:34 -0500 From: "Bugenhagen, Michael K" To: "'MORTON, ALFRED C (AL)'" , "'MARCELO BAGNULO BRAUN'" , "'lmap@ietf.org'" Thread-Topic: [lmap] lmap framework and IPPM registries. Thread-Index: AQHPV/EOB5WK3snlxk28YEUSrOuMq5sTcnuAgAE2OlA= Date: Wed, 16 Apr 2014 19:49:33 +0000 Message-ID: References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <2845723087023D4CB5114223779FA9C8017944A577@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017944A577@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/RwvSFQwKffqbPfy_JrXoCcYL1U0 Subject: Re: [lmap] lmap framework and IPPM registries. 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, 16 Apr 2014 19:49:48 -0000 Marcelo, Al, One gap I think we have here is how to identify a common set of "networ= k environment" attributes that need to be used by the tests. They aren't identified in the test methodology as a common abstract MIB, or= attribute across the board so this needs to be handled elsewhere. My assumption what that it would be in the registry as some type of "header= " or description on how to execute a test, but if I'm following you that as= sumption is wrong. Example - Cross Traffic, or customer traffic...=20 Some tests have assumptions about the presence of this, and when it's accep= table to do the test, or not based on it's existence. Given there is NO common MIB / attribute for it today... this becomes an is= sue in defining the "test method" Kind of a gap... with different ways to close it. Regards, Mike =20 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Tuesday, April 15, 2014 3:14 PM To: MARCELO BAGNULO BRAUN; lmap@ietf.org Subject: Re: [lmap] lmap framework and IPPM registries. For me and those whose needs I understand, a URI for metrics seems useful. = I would guess that IANA has already been asked for some form of ID persiste= nce, and if they agree to provide when requested, then it would be a (new) = requirement in the IANA section. Also, we need both a metric and a method of measurement, these are both pre= sent in our current version of the metric registry. >From Framework 5.2.1 Instruction o the Measurement Task configurations, each of which needs: * the Measurement Method, specified as a URN to a registry entry. The registry could be defined by the IETF [I-D.manyfolks-ippm-metric-registry], locally by the operator of the measurement system or perhaps by another standards organisation. So let's fix this as follows: o the Measurement Task configurations, each of which needs: * the Registered Metric, specified as a URI to a registry entry, and which includes the specification of a Measurement Method. The registry could be defined by the IETF [I-D.manyfolks-ippm-metric-registry], locally by the operator of the measurement system or perhaps by another standards organisation. (off-list discussion contributed to this suggestion), Al Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MARCELO BAGNULO > BRAUN > Sent: Monday, April 14, 2014 10:50 AM > To: lmap@ietf.org > Subject: [lmap] lmap framework and IPPM registries. >=20 > Hi, >=20 > One issue i realized is that the current lmap framework states the the > measurement method is specified as a URN to a registry entry, while the > current IPPM registry draft do not have a URN as metric identifier but > a name and a metric identifier. >=20 > I think it is very important that these two efforts are aligned so i > suggest that we discuss whether a URN is the proper way to go or the > current flat identifier proposed in the ippm registry drafts. >=20 > I am uncertain what is the benefit of an URN versus a flat identifier. > Regards, marcelo >=20 >=20 > -- > ---- > MARCELO BAGNULO BRAUN > WebCartero > Universidad Carlos III de Madrid >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Apr 16 13:11: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 972C01A02A7 for ; Wed, 16 Apr 2014 13:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 aBtCrx5DCo3T for ; Wed, 16 Apr 2014 13:10:57 -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 A20721A0291 for ; Wed, 16 Apr 2014 13:10:57 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id BDF3E5546CA; Wed, 16 Apr 2014 16:10:59 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id 5CFFBF0141; Wed, 16 Apr 2014 16:10:54 -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; Wed, 16 Apr 2014 16:10:54 -0400 From: "MORTON, ALFRED C (AL)" To: "Bugenhagen, Michael K" , 'MARCELO BAGNULO BRAUN' , "'lmap@ietf.org'" Date: Wed, 16 Apr 2014 16:10:53 -0400 Thread-Topic: [lmap] lmap framework and IPPM registries. Thread-Index: AQHPV/EOB5WK3snlxk28YEUSrOuMq5sTcnuAgAE2OlCAAATvEA== Message-ID: <2845723087023D4CB5114223779FA9C8017944A75D@njfpsrvexg8.research.att.com> References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <2845723087023D4CB5114223779FA9C8017944A577@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/YMxNOv0GaNHbCT9EUvKhexW04rI Subject: Re: [lmap] lmap framework and IPPM registries. 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, 16 Apr 2014 20:11:02 -0000 In the original registry proposal(s) over a year ago now, we had an Environment (sub) Registry: http://tools.ietf.org/html/draft-bagnulo-ippm-new-registry-00#section-2.3 We were convinced to take this out of the registry design,=20 it's not really part of the metric specifications and there=20 likely were other reasons I've forgotten, but it's out now for good. The Info model draft covers this topic. http://tools.ietf.org/html/draft-ietf-lmap-information-model-00#section-3.7 ... The result data rows may optionally include an indication of the cross-traffic (e.g., the total number of octets of non-measurement traffic passing through the interfaces used by a Measurement Task during the measurement period). Al > -----Original Message----- > From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com] > Sent: Wednesday, April 16, 2014 3:50 PM > To: MORTON, ALFRED C (AL); 'MARCELO BAGNULO BRAUN'; 'lmap@ietf.org' > Subject: RE: [lmap] lmap framework and IPPM registries. >=20 > Marcelo, Al, >=20 > One gap I think we have here is how to identify a common set of > "network environment" attributes that need to be used by the tests. > They aren't identified in the test methodology as a common abstract MIB, > or attribute across the board so this needs to be handled elsewhere. >=20 > My assumption what that it would be in the registry as some type of > "header" or description on how to execute a test, but if I'm following yo= u > that assumption is wrong. >=20 > Example - >=20 > Cross Traffic, or customer traffic... >=20 > Some tests have assumptions about the presence of this, and when it's > acceptable to do the test, or not based on it's existence. > Given there is NO common MIB / attribute for it today... this becomes an > issue in defining the "test method" >=20 > Kind of a gap... with different ways to close it. >=20 > Regards, > Mike >=20 >=20 >=20 >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C > (AL) > Sent: Tuesday, April 15, 2014 3:14 PM > To: MARCELO BAGNULO BRAUN; lmap@ietf.org > Subject: Re: [lmap] lmap framework and IPPM registries. >=20 > For me and those whose needs I understand, a URI for metrics seems useful= . > I would guess that IANA has already been asked for some form of ID > persistence, and if they agree to provide when requested, then it would b= e > a (new) requirement in the IANA section. >=20 > Also, we need both a metric and a method of measurement, these are both > present in our current version of the metric registry. >=20 > >From Framework 5.2.1 Instruction >=20 > o the Measurement Task configurations, each of which needs: >=20 > * the Measurement Method, specified as a URN to a registry entry. > The registry could be defined by the IETF > [I-D.manyfolks-ippm-metric-registry], locally by the operator > of the measurement system or perhaps by another standards > organisation. >=20 > So let's fix this as follows: >=20 > o the Measurement Task configurations, each of which needs: >=20 > * the Registered Metric, specified as a URI to a registry entry, > and which includes the specification of a Measurement Method. > The registry could be defined by the IETF > [I-D.manyfolks-ippm-metric-registry], locally by the operator > of the measurement system or perhaps by another standards > organisation. >=20 > (off-list discussion contributed to this suggestion), Al >=20 >=20 > Al >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MARCELO BAGNULO > > BRAUN > > Sent: Monday, April 14, 2014 10:50 AM > > To: lmap@ietf.org > > Subject: [lmap] lmap framework and IPPM registries. > > > > Hi, > > > > One issue i realized is that the current lmap framework states the the > > measurement method is specified as a URN to a registry entry, while the > > current IPPM registry draft do not have a URN as metric identifier but > > a name and a metric identifier. > > > > I think it is very important that these two efforts are aligned so i > > suggest that we discuss whether a URN is the proper way to go or the > > current flat identifier proposed in the ippm registry drafts. > > > > I am uncertain what is the benefit of an URN versus a flat identifier. > > Regards, marcelo > > > > > > -- > > ---- > > MARCELO BAGNULO BRAUN > > WebCartero > > Universidad Carlos III de Madrid > > > > _______________________________________________ > > 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 Sat Apr 19 12:23: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 438B81A0087 for ; Sat, 19 Apr 2014 12:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 d7sdqDRP_RSr for ; Sat, 19 Apr 2014 12:23:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA031A0078 for ; Sat, 19 Apr 2014 12:23:37 -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 s3JJNWQO001879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 19 Apr 2014 14:23:32 -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 s3JJNWT0015337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 19 Apr 2014 15:23:32 -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; Sat, 19 Apr 2014 15:23:32 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMg== Date: Sat, 19 Apr 2014 19:23:33 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719532956@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.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7719532956US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ohFW-TqqJPDv3uuJ4Y_ocvVaw6U Subject: [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, 19 Apr 2014 19:23:40 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7719532956US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Team, The BBF is looking at standardizing the model for Timers as suggested by th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7719532956US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Team,

 

The BBF is looking at standardizing the model for Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_9966516C6EB5FC4381E05BF80AA55F7719532956US70UWXCHMBA05z_-- From nobody Sun Apr 20 06: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 948ED1A01D6 for ; Sun, 20 Apr 2014 06:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 lkilJT7Zf1lY for ; Sun, 20 Apr 2014 06:00:19 -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 928A71A01D5 for ; Sun, 20 Apr 2014 06:00:18 -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 dd4c3535.0.887618.00-2094.2458900.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 20 Apr 2014 13:00:14 +0000 (UTC) X-MXL-Hash: 5353c4de5cd20523-5db3966b66e9a71fadf5fd33278077dd6b8fbde6 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 s3KD0D8H009950 for ; Sun, 20 Apr 2014 09:00:13 -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 s3KD07E0009660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 20 Apr 2014 09:00:10 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (GAALPA1MSGHUB9E.itservices.sbc.com [130.8.36.91]) by alpi133.aldc.att.com (RSA Interceptor) for ; Sun, 20 Apr 2014 12:59:45 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.03.0174.001; Sun, 20 Apr 2014 08:59:46 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: framework comments Thread-Index: Ac9cl9SeoAXxoO+sT62j3uhhwzLuTw== Date: Sun, 20 Apr 2014 12:59:45 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130425DAF@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.148.21] 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=xKBz7aRw5-8A:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=JBYBXF9Mo] X-AnalysisOut: [JI7nPB6nCwA:9 a=CjuIK1q_8ugA:10 a=FPFlgvEr_CvIpu_d:21 a=h1] X-AnalysisOut: [ZJni2hD3RhBfzW:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/tgahj2rBYCjqsPDAldkGyoQ1odg Subject: [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: Sun, 20 Apr 2014 13:00:22 -0000 First let me apologize for not having gotten my comments in before the dead= line. I left for vacation shortly after the start of WGLC and have had very= , very limited email and Internet access, or time for non-vacation activiti= es. Barbara General comments 1. I'm concerned about descriptions of "the scope of LMAP" vs. "the scope o= f LMAP WG" vs. "the scope of this framework for LMAP" vs. "the scope of the= LMAP WG charter". I think that what we chartered the LMAP WG to do limits = the scope of this framework for large-scale measurement platforms (LMAP) at= this time. It does not limit the scope of all possible LMAPs (future WG ch= arters or all large-scale measurement platforms) for all time. Where there = is distinction described between "LMAP" and "IPPM" scope (so that LMAP is r= eally the WG more than the term), I agree with the description of "out-of-s= cope" for LMAP (WG) being permanent. Where we could conceive of the LMAP WG= possibly being re-chartered in the future to take on additional tasks, or = other organizations describing large-scale measurement platforms that encom= pass more, I think we should describe the restriction as being out-of-scope= of this framework for LMAP, or out-of-scope of the current LMAP WG charter= , rather than out-of-scope of (all) large-scale measurement platforms (LMAP= ) or the LMAP WG (forever). Part of the problem for me does seem to be that= LMAP is both the WG and a term, and it's sometimes hard to tell which is b= eing referred to.=20 I suggest doing a search for "scope" and making the object of scoping "LMAP= WG", "the current LMAP WG charter", or "this framework for LMAP", as appro= priate. 2. Location of MA: This framework seems to assume the MA is always within a= customer premises network. Is that necessarily true? Use-cases doesn't see= m to indicate this. For example, in the case where measurements are done in= an ONT (fiber termination point, which may be dedicated to a single subscr= iber or serve many in a MDU), the MA would be fully within the ISP network.= Or it could be in a DSLAM and not specific to a single subscriber. If we c= onsider the non-regulatory, ISP-controlled, trouble-shooting use case (whic= h I thought was included in scope and is described in use-cases) then it do= esn't seem like an MA *always* is associated with a single subscriber. But = this case does not seem to be covered by this framework, because there are = many statements that assume MA-to-subscriber association is part of the bas= ic framework. Note that BBF use of MA does not restrict it to being interna= l to or at edge of subscriber network, or to having a necessary subscriber = relationship. Following are some statements where I would recommend expandi= ng the description to include elements outside the customer premises: 1. Introduction: "These devices could be software based agents on PCs, embe= dded agents in consumer devices (e.g. blu-ray players), service provider co= ntrolled devices such as set-top players and home gateways, or simply dedic= ated probes." 6.2. Measurement Agent [this section should have examples of MAs located e= lsewhere in ISP networks and such.] ---------------------------------------------------------------------------= ---- Specific Comments: 1. Introduction o Large-scale - [I-D.ietf-lmap-use-cases] envisages Measurement Agents in every home gateway and edge device such as set-top-boxes and tablet computers. It is expected that a measurement system could easily encompass a few hundred thousand Measurement Agents. Existing systems have up to a few thousand MAs (without judging how much further they could scale). Comment: Why only a few hundred thousand? For the incredibly bandwidth-heav= y regulatory-type use case, I think this is to many. For ISP use cases, I t= hink we're looking at millions. -------------------------------------------------------------------- 2. Outline of an LMAP-based measurement system The main work of the LMAP working group is to define the Control Protocol between the Controller and MA, and the Report Protocol between the MA and Collector. =20 Comment: I realize Greg already commented on this and Phil responded that h= e agreed. But it wasn't clear to me exactly what would be done about it. My= preference would be to use the charter phrase: " The LMAP working group is= chartered to specify an information model, the associated data models, and= select/extend one or more protocols for the secure communication:" I would= prefer not to debate which of these items are "main" (implying the others = are lesser deliverables).=20 -------- A device with a Measurement Agent may have multiple interfaces (Wi-Fi, Ethernet, DSL, fibre, etc.) and the Measurement Tasks may specify any one of these. Comment: Only PHY interfaces are listed. I would recommend listing other in= terfaces as well (that carry IP) to make it clear the term is not limited t= o PHY interfaces. Such as PPPoE, L2TP, 6rd, DS-Lite, IPsec. --------- Measurement Tasks may be Active (the MA generates Active Measurement Traffic and measures some metric associated with its transfer), Passive (the MA observes user traffic), or some hybrid form of the two. Comment: I recommend deleting "user" from the phrase, unless we really are = restricting MAs to only be associated with specific subscribers. --------- The data analysis tools receive the results from the Collector or via the Results repository. They might visualise the data or identify which component or link is likely to be the cause of a fault or degradation. Comment: What does it mean to visualize data? I'm unfamiliar with this word= in this context. ---------------------------------------------- 3. Terminology Subscriber: An entity (associated with one or more users) that is engaged in a subscription with a service provider. The Subscriber is allowed to subscribe and un-subscribe services, and to register a user or a list of users authorized to enjoy these services. [Q1741]. Both the Subscriber and service provider are allowed to set the limits relative to the use that associated users make of subscribed services. Comment: The reference is to a 3GPP document and the last 2 sentences are v= ery 3GPP-specific and not relevant to the concept of a wireline subscriber.= I recommend deleting the last 2 sentences from this definition. ----------------------------------------------- 4.1. Measurement system is under the direction of a single organisation In the LMAP framework, the measurement system is under the direction of a single organisation that is responsible for any impact that measurements have on a user's quality of experience and privacy. Comment: Recommend "... that is responsible for any impact that its measure= ments have..." They cannot be responsible for the impact of others' measure= ments. ------------------------------------------------ 5.3.1. Starting and Stopping Measurement Tasks ... o the MA checking that there is no cross-traffic. In other words, a check that the end-user isn't already sending traffic; Comment: It may not be the end user directly engaged in sending the traffic= . It may be some other autonomous or scheduled application. Recommend "...t= hat the end-user or other application isn't..." ,,, o the first part of the Measurement Task consisting of traffic that probes the path to make sure it isn't overloaded; o the first part of the Measurement Task checking that the device with the MA has enough resources to execute the Measurement Task reliably. Note that the designer of the measurement system should ensure that the device's capabilities are normally sufficient to comfortably operate the Measurement Tasks. It is possible that similar checks continue during the Measurement Task , ... Comment: This describes a very unusual and inefficient way of designing "Me= asurement Tasks". It suggests that a Measurement Method can be something ve= ry complex with multiple, disparate test protocols. Personally, I would use= a Measurement Schedule to identify a sequence of atomic Measurement Tasks,= rather than define mega Measurement Methods that combine lots of stuff tog= ether so that a single Measurement Task is really a whole sequence of diffe= rent tests. I don't object to people doing it this way if that's what they = want, I just want to make absolutely sure that it's not going to end up bei= ng mandated or assumed that mega Measurement Methods must be defined, inste= ad of allowing measurement system operators to define a sequence of individ= ual Tasks within a Measurement Schedule. ....... 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 doin= g measurements if it didn't hear from the Controller in a while. ....... It is likely to be important to include in the Measurement Report the fact that the Measurement Task overlapped with another. Comment: I think "It may be important..." rather than "likely to be importa= nt". What is important is knowing whether or not (and how much) cross-traff= ic is present. The precise nature of the cross traffic (that it was another= Measurement Task) isn't that important. ...........................................................................= . 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 t= here being Push, Pull, and multicast transport protocols. Multicast only ha= ppens 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 characteristic= s. 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. ...........................................................................= . 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 desi= gn (such as one that is just for the ISP use case and has nothing to do wit= h regulatory use case)? ------------------------------------------------------------- 6.1. Controller and the measurement system ... ; if it will, then the measurement system may need to compensate the Subscriber, for instance . Comment: This statement needs to be deleted. This document is no place for = speculation regarding compensation models. ------------------------------------------------------------- 6.2.2. Measurement Agent embedded in site gateway ... However, if the site gateway is owned and operated by the service provider, the Measurement Agent will generally not be directly available for over the top providers, the regulator, end users or enterprises. Comment: True. But it's also true that where the gateway is owned by the en= d user, it's even less likely that it will be available for service provide= rs, ott providers or regulators. End-user owned gateway is a common model, = so I would suggest mentioning this fact as well. -------------------------------------------------------------- 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 ha= s to do with UPnP. Why not just mention STUN as an option for keeping NAT t= able entries from timing out? ------------------------------------------------------------- 7. Security considerations Reporting by the MA must also be secured to maintain confidentiality. The results must be encrypted such that only the authorised Collector can decrypt the results to prevent the leakage of confidential or private information. =20 Comment: There are other ways of securing communications. For example, wher= e the MA is in a fiber ONT or other ISP network element (generally for ISP = troubleshooting and not the regulatory use case), the communication may occ= ur over the ISP's dedicated management network. In this case, encryption is= not needed. Therefore I disagree that the results must be encrypted. The s= econd sentence could be changed to start "Where encryption is used, the res= ults must be..." ... A malicious party could "game the system". For example, where a regulator is running a measurement system in order to benchmark operators, an operator could try to identify the broadband lines that the regulator was measuring and prioritise that traffic. This potential issue is currently handled by a code of conduct. It is outside the scope of the LMAP WG to consider the issue. Comment: The existence of a code of conduct is not universally true. I sugg= est deleting this sentence. -------------------------------- 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 b= e located in a place where it is associated with a single end user or subsc= riber. I recommend " Passive Measurement Tasks can be conducted on a user= 's traffic ,..." ------------------------------------- 8.4.1. MA Bootstrapping ... During the Bootstrap process, the MA receives its MA-ID which is a persistent pseudonym for the Subscriber ... Comment: Only true if the MA is associated with a specific subscriber.=20 -------------------------------------- 8.5. Threats Comment: I recommend mentioning some of the threats described in the Securi= ty section here, especially the possibility of DoS attacks. I think DoS att= acks pose a huge threat. -------------------------------------- 8.5.4. Secondary Use and Disclosure ... Passive Measurement Tasks are a form of Secondary Use, and the Subscribers' permission and the measured ISP's permission should be obtained beforehand . =20 Comment: This "should" statement as it applies to subscribers is dependent = on national laws and regulations. How it applies to ISPs, I don't understan= d. In what case is someone supposed to get the ISP's permission to do passi= ve measurements (presumably from a location outside the ISP network?)? I re= commend deleting this sentence, or at least the 2nd part of the sentence ("= , and the Subscribers'...beforehand"). ------------------------------------------ 8.6.1. Data Minimisation ... There are two levels of information needed for LMAP results to be useful for a specific task : troubleshooting and general results reporting. Comment: I don't understand "levels of information". I recommend: "There ar= e two main uses of LMAP results:"=20 ------------------------------------------- 8.6.4. Other Mitigations ... The informed consent of the Subscriber (and, if different, the end user) is needed ,... Comment: This depends on local laws and regulations. I suggest it "may be n= eeded". ... It is good practice to time limit the storage of personal information. Comment: I suggest: "Where privacy is important, it is good practice ..." ---------------------------------------------------------------------------= --------------------- Nits - Inconsistent use of "set-top players" vs "set-top-boxes". My preference = would be "set-top boxes". - Instruction vs. Instructions: If the term is really supposed to be singu= lar, consider searching for "Instructions" and replacing either with "Instr= uction" or "Instruction messages" or "Instruction-carrying messages" or suc= h. - "for example: "Report results once a day in a batch at 4am + Unif[0,180= ] seconds; if the end user is active then delay the report 5 minutes ". " = Comment: Interesting that the "delay" example is for delayed reporting inst= ead of delayed measurement. I'm not familiar with a lot of need to delay re= porting. From nobody Mon Apr 21 01:08: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 652641A01B0 for ; Mon, 21 Apr 2014 01:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] 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 WZGOnR8PDCcz for ; Mon, 21 Apr 2014 01:08:43 -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 7D2EB1A01BB for ; Mon, 21 Apr 2014 01:08:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwHAO3QVFOHCzIm/2dsb2JhbABPBAaCZSFPV6ookgcfhzyBIhZ0giUBAQEBAwEBAQ8oNAQTBAIBCA0EBAEBCwIBEQkHJwsUCQgBAQQBCQcCCBqIHwEMn0StQRMEjX8BBgQBBgEHBhI4BoMegRQEhTiPSIpui0+DMUGBKAEIFyI X-IronPort-AV: E=Sophos;i="4.97,895,1389762000"; d="scan'208";a="51335144" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Apr 2014 04:08:34 -0400 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; 21 Apr 2014 04:07:40 -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; Mon, 21 Apr 2014 04:07:34 -0400 From: "Romascanu, Dan (Dan)" To: "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: framework comments Thread-Index: Ac9cl9SeoAXxoO+sT62j3uhhwzLuTwAn4/lg Date: Mon, 21 Apr 2014 08:07:33 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7B5B44@AZ-FFEXMB04.global.avaya.com> References: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130425DAF@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.45] 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/uUAtBD4_BLUtp_DdMXDua8H_vhM 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: Mon, 21 Apr 2014 08:08:46 -0000 Hi, One observation about general comment #1. I understand the comment and I ag= ree to a large extent with the intent. We need to be clear about the places= when we are talking about the broader scope of LMAP (like when tracing the= delineation line between what LMAP does and what IPPM or other groups or o= rganization do) and the places where we refer to the current charter. This = document may contain both (broader and narrower) scope items, as a framewor= k may draw lines for work beyond the current charter. We just need to be cl= ear.=20 Having said this, I do not believe that we should talk explicitly about the= LMAP WG charter in this document, and this is for two reasons. One is tha= t WGs come and go, while RFCs stay, so we would like to write the document = in a language that is meaningful even after the WG has completed work. Seco= nd is that the LMAP charter may and probably will change in time, so talkin= g about "the current LMAP WG charter" may point to something different in t= he future. I would suggest to use a more neutral term, like "the first phas= e of the LMAP work". Regards, Dan =20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Sunday, April 20, 2014 4:00 PM > To: lmap@ietf.org > Subject: [lmap] framework comments >=20 > First let me apologize for not having gotten my comments in before the > deadline. I left for vacation shortly after the start of WGLC and have ha= d > very, very limited email and Internet access, or time for non-vacation > activities. > Barbara >=20 > General comments > 1. I'm concerned about descriptions of "the scope of LMAP" vs. "the scope= of > LMAP WG" vs. "the scope of this framework for LMAP" vs. "the scope of the > LMAP WG charter". I think that what we chartered the LMAP WG to do limits > the scope of this framework for large-scale measurement platforms (LMAP) > at this time. It does not limit the scope of all possible LMAPs (future W= G > charters or all large-scale measurement platforms) for all time. Where th= ere > is distinction described between "LMAP" and "IPPM" scope (so that LMAP is > really the WG more than the term), I agree with the description of "out-o= f- > scope" for LMAP (WG) being permanent. Where we could conceive of the > LMAP WG possibly being re-chartered in the future to take on additional > tasks, or other organizations describing large-scale measurement platform= s > that encompass more, I think we should describe the restriction as being = out- > of-scope of this framework for LMAP, or out-of-scope of the current LMAP > WG charter, rather than out-of-sc ope of (all) large-scale measurement > platforms (LMAP) or the LMAP WG (forever). Part of the problem for me > does seem to be that LMAP is both the WG and a term, and it's sometimes > hard to tell which is being referred to. > I suggest doing a search for "scope" and making the object of scoping "LM= AP > WG", "the current LMAP WG charter", or "this framework for LMAP", as > appropriate. >=20 > 2. Location of MA: This framework seems to assume the MA is always within > a customer premises network. Is that necessarily true? Use-cases doesn't > seem to indicate this. For example, in the case where measurements are > done in an ONT (fiber termination point, which may be dedicated to a sing= le > subscriber or serve many in a MDU), the MA would be fully within the ISP > network. Or it could be in a DSLAM and not specific to a single subscribe= r. If > we consider the non-regulatory, ISP-controlled, trouble-shooting use case > (which I thought was included in scope and is described in use-cases) the= n it > doesn't seem like an MA *always* is associated with a single subscriber. = But > this case does not seem to be covered by this framework, because there ar= e > many statements that assume MA-to-subscriber association is part of the > basic framework. Note that BBF use of MA does not restrict it to being > internal to or at edge of subscriber network, or to having a necessary > subscriber relationship. Following > are some statements where I would recommend expanding the description > to include elements outside the customer premises: > 1. Introduction: "These devices could be software based agents on PCs, > embedded agents in consumer devices (e.g. blu-ray players), service > provider controlled devices such as set-top players and home gateways, or > simply dedicated probes." > 6.2. Measurement Agent [this section should have examples of MAs located > elsewhere in ISP networks and such.] >=20 > -------------------------------------------------------------------------= ------ > Specific Comments: > 1. Introduction > o Large-scale - [I-D.ietf-lmap-use-cases] envisages Measurement > Agents in every home gateway and edge device such as set-top-boxes > and tablet computers. It is expected that a measurement system > could easily encompass a few hundred thousand Measurement Agents. > Existing systems have up to a few thousand MAs (without judging > how much further they could scale). > Comment: Why only a few hundred thousand? For the incredibly bandwidth- > heavy regulatory-type use case, I think this is to many. For ISP use case= s, I > think we're looking at millions. > -------------------------------------------------------------------- > 2. Outline of an LMAP-based measurement system > The main work of the LMAP working group is to define the Control > Protocol between the Controller and MA, and the Report Protocol > between the MA and Collector. > Comment: I realize Greg already commented on this and Phil responded that > he agreed. But it wasn't clear to me exactly what would be done about it.= My > preference would be to use the charter phrase: " The LMAP working group i= s > chartered to specify an information model, the associated data models, an= d > select/extend one or more protocols for the secure communication:" I woul= d > prefer not to debate which of these items are "main" (implying the others > are lesser deliverables). > -------- > A device with a > Measurement Agent may have multiple interfaces (Wi-Fi, Ethernet, DSL, > fibre, etc.) and the Measurement Tasks may specify any one of these. > Comment: Only PHY interfaces are listed. I would recommend listing other > interfaces as well (that carry IP) to make it clear the term is not limit= ed to PHY > interfaces. Such as PPPoE, L2TP, 6rd, DS-Lite, IPsec. > --------- > Measurement Tasks may be Active (the MA generates Active > Measurement > Traffic and measures some metric associated with its transfer), > Passive (the MA observes user traffic), or some hybrid form of the > two. > Comment: I recommend deleting "user" from the phrase, unless we really > are restricting MAs to only be associated with specific subscribers. > --------- > The data analysis tools receive the results from the Collector or via > the Results repository. They might visualise the data or identify > which component or link is likely to be the cause of a fault or > degradation. > Comment: What does it mean to visualize data? I'm unfamiliar with this wo= rd > in this context. > ---------------------------------------------- > 3. Terminology > Subscriber: An entity (associated with one or more users) that is > engaged in a subscription with a service provider. The Subscriber is > allowed to subscribe and un-subscribe services, and to register a > user or a list of users authorized to enjoy these services. [Q1741]. > Both the Subscriber and service provider are allowed to set the > limits relative to the use that associated users make of subscribed > services. > Comment: The reference is to a 3GPP document and the last 2 sentences are > very 3GPP-specific and not relevant to the concept of a wireline subscrib= er. I > recommend deleting the last 2 sentences from this definition. > ----------------------------------------------- > 4.1. Measurement system is under the direction of a single organisation >=20 > In the LMAP framework, the measurement system is under the direction > of a single organisation that is responsible for any impact that > measurements have on a user's quality of experience and privacy. > Comment: Recommend "... that is responsible for any impact that its > measurements have..." They cannot be responsible for the impact of others= ' > measurements. > ------------------------------------------------ > 5.3.1. Starting and Stopping Measurement Tasks ... > o the MA checking that there is no cross-traffic. In other words, a > check that the end-user isn't already sending traffic; > Comment: It may not be the end user directly engaged in sending the traff= ic. > It may be some other autonomous or scheduled application. Recommend > "...that the end-user or other application isn't..." > ,,, > o the first part of the Measurement Task consisting of traffic that > probes the path to make sure it isn't overloaded; > o the first part of the Measurement Task checking that the device > with the MA has enough resources to execute the Measurement Task > reliably. Note that the designer of the measurement system should > ensure that the device's capabilities are normally sufficient to > comfortably operate the Measurement Tasks. > It is possible that similar checks continue during the Measurement > Task , ... > Comment: This describes a very unusual and inefficient way of designing > "Measurement Tasks". It suggests that a Measurement Method can be > something very complex with multiple, disparate test protocols. Personall= y, I > would use a Measurement Schedule to identify a sequence of atomic > Measurement Tasks, rather than define mega Measurement Methods that > combine lots of stuff together so that a single Measurement Task is reall= y a > whole sequence of different tests. I don't object to people doing it this= way if > that's what they want, I just want to make absolutely sure that it's not = going > to end up being mandated or assumed that mega Measurement Methods > must be defined, instead of allowing measurement system operators to > define a sequence of individual Tasks within a Measurement Schedule. > ....... > 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. > ....... > It is likely to be important to include in the Measurement Report the > fact that the Measurement Task overlapped with another. > Comment: I think "It may be important..." rather than "likely to be > important". What is important is knowing whether or not (and how much) > cross-traffic is present. The precise nature of the cross traffic (that i= t was > another Measurement Task) isn't that important. > .........................................................................= ... > 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 unlik= e any > use of "transport protocol" I've ever seen. Especially the part about the= re > being Push, Pull, and multicast transport protocols. Multicast only happe= ns 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 proto= col" > 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, TC= P, > UDP and such have no Push, Pull, or multicast characteristics. I'm not su= re > 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. > .........................................................................= ... > 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 de= sign > (such as one that is just for the ISP use case and has nothing to do with > regulatory use case)? > ------------------------------------------------------------- > 6.1. Controller and the measurement system ... > ; if it will, then the > measurement system may need to compensate the Subscriber, for > instance . > Comment: This statement needs to be deleted. This document is no place fo= r > speculation regarding compensation models. > ------------------------------------------------------------- > 6.2.2. Measurement Agent embedded in site gateway ... > However, if the site gateway is owned and operated by the service > provider, the Measurement Agent will generally not be directly > available for over the top providers, the regulator, end users or > enterprises. > Comment: True. But it's also true that where the gateway is owned by the > end user, it's even less likely that it will be available for service pro= viders, ott > providers or regulators. End-user owned gateway is a common model, so I > would suggest mentioning this fact as well. > -------------------------------------------------------------- > 6.2.3. Measurement Agent embedded behind site NAT /Firewall >=20 > 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? > ------------------------------------------------------------- > 7. Security considerations > Reporting by the MA must also be secured to maintain confidentiality. > The results must be encrypted such that only the authorised Collector > can decrypt the results to prevent the leakage of confidential or > private information. > Comment: There are other ways of securing communications. For example, > where the MA is in a fiber ONT or other ISP network element (generally fo= r > ISP troubleshooting and not the regulatory use case), the communication > may occur over the ISP's dedicated management network. In this case, > encryption is not needed. Therefore I disagree that the results must be > encrypted. The second sentence could be changed to start "Where > encryption is used, the results must be..." > ... > A malicious party could "game the system". For example, where a > regulator is running a measurement system in order to benchmark > operators, an operator could try to identify the broadband lines that > the regulator was measuring and prioritise that traffic. This > potential issue is currently handled by a code of conduct. It is > outside the scope of the LMAP WG to consider the issue. > Comment: The existence of a code of conduct is not universally true. I > suggest deleting this sentence. > -------------------------------- > 8.3. Key Distinction Between Active and Passive Measurement Tasks >=20 > Passive and Active Measurement Tasks raise different privacy issues. >=20 > 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 subsc= riber. I > recommend " Passive Measurement Tasks can be conducted on a user's > traffic ,..." > ------------------------------------- > 8.4.1. MA Bootstrapping > ... > During the Bootstrap process, the MA receives its MA-ID which is a > persistent pseudonym for the Subscriber ... > Comment: Only true if the MA is associated with a specific subscriber. > -------------------------------------- > 8.5. Threats > Comment: I recommend mentioning some of the threats described in the > Security section here, especially the possibility of DoS attacks. I think= DoS > attacks pose a huge threat. > -------------------------------------- > 8.5.4. Secondary Use and Disclosure > ... > Passive Measurement Tasks are a form of Secondary Use, and the > Subscribers' permission and the measured ISP's permission should be > obtained beforehand . > Comment: This "should" statement as it applies to subscribers is dependen= t > on national laws and regulations. How it applies to ISPs, I don't underst= and. In > what case is someone supposed to get the ISP's permission to do passive > measurements (presumably from a location outside the ISP network?)? I > recommend deleting this sentence, or at least the 2nd part of the sentenc= e > (", and the Subscribers'...beforehand"). > ------------------------------------------ > 8.6.1. Data Minimisation > ... > There are two levels of information needed for LMAP results to be > useful for a specific task : troubleshooting and general results > reporting. > Comment: I don't understand "levels of information". I recommend: "There > are two main uses of LMAP results:" > ------------------------------------------- > 8.6.4. Other Mitigations > ... > The informed consent of the Subscriber (and, if > different, the end user) is needed ,... > Comment: This depends on local laws and regulations. I suggest it "may be > needed". > ... > It is good practice to time limit the storage of > personal information. > Comment: I suggest: "Where privacy is important, it is good practice ..." >=20 > -------------------------------------------------------------------------= --------------------- > -- > Nits > - Inconsistent use of "set-top players" vs "set-top-boxes". My preferenc= e > would be "set-top boxes". > - Instruction vs. Instructions: If the term is really supposed to be sin= gular, > consider searching for "Instructions" and replacing either with "Instruct= ion" > or "Instruction messages" or "Instruction-carrying messages" or such. > - "for example: "Report results once a day in a batch at 4am + Unif[0,1= 80] > seconds; if the end user is active then delay the report 5 minutes ". " > Comment: Interesting that the "delay" example is for delayed reporting > instead of delayed measurement. I'm not familiar with a lot of need to de= lay > reporting. >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Apr 22 00:21:40 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D591A007A for ; Tue, 22 Apr 2014 00:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.473 X-Spam-Level: X-Spam-Status: No, score=-104.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 NNYuOdTHprEi for ; Tue, 22 Apr 2014 00:21:35 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 080FD1A00E6 for ; Tue, 22 Apr 2014 00:21:34 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5CD98878C16 for ; Tue, 22 Apr 2014 09:21:28 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.88.240] (unknown [163.117.88.240]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 511388754B4 for ; Tue, 22 Apr 2014 09:21:28 +0200 (CEST) Message-ID: <535618A2.3030705@it.uc3m.es> Date: Tue, 22 Apr 2014 09:22:10 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: lmap@ietf.org References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <2845723087023D4CB5114223779FA9C8017944A577@njfpsrvexg8.research.att.com> <20140415233436.sfay4k84j4s4w8o0@webcartero01.uc3m.es> <20140416073332.GA12252@elstar.local> In-Reply-To: <20140416073332.GA12252@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20648.005 X-TM-AS-Result: No--8.075-7.0-31-1 X-imss-scan-details: No--8.075-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/LXUnJ--GHCZJsdamtJDKr3aUG90 Subject: Re: [lmap] lmap framework and IPPM registries. 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, 22 Apr 2014 07:21:37 -0000 Hi, I have checked RFC3553 and I guess we can do a similar approach. In order to do that, the IPPM registry draft (in particular the core registry draft) would need to add a mandatory URI column in the registry. I will take the issue to IPPM to see if they are ok with that. Regards, marcelo El 16/04/14 09:33, Juergen Schoenwaelder escribió: > On Tue, Apr 15, 2014 at 11:34:36PM +0200, MARCELO BAGNULO BRAUN wrote: > >> So, the question I have is whether IANA can handle URI allocations. >> I dont know the answer to this question. If they can, then i think >> we are ok. If they cant, i think we have a problem. > IANA already manages URNs for several protocols. I guess they won't > have a problem doing one more. See RFC 3553 (BCP 73) for a starting > point. > > /js > From nobody Tue Apr 22 01:35: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 C99E91A014B for ; Tue, 22 Apr 2014 01:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 HXc0fuBulkQD for ; Tue, 22 Apr 2014 01:35:11 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8F62B1A013D for ; Tue, 22 Apr 2014 01:35:10 -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; Tue, 22 Apr 2014 09:35:12 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.56]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 22 Apr 2014 09:35:04 +0100 From: To: , Date: Tue, 22 Apr 2014 09:35:03 +0100 Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rw Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719532956@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: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72D45F400A3EMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/aGsd6s5A_78gpDWTc8P1iPl2qXY 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: Tue, 22 Apr 2014 08:35:15 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72D45F400A3EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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."po= isson_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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72D45F400A3EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

On continuous counterparts of Poisson I’m far from= any expert and it would certainly be up to the user to decide if such func= tions 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://cmsci= ence.blogspot.co.uk/2008/04/mt-6-poisson-and-gamma-distribution.html

http://arxiv.org/abs/1303.5990

=  

A= s I tried to say the current Information Model can take either discrete or = continuous functions – only that there is currently no explicit suppo= rt for specifying the interval used for a discrete function. I was question= ing the need to add this.

 

Personally I’d think that Normal and Unifo= rm distributions would cover most needs, but the framework should be flexib= le in this regard.

 

Trevor.

 

<= span style=3D'color:#1F497D'> 

From: lmap [mailto:lmap-bou= nces@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,

&= nbsp;

The BBF is lo= oking at standardizing the model for Timers as suggested by the IETF LMAP i= nformation model.

 

Dur= ing the review of the timers we had addition questions regarding Trevors re= sponse to the Poisson distribution for the Randomness of the Periodic Timer= .

 <= /o:p>

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 els= e 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 funct= ion – obviously needed on a uniform distribution but useful to constr= ain other functions.

 

I will make all this clear in th= e next release.<= /span>

 <= span lang=3DEN-US style=3D'color:black'>

As for poisson I think there are 3 op= tions:

-&n= bsp;       Use a continuous form instead

-    &= nbsp;   Have the discrete interval implicit in the function choice e.g.“p= oisson_1_sec”

-        = Add an interval to the information = model.

 

<= span style=3D'color:#1F497D'>I was really thinking about the first, but I d= on’t see the problem with the second. However I wouldn’t do the= third unless they was a demonstrable value to supporting discrete function= s (rather than continuous versions of them).

 “= ;

 

But as people looked at Trevors response there wer= e additional questions:

 

I don't und= erstand what Trevor means about the Poisson distribution.  As far as I= know, it is a discrete distribution, so a "continuous form" woul= d be a different distribution and not Poisson.  And I believe that we = do need a continuous distribution.  But what matters is that the defin= ition is clear, not the particular distribution (I don't have an opinion on= that).

 

 

Could some please clarify th= is for us – Are we planning something other than Poisson method; bett= er yet is there a definition for the types of distribution:

Poisson= , Normal and Uniform.

 

Thanks,

=

Tim

<= o:p> 

= --_000_ED51D9282D1D3942B9438CA8F3372EB72D45F400A3EMV64UKRDdoma_-- From nobody Tue Apr 22 06:23: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 1A4B11A0473 for ; Tue, 22 Apr 2014 06:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] 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 dRbPjmi3QBbg for ; Tue, 22 Apr 2014 06:23:05 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 699B81A046F for ; Tue, 22 Apr 2014 06:23:05 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 842AAA05BA; Tue, 22 Apr 2014 09:22:59 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 2D723A05B7; Tue, 22 Apr 2014 09:22:59 -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; Tue, 22 Apr 2014 09:22:59 -0400 From: Sharam Hakimi To: "timothy.carey@alcatel-lucent.com" , "lmap@ietf.org" , "trevor.burbridge@bt.com" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAA= Date: Tue, 22 Apr 2014 13:22:58 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@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: [10.28.36.10] Content-Type: multipart/alternative; boundary="_000_89294A6F3C6C91459E52E4128C4B02B70417CCSPQCMBX02exfocom_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20648.007 X-TM-AS-Result: No--22.093-5.0-31-10 X-imss-scan-details: No--22.093-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20648.007 X-TMASE-Result: 10--22.093100-5.000000 X-TMASE-MatchedRID: 0lhM5bBmjEO0/JWJqIoqphcqpH7D1rtQkKAa/khZ3iTagsZM0qVv1wAc 7aMGN3FAcCs1o0v1HksXPRo0MnqIfFgFRUdvzHmklVHM/F6YkvRCs7hdHoFFAxtDdc/8nLiyG9v VgL2UultZTI37JuYjhxrMy4f0beZvhnk2xlnUc9ZjoaO27r+3fVt06oMfzUpKtYO4QjHEjfHnGN HoyK4fI6qrikBgrdGbvTyMtG3v9FQtJMbDWD8p3sAmcZEx8XHJxmk2/Mikg70+gR+s21UkWL7qf 3d2iYd4gWxqFqaN8JqSFWmbVtTLquhRubJazHK+sBytgTF4TTQR5c83KIxTTpdaQbAiMdJbM+p+ NpswZmppJsg8GzyrlstHJ5mG0L9nfpMzRCm11qPNRsyOiZyYyp6KYa03LCO2dDwP5ItpCOwcSRF 9JP5Ozi4jb1n1eNA354mbosKUuYfCKxdd3mKUawnK0/SgO/u/di/yWILjNHs6iP0NczjR0vwfmW wydLFJ4j4lr4Wn4RisEFKef8ZUxqf50/sZyNUdupDIC9422DrTMQ/93vE8XUbaqUVvLFsiakcq2 RAHKcpj6nYvURA3nX+yPj/DkaXJYNLPQiXPF7zLtNJZxvPj1pKLNrbpy/A0EB0PuwJG07ERbj4N 8pH+YbwHZc988a+m9yaXhPhnUZ2CIg7tJ//usYvptQwz5tsim/y00tE9StZdJqXcElZhZiJkpIM WHcbCxuNqRoLHxZwY6G+qe6yzT5r8q/DaK2EqngIgpj8eDcBpkajQR5gb3hziNLWewPgdRRgndE tDQrLQvzxTzaYHtIUP7Dcph6bbIzkapyqFooz4rbZVKc6aK2A7bUFBqh2V Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/r4U1nmnSD5pvJwvQkHPmLg7Y4T4 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: Tue, 22 Apr 2014 13:23:11 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B70417CCSPQCMBX02exfocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_89294A6F3C6C91459E52E4128C4B02B70417CCSPQCMBX02exfocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [ma= ilto: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; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

From: lmap [ma= ilto: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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_89294A6F3C6C91459E52E4128C4B02B70417CCSPQCMBX02exfocom_-- From nobody Tue Apr 22 09:33: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 678C21A0222 for ; Tue, 22 Apr 2014 09:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0icX3BG54Se6 for ; Tue, 22 Apr 2014 09:33:38 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 150061A021F for ; Tue, 22 Apr 2014 09:33:37 -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, 22 Apr 2014 17:31:35 +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, 22 Apr 2014 17:33:31 +0100 From: To: , Date: Tue, 22 Apr 2014 17:33:30 +0100 Thread-Topic: framework comments Thread-Index: Ac9cl9SeoAXxoO+sT62j3uhhwzLuTwBfuc6w Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/woR4l2t74TEiVH5YiVmXn8WbPc8 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, 22 Apr 2014 16:33:43 -0000 Barbara, Thanks very much for your detailed comments! Some follow-ups in-line phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: 20 April 2014 14:00 > To: lmap@ietf.org > Subject: [lmap] framework comments > > First let me apologize for not having gotten my comments in before the > deadline. I left for vacation shortly after the start of WGLC and have > had very, very limited email and Internet access, or time for non- > vacation activities. > Barbara > > General comments > 1. I'm concerned about descriptions of "the scope of LMAP" vs. "the > scope of LMAP WG" vs. "the scope of this framework for LMAP" vs. "the > scope of the LMAP WG charter". I think that what we chartered the LMAP > WG to do limits the scope of this framework for large-scale measurement > platforms (LMAP) at this time. It does not limit the scope of all > possible LMAPs (future WG charters or all large-scale measurement > platforms) for all time. Where there is distinction described between > "LMAP" and "IPPM" scope (so that LMAP is really the WG more than the > term), I agree with the description of "out-of-scope" for LMAP (WG) > being permanent. Where we could conceive of the LMAP WG possibly being > re-chartered in the future to take on additional tasks, or other > organizations describing large-scale measurement platforms that > encompass more, I think we should describe the restriction as being > out-of-scope of this framework for LMAP, or out-of-scope of the current > LMAP WG charter, rather than out-of-sc ope of (all) large-scale > measurement platforms (LMAP) or the LMAP WG (forever). Part of the > problem for me does seem to be that LMAP is both the WG and a term, and > it's sometimes hard to tell which is being referred to. > I suggest doing a search for "scope" and making the object of scoping > "LMAP WG", "the current LMAP WG charter", or "this framework for LMAP", > as appropriate. [phil] will try and follow Dan's guidance > > 2. Location of MA: This framework seems to assume the MA is always > within a customer premises network. Is that necessarily true? Use-cases > doesn't seem to indicate this. For example, in the case where > measurements are done in an ONT (fiber termination point, which may be > dedicated to a single subscriber or serve many in a MDU), the MA would > be fully within the ISP network. Or it could be in a DSLAM and not > specific to a single subscriber. If we consider the non-regulatory, > ISP-controlled, trouble-shooting use case (which I thought was included > in scope and is described in use-cases) then it doesn't seem like an MA > *always* is associated with a single subscriber. But this case does not > seem to be covered by this framework, because there are many statements > that assume MA-to-subscriber association is part of the basic > framework. Note that BBF use of MA does not restrict it to being > internal to or at edge of subscriber network, or to having a necessary > subscriber relationship. Following > are some statements where I would recommend expanding the description > to include elements outside the customer premises: > 1. Introduction: "These devices could be software based agents on PCs, > embedded agents in consumer devices (e.g. blu-ray players), service > provider controlled devices such as set-top players and home gateways, > or simply dedicated probes." > 6.2. Measurement Agent [this section should have examples of MAs > located elsewhere in ISP networks and such.] [phil] I agree with you, the MA does not have to be in the customer's premi= ses. S6 - if anyone can contribute text of MAs located elsewhere, that would be = very helpful. > > ----------------------------------------------------------------------- > -------- > Specific Comments: > 1. Introduction > o Large-scale - [I-D.ietf-lmap-use-cases] envisages Measurement > Agents in every home gateway and edge device such as set-top- > boxes > and tablet computers. It is expected that a measurement system > could easily encompass a few hundred thousand Measurement > Agents. > Existing systems have up to a few thousand MAs (without judging > how much further they could scale). > Comment: Why only a few hundred thousand? For the incredibly bandwidth- > heavy regulatory-type use case, I think this is to many. For ISP use > cases, I think we're looking at millions. [phil] how about: could easily encompass a few hundred thousand or even millions of Measureme= nt Agents. ... > --------- > The data analysis tools receive the results from the Collector or > via > the Results repository. They might visualise the data or identify > which component or link is likely to be the cause of a fault or > degradation. > Comment: What does it mean to visualize data? I'm unfamiliar with this > word in this context. http://en.wikipedia.org/wiki/Data_visualization > ---------------------------------------------- > 3. Terminology > Subscriber: An entity (associated with one or more users) that is > engaged in a subscription with a service provider. The Subscriber > is > allowed to subscribe and un-subscribe services, and to register a > user or a list of users authorized to enjoy these services. > [Q1741]. > Both the Subscriber and service provider are allowed to set the > limits relative to the use that associated users make of subscribed > services. > Comment: The reference is to a 3GPP document and the last 2 sentences > are very 3GPP-specific and not relevant to the concept of a wireline > subscriber. I recommend deleting the last 2 sentences from this > definition. [phil] I think the definition is copied from Q.1741. personally am ok with = deleting the last 2 sentences. ... > o the first part of the Measurement Task consisting of traffic > that > probes the path to make sure it isn't overloaded; > o the first part of the Measurement Task checking that the device > with the MA has enough resources to execute the Measurement Task > reliably. Note that the designer of the measurement system > should > ensure that the device's capabilities are normally sufficient to > comfortably operate the Measurement Tasks. > It is possible that similar checks continue during the Measurement > Task , ... > Comment: This describes a very unusual and inefficient way of designing > "Measurement Tasks". It suggests that a Measurement Method can be > something very complex with multiple, disparate test protocols. > Personally, I would use a Measurement Schedule to identify a sequence > of atomic Measurement Tasks, rather than define mega Measurement > Methods that combine lots of stuff together so that a single > Measurement Task is really a whole sequence of different tests. I don't > object to people doing it this way if that's what they want, I just > want to make absolutely sure that it's not going to end up being > mandated or assumed that mega Measurement Methods must be defined, > instead of allowing measurement system operators to define a sequence > of individual Tasks within a Measurement Schedule. [phil] yes, that's ok. whatever - the issue is that the later task or sub-t= ask runs (or not) depending on the result of the earlier (sub)task. > ....... > 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= . ... > 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 f= or instance if it operates over http, then at this "underlying" layer the M= A does a request (pull) to the Controller and its reply includes the LMAP C= ontrol Protocol info. Or the "underlying" layer may be push or even multica= st. "transport" didn't mean layer 4 but something transporting the LMAP info. Would "underlying packet transfer mechanism" or "model" be clearer? > ....................................................................... > ..... > 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 somethi= ng we want to avoid. > ------------------------------------------------------------- > 6.1. Controller and the measurement system ... > ; if it will, then the > measurement system may need to compensate the Subscriber, for > instance . > Comment: This statement needs to be deleted. This document is no place > for speculation regarding compensation models. [phil] I'm ok to delete this phrase > 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" an= d "for the latter" to "firewall pin holing" > ------------------------------------------------------------- > 7. Security considerations > Reporting by the MA must also be secured to maintain > confidentiality. > The results must be encrypted such that only the authorised > Collector > can decrypt the results to prevent the leakage of confidential or > private information. > Comment: There are other ways of securing communications. For example, > where the MA is in a fiber ONT or other ISP network element (generally > for ISP troubleshooting and not the regulatory use case), the > communication may occur over the ISP's dedicated management network. In > this case, encryption is not needed. Therefore I disagree that the > results must be encrypted. The second sentence could be changed to > start "Where encryption is used, the results must be..." [phil] this may need some more discussion. I'm not sure we should mention t= his. Anyway, here's a suggestion:- (new penultimate paragraph for the section) The security mechanisms described above may not be strictly necessary if th= e network's design ensures the LMAP components and their communications are= already secured, for example potentially if they are all part of an ISP's = dedicated management network. (replacement Reporting para) Reporting by the MA must be encrypted to maintain confidentiality, to preve= nt the leakage of confidential or private information. Reporting must also = be authenticated (to ensure that it comes from a trusted MA) and not vulner= able to tampering (which can be ensured through integrity and replay checks= ). It must not be possible to fool a MA into injecting falsified data and t= he results must also be held and processed securely after collection and an= alysis (see section 8.5.2 ...). I also think we should mention that the Control messages also need to be co= nfidential. "The Instruction messages also need to be encrypted to maintain confidentia= lity, as the information might be useful to an attacker." > ... > A malicious party could "game the system". For example, where a > regulator is running a measurement system in order to benchmark > operators, an operator could try to identify the broadband lines > that > the regulator was measuring and prioritise that traffic. This > potential issue is currently handled by a code of conduct. It is > outside the scope of the LMAP WG to consider the issue. > Comment: The existence of a code of conduct is not universally true. I > suggest deleting this sentence. [phil] think we should add "normally" to the sentence but keep it. The topi= c has come up several times, so seems to be something that readers often wo= nder about. > -------------------------------- > 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") > ------------------------------------- > 8.4.1. MA Bootstrapping > ... > During the Bootstrap process, the MA receives its MA-ID which is a > persistent pseudonym for the Subscriber ... > Comment: Only true if the MA is associated with a specific subscriber. [phil] ok, this needs "may" or "for a MA located at an end-user" > -------------------------------------- > 8.5. Threats > Comment: I recommend mentioning some of the threats described in the > Security section here, especially the possibility of DoS attacks. I > think DoS attacks pose a huge threat. [phil] agree DOS attacks are the most worrying ones/. > -------------------------------------- > 8.5.4. Secondary Use and Disclosure > ... > Passive Measurement Tasks are a form of Secondary Use, and the > Subscribers' permission and the measured ISP's permission should be > obtained beforehand . > Comment: This "should" statement as it applies to subscribers is > dependent on national laws and regulations. How it applies to ISPs, I > don't understand. In what case is someone supposed to get the ISP's > permission to do passive measurements (presumably from a location > outside the ISP network?)? I recommend deleting this sentence, or at > least the 2nd part of the sentence (", and the > Subscribers'...beforehand"). [phil] how about shortening the second para:- Secondary use could be made of the Results from both Active and Passive Mea= surement Tasks, for example to inform an unauthorised marketing campaign. S= econdary use may break national laws and regulations, and may violate peopl= e's expectations or desires. -- At the moment the section says that all Passive measurements are intrins= ically secondary use - is this really true? From nobody Tue Apr 22 10:25: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 11A931A06B6 for ; Tue, 22 Apr 2014 10:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 WqB1voNpwfAG for ; Tue, 22 Apr 2014 10:25:36 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF8A1A06B2 for ; Tue, 22 Apr 2014 10:25:36 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s3MHPO0E013171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2014 12:25:24 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 59F741E0071; Tue, 22 Apr 2014 11:25:19 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 2F2421E0072; Tue, 22 Apr 2014 11:25:19 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s3MHPI6T022881; Tue, 22 Apr 2014 11:25:18 -0600 (MDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s3MHPIXd022870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 11:25:18 -0600 (MDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Tue, 22 Apr 2014 12:25:17 -0500 From: "Bugenhagen, Michael K" To: "'MORTON, ALFRED C (AL)'" , "'lmap@ietf.org'" , "'philip.eardley@bt.com'" Thread-Topic: Standardize behaviors for test environments - lmap framework and IPPM registries. Thread-Index: AQHPXk/TFgZFQrcUu0uDtZ2yfBfgeg== Date: Tue, 22 Apr 2014 17:25:17 +0000 Message-ID: References: <20140414165014.2yrfm9hptwkcog0w@webcartero01.uc3m.es> <2845723087023D4CB5114223779FA9C8017944A577@njfpsrvexg8.research.att.com> <2845723087023D4CB5114223779FA9C8017944A75D@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017944A75D@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/GzNR1syTX9j-lxc36qT-pyPulTc Cc: 'MARCELO BAGNULO BRAUN' , "Cook, Charles" Subject: [lmap] Standardize behaviors for test environments - lmap framework and IPPM registries. 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, 22 Apr 2014 17:25:41 -0000 Al, Phil, In order to execute a test we need consistant MA behavior "about" or whe= n different test environment variables are encountered. As Al pointed out, we have some "information model" objects that call out d= ifferent environmental conditions - First - We need to identify those with definitions vs. just objects. Secondly - but very possibly more challenging - How do we take those "environmental" attributes and define the test behavi= or around those when the test being used is in a registry. Example case ... Test A =3D throughput Test B =3D latency Environmental x =3D cross traffic. Behaviors of the test with the environmental...=20 For Test A --- terminate a test when environmental "x" is detected, then m= ark the test as terminated due to "environment x". For Test B --- record environmental "x" during test b. What this indicates to me is that we need a very Standard Test Execution st= ring that details out all the environmental with Codified "behavior" codes = as to what the MA does during and after the test when it experiences a envi= ronmental.. More problematically operationally reaction to things like cross traffic g= enerally doesn't use "lab like" absolutes like "zero cross traffic" so we w= ill also have some fuzzy logic (thresholds) in our environmental definition= s. So - Cap statement.... At the end of the day it looks like we still need a standardized (about env= ironmental) test instruction set that is implemented the same across the bo= ard. Both from a Attribute, and behavior aspect. This constitutes a Gap that needs to be fixed. Regards, Mike =20 -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Wednesday, April 16, 2014 3:11 PM To: Bugenhagen, Michael K; 'MARCELO BAGNULO BRAUN'; 'lmap@ietf.org' Subject: RE: [lmap] lmap framework and IPPM registries. In the original registry proposal(s) over a year ago now, we had an Environ= ment (sub) Registry: http://tools.ietf.org/html/draft-bagnulo-ippm-new-registry-00#section-2.3 We were convinced to take this out of the registry design, it's not really = part of the metric specifications and there likely were other reasons I've = forgotten, but it's out now for good. The Info model draft covers this topic. http://tools.ietf.org/html/draft-ietf-lmap-information-model-00#section-3.7 ... The result data rows may optionally include an indication of the cross-traffic (e.g., the total number of octets of non-measurement traffic passing through the interfaces used by a Measurement Task during the measurement period). Al > -----Original Message----- > From: Bugenhagen, Michael K=20 > [mailto:Michael.K.Bugenhagen@centurylink.com] > Sent: Wednesday, April 16, 2014 3:50 PM > To: MORTON, ALFRED C (AL); 'MARCELO BAGNULO BRAUN'; 'lmap@ietf.org' > Subject: RE: [lmap] lmap framework and IPPM registries. >=20 > Marcelo, Al, >=20 > One gap I think we have here is how to identify a common set of=20 > "network environment" attributes that need to be used by the tests. > They aren't identified in the test methodology as a common abstract=20 > MIB, or attribute across the board so this needs to be handled elsewhere. >=20 > My assumption what that it would be in the registry as some type of=20 > "header" or description on how to execute a test, but if I'm following=20 > you that assumption is wrong. >=20 > Example - >=20 > Cross Traffic, or customer traffic... >=20 > Some tests have assumptions about the presence of this, and when it's=20 > acceptable to do the test, or not based on it's existence. > Given there is NO common MIB / attribute for it today... this becomes=20 > an issue in defining the "test method" >=20 > Kind of a gap... with different ways to close it. >=20 > Regards, > Mike >=20 >=20 >=20 >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED=20 > C > (AL) > Sent: Tuesday, April 15, 2014 3:14 PM > To: MARCELO BAGNULO BRAUN; lmap@ietf.org > Subject: Re: [lmap] lmap framework and IPPM registries. >=20 > For me and those whose needs I understand, a URI for metrics seems useful= . > I would guess that IANA has already been asked for some form of ID=20 > persistence, and if they agree to provide when requested, then it=20 > would be a (new) requirement in the IANA section. >=20 > Also, we need both a metric and a method of measurement, these are=20 > both present in our current version of the metric registry. >=20 > >From Framework 5.2.1 Instruction >=20 > o the Measurement Task configurations, each of which needs: >=20 > * the Measurement Method, specified as a URN to a registry entry. > The registry could be defined by the IETF > [I-D.manyfolks-ippm-metric-registry], locally by the operator > of the measurement system or perhaps by another standards > organisation. >=20 > So let's fix this as follows: >=20 > o the Measurement Task configurations, each of which needs: >=20 > * the Registered Metric, specified as a URI to a registry entry, > and which includes the specification of a Measurement Method. > The registry could be defined by the IETF > [I-D.manyfolks-ippm-metric-registry], locally by the operator > of the measurement system or perhaps by another standards > organisation. >=20 > (off-list discussion contributed to this suggestion), Al >=20 >=20 > Al >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MARCELO=20 > > BAGNULO BRAUN > > Sent: Monday, April 14, 2014 10:50 AM > > To: lmap@ietf.org > > Subject: [lmap] lmap framework and IPPM registries. > > > > Hi, > > > > One issue i realized is that the current lmap framework states the=20 > > the measurement method is specified as a URN to a registry entry,=20 > > while the current IPPM registry draft do not have a URN as metric=20 > > identifier but a name and a metric identifier. > > > > I think it is very important that these two efforts are aligned so i=20 > > suggest that we discuss whether a URN is the proper way to go or the=20 > > current flat identifier proposed in the ippm registry drafts. > > > > I am uncertain what is the benefit of an URN versus a flat identifier. > > Regards, marcelo > > > > > > -- > > ---- > > MARCELO BAGNULO BRAUN > > WebCartero > > Universidad Carlos III de Madrid > > > > _______________________________________________ > > 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 Tue Apr 22 12: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 748CC1A003D for ; Tue, 22 Apr 2014 12:16:20 -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 rC_ZEBMvqFMj for ; Tue, 22 Apr 2014 12:16:15 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 251301A010B for ; Tue, 22 Apr 2014 12:16:15 -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 s3MJG4OC007473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Apr 2014 14:16:04 -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 s3MJG3uB007811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 15:16:03 -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, 22 Apr 2014 15:16:03 -0400 From: "Carey, Timothy (Timothy)" To: Sharam Hakimi , "lmap@ietf.org" , "trevor.burbridge@bt.com" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUA== Date: Tue, 22 Apr 2014 19:16:02 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> 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: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77195344C3US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/MigLl7bPJBGlBVi4G-cwMT7K_8o 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: Tue, 22 Apr 2014 19:16:20 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77195344C3US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, The data model is extensible by vendors so we can add functions and input v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77195344C3US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_9966516C6EB5FC4381E05BF80AA55F77195344C3US70UWXCHMBA05z_-- From nobody Tue Apr 22 13:22: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 E090D1A0226 for ; Tue, 22 Apr 2014 13:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 QSCcgyDYrwKu for ; Tue, 22 Apr 2014 13:22:36 -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 7CDE81A013F for ; Tue, 22 Apr 2014 13:22:36 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-red.research.att.com (Postfix) with ESMTP id B62CE55421B; Tue, 22 Apr 2014 16:22:54 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-azure.research.att.com (Postfix) with ESMTP id CAD2DE01E7; Tue, 22 Apr 2014 16:22:30 -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; Tue, 22 Apr 2014 16:22:30 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , Sharam Hakimi , "lmap@ietf.org" , "trevor.burbridge@bt.com" Date: Tue, 22 Apr 2014 16:22:28 -0400 Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAALdaAQ Message-ID: <2845723087023D4CB5114223779FA9C8017944AE0B@njfpsrvexg8.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.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_2845723087023D4CB5114223779FA9C8017944AE0Bnjfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/vBPem6a_E0_NnfZagYAgNwZFybA 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: Tue, 22 Apr 2014 20:22:42 -0000 --_000_2845723087023D4CB5114223779FA9C8017944AE0Bnjfpsrvexg8re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Both the examples in the framework draft use Uniform, http://tools.ietf.org/html/draft-ietf-lmap-framework-04#section-2 we're just trying to avoid strict periodicity - let's keep it simple (to specify, to generate...). Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: Tuesday, April 22, 2014 3:16 PM To: Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com Subject: Re: [lmap] Timer: Poisson distribution question Trevor, The data model is extensible by vendors so we can add functions and input v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_2845723087023D4CB5114223779FA9C8017944AE0Bnjfpsrvexg8re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Both the examples in the framewo= rk draft use Uniform,

http://tools.ietf.org/ht= ml/draft-ietf-lmap-framework-04#section-2

we're just trying to avoid strict periodicity -

let's keep it simple (to specify, to generate...).=

Al

 

From: lmap [mailto:lmap-= bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent:<= /b> Tuesday, April 22, 2014 3:16 PM
To: Sharam Hakimi; lmap@ietf.= org; trevor.burbridge@bt.com
Subject: Re: [lmap] Timer: Poisson d= istribution question

=  

Tre= vor,

 

The data model is extensible by vendors so we can add functions and i= nput variables as we need.

 

However we have to decide on which small subset= we actually want to standardize.

 

You suggested the Uniform and Normal whi= ch 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 r= andom number. Otherwise we will have 2 implementers of the same standard al= gorithm implement different variations. – Not good.=

 

So I suggest we = keep this simple.

 

Uniform Discrete – input variables - maximum [posi= tive integer]

Gaussian –input variables – mean of min/max, spread = =3D standard deviation

 

The min/max would be milliseconds – Spread wo= uld be an integer.

 

 

This sound OK?

 

BR

Tim

 

 

=

From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
Sent: Tu= esday, April 22, 2014 8:23 AM
To: Carey, Timothy (Timothy); lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE: Timer: Po= isson distribution question

 

Tim,

I think the Periodic Timer distribution needs to have closer configur= ation control by the user and I think your 2nd  choice atte= mpts to provide it but having a discrete interval definition is a better wa= y to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounc= es@ietf.org] On Behalf Of trevor.burbridge@bt.com
Sent: Tuesday, April 22, 2014 4:= 35 AM
To: tim= othy.carey@alcatel-lucent.com; lmap@ie= tf.org
Subject: Re: [lmap] Timer: Poisson distribution questi= on

 <= /p>

&nb= sp;

On continuous counterparts of Poisson I’m far from any exper= t 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 o= ne is continuous and one is discrete:

http://cm= science.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 Info= rmation Model can take either discrete or continuous functions – only= that there is currently no explicit support for specifying the interval us= ed for a discrete function. I was questioning the need to add this.

 

Personally I’d think that Normal and Uniform dist= ributions would cover most needs, but the framework should be flexible in t= his regard.

 

Trevor.

 <= /span>

<= o:p> 

 

Team,

 

The BBF is looking at standardiz= ing the model for Timers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition questions regarding Trevor= s response to the Poisson distribution for the Randomness of the Periodic T= imer.

 

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 stand= ard deviation (could use mean deviation or something else but I see no adva= ntage as long as we all know what it refers to) and need to change to a flo= at. The upper and lower cuts would be in seconds +/- the mean (also needs t= o change to float) and are simply used to trim the function – obvious= ly needed on a uniform distribution but useful to constrain other functions= .

 

I will make all this clear in the next release.

<= span lang=3DEN-GB style=3D'color:#1F497D'> 

As for poisson I think there are 3 options:

-        =   Use a continuous form instead=

-=           Have the discrete int= erval 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 de= monstrable value to supporting discrete functions (rather than continuous v= ersions of them).

<= p class=3DMsoNormal> “

 

But as people looked at Trevors response = there were additional questions:

=  

I don't understand what Trev= or means about the Poisson distribution.  As far as I know, it is a di= screte distribution, so a "continuous form" would be a different = distribution and not Poisson.  And I believe that we do need a continu= ous distribution.  But what matters is that the definition is clear, n= ot the particular distribution (I don't have an opinion on that).

 

 <= /o:p>

Could some= please clarify this for us – Are we planning something other than Po= isson method; better yet is there a definition for the types of distributio= n:

Po= isson, Normal and Uniform.

 

Thanks,

<= span style=3D'color:black'>Tim

 

= --_000_2845723087023D4CB5114223779FA9C8017944AE0Bnjfpsrvexg8re_-- From nobody Tue Apr 22 14:00: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 C44181A0272 for ; Tue, 22 Apr 2014 14:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] 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 WYsSVZpqH2dK for ; Tue, 22 Apr 2014 14:00:15 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id D996E1A0279 for ; Tue, 22 Apr 2014 13:59:18 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 185AAA05D6; Tue, 22 Apr 2014 16:59:13 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id C54B6A05D5; Tue, 22 Apr 2014 16:59:12 -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; Tue, 22 Apr 2014 16:59:12 -0400 From: Sharam Hakimi To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" , "trevor.burbridge@bt.com" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdw Date: Tue, 22 Apr 2014 20:59:11 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.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: multipart/alternative; boundary="_000_89294A6F3C6C91459E52E4128C4B02B7041ACFSPQCMBX02exfocom_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20650.002 X-TM-AS-Result: No--13.751-5.0-31-10 X-imss-scan-details: No--13.751-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20650.002 X-TMASE-Result: 10--13.751500-5.000000 X-TMASE-MatchedRID: yebcs53SkkBSZjI14BRie0vrB8UvzFr4xNK79ogfIKlBDVeC8J7uwYnV 4FKib7SLI1j68AwVJtUMGuTj77aWWNkofSZrkji4e0i2wcB24/ExmbT6wQT2a9r4gfya+A9U1Jr HgQqRSi0upY/Fd0U7XGme6+G8/jWguvFawcWbGbbzh2yKdnl7WNSqEluSYtV7S4KPPiCB23AzBH KsDHLon79wRdfb+nI8xni7iafu/8Xyha4uErRN/Z21GZGE81yGttKJDdalq/Vhb6wYa04uHakU3 IqkktvjetUMoqZXFCzygzLxhdJB4Pd9n5vMgdWe4t2mucDkRBGLB4sTRpOnCTDJ9a3KikGoVhbD EH23DRO7KT8e5NWWCtVg9dC9MBH4Nr0FMj05PCGJQ9k+Ypk5CTQAp53S718HTzZrG+KJluYnRZF AjYQbtOR20ZMStPgujDfe6AqlsEdCl9DEsHnSbfC3jJqTOlQ/rL4LuDUDfbv1hE3O9q/rWIxspL 0xHi6RQucVrsj3E5srYU6hmU0zMsDoopkHKDdMnRkmJG0j71Br9+Kgn2XgeLJ3rmpkUU+TRNf3O R6EuY6+vnj1OlvHU6hj3Trrjooh/fqypUX9Vmj9KXlxhBAZb+q9xwosX7inHOK4uESVf9XnOCp4 eeC28fYVODXc3hApPC7j/mzpDFpf3V78elX061gowyUWHgGdh+w9Wz/xXDoR8rMICe0qkPMxs+u cp3ZM//nkqRz73/pz3XExg2oeRXDlgzIiCJsCe5NWR5iixe25pw2tsxj4tLXvDHySC+eUFH5MHb eBKsqEVz1gVrV2xopCK64ZIfMflyrPeDQDh/KeAiCmPx4NwGmRqNBHmBvepvI8UZOf47jCfAb/g l95jm9go1P3rNNNaxrmIy0PWOqAd1/AzISrWQ4ao6vqoo9cV/mo29NS7v+y7bPmQOaLDM1NS6FR lmXvVfj0/BdOnDvnE3eMuLM2nq/epBb+Z8e4 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/GrmfAEgmT4dlLiUenIQV7-3t0R0 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: Tue, 22 Apr 2014 21:00:21 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B7041ACFSPQCMBX02exfocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_89294A6F3C6C91459E52E4128C4B02B7041ACFSPQCMBX02exfocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim,=

I think the min/max sh= ould have microseconds granularity. Milliseconds would not be accurate enou= gh.

 

Personally, I would no= t trust my periodic tests in a large scale deployment to a random number ge= nerator and would want to know exactly how and when tests would be run.

 

 

Thanks,

Sharam

 

From: Carey, T= imothy (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<= /p>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_89294A6F3C6C91459E52E4128C4B02B7041ACFSPQCMBX02exfocom_-- From nobody Tue Apr 22 14: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 B5F5E1A0270 for ; Tue, 22 Apr 2014 14:07:39 -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 FLGTKPWCxDJy for ; Tue, 22 Apr 2014 14:07:34 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 103691A025D for ; Tue, 22 Apr 2014 14:07:34 -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 s3ML7CWg020647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Apr 2014 16:07:13 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s3ML7CJH032153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 17:07:12 -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, 22 Apr 2014 17:07:12 -0400 From: "Carey, Timothy (Timothy)" To: Sharam Hakimi , "lmap@ietf.org" , "trevor.burbridge@bt.com" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rA= Date: Tue, 22 Apr 2014 21:07:11 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> 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: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771953476FUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/kbPkOB2rJ7LO4mFZbrJmCEVaNMc 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: Tue, 22 Apr 2014 21:07:39 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771953476FUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sharam, We are talking about offsets for when to report; in the world we live in mi= lliseconds 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 woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771953476FUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sharam,

 

We are talking about o= ffsets for when to report; in the world we live in milliseconds is sufficie= nt – IMHO.

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the min/max sh= ould have microseconds granularity. Milliseconds would not be accurate enou= gh.

 

Personally, I would no= t trust my periodic tests in a large scale deployment to a random number ge= nerator and would want to know exactly how and when tests would be run.

 

 

Thanks,

Sharam

 

From: Carey, T= imothy (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<= /p>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_9966516C6EB5FC4381E05BF80AA55F771953476FUS70UWXCHMBA05z_-- From nobody Tue Apr 22 14:16: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 8D3641A026D for ; Tue, 22 Apr 2014 14:16:40 -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 f4EitIYnfXKe for ; Tue, 22 Apr 2014 14:16:35 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 748721A026B for ; Tue, 22 Apr 2014 14:16:35 -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 s3MLGKqg009537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Apr 2014 16:16:21 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s3MLGKNj028853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 17:16:20 -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; Tue, 22 Apr 2014 17:16:20 -0400 From: "Carey, Timothy (Timothy)" To: "MORTON, ALFRED C (AL)" , Sharam Hakimi , "lmap@ietf.org" , "trevor.burbridge@bt.com" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAALdaAQAAGpnHA= Date: Tue, 22 Apr 2014 21:16:19 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771953479E@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <2845723087023D4CB5114223779FA9C8017944AE0B@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017944AE0B@njfpsrvexg8.research.att.com> 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: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771953479EUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Hl2rta5YyIXP0IGAtmD-3oEcqpo 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: Tue, 22 Apr 2014 21:16:40 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771953479EUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Al, * Normal (The Gaussian distribution function) * Uniform-Discrete (The Uniform.Discrete distribution function) * Uniform-Continuous (The Uniform.Continuous distribution function) - This= was your uniform(0,180) I was able to define fairly simply these functions in the data models. What do you think? BR, Tim From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Tuesday, April 22, 2014 3:22 PM To: Carey, Timothy (Timothy); Sharam Hakimi; lmap@ietf.org; trevor.burbridg= e@bt.com Subject: RE: Timer: Poisson distribution question Both the examples in the framework draft use Uniform, http://tools.ietf.org/html/draft-ietf-lmap-framework-04#section-2 we're just trying to avoid strict periodicity - let's keep it simple (to specify, to generate...). Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: Tuesday, April 22, 2014 3:16 PM To: Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com Subject: Re: [lmap] Timer: Poisson distribution question Trevor, The data model is extensible by vendors so we can add functions and input v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771953479EUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Al,<= /p>

 

= ·  Normal (The Gaussian distribution function)

= ·  Uniform-Discrete (The Uniform.Discrete distribution function) <= /o:p>

= ·  Uniform-Continuous<= /i> (The Uniform.Continuous distribution function) – This was you= r uniform(0,180)

 

I was able to define fairly simply t= hese functions in the data models.

 

 

What do you think?=

 

BR,

Tim

 

From: MORTON, = ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Tuesday, April 22, 2014 3:22 PM
To: Carey, Timothy (Timothy); Sharam Hakimi; lmap@ietf.org; trevor.b= urbridge@bt.com
Subject: RE: Timer: Poisson distribution question<= /p>

 

Both the examples in the framework draft use Uniform,=

http://tools.ietf.org/html/draft-ietf-lmap-framework-04= #section-2

 

we're just trying to avoid strict periodicity -

let's keep it simple (to specify, to generate...).

Al

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: Tuesday, April 22, 2014 3:16 PM
To: Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_9966516C6EB5FC4381E05BF80AA55F771953479EUS70UWXCHMBA05z_-- From nobody Tue Apr 22 14:26: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 7195A1A025D for ; Tue, 22 Apr 2014 14:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 8gEBKAqkz8zu for ; Tue, 22 Apr 2014 14:25:56 -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 701911A026E for ; Tue, 22 Apr 2014 14:25:27 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-red.research.att.com (Postfix) with ESMTP id 145EF55435B; Tue, 22 Apr 2014 17:25:46 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-azure.research.att.com (Postfix) with ESMTP id 04519E01E7; Tue, 22 Apr 2014 17:25:22 -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; Tue, 22 Apr 2014 17:25:21 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , Sharam Hakimi , "lmap@ietf.org" , "trevor.burbridge@bt.com" Date: Tue, 22 Apr 2014 17:25:20 -0400 Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAALdaAQAAGpnHAAAF8OsA== Message-ID: <2845723087023D4CB5114223779FA9C8017944AE32@njfpsrvexg8.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <2845723087023D4CB5114223779FA9C8017944AE0B@njfpsrvexg8.research.att.com> <9966516C6EB5FC4381E05BF80AA55F771953479E@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771953479E@US70UWXCHMBA05.zam.alcatel-lucent.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_2845723087023D4CB5114223779FA9C8017944AE32njfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/WmXqjI93Y_UCqF728DmmbId0BYo 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: Tue, 22 Apr 2014 21:26:01 -0000 --_000_2845723087023D4CB5114223779FA9C8017944AE32njfpsrvexg8re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tim, ultimately, the scheduling resolution will render a continuous function discrete to some degree, right? seems like Uniform-discrete would do it, match the resolutions if possible.= . Al From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Tuesday, April 22, 2014 5:16 PM To: MORTON, ALFRED C (AL); Sharam Hakimi; lmap@ietf.org; trevor.burbridge@b= t.com Subject: RE: Timer: Poisson distribution question Al, * Normal (The Gaussian distribution function) * Uniform-Discrete (The Uniform.Discrete distribution function) * Uniform-Continuous (The Uniform.Continuous distribution function) - This= was your uniform(0,180) I was able to define fairly simply these functions in the data models. What do you think? BR, Tim From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Tuesday, April 22, 2014 3:22 PM To: Carey, Timothy (Timothy); Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com Subject: RE: Timer: Poisson distribution question Both the examples in the framework draft use Uniform, http://tools.ietf.org/html/draft-ietf-lmap-framework-04#section-2 we're just trying to avoid strict periodicity - let's keep it simple (to specify, to generate...). Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: Tuesday, April 22, 2014 3:16 PM To: Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt= .com Subject: Re: [lmap] Timer: Poisson distribution question Trevor, The data model is extensible by vendors so we can add functions and input v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_2845723087023D4CB5114223779FA9C8017944AE32njfpsrvexg8re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tim,

discrete to some degree, right?  <= /span>

seems like Uniform-discrete would do it, match the resolutio= ns if possible..

Al

 

From:<= /b> Care= y, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent:= Tuesday, April 22, 2014 5:16 PM
To: MORTON, ALFRED C (AL); S= haram Hakimi; lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE:= Timer: Poisson distribution question

 

Al,

 

·  Normal (T= he Gaussian distribution function)

·  Uniform-Discrete (The Uniform.Discrete distribution function)

·  Uniform-Continuous (The Uniform.Continuous distribution = function) – This was your uniform(0,180)

 

I was able to define= fairly simply these functions in the data models.

 

 

What do you think?

 

BR,

Tim=

 

From: MORTON, ALFRED C (AL)= [mailto:acmorton@att.com]
S= ent: Tuesday, April 22, 2014 3:22 PM
To: Carey, Timothy (Timo= thy); Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com
= Subject: RE: Timer: Poisson distribution question

=

 

= Both the example= s in the framework draft use Uniform,

http://t= ools.ietf.org/html/draft-ietf-lmap-framework-04#section-2

 

we're just trying to avoid = strict periodicity -

let's keep it simple (to sp= ecify, to generate...).

Al

<= p class=3DMsoNormal> 

<= b>From:<= /span> lmap [mailto:lmap-bounces@ietf.= org] On Behalf Of Carey, Timothy (Timothy)
Sent: Tuesd= ay, April 22, 2014 3:16 PM
To: Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com
Subject: Re: [lmap] Timer: Poisson d= istribution question

=  

Tre= vor,

 

The data model is extensible by vendors so we can add functions and i= nput variables as we need.

 

However we have to decide on which small subset= we actually want to standardize.

 

You suggested the Uniform and Normal whi= ch 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 r= andom number. Otherwise we will have 2 implementers of the same standard al= gorithm implement different variations. – Not good.=

 

So I suggest we = keep this simple.

 

Uniform Discrete – input variables - maximum [posi= tive integer]

Gaussian –input variables – mean of min/max, spread = =3D standard deviation

 

The min/max would be milliseconds – Spread wo= uld be an integer.

 

 

This sound OK?

 

BR

Tim

 

 

=

From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
Sent: Tu= esday, April 22, 2014 8:23 AM
To: Carey, Timothy (Timothy); lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE: Timer: Po= isson distribution question

 

Tim,

I think the Periodic Timer distribution needs to have closer configur= ation control by the user and I think your 2nd  choice atte= mpts to provide it but having a discrete interval definition is a better wa= y to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounc= es@ietf.org] On Behalf Of trevor.burbridge@bt.com
Sent: Tuesday, April 22, 2014 4:= 35 AM
To: tim= othy.carey@alcatel-lucent.com; lmap@ie= tf.org
Subject: Re: [lmap] Timer: Poisson distribution questi= on

 <= /p>

&nb= sp;

On continuous counterparts of Poisson I’m far from any exper= t 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 o= ne is continuous and one is discrete:

http://cm= science.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 Info= rmation Model can take either discrete or continuous functions – only= that there is currently no explicit support for specifying the interval us= ed for a discrete function. I was questioning the need to add this.

 

Personally I’d think that Normal and Uniform dist= ributions would cover most needs, but the framework should be flexible in t= his regard.

 

Trevor.

 <= /span>

<= o:p> 

 

Team,

 

The BBF is looking at standardiz= ing the model for Timers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition questions regarding Trevor= s response to the Poisson distribution for the Randomness of the Periodic T= imer.

 

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 stand= ard deviation (could use mean deviation or something else but I see no adva= ntage as long as we all know what it refers to) and need to change to a flo= at. The upper and lower cuts would be in seconds +/- the mean (also needs t= o change to float) and are simply used to trim the function – obvious= ly needed on a uniform distribution but useful to constrain other functions= .

 

I will make all this clear in the next release.

<= span lang=3DEN-GB style=3D'color:#1F497D'> 

As for poisson I think there are 3 options:

-        =   Use a continuous form instead=

-=           Have the discrete int= erval 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 de= monstrable value to supporting discrete functions (rather than continuous v= ersions of them).

<= p class=3DMsoNormal> “

 

But as people looked at Trevors response = there were additional questions:

=  

I don't understand what Trev= or means about the Poisson distribution.  As far as I know, it is a di= screte distribution, so a "continuous form" would be a different = distribution and not Poisson.  And I believe that we do need a continu= ous distribution.  But what matters is that the definition is clear, n= ot the particular distribution (I don't have an opinion on that).

 

 <= /o:p>

Could some= please clarify this for us – Are we planning something other than Po= isson method; better yet is there a definition for the types of distributio= n:

Po= isson, Normal and Uniform.

 

Thanks,

<= span style=3D'color:black'>Tim

 

= --_000_2845723087023D4CB5114223779FA9C8017944AE32njfpsrvexg8re_-- From nobody Tue Apr 22 14:34: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 103021A025F for ; Tue, 22 Apr 2014 14:34:06 -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 FZqayRtxbXeu for ; Tue, 22 Apr 2014 14:34:01 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id F373B1A025D for ; Tue, 22 Apr 2014 14:34:00 -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 s3MLXRoM017779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Apr 2014 16:33:27 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s3MLXQB6003090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 17:33:26 -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, 22 Apr 2014 17:33:26 -0400 From: "Carey, Timothy (Timothy)" To: "MORTON, ALFRED C (AL)" , Sharam Hakimi , "lmap@ietf.org" , "trevor.burbridge@bt.com" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAALdaAQAAGpnHAAAF8OsAAAT4Pg Date: Tue, 22 Apr 2014 21:33:25 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719534839@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <2845723087023D4CB5114223779FA9C8017944AE0B@njfpsrvexg8.research.att.com> <9966516C6EB5FC4381E05BF80AA55F771953479E@US70UWXCHMBA05.zam.alcatel-lucent.com> <2845723087023D4CB5114223779FA9C8017944AE32@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017944AE32@njfpsrvexg8.research.att.com> 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: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7719534839US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/J8udvZ2nQF6hJtDNLpAbLQmOXVE 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: Tue, 22 Apr 2014 21:34:06 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7719534839US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Al, Yes I think so - I am no expert on these functions but from what I understa= nd the Discrete function only takes an upper limit; the continuous takes a = lower and upper. BR, Tim From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Tuesday, April 22, 2014 4:25 PM To: Carey, Timothy (Timothy); Sharam Hakimi; lmap@ietf.org; trevor.burbridg= e@bt.com Subject: RE: Timer: Poisson distribution question Hi Tim, ultimately, the scheduling resolution will render a continuous function discrete to some degree, right? seems like Uniform-discrete would do it, match the resolutions if possible.= . Al From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Tuesday, April 22, 2014 5:16 PM To: MORTON, ALFRED C (AL); Sharam Hakimi; lmap@ietf.org; trevor.burbridge@b= t.com Subject: RE: Timer: Poisson distribution question Al, * Normal (The Gaussian distribution function) * Uniform-Discrete (The Uniform.Discrete distribution function) * Uniform-Continuous (The Uniform.Continuous distribution function) - This= was your uniform(0,180) I was able to define fairly simply these functions in the data models. What do you think? BR, Tim From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Tuesday, April 22, 2014 3:22 PM To: Carey, Timothy (Timothy); Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com Subject: RE: Timer: Poisson distribution question Both the examples in the framework draft use Uniform, http://tools.ietf.org/html/draft-ietf-lmap-framework-04#section-2 we're just trying to avoid strict periodicity - let's keep it simple (to specify, to generate...). Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: Tuesday, April 22, 2014 3:16 PM To: Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt= .com Subject: Re: [lmap] Timer: Poisson distribution question Trevor, The data model is extensible by vendors so we can add functions and input v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7719534839US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Al,<= /p>

 

Yes I think so –= I am no expert on these functions but from what I understand the Discrete = function only takes an upper limit; the continuous takes a lower and upper.=

 

BR,<= /p>

Tim<= /p>

 

From: MORTON, = ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Tuesday, April 22, 2014 4:25 PM
To: Carey, Timothy (Timothy); Sharam Hakimi; lmap@ietf.org; trevor.b= urbridge@bt.com
Subject: RE: Timer: Poisson distribution question<= /p>

 

Hi Tim,

ultimately, the scheduling resolution will render a contin= uous function

discrete to some degree, right? 

seems like Uniform-discrete would do it, match the resolut= ions if possible..

Al

 

From: Carey, T= imothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: Tuesday, April 22, 2014 5:16 PM
To: MORTON, ALFRED C (AL); Sharam Hakimi; lmap@ietf.org; trevor.burb= ridge@bt.com
Subject: RE: Timer: Poisson distribution question<= /p>

 

Al,<= /p>

 

= ·  Normal (The Gaussian distribution function)

= ·  Uniform-Discrete (The Uniform.Discrete distribution function) <= /o:p>

= ·  Uniform-Continuous<= /i> (The Uniform.Continuous distribution function) – This was you= r uniform(0,180)

 

I was able to define fairly simply t= hese functions in the data models.

 

 

What do you think?=

 

BR,

Tim

 

 

Both the examples in the framework draft use Uniform,=

http://tools.ietf.org/html/draft-ietf-lmap-framework-04= #section-2

 

we're just trying to avoid strict periodicity -

let's keep it simple (to specify, to generate...).

Al

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: Tuesday, April 22, 2014 3:16 PM
To: Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_9966516C6EB5FC4381E05BF80AA55F7719534839US70UWXCHMBA05z_-- From nobody Tue Apr 22 15:04: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 536231A0278 for ; Tue, 22 Apr 2014 15:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 puMd48BuRTP0 for ; Tue, 22 Apr 2014 15:04:32 -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 19E381A027C for ; Tue, 22 Apr 2014 15:04:32 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 0F4C8120315; Tue, 22 Apr 2014 18:04:50 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-azure.research.att.com (Postfix) with ESMTP id 6EEFAE01E7; Tue, 22 Apr 2014 18:04:26 -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; Tue, 22 Apr 2014 18:04:26 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , Sharam Hakimi , "lmap@ietf.org" , "trevor.burbridge@bt.com" Date: Tue, 22 Apr 2014 18:04:24 -0400 Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAALdaAQAAGpnHAAAF8OsAAAT4PgAAFAqZA= Message-ID: <2845723087023D4CB5114223779FA9C8017944AE3E@njfpsrvexg8.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <2845723087023D4CB5114223779FA9C8017944AE0B@njfpsrvexg8.research.att.com> <9966516C6EB5FC4381E05BF80AA55F771953479E@US70UWXCHMBA05.zam.alcatel-lucent.com> <2845723087023D4CB5114223779FA9C8017944AE32@njfpsrvexg8.research.att.com> <9966516C6EB5FC4381E05BF80AA55F7719534839@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719534839@US70UWXCHMBA05.zam.alcatel-lucent.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_2845723087023D4CB5114223779FA9C8017944AE3Enjfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ibXP2dZmVuCX1aKFv1LPDPjpgLk 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: Tue, 22 Apr 2014 22:04:38 -0000 --_000_2845723087023D4CB5114223779FA9C8017944AE3Enjfpsrvexg8re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable probably assumes LL =3D zero then, there have to be two limits. From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Tuesday, April 22, 2014 5:33 PM To: MORTON, ALFRED C (AL); Sharam Hakimi; lmap@ietf.org; trevor.burbridge@b= t.com Subject: RE: Timer: Poisson distribution question Al, Yes I think so - I am no expert on these functions but from what I understa= nd the Discrete function only takes an upper limit; the continuous takes a = lower and upper. BR, Tim From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Tuesday, April 22, 2014 4:25 PM To: Carey, Timothy (Timothy); Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com Subject: RE: Timer: Poisson distribution question Hi Tim, ultimately, the scheduling resolution will render a continuous function discrete to some degree, right? seems like Uniform-discrete would do it, match the resolutions if possible.= . Al From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Tuesday, April 22, 2014 5:16 PM To: MORTON, ALFRED C (AL); Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com Subject: RE: Timer: Poisson distribution question Al, * Normal (The Gaussian distribution function) * Uniform-Discrete (The Uniform.Discrete distribution function) * Uniform-Continuous (The Uniform.Continuous distribution function) - This= was your uniform(0,180) I was able to define fairly simply these functions in the data models. What do you think? BR, Tim From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Tuesday, April 22, 2014 3:22 PM To: Carey, Timothy (Timothy); Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com Subject: RE: Timer: Poisson distribution question Both the examples in the framework draft use Uniform, http://tools.ietf.org/html/draft-ietf-lmap-framework-04#section-2 we're just trying to avoid strict periodicity - let's keep it simple (to specify, to generate...). Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: Tuesday, April 22, 2014 3:16 PM To: Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt= .com Subject: Re: [lmap] Timer: Poisson distribution question Trevor, The data model is extensible by vendors so we can add functions and input v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_2845723087023D4CB5114223779FA9C8017944AE3Enjfpsrvexg8re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

probably assumes LL =3D zero the= n, there have to be two limits.

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

From: Carey, Timothy (Ti= mothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: Tuesday, = April 22, 2014 5:33 PM
To: MORTON, ALFRED C (AL); Sharam Hakimi; = lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE: Timer: Poisso= n distribution question

 

= Al,

 

Yes I think so – I am no expert on these functions but from what= I understand the Discrete function only takes an upper limit; the continuo= us takes a lower and upper.

 

<= span style=3D'color:#1F497D'>BR,

= Tim

 

<= p class=3DMsoNormal>From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Tuesday, April 22, 20= 14 4:25 PM
To: Carey, Timothy (Timothy); Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE: Timer: Pois= son distribution question

 

Hi Tim,

ultimately= , the scheduling resolution will render a continuous function

discrete to some degree, right? 

Al

 

From: Carey, Timothy (= Timothy) [mailto:timoth= y.carey@alcatel-lucent.com]
Sent: Tuesday, April 22, 2014 5:= 16 PM
To: MORTON, ALFRED C (AL); Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE: Timer: Poisson distri= bution question

=  

Al,=

&n= bsp;

·  Normal (The Gaussian distributi= on function)

·  Uniform-Discrete = (The Uniform.Discrete distribution function)

·  Uniform-Con= tinuous (The Uniform.Continuous distribution function) – This= was your uniform(0,180)

 <= /o:p>

I was able to define fairly simply these f= unctions in the data models.

&nb= sp;

 

What do you think?

&nbs= p;

BR,

From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Tuesday, A= pril 22, 2014 3:22 PM
To: Carey, Timothy (Timothy); Sharam Hakimi= ; lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE: Ti= mer: Poisson distribution question

 

Both the examples in the framework = draft use Uniform,

http://tools.ietf.org/html/= draft-ietf-lmap-framework-04#section-2

&= nbsp;

we're just trying to avoid strict periodicity - =

let's keep it simple (to specify, to generate...= ).

Al

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf= Of Carey, Timothy (Timothy)
Sent: Tuesday, April 22, 2014 3:= 16 PM
To: Sharam Hakimi; lmap@ie= tf.org; trevor.burbridge@bt.= com
Subject: Re: [lmap] Timer: Poisson distribution question<= o:p>

 

=

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 th= e 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. Otherwi= se we will have 2 implementers of the same standard algorithm implement dif= ferent variations. – Not good.

 

So I suggest we keep this simple.

&= nbsp;

Un= iform Discrete – input variables - maximum [positive integer]

Gaussian &= #8211;input variables – mean of min/max, spread =3D standard deviatio= n

<= o:p> 

The min/max would be milliseconds – Spread would be an integer.

=  

<= o:p> 

This sound OK?

 

BR

Tim

 

 

From: Sharam Hakimi [m= ailto: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 que= stion

 

Tim,

I think the Peri= odic Timer distribution needs to have closer configuration control by the u= ser and I think your 2nd  choice attempts to provide it but= having a discrete interval definition is a better way to go.

 

 =

Sharam<= o:p>

 

From: lmap [mailto:lmap-bounces@ietf.org] O= n Behalf Of trevor.burbridge= @bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: <= a href=3D"mailto:timothy.carey@alcatel-lucent.com">timothy.carey@alcatel-lu= cent.com; lmap@ietf.org
Subj= ect: Re: [lmap] Timer: Poisson distribution question<= /p>

 

 

<= p class=3DMsoNormal>On continuou= s counterparts of Poisson I’m far from any expert and it would certai= nly be up to the user to decide if such functions were suitable replacement= s for the discrete Poisson function. Yes it would be a different function e= ven if there was perfect fit (which they are not) as one is continuous and = one is discrete:

http://cmscience.blogspot.co.u= k/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 tak= e either discrete or continuous functions – only that there is curren= tly no explicit support for specifying the interval used for a discrete fun= ction. I was questioning the need to add this.

 <= /span>

P= ersonally 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

<= /div>

 

Team,

 

The BBF is looking at standardizing the model fo= r Timers as suggested by the IETF LMAP information model.

 

During the revi= ew of the timers we had addition questions regarding Trevors response to th= e Poisson distribution for the Randomness of the Periodic Timer.=

 

Trevor r= esponded:

 

“Yes this doe= s 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 a= s we all know what it refers to) and need to change to a float. The upper a= nd lower cuts would be in seconds +/- the mean (also needs to change to flo= at) and are simply used to trim the function – obviously needed on a = uniform distribution but useful to constrain other functions.

 <= o:p>

I will make all this clear in the next release.

 <= /o:p>

As for poisson I think there are 3 options:

-          = Use a co= ntinuous form instead<= /p>

-  &n= bsp;       Have the discrete interval implicit= in the function choice e.g.“poisson_1_sec”

-         = ; Add an interval to the information model.

 

I was real= ly thinking about the first, but I don’t see the problem with the sec= ond. However I wouldn’t do the third unless they was a demonstrable v= alue to supporting discrete functions (rather than continuous versions of t= hem).

 “

 

But as people looked at Trevors response there were a= dditional questions:

 

I don't understand what Trevor means ab= out the Poisson distribution.  As far as I know, it is a discrete dist= ribution, so a "continuous form" would be a different distributio= n and not Poisson.  And I believe that we do need a continuous distrib= ution.  But what matters is that the definition is clear, not the part= icular distribution (I don't have an opinion on that).

 <= /p>

 

Could some please cla= rify this for us – Are we planning something other than Poisson metho= d; better yet is there a definition for the types of distribution:

Poisson, Norm= al and Uniform.

 

Thanks,

Tim

 

= = --_000_2845723087023D4CB5114223779FA9C8017944AE3Enjfpsrvexg8re_-- From nobody Wed Apr 23 00:55: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 D87ED1A00D5 for ; Wed, 23 Apr 2014 00:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 bLW9Yg7YwQE8 for ; Wed, 23 Apr 2014 00:55:23 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id F319C1A00CF for ; Wed, 23 Apr 2014 00:55:22 -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; Wed, 23 Apr 2014 08:52:20 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.56]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 23 Apr 2014 08:54:59 +0100 From: To: , , Date: Wed, 23 Apr 2014 08:54:57 +0100 Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAA== Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771953476F@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: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72D46056FCAEMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/5jtdT91nHhW7IjCVTcL1-7vlh_I 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, 23 Apr 2014 07:55:29 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72D46056FCAEMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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."po= isson_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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72D46056FCAEMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 C= ontroller). 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 r= egistry). I’d like to avoid that.

 

Trevor.

 

Trevor Burbridge
Network Infrastructu= re & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax:= 01473 640929

Th= is 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 usin= g this information is prohibited. If you've received this email in error, p= lease 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: 180= 0000

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4= .0pt'>

From: Care= y, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent:= 22 April 2014 22:07
To: Sharam Hakimi; lmap@ietf.org; Burbri= dge,T,Trevor,TUB8 R
Subject: RE: Timer: Poisson distribution ques= tion

 

Sharam= ,

 

We are talking about offsets for when to repo= rt; 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; tr= evor.burbridge@bt.com
Subject: RE: Timer: Poisson distributio= n question

 

Tim,

I think the min/max should have mi= croseconds granularity. Milliseconds would not be accurate enough.

 

Personally, I would not trust my periodic tests in a lar= ge scale deployment to a random number generator and would want to know exa= ctly how and when tests would be run.

 

&nbs= p;

Thanks,

Sharam

=  

From: Carey, Timothy= (Timothy) [mailto:timo= thy.carey@alcatel-lucent.com]
Sent: Tuesday, April 22, 2014 = 3:16 PM
To: Sharam Hakimi; lmap@= ietf.org; trevor.burbridge@b= t.com
Subject: RE: Timer: Poisson distribution question<= /o:p>

&n= bsp;

Trevor,

 

The data model is extensible b= y vendors so we can add functions and input variables as we need.

 

However we have to decide on which small subset we actua= lly want to standardize.

 

You suggested the Unifo= rm and Normal which is fine but for the model we need to go farther by defi= ning 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.<= o:p>

 

So I suggest we keep this simple.

 

Uniform Discrete – input variables - maximum [positive i= nteger]

Gaussian –input variables – mean of min/max,= spread =3D standard deviation

 

The min/max would= be milliseconds – Spread would be an integer.

<= p class=3DMsoNormal> <= /o:p>

 

This sound OK?

 

=

BR

Tim

 

 

=

From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
<= b>Sent: Tuesday, April 22, 2014 8:23 AM
To: Carey, Timothy (T= imothy); lmap@ietf.org; trevor.burbridge@bt.com
Subject:= RE: Timer: Poisson distribution question

=

 

Tim,

I t= hink the Periodic Timer distribution needs to have closer configuration con= trol by the user and I think your 2nd  choice attempts to p= rovide it but having a discrete interval definition is a better way to go. =

 

 

Sharam

 

From:<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'> lmap [mailto:lmap-bounces@iet= f.org] On Behalf Of t= revor.burbridge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM<= br>To: timothy.c= arey@alcatel-lucent.com; lmap@ietf.org=
Subject: Re: [lmap] Timer: Poisson distribution question

=  

<= o:p> 

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 suita= ble replacements for the discrete Poisson function. Yes it would be a diffe= rent function even if there was perfect fit (which they are not) as one is = continuous and one is discrete:

<= span style=3D'color:#1F497D'>http://cmscience.blogspot.co= .uk/2008/04/mt-6-poisson-and-gamma-distribution.html<= /p>

http://arxiv.org/abs/1303.5990<= /p>

 

As I tried to say= the current Information Model can take either discrete or continuous funct= ions – only that there is currently no explicit support for specifyin= g 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 regar= d.

=  

Trevor.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timo= thy (Timothy)
Sent: 19 April 2014 20:24
To: lmap@ietf.org
Subject: [lmap] Timer: Po= isson distribution question

 

Team,

 

The BBF is looking at = standardizing the model for Timers as suggested by the IETF LMAP informatio= n model.

=  

During the r= eview 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 distribut= ion 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 s= ee no advantage as long as we all know what it refers to) and need to chang= e to a float. The upper and lower cuts would be in seconds +/- the mean (al= so needs to change to float) and are simply used to trim the function ̵= 1; obviously needed on a uniform distribution but useful to constrain other= functions.

 

I will make all this clear in the next re= lease.

 

<= span style=3D'color:#1F497D'>As for poisson I think there are 3 options:

<= ![if !supportLists]>-  = ;      Use a continuous form instead

-      = ;  Have t= he discrete interval implicit in the function choice e.g.“poisson_1_s= ec”=

-        = 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 un= less they was a demonstrable value to supporting discrete functions (rather= than continuous versions of them).

 “

 

But as people looked at Trevors response there were additi= onal questions:

 

I don't understand = what Trevor means about the Poisson distribution.  As far as I know, i= t is a discrete distribution, so a "continuous form" would be a d= ifferent 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).<= o:p>

 

 

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=

&nbs= p;

= --_000_ED51D9282D1D3942B9438CA8F3372EB72D46056FCAEMV64UKRDdoma_-- From nobody Wed Apr 23 05:00: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 9168A1A0348 for ; Wed, 23 Apr 2014 04:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=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 JK_CveII7fvO for ; Wed, 23 Apr 2014 04:59:43 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0267D1A034A for ; Wed, 23 Apr 2014 04:59:42 -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 s3NBxVIZ024857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Apr 2014 06:59:32 -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 s3NBxPYA006997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 07:59:31 -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; Wed, 23 Apr 2014 07:59:25 -0400 From: "Carey, Timothy (Timothy)" To: "marc.ibrahim" , "trevor.burbridge@bt.com" , "sharam.hakimi@exfo.com" , "lmap@ietf.org" Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAJhDsAAAFAvPA= Date: Wed, 23 Apr 2014 11:59:24 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719534E5D@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <20140423082219.M2420@mail.usj.edu.lb> In-Reply-To: <20140423082219.M2420@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.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/fEHm8PFSqeYJ9oKn9UE_NGbPeVo 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, 23 Apr 2014 11:59:57 -0000 Marc, Thanks for the comments; I agree that microseconds is too small for this; m= illiseconds would be the smallest increment I could ever envision but I hav= e no issue with seconds as well. I will leave it to consensus from the grou= p. -----Original Message----- From: marc.ibrahim [mailto:marc.ibrahim@usj.edu.lb]=20 Sent: Wednesday, April 23, 2014 3:24 AM To: trevor.burbridge@bt.com; Carey, Timothy (Timothy); sharam.hakimi@exfo.c= om; lmap@ietf.org Subject: Re: [lmap] Timer: Poisson distribution question Hello, In my opinion, if the random timing aims at spreading the load at controlle= r/collector,=20 uniform random timing is the only needed.=20 It is a kind of backoff timer to avoid simultaneous events. So no need for = other than=20 uniform distribution. Also I think that microseconds and milliseconds are too small compared to m= easurement=20 duration or transmitting time of a report. For example, If we don't want 10= MAs to=20 report simultaneously, the scale of seconds have to be used to avoid simult= aneous=20 connections to collector. BR, __________________________________ Marc Ibrahim Assistant Professor, Engineering Faculty Saint-Joseph University (USJ), Lebanon, _________________________________ On Wed, 23 Apr 2014 08:54:57 +0100, trevor.burbridge wrote > The random timing can be used for both specifying when a test runs, or wh= en a=20 > report is sent (or any other task such as contacting the Controller). It= =20 > doesn't have to be used, but it can be. >=20 > I don't really want different input variable for different functions. I d= on't=20 > see we need to. Also if we do, then we would have to have schema for each= =20 > function to specify which inputs are expected (like the measurement task= =20 > registry). I'd like to avoid that. >=20 > Trevor. >=20 > Trevor Burbridge > Network Infrastructure & Innovation | BT Innovate & Design > Tel: 01473 645115 > Fax: 01473 640929 >=20 > This email contains BT information, which may be privileged or confidenti= al.=20 > It's meant only for the individual(s) or entity named above. If you're no= t the=20 > intended recipient, note that disclosing, copying, distributing or using = this=20 > information is prohibited. If you've received this email in error, please= let=20 > me know immediately on the email address above. Thank you. We monitor our= =20 > email system, and may record your emails. British Telecommunications plc= =20 > Registered office: 81 Newgate Street London EC1A 7AJ Registered in Englan= d no:=20 > 1800000 >=20 > 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 >=20 > Sharam, >=20 > We are talking about offsets for when to report; in the world we live in= =20 > milliseconds is sufficient - IMHO. >=20 > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: Tuesday, April 22, 2014 3:59 PM > To: Carey, Timothy (Timothy); lmap@ietf.org;=20 trevor.burbridge@bt.com > Subject: RE: Timer: Poisson distribution question >=20 > Tim, > I think the min/max should have microseconds granularity. Milliseconds wo= uld=20 > not be accurate enough. >=20 > Personally, I would not trust my periodic tests in a large scale deployme= nt to=20 > a random number generator and would want to know exactly how and when tes= ts=20 > would be run. >=20 > Thanks, > Sharam >=20 > From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] > Sent: Tuesday, April 22, 2014 3:16 PM > To: Sharam Hakimi; lmap@ietf.org;=20 trevor.burbridge@bt.com > Subject: RE: Timer: Poisson distribution question >=20 > Trevor, >=20 > The data model is extensible by vendors so we can add functions and input= =20 > variables as we need. >=20 > However we have to decide on which small subset we actually want to stand= ardize. >=20 > You suggested the Uniform and Normal which is fine but for the model we n= eed=20 > to go farther by defining the specific function along with which inputs a= re=20 > used by the function to derive what random number. Otherwise we will have= 2=20 > implementers of the same standard algorithm implement different variation= s. - > Not good. >=20 > So I suggest we keep this simple. >=20 > Uniform Discrete - input variables - maximum [positive integer] > Gaussian -input variables - mean of min/max, spread =3D standard deviatio= n >=20 > The min/max would be milliseconds - Spread would be an integer. >=20 > This sound OK? >=20 > BR > Tim >=20 > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: Tuesday, April 22, 2014 8:23 AM > To: Carey, Timothy (Timothy); lmap@ietf.org;=20 trevor.burbridge@bt.com > Subject: RE: Timer: Poisson distribution question >=20 > Tim, > I think the Periodic Timer distribution needs to have closer configuratio= n=20 > control by the user and I think your 2nd choice attempts to provide it b= ut=20 > having a discrete interval definition is a better way to go. >=20 > Sharam >=20 > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of=20 trevor.burbridge@bt.com > Sent: Tuesday, April 22, 2014 4:35 AM > To: timothy.carey@alcatel-lucent.com;=20 > lmap@ietf.org Subject: Re: [lmap] Timer: Poisson=20 > distribution question >=20 > On continuous counterparts of Poisson I'm far from any expert and it woul= d=20 > certainly be up to the user to decide if such functions were suitable=20 > replacements for the discrete Poisson function. Yes it would be a differe= nt=20 > function even if there was perfect fit (which they are not) as one is=20 > continuous and one is discrete: http://cmscience.blogspot.co.uk/2008/04/m= t-6- > poisson-and-gamma-distribution.html http://arxiv.org/abs/1303.5990 >=20 > As I tried to say the current Information Model can take either discrete = or=20 > continuous functions - only that there is currently no explicit support f= or=20 > specifying the interval used for a discrete function. I was questioning t= he=20 > need to add this. >=20 > Personally I'd think that Normal and Uniform distributions would cover mo= st=20 > needs, but the framework should be flexible in this regard. >=20 > Trevor. >=20 > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Ti= mothy) > Sent: 19 April 2014 20:24 > To: lmap@ietf.org > Subject: [lmap] Timer: Poisson distribution question >=20 > Team, >=20 > The BBF is looking at standardizing the model for Timers as suggested by = the=20 > IETF LMAP information model. >=20 > During the review of the timers we had addition questions regarding Trevo= rs=20 > response to the Poisson distribution for the Randomness of the Periodic T= imer. >=20 > Trevor responded: >=20 > "Yes this does need to be clarified. I was assuming a distribution about = the=20 > mean (i.e. the timing given is the mean). The spread would be the standar= d=20 > deviation (could use mean deviation or something else but I see no advant= age=20 > as long as we all know what it refers to) and need to change to a float. = The=20 > upper and lower cuts would be in seconds +/- the mean (also needs to chan= ge to=20 > float) and are simply used to trim the function - obviously needed on a=20 > uniform distribution but useful to constrain other functions. >=20 > I will make all this clear in the next release. >=20 > As for poisson I think there are 3 options: >=20 > - Use a continuous form instead >=20 > - Have the discrete interval implicit in the function choice=20 e.g."poisson_1_sec" >=20 > - Add an interval to the information model. >=20 > I was really thinking about the first, but I don't see the problem with t= he=20 > second. However I wouldn't do the third unless they was a demonstrable va= lue=20 > to supporting discrete functions (rather than continuous versions of them= ). " >=20 > But as people looked at Trevors response there were additional questions: >=20 > I don't understand what Trevor means about the Poisson distribution. As = far=20 > as I know, it is a discrete distribution, so a "continuous form" would be= a=20 > different distribution and not Poisson. And I believe that we do need a= =20 > continuous distribution. But what matters is that the definition is clea= r, > not the particular distribution (I don't have an opinion on that). >=20 > Could some please clarify this for us - Are we planning something other t= han=20 > Poisson method; better yet is there a definition for the types of=20 > distribution: Poisson, Normal and Uniform. >=20 > Thanks, > Tim -- Open WebMail Project (http://openwebmail.org) From nobody Wed Apr 23 05:03: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 EB3741A035F for ; Wed, 23 Apr 2014 05:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 PGiAP69Akkr7 for ; Wed, 23 Apr 2014 05:03:41 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DF1B91A0347 for ; Wed, 23 Apr 2014 05:03:40 -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 s3NC3Wo3026627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Apr 2014 07:03:32 -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 s3NC3Vng009589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 08:03:31 -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; Wed, 23 Apr 2014 08:03:31 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "sharam.hakimi@exfo.com" , "lmap@ietf.org" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRA Date: Wed, 23 Apr 2014 12:03:30 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@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: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7719534E82US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/jlzN8encHUPq83ul4d_49tZ7WcE 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, 23 Apr 2014 12:03:47 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7719534E82US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion 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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7719534E82US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

If we don’t defi= ne the inputs for each function (leaving the inputs opaque) you will have i= nterop problems.

MA vendor 1 uses these= 2 inputs named “A” and “B”; MA vendor 2 uses 3 inp= uts named “A”, “X” and “Y” for the same= function.

 

I think we need to avo= id that if we realistically want the Randomness function to be used efficie= ntly.

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@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<= br> Subject: RE: Timer: Poisson distribution question<= /p>

 

The ran= dom timing can be used for both specifying when a test runs, or when a repo= rt is sent (or any other task such as contacting the Controller). It doesn&= #8217;t have to be used, but it can be.

&n= bsp;

I don&#= 8217;t really want different input variable for different functions. I don&= #8217;t see we need to. Also if we do, then we would have to have schema fo= r each function to specify which inputs are expected (like the measurement task registry). I’d like to avoid that.

&n= bsp;

Trevor.=

&n= bsp;

Trevor Bu= rbridge
Network Infrastructure & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(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 immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: Carey, T= imothy (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<= /p>

 

Sharam,

 

We are talking about o= ffsets for when to report; in the world we live in milliseconds is sufficie= nt – IMHO.

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the min/max sh= ould have microseconds granularity. Milliseconds would not be accurate enou= gh.

 

Personally, I would no= t trust my periodic tests in a large scale deployment to a random number ge= nerator and would want to know exactly how and when tests would be run.

 

 

Thanks,

Sharam

 

From: Carey, T= imothy (Timothy) [mailt= o: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<= /p>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_9966516C6EB5FC4381E05BF80AA55F7719534E82US70UWXCHMBA05z_-- From nobody Wed Apr 23 05:14: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 9F85C1A033B for ; Wed, 23 Apr 2014 05:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.272] 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 1xJTliPYXWF3 for ; Wed, 23 Apr 2014 05:14:11 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3FB1A0345 for ; Wed, 23 Apr 2014 05:14:11 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4F005A05E4; Wed, 23 Apr 2014 08:14:05 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 0FE10A05DF; Wed, 23 Apr 2014 08:14:05 -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; Wed, 23 Apr 2014 08:14:04 -0400 From: Sharam Hakimi To: "Carey, Timothy (Timothy)" , "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsA= Date: Wed, 23 Apr 2014 12:14:03 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.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: multipart/alternative; boundary="_000_89294A6F3C6C91459E52E4128C4B02B7041C05SPQCMBX02exfocom_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20650.007 X-TM-AS-Result: No--23.520-5.0-31-10 X-imss-scan-details: No--23.520-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20650.007 X-TMASE-Result: 10--23.519500-5.000000 X-TMASE-MatchedRID: pS5owHKhBO3eCNsd8bAqKLbQFsbjObJekgdwOpH8MWuFiT913RgMLgn9 ofQNoBQFPAvM+6MMmASHc4lwrx5hRCk9yXybJEtFlVHM/F6YkvSBHKTJ+sfXGZCngwEFj8Ix9Gb SSaq0f4P9OkTwUtVDKB8qsdUOh8PVJX/6wXlfbdFjoaO27r+3fZZ6zKu0q4rtHNJ22Gj+T8PnPb k1mVbRPXx/qsc6hdR4MSptkybvTyT0MLyooWuV8ZMSBMTQNiSAIfyQNHR2nablFby2iUWMmXaSg 7fiy0fI6B0xdyB1vBorrgC2DBe6shuydPTMFoR93It1/XcjYFMYgUSZaaEbBKjIAQm4zrjImuj0 YqjvrTMmieIJFGadmAACABC1vWQt6p7RvzM9iMtc/msUC5wFQZWr6iSXWtgPpzM0YVFmq6Zqapa 4NogScArcM7oybZvOTFO/oaPGV++rS9MAWgPxvoGLeiqu1yTKNNuh+5zmS681XgaT/3PTvoKi1k Mq95iluNRhn56czq40GaZO0xs/uTXsnl5F3ulZpkIW3Gref33llxDoyf1DWK+WgCcaviqG7Pcjn 1n460cdrrr/8xe31iw0EyG9wJEnum73Eco3Ptyp4G6k2AuBh+PmXK6rwg5Bq8z7POX8FJOpcW3l E1yJH0WsFZyEts6RJS6dICVZpkdCl9DEsHnSbeJ28KqpjndpbaH3VbOE/TlhmkNzrJb6ne//vbM LiEkVnfCgnZR65gXocyiWIpet6KOUVKBdY9a49TVembY3XZKCS0QTA8JzpEn+ggZfLJfy1MBQDb 2UJkL3TfNrpcz9AhQjizXtCXfTWYqLLUX2mAueAiCmPx4NwGmRqNBHmBveHOI0tZ7A+B1FGCd0S 0NCshNj+m6U4nDdq3zpOfDfWFVWFub11IqiCeqKlrkcQT62xYVzI3UCCaY= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/iktW5uuXq-p3dCxquJzqH1ENfoA 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, 23 Apr 2014 12:14:16 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B7041C05SPQCMBX02exfocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not see why vendor A or B or C matters. They would all be under the co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion 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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_89294A6F3C6C91459E52E4128C4B02B7041C05SPQCMBX02exfocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I do not see why vendo= r A or B or C matters. They would all be under the control of one Measureme= nt Controller which would specify what inputs to use for all MAs in a group= .

 

 

As Trevor also mention= ed this timer can be used for both testing and reporting and I would strong= ly suggest to have microsecond granularity. For reporting one could choose = seconds in terms of microseconds.

 

Thanks,

Sharam

 

 

 

From: Carey, T= imothy (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<= /p>

 

Trevor,

 

If we don’t defi= ne the inputs for each function (leaving the inputs opaque) you will have i= nterop problems.

MA vendor 1 uses these= 2 inputs named “A” and “B”; MA vendor 2 uses 3 inp= uts named “A”, “X” and “Y” for the same= function.

 

I think we need to avo= id that if we realistically want the Randomness function to be used efficie= ntly.

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@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<= br> Subject: RE: Timer: Poisson distribution question<= /p>

 

The ran= dom timing can be used for both specifying when a test runs, or when a repo= rt is sent (or any other task such as contacting the Controller). It doesn&= #8217;t have to be used, but it can be.

&n= bsp;

I don&#= 8217;t really want different input variable for different functions. I don&= #8217;t see we need to. Also if we do, then we would have to have schema fo= r each function to specify which inputs are expected (like the measurement task registry). I’d like to avoid that.

&n= bsp;

Trevor.=

&n= bsp;

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 infor= mation 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

&n= bsp;

From: Carey, T= imothy (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<= /p>

 

Sharam,

 

We are talking about o= ffsets for when to report; in the world we live in milliseconds is sufficie= nt – IMHO.

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the min/max sh= ould have microseconds granularity. Milliseconds would not be accurate enou= gh.

 

Personally, I would no= t trust my periodic tests in a large scale deployment to a random number ge= nerator and would want to know exactly how and when tests would be run.

 

 

Thanks,

Sharam

 

From: Carey, T= imothy (Timothy) [mailt= o: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<= /p>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_89294A6F3C6C91459E52E4128C4B02B7041C05SPQCMBX02exfocom_-- From nobody Wed Apr 23 05:15: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 CEE801A0354 for ; Wed, 23 Apr 2014 05:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 nDdPHInl00dU for ; Wed, 23 Apr 2014 05:15:46 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E6DD81A033B for ; Wed, 23 Apr 2014 05:15:45 -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 s3NCFadh024750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Apr 2014 07:15:36 -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 s3NCFZoh022500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 08:15:35 -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, 23 Apr 2014 08:15:35 -0400 From: "Carey, Timothy (Timothy)" To: Sharam Hakimi , "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sA== Date: Wed, 23 Apr 2014 12:15:34 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> 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: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7719534F79US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/z3OhJkPi94aaekXDpBmuMhIQUZk 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, 23 Apr 2014 12:15:53 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7719534F79US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So the burden is on the Measurement controller to know the functions and in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion 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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7719534F79US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So the burden is on th= e Measurement controller to know the functions and inputs specifications fo= r each possible MA vendor; not something I would want to have to do as a Me= asurement controller vendor.

 

From: Sharam H= akimi [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<= /p>

 

 

I do not see why vendo= r A or B or C matters. They would all be under the control of one Measureme= nt Controller which would specify what inputs to use for all MAs in a group= .

 

 

As Trevor also mention= ed this timer can be used for both testing and reporting and I would strong= ly suggest to have microsecond granularity. For reporting one could choose = seconds in terms of microseconds.

 

Thanks,

Sharam

 

 

 

From: Carey, T= imothy (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<= /p>

 

Trevor,

 

If we don’t defi= ne the inputs for each function (leaving the inputs opaque) you will have i= nterop problems.

MA vendor 1 uses these= 2 inputs named “A” and “B”; MA vendor 2 uses 3 inp= uts named “A”, “X” and “Y” for the same= function.

 

I think we need to avo= id that if we realistically want the Randomness function to be used efficie= ntly.

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@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<= br> Subject: RE: Timer: Poisson distribution question<= /p>

 

The ran= dom timing can be used for both specifying when a test runs, or when a repo= rt is sent (or any other task such as contacting the Controller). It doesn&= #8217;t have to be used, but it can be.

&n= bsp;

I don&#= 8217;t really want different input variable for different functions. I don&= #8217;t see we need to. Also if we do, then we would have to have schema fo= r each function to specify which inputs are expected (like the measurement task registry). I’d like to avoid that.

&n= bsp;

Trevor.=

&n= bsp;

Trevor Bu= rbridge
Network Infrastructure & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(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 immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: Carey, T= imothy (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<= /p>

 

Sharam,

 

We are talking about o= ffsets for when to report; in the world we live in milliseconds is sufficie= nt – IMHO.

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the min/max sh= ould have microseconds granularity. Milliseconds would not be accurate enou= gh.

 

Personally, I would no= t trust my periodic tests in a large scale deployment to a random number ge= nerator and would want to know exactly how and when tests would be run.

 

 

Thanks,

Sharam

 

From: Carey, T= imothy (Timothy) [mailt= o: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<= /p>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_9966516C6EB5FC4381E05BF80AA55F7719534F79US70UWXCHMBA05z_-- From nobody Wed Apr 23 05:24: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 2F9471A0345 for ; Wed, 23 Apr 2014 05:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.272] 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 8lRTUXaFOzSW for ; Wed, 23 Apr 2014 05:24:14 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5041A01C3 for ; Wed, 23 Apr 2014 05:24:13 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B48C3A05DF; Wed, 23 Apr 2014 08:24:07 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 6BEB8A05D9; Wed, 23 Apr 2014 08:24:07 -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; Wed, 23 Apr 2014 08:24:07 -0400 From: Sharam Hakimi To: "Carey, Timothy (Timothy)" , "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFw Date: Wed, 23 Apr 2014 12:24:06 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.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: multipart/alternative; boundary="_000_89294A6F3C6C91459E52E4128C4B02B7041C1CSPQCMBX02exfocom_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20650.007 X-TM-AS-Result: No--24.998-5.0-31-10 X-imss-scan-details: No--24.998-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20650.007 X-TMASE-Result: 10--24.998100-5.000000 X-TMASE-MatchedRID: pS5owHKhBO3MceyksUtCF0vrB8UvzFr4SMHPUFBx5taCsBeCv8CM/a9Z jAr+wzbbkSqH+Kc9BkIIxrtwrtZTIrUrw2b8K7DJlVHM/F6YkvRTL7AiHD6F5ulcq5anlmrUQfX exN3meZAoQCinIwCb3swhBUgPv4PsC3d7vPRaKlFVnniKh7YTC4EcpMn6x9cZkKeDAQWPwjH9VA behV/Hfhzj+86Aml1WHkrcIaHtsIMwH8qwXC+TQcjz0VPUnBA1/qWl+m17jWHF7duWDXiFEsNsx 6mgbAHnw/zmqegMe1bu/XquOh0chXjxgHkp9duCvBfThNe0zu9lrsuS5tC+P7rtDe4+j0ojJKip JgRx1kPeCrl6+Gl3yD0EYgRCBKDj/XV8bfqzEl8ea0JeKHt/00rCzBY4ZVGjQQ1XgvCe7sFed7P Ui7Muaa0hXW9fKY6w+dc3jTf9uFn7o9nJu0YiPDdhcxt1NzmuYpovC7zX5q+tj24Xqh0yXGHiv/ AI/OFkv3BF19v6cjzGeLuJp+7/xflYy+7Yif7JF0vYDRID+cqYZJKiXhR6LR2MqMQkpb/v5z54d P+Idrw29WXe+JdrM4zt0lGn9FQu5U8dS5kDfoZ/TWpwlAOFXiGi0ftsSkQypyURDSVseYuHb29D R0Z/Y2nNegw+u0O1ji3ltKoZ05GK6EB7L3k2mhNEPNwNrw/roYvTAujgTsKXWkGwIjHSW9eul29 /x8OD7Xmj9m2nDwdf3ExCVkYgwBFyIYZe6FcS/Sl5cYQQGW+DddlymG7iS0rRZP/NcCCSizrFpW HTBvcNat/xqna6p2rEBfVjKK6u1lfDCm9+EZWeAiCmPx4NwGmRqNBHmBveHOI0tZ7A+B1FGCd0S 0NCsrkX9T+aazh2eN8VjcdeF2E3Il4bqeYC49a+V8Unu9VjlExlQIQeRG0= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/B3pDkr7AJqs300rVarQBJdBL5yo 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, 23 Apr 2014 12:24:18 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B7041C1CSPQCMBX02exfocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion 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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_89294A6F3C6C91459E52E4128C4B02B7041C1CSPQCMBX02exfocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The measurement contro= ller has to communicate what tests have to be run on an MA, for how long, w= hen to run them, what test results are generated, etc. Why would configurin= g this parameter be any different. Maybe I am missing something.

 

 

 

From: Carey, T= imothy (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<= /p>

 

So the burden is on th= e Measurement controller to know the functions and inputs specifications fo= r each possible MA vendor; not something I would want to have to do as a Me= asurement controller vendor.

 

From: Sharam H= akimi [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<= /p>

 

 

I do not see why vendo= r A or B or C matters. They would all be under the control of one Measureme= nt Controller which would specify what inputs to use for all MAs in a group= .

 

 

As Trevor also mention= ed this timer can be used for both testing and reporting and I would strong= ly suggest to have microsecond granularity. For reporting one could choose = seconds in terms of microseconds.

 

Thanks,

Sharam

 

 

 

From: Carey, T= imothy (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<= /p>

 

Trevor,

 

If we don’t defi= ne the inputs for each function (leaving the inputs opaque) you will have i= nterop problems.

MA vendor 1 uses these= 2 inputs named “A” and “B”; MA vendor 2 uses 3 inp= uts named “A”, “X” and “Y” for the same= function.

 

I think we need to avo= id that if we realistically want the Randomness function to be used efficie= ntly.

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@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<= br> Subject: RE: Timer: Poisson distribution question<= /p>

 

The ran= dom timing can be used for both specifying when a test runs, or when a repo= rt is sent (or any other task such as contacting the Controller). It doesn&= #8217;t have to be used, but it can be.

&n= bsp;

I don&#= 8217;t really want different input variable for different functions. I don&= #8217;t see we need to. Also if we do, then we would have to have schema fo= r each function to specify which inputs are expected (like the measurement task registry). I’d like to avoid that.

&n= bsp;

Trevor.=

&n= bsp;

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 infor= mation 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

&n= bsp;

From: Carey, T= imothy (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<= /p>

 

Sharam,

 

We are talking about o= ffsets for when to report; in the world we live in milliseconds is sufficie= nt – IMHO.

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the min/max sh= ould have microseconds granularity. Milliseconds would not be accurate enou= gh.

 

Personally, I would no= t trust my periodic tests in a large scale deployment to a random number ge= nerator and would want to know exactly how and when tests would be run.

 

 

Thanks,

Sharam

 

From: Carey, T= imothy (Timothy) [mailt= o: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<= /p>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_89294A6F3C6C91459E52E4128C4B02B7041C1CSPQCMBX02exfocom_-- From nobody Wed Apr 23 05:36: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 9571C1A036F for ; Wed, 23 Apr 2014 05:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 EKSjyFukUh1T for ; Wed, 23 Apr 2014 05:36:14 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B0B5F1A0357 for ; Wed, 23 Apr 2014 05:36:13 -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 s3NCa49B010123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Apr 2014 07:36:05 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s3NCa2ww029263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 08:36:03 -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, 23 Apr 2014 08:36:02 -0400 From: "Carey, Timothy (Timothy)" To: Sharam Hakimi , "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsA= Date: Wed, 23 Apr 2014 12:36:01 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> 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: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7719535085US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/WaKezRcrsiN6k1v4NkzXHAvZu5g 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, 23 Apr 2014 12:36:26 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7719535085US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 cont= roller doesn't have a standard way of configuring a timer. For example - If I specify for a Uniform distribution function called "Unif= orm" you have a variable called "UpperLimit", the MA will implement the sp= ecification; the controller will implement the specification and things wor= k. If I do not specify anything for the Uniform distribution function - MA ven= dor 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 in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion 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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7719535085US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Its not that the Measu= rement controller has to configure the timer for the MA.

 

If we do not specify t= he functions and variable names, the measurement controller doesn’t h= ave 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 imp= lement the specification; the controller will implement the specification and things work.

 

If I do not specify an= ything for the Uniform distribution function – MA vendor 1 can call i= t “UniformDF” and “UL – which is typed real” = and maybe an “Enable” parameter for good measure; MA vendor 2 c= an call it “U” and have an attribute “X that is an integer”.<= o:p>

 

Now put that variation= on steroids based on the number of MA vendors – That is why we speci= fy things, right?

 

BR,<= /p>

Tim<= /p>

 

From: Sharam H= akimi [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<= /p>

 

The measurement contro= ller has to communicate what tests have to be run on an MA, for how long, w= hen to run them, what test results are generated, etc. Why would configurin= g this parameter be any different. Maybe I am missing something.

 

 

 

From: Carey, T= imothy (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<= /p>

 

So the burden is on th= e Measurement controller to know the functions and inputs specifications fo= r each possible MA vendor; not something I would want to have to do as a Me= asurement controller vendor.

 

From: Sharam H= akimi [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<= /p>

 

 

I do not see why vendo= r A or B or C matters. They would all be under the control of one Measureme= nt Controller which would specify what inputs to use for all MAs in a group= .

 

 

As Trevor also mention= ed this timer can be used for both testing and reporting and I would strong= ly suggest to have microsecond granularity. For reporting one could choose = seconds in terms of microseconds.

 

Thanks,

Sharam

 

 

 

From: Carey, T= imothy (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<= /p>

 

Trevor,

 

If we don’t defi= ne the inputs for each function (leaving the inputs opaque) you will have i= nterop problems.

MA vendor 1 uses these= 2 inputs named “A” and “B”; MA vendor 2 uses 3 inp= uts named “A”, “X” and “Y” for the same= function.

 

I think we need to avo= id that if we realistically want the Randomness function to be used efficie= ntly.

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@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<= br> Subject: RE: Timer: Poisson distribution question<= /p>

 

The ran= dom timing can be used for both specifying when a test runs, or when a repo= rt is sent (or any other task such as contacting the Controller). It doesn&= #8217;t have to be used, but it can be.

&n= bsp;

I don&#= 8217;t really want different input variable for different functions. I don&= #8217;t see we need to. Also if we do, then we would have to have schema fo= r each function to specify which inputs are expected (like the measurement task registry). I’d like to avoid that.

&n= bsp;

Trevor.=

&n= bsp;

Trevor Bu= rbridge
Network Infrastructure & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(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 immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: Carey, T= imothy (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<= /p>

 

Sharam,

 

We are talking about o= ffsets for when to report; in the world we live in milliseconds is sufficie= nt – IMHO.

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the min/max sh= ould have microseconds granularity. Milliseconds would not be accurate enou= gh.

 

Personally, I would no= t trust my periodic tests in a large scale deployment to a random number ge= nerator and would want to know exactly how and when tests would be run.

 

 

Thanks,

Sharam

 

From: Carey, T= imothy (Timothy) [mailt= o: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<= /p>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_9966516C6EB5FC4381E05BF80AA55F7719535085US70UWXCHMBA05z_-- From nobody Wed Apr 23 05:39: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 914E91A0357 for ; Wed, 23 Apr 2014 05:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 prhI7-Y5jHaL for ; Wed, 23 Apr 2014 05:39:46 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id CDF411A02C5 for ; Wed, 23 Apr 2014 05:39:45 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 23 Apr 2014 13:39:48 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.56]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Wed, 23 Apr 2014 13:38:33 +0100 From: To: , , Date: Wed, 23 Apr 2014 13:38:32 +0100 Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAzGvQ Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719534F79@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: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72D460571E5EMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ihUeKDok2laXfJQKWSZ7UXwDN2o 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, 23 Apr 2014 12:39:51 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72D460571E5EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let me make it clear that I agree. What I tried to say was that every funct= ion should have the SAME inputs - e.g. upper/lower cuts, spread, mean (inte= rval for discrete functions?). 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. 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:16 To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: Timer: Poisson distribution question So the burden is on the Measurement controller to know the functions and in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion 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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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."po= isson_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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72D460571E5EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let me make it clear that I agree. What I tried to say was th= at every function should have the SAME inputs – e.g. upper/lower cuts= , spread, mean (interval for discrete functions?).

 

Trevor.

 <= /span>

Trevor Burbridge
Network Inf= rastructure & Innovation | BT Innovate & Design
Tel: 01473 64511= 5
Fax: 01473 640929

This email contains BT information, which may be privileged or confi= dential. It's meant only for the individual(s) or entity named above. If yo= u're not the intended recipient, note that disclosing, copying, distributin= g 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 yo= u.
We monitor our email system, and may record your emails.
British Telecommunications plc
R= egistered office: 81 Newgate Street London EC1A 7AJ
Registered in Englan= d no: 1800000

 

From:<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'> Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 23 April 2014 13:16
To: Sharam Hakimi; Burbridge,T,= Trevor,TUB8 R; lmap@ietf.org
Subject: RE: Timer: Poisson distribu= tion question

&n= bsp;

So the burden is on the Measurement controller to know the functions and= inputs specifications for each possible MA vendor; not something I would w= ant to have to do as a Measurement controller vendor.

=

 =

From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
Sent: Wedne= sday, April 23, 2014 7:14 AM
To: Carey, Timothy (Timothy); trevor= .burbridge@bt.com; lmap@ietf.org
Subject: RE: Timer: Poisson dist= ribution 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 ti= mer 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, Timot= hy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: Wed= nesday, April 23, 2014 8:04 AM
To: trevor.burbridge@bt.com; Shara= m Hakimi; lmap@ietf.org
Subject: RE: Timer: Poisson distribution = question

 

Trevor,

 

If we don̵= 7;t define the inputs for each function (leaving the inputs opaque) you wil= l have interop problems.

MA vendor 1 uses these 2 inputs named &#= 8220;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 [mai= lto:trevor.burbridge@bt.com]
Sent: Wednesday, April 23, 2014 2:5= 5 AM
To: Carey, Timothy (Timothy); sharam.hakimi@exfo.com; lmap@i= etf.org
Subject: RE: Timer: Poisson distribution question

&nbs= p;

The r= andom timing can be used for both specifying when a test runs, or when a re= port is sent (or any other task such as contacting the Controller). It does= n’t have to be used, but it can be.

 

I don’t really want differ= ent input variable for different functions. I don’t see we need to. A= lso if we do, then we would have to have schema for each function to specif= y 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 recipie= nt, note that disclosing, copying, distributing or using this information i= s prohibited. If you've received this email in error, please let me know im= mediately on the email address above. Thank you.
We monitor our email sy= stem, 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 2= 2:07
To: Sharam Hakimi; lmap@ietf.org; Burbridge,T,Trevor,TUB8 R<= br>Subject: RE: Timer: Poisson distribution question

 

Sharam, =

&n= bsp;

We are talking about offsets for when to report; in the world we = live in milliseconds is sufficient – IMHO.

 

From: Sharam Hakimi [mailto:sharam.h= akimi@exfo.com]
Sent: Tuesday, April 22, 2014 3:59 PM
= To: Carey, Timothy (Timothy); lmap@iet= f.org; trevor.burbridge@bt.c= om
Subject: RE: Timer: Poisson distribution question

 = ;

Tim,

I think the min/max should have microseconds granular= ity. 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 t= ests would be run.

 

 

=

Thanks,

Sharam

 

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-= lucent.com]
Sent: Tuesday, April 22, 2014 3:16 PM
To:<= /b> Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com
Su= bject: RE: Timer: Poisson distribution question

 <= /p>

Trevor,<= o:p>

 

The data model is extensible by vendors so we ca= n add functions and input variables as we need.

 =

= However we have to decide on which small subset we actually want to standar= dize.

 

You suggested the Uniform and Normal which= is fine but for the model we need to go farther by defining the specific f= unction along with which inputs are used by the function to derive what ran= dom number. Otherwise we will have 2 implementers of the same standard algo= rithm implement different variations. – Not good.

&nbs= p;

So I suggest we keep this simple.

 

Unifor= m Discrete – input variables - maximum [positive integer]<= /span>

G= aussian –input variables – mean of min/max, spread =3D standard= deviation

 

The min/max would be milliseconds = 211; Spread would be an integer.

=  

 

This sound OK?

 

BR

Tim

 

 

From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
Sent: Tuesday, A= pril 22, 2014 8:23 AM
To: Carey, Timothy (Timothy); lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE: Timer: Poisson di= stribution question

<= span lang=3DEN-US> 

Tim,

I think the Periodic Time= r 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 Behal= f Of trevor.burbridge@bt.com=
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.carey@alcatel-lucent.c= om; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question

 

 

On continuous coun= terparts 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-pois= son-and-gamma-distribution.html

http://arxiv.org/abs/1303.5990

 

As I tried to say the current Informat= ion Model can take either discrete or continuous functions – only tha= t there is currently no explicit support for specifying the interval used f= or a discrete function. I was questioning the need to add this.<= /span>

 

Personally= I’d think that Normal and Uniform distributions would cover most nee= ds, but the framework should be flexible in this regard.<= /p>

 

Trevor.

 <= /o:p>

&nb= sp;

From:= lmap [mailto:lmap= -bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
S= ent: 19 April 2014 20:24
To: lmap@ietf.org
Subject: [lmap] Timer: Poisson distribution qu= estion

 

Team,

<= p class=3DMsoNormal> 

The BBF is looking at standardizing the mod= el for Timers as suggested by the IETF LMAP information model.

 

During the review of the timers w= e had addition questions regarding Trevors response to the Poisson distribu= tion for the Randomness of the Periodic Timer.

 

Trevor responded:

 

“Yes th= is 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 devia= tion (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 u= pper 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.<= span lang=3DEN-US style=3D'color:black'>

 

I will make all this clear in the next release.

 

As for poisson I think there are 3 options:

-=      =    U= se a continuous form instead

-        Have the discrete interval= implicit in the function choice e.g.“poisson_1_sec”

-   &= nbsp;    Add an interval to the information model.

 

I= was really thinking about the first, but I don’t see the problem wit= h the second. However I wouldn’t do the third unless they was a demon= strable value to supporting discrete functions (rather than continuous vers= ions of them).

 “

 

But a= s people looked at Trevors response there were additional questions:

 

I don't understand what Trevor means abou= t the Poisson distribution.  As far as I know, it is a discrete distri= bution, so a "continuous form" would be a different distribution = and not Poisson.  And I believe that we do need a continuous distribut= ion.  But what matters is that the definition is clear, not the partic= ular distribution (I don't have an opinion on that).

<= p class=3DMsoNormal> 

 

Could some please clarify this for us – Are we plann= ing something other than Poisson method; better yet is there a definition f= or the types of distribution:

Poisson, Normal and Uniform.

=  

Thanks,

Tim

 

= --_000_ED51D9282D1D3942B9438CA8F3372EB72D460571E5EMV64UKRDdoma_-- From nobody Wed Apr 23 05:41: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 21F181A0380 for ; Wed, 23 Apr 2014 05:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 lFWBYrpbjHU7 for ; Wed, 23 Apr 2014 05:40:57 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9D71A037B for ; Wed, 23 Apr 2014 05:40:56 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 23 Apr 2014 13:37:55 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.56]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Wed, 23 Apr 2014 13:40:47 +0100 From: To: , , Date: Wed, 23 Apr 2014 13:40:45 +0100 Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsA== Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7719535085@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: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72D460571EBEMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/fXkFoRS5h6gLHnhHqPmy-fAqaXU 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, 23 Apr 2014 12:41:04 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72D460571EBEMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 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. 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 cont= roller doesn't have a standard way of configuring a timer. For example - If I specify for a Uniform distribution function called "Unif= orm" you have a variable called "UpperLimit", the MA will implement the sp= ecification; the controller will implement the specification and things wor= k. If I do not specify anything for the Uniform distribution function - MA ven= dor 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 in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion 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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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."po= isson_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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72D460571EBEMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree we need to have well defined function names. I thought = you were also suggesting different functions needed different input paramet= ers.

 

Trevor.

 

Tr= evor Burbridge
Network Infrastructure & Innovation | BT Innovate &am= p; Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT information, whi= ch 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 dis= closing, 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 rec= ord your emails.
Britis= h Telecommunications plc
Registered office: 81 Newgate Street London EC1= A 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 ha= s to configure the timer for the MA.

 

If we do n= ot specify the functions and variable names, the measurement controller doe= sn’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 “Upper= Limit”, 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 i= s typed real” and maybe an “Enable” parameter for good me= asure; MA vendor 2 can call it “U” and have an attribute “= ;X that is an integer”.

 

Now put that varia= tion on steroids based on the number of MA vendors – That is why we s= pecify things, right?

 

BR,

=

Tim

 

F= rom: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
S= ent: Wednesday, April 23, 2014 7:24 AM
To: Carey, Timothy (Ti= mothy); 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 th= is parameter be any different. Maybe I am missing something.

 

 

 

<= p class=3DMsoNormal>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; lma= p@ietf.org
Subject: RE: Timer: Poisson distribution question=

&= nbsp;

So the burden is on the Measurement controller to know the funct= ions 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 (Timoth= y); trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: Timer: Po= isson distribution question

 

=  

I do not see wh= y vendor A or B or C matters. They would all be under the control of one Me= asurement Controller which would specify what inputs to use for all MAs in = a group.

 

 

As Trevor also mention= ed this timer can be used for both testing and reporting and I would strong= ly suggest to have microsecond granularity. For reporting one could choose = seconds in terms of microseconds.

 

Thanks,

Sharam

 

 

 

From: C= arey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Se= nt: Wednesday, April 23, 2014 8:04 AM
To: trevor.burbridge@bt= .com; Sharam Hakimi; lmap@ietf.org
Subject: RE: Timer: Poisson di= stribution question

<= span lang=3DEN-US> 

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 realistic= ally want the Randomness function to be used efficiently.=

&n= bsp;

BR,

Tim

 

From: trevor.burbridge@b= t.com [mailto:trevor.burbridge@bt.com]
Sent: Wednesday, April 23= , 2014 2:55 AM
To: Carey, Timothy (Timothy); sharam.hakimi@exfo.c= om; lmap@ietf.org
Subject: RE: Timer: Poisson distribution questi= on

 

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 w= ant 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 & In= novation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 6409= 29

This email co= ntains 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 intende= d recipient, note that disclosing, copying, distributing or using this info= rmation is prohibited. If you've received this email in error, please let m= e 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, Timoth= y (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: 22 A= pril 2014 22:07
To: Sharam Hakimi; lmap@ietf.org; Burbridge,T,Tre= vor,TUB8 R
Subject: RE: Timer: Poisson distribution question=

 

Sharam,

 

We are talking about offsets for when to report; in th= e world we live in milliseconds is sufficient – IMHO.

=  

From: Sharam Hakimi [mailt= o:sharam.hakimi@exfo.com]
Sent: Tuesday, April 22, 2014 3:59= PM
To: Carey, Timothy (Timothy); lmap@ietf.org; trevor.burb= ridge@bt.com
Subject: RE: Timer: Poisson distribution questio= n

=  

Tim,

I think the min/max should have microseco= nds granularity. Milliseconds would not be accurate enough.

=  

Personally, I would not trust my periodic tests in a large scal= e deployment to a random number generator and would want to know exactly ho= w and when tests would be run.

<= span lang=3DEN-US style=3D'color:#1F497D'> 

 

Thanks,

Sharam

 

From: Carey, Timothy (Timot= hy) [mailto:timothy.car= ey@alcatel-lucent.com]
Sent: Tuesday, April 22, 2014 3:16 PM=
To: Sharam Hakimi; lmap@ietf.or= g; trevor.burbridge@bt.com
Subject: RE: Timer: Poisson distribution question

 

Trevor,

 

The data model is extensible by vendo= rs so we can add functions and input variables as we need.

&= nbsp;

However we have to decide on which small subset we actually want= to standardize.

 

You suggested the Uniform and N= ormal 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 deri= ve what random number. Otherwise we will have 2 implementers of the same st= andard algorithm implement different variations. – Not good.

 

So I suggest we keep this simple.

<= p class=3DMsoNormal> <= /o:p>

Uniform Discrete – input variables - maximum [positive integer]<= o:p>

Gaussian –input variables – mean of min/max, spread = =3D standard deviation

 

The min/max would be mill= iseconds – 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: Time= r: 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 i= t but having a discrete interval definition is a better way to go.

 

 

Sharam

 

From: l= map [mailto:lmap-bounces@ietf.org<= /a>] On Behalf Of trevor.= burbridge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
= To: timothy.carey@a= lcatel-lucent.com; lmap@ietf.orgSubject: Re: [lmap] Timer: Poisson distribution question

 =

&n= bsp;

On = continuous counterparts of Poisson I’m far from any expert and it wou= ld certainly be up to the user to decide if such functions were suitable re= placements for the discrete Poisson function. Yes it would be a different f= unction even if there was perfect fit (which they are not) as one is contin= uous and one is discrete:

http://cmscience.blogspot.co.uk/20= 08/04/mt-6-poisson-and-gamma-distribution.html

http://arxiv.org/abs/1303.5990

 

As I tried to say the c= urrent Information Model can take either discrete or continuous functions &= #8211; only that there is currently no explicit support for specifying the = interval used for a discrete function. I was questioning the need to add th= is.

 

Personally I’d think that Normal and Uniform distributions would= cover most needs, but the framework should be flexible in this regard.

&= nbsp;

Tr= evor.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (T= imothy)
Sent: 19 April 2014 20:24
To: lmap@ietf.org
Subject: [lmap] Timer: Poisson = distribution question

 

Team,

 

The BBF is looking at standa= rdizing the model for Timers as suggested by the IETF LMAP information mode= l.

 =

During the review = of the timers we had addition questions regarding Trevors response to the P= oisson distribution for the Randomness of the Periodic Timer.

 

Trevor responded:

 

“Yes this does need to be clarified. I was assuming a distribution ab= out the mean (i.e. the timing given is the mean). The spread would be the s= tandard 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 nee= ds to change to float) and are simply used to trim the function – obv= iously needed on a uniform distribution but useful to constrain other funct= ions.

=

 

<= span style=3D'color:#1F497D'>I will make all this clear in the next release= .

 

As for poisson I think there are 3 options:<= span lang=3DEN-US style=3D'color:black'>

-  &nbs= p;     Use a continuous form instead

-      &nb= sp; Have the d= iscrete interval implicit in the function choice e.g.“poisson_1_sec&#= 8221;

=

-&nb= sp;       Add an interval to the information model.<= span lang=3DEN-US style=3D'color:black'>

 

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 q= uestions:

 

I don't understand what T= revor means about the Poisson distribution.  As far as I know, it is a= discrete distribution, so a "continuous form" would be a differe= nt distribution and not Poisson.  And I believe that we do need a cont= inuous 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 ̵= 1; Are we planning something other than Poisson method; better yet is there= a definition for the types of distribution:

Poisson, Normal and U= niform.

 

Thanks,

Tim

 

= --_000_ED51D9282D1D3942B9438CA8F3372EB72D460571EBEMV64UKRDdoma_-- From nobody Wed Apr 23 05:47: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 5902D1A037B for ; Wed, 23 Apr 2014 05:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 Zbj1M6qXIcpz for ; Wed, 23 Apr 2014 05:47:31 -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 3C40E1A02C5 for ; Wed, 23 Apr 2014 05:47:31 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 091671202DF; Wed, 23 Apr 2014 08:47:51 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id 89235F0386; Wed, 23 Apr 2014 08:47:25 -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; Wed, 23 Apr 2014 08:47:25 -0400 From: "MORTON, ALFRED C (AL)" To: "trevor.burbridge@bt.com" , "timothy.carey@alcatel-lucent.com" , "sharam.hakimi@exfo.com" , "lmap@ietf.org" Date: Wed, 23 Apr 2014 08:47:23 -0400 Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAJ3Bg Message-ID: <2845723087023D4CB5114223779FA9C8017944AE6F@njfpsrvexg8.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.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: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8017944AE6Fnjfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/l9_QZDs4rKzpg7v2HJWtr_hcRso 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, 23 Apr 2014 12:47:40 -0000 --_000_2845723087023D4CB5114223779FA9C8017944AE6Fnjfpsrvexg8re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems as though a good part of this exchange has been skipped-over, Tim and I clarified a lot of this last night... One function will do, discrete Uniform seems to meet the need. Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.= com Sent: Wednesday, April 23, 2014 8:41 AM To: timothy.carey@alcatel-lucent.com; sharam.hakimi@exfo.com; lmap@ietf.org Subject: Re: [lmap] 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 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. 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 cont= roller doesn't have a standard way of configuring a timer. For example - If I specify for a Uniform distribution function called "Unif= orm" you have a variable called "UpperLimit", the MA will implement the sp= ecification; the controller will implement the specification and things wor= k. If I do not specify anything for the Uniform distribution function - MA ven= dor 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 in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion to be used efficiently. BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_2845723087023D4CB5114223779FA9C8017944AE6Fnjfpsrvexg8re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It seems as though a good part o= f this exchange has been skipped-over,

Tim and I = clarified a lot of this last night...

 =

One function will do, discrete Uniform seems to meet = the need.

 

Al

 

<= p class=3DMsoNormal>From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of= trevor.burbridge@bt.com
Sent: Wednesday, April 23, 2014 8:41= AM
To: timothy.carey@alcatel-lucent.com; sharam.hakimi@exfo.com;= lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution qu= estion

 

Agre= e we need to have well defined function names. I thought you were also sugg= esting different functions needed different input parameters.

 

Trevor.

 

Trevor Burbridge
Network Infrastructur= e & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: = 01473 640929

<= /span>This email contains BT information, which may be pri= vileged or confidential. It's meant only for the individual(s) or entity na= med above. If you're not the intended recipient, note that disclosing, copy= ing, distributing or using this information is prohibited. If you've receiv= ed 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 emai= ls.
British Telecommunications plc
Registered office: 81 Newgate Stre= et London EC1A 7AJ
Registered in England no: 1800000

 

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alca= tel-lucent.com]
Sent: 23 April 2014 13:36
To: Shar= am 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 measureme= nt controller doesn’t have a standard way of configuring a timer.

&= nbsp;

Fo= r example – If I specify for a Uniform distribution function called &= #8220;Uniform” you have a  variable called “UpperLimitR= 21;, the MA will implement the specification; the controller will implement= the specification and things work.

 

If I do not specify anything for the U= niform distribution function – MA vendor 1 can call it “Uniform= DF” and “UL – which is typed real” and maybe an = 220;Enable” parameter for good measure; MA vendor 2 can call it ̶= 0;U” and have an attribute “X that is an integer”.

&nbs= p;

Now p= ut that variation on steroids based on the number of MA vendors – Tha= t 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 d= istribution 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. W= hy would configuring this parameter be any different. Maybe I am missing so= mething.

 

 

 

Fro= m: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: Wedn= esday, April 23, 2014 8:16 AM
To: Sharam Hakimi; trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: Timer: Poisson distr= ibution question

 

So the = burden is on the Measurement controller to know the functions and inputs sp= ecifications for each possible MA vendor; not something I would want to hav= e to do as a Measurement controller vendor.

 

From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
Sent: Wednes= day, April 23, 2014 7:14 AM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: Timer: Pois= son 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 t= o 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 o= f 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 Hak= imi; lmap@ietf.org
Subject: = RE: Timer: Poisson distribution question

<= p class=3DMsoNormal> 

Trevor,

 

If we don’t define the inputs for each fu= nction (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” f= or the same function.

 

I think we need to avoid that if we realistically w= ant the Randomness function to be used efficiently.

 

BR,<= /p>

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 di= stribution question

<= o:p> 

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 Contro= ller). It doesn’t have to be used, but it can be.

&nbs= p;

I don’t really want different input variable for different fu= nctions. 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 t= he measurement task registry). I’d like to avoid that.

 

Trevor.

 

Trevor Burbridge
Network Infrastructur= e & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: = 01473 640929

<= /span>This email contains BT information, which may be pri= vileged or confidential. It's meant only for the individual(s) or entity na= med above. If you're not the intended recipient, note that disclosing, copy= ing, distributing or using this information is prohibited. If you've receiv= ed 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 emai= ls.
British Telecommunications plc
Registered office: 81 Newgate Stre= et London EC1A 7AJ
Registered in England no: 1800000

 

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alca= tel-lucent.com]
Sent: 22 April 2014 22:07
To: Shar= am 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: Tu= esday, April 22, 2014 3:59 PM
To: Carey, Timothy (Timothy); lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE: Timer: Po= isson distribution question

 

Tim,

I think the min/max should have microseconds granularity. Millisecond= s would not be accurate enough.

<= span style=3D'color:#1F497D'> 

Personally, I would not trust my periodic = tests in a large scale deployment to a random number generator and would wa= nt to know exactly how and when tests would be run.

<= p class=3DMsoNormal> <= /p>

 

Thanks,

Sharam<= /o:p>

&nb= sp;

From: Carey, Timothy (= Timothy) [mailto:timoth= y.carey@alcatel-lucent.com]
Sent: Tuesday, April 22, 2014 3:= 16 PM
To: Sharam Hakimi; lmap@ie= tf.org; trevor.burbridge@bt.= com
Subject: RE: Timer: Poisson distribution question

 

Trevor,

 

The data model is exte= nsible 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 standar= dize.

 

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 i= nputs are used by the function to derive what random number. Otherwise we w= ill have 2 implementers of the same standard algorithm implement different = variations. – Not good.

 

So I suggest we keep this simple.=

 

Uniform D= iscrete – input variables - maximum [positive integer]

Gaussian –i= nput variables – mean of min/max, spread =3D standard deviation<= /o:p>

&nb= sp;

The = min/max would be milliseconds – Spread would be an integer.

 <= /o:p>

&nb= sp;

This= sound OK?

 

BR

Tim

 

 

From: Sharam Hakimi [mailto:= sharam.hakimi@exfo.com]
Sent: Tuesday, April 22, 2014 8:23 A= M
To: Carey, Timothy (Timothy); = lmap@ietf.org; trevor.burbri= dge@bt.com
Subject: RE: Timer: Poisson distribution question<= o:p>

 

=

Tim,

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go. <= /p>

 

 =

Sharam

&nbs= p;

From: lmap [mailto:lmap-bounces@ietf.org] On Behal= f Of trevor.burbridge@bt.com=
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.carey@alcatel-lucent.c= om; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question

 

 

On continuous coun= terparts 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 eith= er 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.

 =

Persona= lly 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 Car= ey, Timothy (Timothy)
Sent: 19 April 2014 20:24
To: lmap@ietf.org
Subject: [lmap] T= imer: 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 t= imers we had addition questions regarding Trevors response to the Poisson d= istribution 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 g= iven is the mean). The spread would be the standard deviation (could use me= an deviation or something else but I see no advantage as long as we all kno= w what it refers to) and need to change to a float. The upper and lower cut= s 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 dist= ribution but useful to constrain other functions.

 

I w= ill make all this clear in the next release.

 <= /p>

As for p= oisson I think there are 3 options:=

-=           Use a continuous form= instead

-    &= nbsp;     Have the discrete interval implicit in the fun= ction choice e.g.“poisson_1_sec”

-          Add an inter= val to the information model.=

=  

I was really thinking a= bout 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 suppo= rting discrete functions (rather than continuous versions of them).<= span style=3D'color:black'>

 “

 

But as people looked at Trevors response there were additional que= stions:

 

I don't understand what Trevor means about the Poisso= n distribution.  As far as I know, it is a discrete distribution, so a= "continuous form" would be a different distribution and not Pois= son.  And I believe that we do need a continuous distribution.  B= ut what matters is that the definition is clear, not the particular distrib= ution (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 Unifor= m.

 

= Thanks,

Tim

 

= --_000_2845723087023D4CB5114223779FA9C8017944AE6Fnjfpsrvexg8re_-- From nobody Wed Apr 23 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 CF2CA1A02C5 for ; Wed, 23 Apr 2014 05:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ztaHHzObhWi2 for ; Wed, 23 Apr 2014 05:47:38 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF991A037A for ; Wed, 23 Apr 2014 05:47: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 s3NClSXf021461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Apr 2014 07:47:29 -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 s3NClSGs012672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 08:47:28 -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; Wed, 23 Apr 2014 08:47:28 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "sharam.hakimi@exfo.com" , "lmap@ietf.org" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAMH2A Date: Wed, 23 Apr 2014 12:47:23 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@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: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771953515BUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/gdE9-R-oPkLXD90J3aVpALtn20A 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, 23 Apr 2014 12:47:49 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771953515BUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, No - I am using the variable of your Information Model (LowerLimit, UpperLi= mit, Spread) - works so far. Marc suggested a TimeStep parameter so we don't lockin on a specific micros= econd, 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 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. 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 cont= roller doesn't have a standard way of configuring a timer. For example - If I specify for a Uniform distribution function called "Unif= orm" you have a variable called "UpperLimit", the MA will implement the sp= ecification; the controller will implement the specification and things wor= k. If I do not specify anything for the Uniform distribution function - MA ven= dor 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 in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion 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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771953515BUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

No – I am using = the variable of your Information Model (LowerLimit, UpperLimit, Spread) = 211; works so far.

Marc suggested a TimeS= tep parameter so we don’t lockin on a specific microsecond, milliseco= nd, second thing – I am open to that.

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@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<= br> Subject: RE: Timer: Poisson distribution question<= /p>

 

Agree w= e need to have well defined function names. I thought you were also suggest= ing different functions needed different input parameters.

&n= bsp;

Trevor.=

&n= bsp;

Trevor Bu= rbridge
Network Infrastructure & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(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 immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: Carey, T= imothy (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<= /p>

 

Its not that the Measu= rement controller has to configure the timer for the MA.

 

If we do not specify t= he functions and variable names, the measurement controller doesn’t h= ave 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 imp= lement the specification; the controller will implement the specification and things work.

 

If I do not specify an= ything for the Uniform distribution function – MA vendor 1 can call i= t “UniformDF” and “UL – which is typed real” = and maybe an “Enable” parameter for good measure; MA vendor 2 c= an call it “U” and have an attribute “X that is an integer”.<= o:p>

 

Now put that variation= on steroids based on the number of MA vendors – That is why we speci= fy things, right?

 

BR,<= /p>

Tim<= /p>

 

From: Sharam H= akimi [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<= /p>

 

The measurement contro= ller has to communicate what tests have to be run on an MA, for how long, w= hen to run them, what test results are generated, etc. Why would configurin= g this parameter be any different. Maybe I am missing something.

 

 

 

From: Carey, T= imothy (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<= /p>

 

So the burden is on th= e Measurement controller to know the functions and inputs specifications fo= r each possible MA vendor; not something I would want to have to do as a Me= asurement controller vendor.

 

From: Sharam H= akimi [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<= /p>

 

 

I do not see why vendo= r A or B or C matters. They would all be under the control of one Measureme= nt Controller which would specify what inputs to use for all MAs in a group= .

 

 

As Trevor also mention= ed this timer can be used for both testing and reporting and I would strong= ly suggest to have microsecond granularity. For reporting one could choose = seconds in terms of microseconds.

 

Thanks,

Sharam

 

 

 

From: Carey, T= imothy (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<= /p>

 

Trevor,

 

If we don’t defi= ne the inputs for each function (leaving the inputs opaque) you will have i= nterop problems.

MA vendor 1 uses these= 2 inputs named “A” and “B”; MA vendor 2 uses 3 inp= uts named “A”, “X” and “Y” for the same= function.

 

I think we need to avo= id that if we realistically want the Randomness function to be used efficie= ntly.

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@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<= br> Subject: RE: Timer: Poisson distribution question<= /p>

 

The ran= dom timing can be used for both specifying when a test runs, or when a repo= rt is sent (or any other task such as contacting the Controller). It doesn&= #8217;t have to be used, but it can be.

&n= bsp;

I don&#= 8217;t really want different input variable for different functions. I don&= #8217;t see we need to. Also if we do, then we would have to have schema fo= r each function to specify which inputs are expected (like the measurement task registry). I’d like to avoid that.

&n= bsp;

Trevor.=

&n= bsp;

Trevor Bu= rbridge
Network Infrastructure & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(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 immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: Carey, T= imothy (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<= /p>

 

Sharam,

 

We are talking about o= ffsets for when to report; in the world we live in milliseconds is sufficie= nt – IMHO.

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the min/max sh= ould have microseconds granularity. Milliseconds would not be accurate enou= gh.

 

Personally, I would no= t trust my periodic tests in a large scale deployment to a random number ge= nerator and would want to know exactly how and when tests would be run.

 

 

Thanks,

Sharam

 

From: Carey, T= imothy (Timothy) [mailt= o: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<= /p>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_9966516C6EB5FC4381E05BF80AA55F771953515BUS70UWXCHMBA05z_-- From nobody Wed Apr 23 05:57: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 08FEF1A037A for ; Wed, 23 Apr 2014 05:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.272] 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 LXC_QJhm9Qmn for ; Wed, 23 Apr 2014 05:57:46 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC831A0260 for ; Wed, 23 Apr 2014 05:57:45 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A2A27A05E7; Wed, 23 Apr 2014 08:57:39 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 5A71CA05DB; Wed, 23 Apr 2014 08:57:39 -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; Wed, 23 Apr 2014 08:57:39 -0400 From: Sharam Hakimi To: "Carey, Timothy (Timothy)" , "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAMH2AAABWvrA= Date: Wed, 23 Apr 2014 12:57:37 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.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: multipart/alternative; boundary="_000_89294A6F3C6C91459E52E4128C4B02B7041C88SPQCMBX02exfocom_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20650.007 X-TM-AS-Result: No--24.296-5.0-31-10 X-imss-scan-details: No--24.296-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20650.007 X-TMASE-Result: 10--24.296100-5.000000 X-TMASE-MatchedRID: yebcs53SkkDVmBqdOLvJWOYAh37ZsBDCxPrUkqCg2imRl9YdphffeqAs suKVAEQ3Cr+P5d3MBIuMH+sT1Wp69KLCTO1UKypviUPZPmKZOQkWTveLitVUgTCmUYns3FLTEOI nF2EbxTGFSrRXMqcCo49Tn2sH/B9ywp5rCVeeTws4lNZ1y5cL/uHQ21j8RtplUyeewPMwj/SFx9 58Z6wa7XYae8Rp46t3LF0rTpfKWokbsnT0zBaEfdyLdf13I2BTo3e/haHuROeFiT913RgMLvWw4 jomxW69JGrXkceKszx91MBYnxZVu1lQJeEqNNYAF6z9HGHKwNuZ2scyRQcer8xxkv+2grBShy3q 5/XOIACkSBTXCEpAxZ+uSzXkBAN5TFnG8jQTQ3BCnGIuUMP0VR852jgffnmIYe1mzp7dkwea8U8 +5uEy2RDAMGki/LsIXUIrNdirVrrcx97ZZVZcMghWgIsZuXlPJQSryPTViF+Qp4MBBY/CMZrXEN q9aJxMBkXCM2PA5G+z7F97+gPYWYZ5NsZZ1HPWw69AIwXJn0YJTg3SSYouWj4WF4CyQgwIZy2my Ou1WXwrhAqjQ5f9afFU/97fYTSWXtne4opDTiDYwybFNa+tm0KzuF0egUUDG0N1z/ycuLIRF1oM l0MP8X+SMDssjO+EkbS7g4PdQ+b3fZ+bzIHVnuLdprnA5EQRiweLE0aTpwkwyfWtyopBqPMTuIr C6WWhOZW4xcAmoVzchYgbaBnRwhLekAZjy1WtCPKPqEbU3ZO0NJ9wxH7tk5UyTIJurbdhXbliHD qujj0ld3EqymRaj1/cTEJWRiDAEXIhhl7oVxKeAiCmPx4NwGmRqNBHmBveuNQM32UkivK1gtp05 /+9u3yKEObJsxUWb8rWPsmXCtrZe7MRq8pNP9v2b++YAQJJ+e1xsAGDyB4= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/bqqFbdYnCaLA4kAFxqpgO6jOn7s 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, 23 Apr 2014 12:57:53 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B7041C88SPQCMBX02exfocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marc's suggestion works for me. That allows better interoperability in my o= pinion. 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, UpperLi= mit, Spread) - works so far. Marc suggested a TimeStep parameter so we don't lockin on a specific micros= econd, 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 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. 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 cont= roller doesn't have a standard way of configuring a timer. For example - If I specify for a Uniform distribution function called "Unif= orm" you have a variable called "UpperLimit", the MA will implement the sp= ecification; the controller will implement the specification and things wor= k. If I do not specify anything for the Uniform distribution function - MA ven= dor 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 in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion 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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_89294A6F3C6C91459E52E4128C4B02B7041C88SPQCMBX02exfocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Marc’s suggestio= n works for me. That allows better interoperability in my opinion.

 

I do agree that we nee= d a common “structure” and “names”.

 

Thanks,

Sharam

 

From: Carey, T= imothy (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<= /p>

 

Trevor,

 

No – I am using = the variable of your Information Model (LowerLimit, UpperLimit, Spread) = 211; works so far.

Marc suggested a TimeS= tep parameter so we don’t lockin on a specific microsecond, milliseco= nd, second thing – I am open to that.

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@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<= br> Subject: RE: Timer: Poisson distribution question<= /p>

 

Agree w= e need to have well defined function names. I thought you were also suggest= ing different functions needed different input parameters.

&n= bsp;

Trevor.=

&n= bsp;

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 infor= mation 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

&n= bsp;

From: Carey, T= imothy (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<= /p>

 

Its not that the Measu= rement controller has to configure the timer for the MA.

 

If we do not specify t= he functions and variable names, the measurement controller doesn’t h= ave 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 imp= lement the specification; the controller will implement the specification and things work.

 

If I do not specify an= ything for the Uniform distribution function – MA vendor 1 can call i= t “UniformDF” and “UL – which is typed real” = and maybe an “Enable” parameter for good measure; MA vendor 2 c= an call it “U” and have an attribute “X that is an integer”.<= o:p>

 

Now put that variation= on steroids based on the number of MA vendors – That is why we speci= fy things, right?

 

BR,<= /p>

Tim<= /p>

 

From: Sharam H= akimi [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<= /p>

 

The measurement contro= ller has to communicate what tests have to be run on an MA, for how long, w= hen to run them, what test results are generated, etc. Why would configurin= g this parameter be any different. Maybe I am missing something.

 

 

 

From: Carey, T= imothy (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<= /p>

 

So the burden is on th= e Measurement controller to know the functions and inputs specifications fo= r each possible MA vendor; not something I would want to have to do as a Me= asurement controller vendor.

 

From: Sharam H= akimi [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<= /p>

 

 

I do not see why vendo= r A or B or C matters. They would all be under the control of one Measureme= nt Controller which would specify what inputs to use for all MAs in a group= .

 

 

As Trevor also mention= ed this timer can be used for both testing and reporting and I would strong= ly suggest to have microsecond granularity. For reporting one could choose = seconds in terms of microseconds.

 

Thanks,

Sharam

 

 

 

From: Carey, T= imothy (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<= /p>

 

Trevor,

 

If we don’t defi= ne the inputs for each function (leaving the inputs opaque) you will have i= nterop problems.

MA vendor 1 uses these= 2 inputs named “A” and “B”; MA vendor 2 uses 3 inp= uts named “A”, “X” and “Y” for the same= function.

 

I think we need to avo= id that if we realistically want the Randomness function to be used efficie= ntly.

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@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<= br> Subject: RE: Timer: Poisson distribution question<= /p>

 

The ran= dom timing can be used for both specifying when a test runs, or when a repo= rt is sent (or any other task such as contacting the Controller). It doesn&= #8217;t have to be used, but it can be.

&n= bsp;

I don&#= 8217;t really want different input variable for different functions. I don&= #8217;t see we need to. Also if we do, then we would have to have schema fo= r each function to specify which inputs are expected (like the measurement task registry). I’d like to avoid that.

&n= bsp;

Trevor.=

&n= bsp;

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 infor= mation 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

&n= bsp;

From: Carey, T= imothy (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<= /p>

 

Sharam,

 

We are talking about o= ffsets for when to report; in the world we live in milliseconds is sufficie= nt – IMHO.

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the min/max sh= ould have microseconds granularity. Milliseconds would not be accurate enou= gh.

 

Personally, I would no= t trust my periodic tests in a large scale deployment to a random number ge= nerator and would want to know exactly how and when tests would be run.

 

 

Thanks,

Sharam

 

From: Carey, T= imothy (Timothy) [mailt= o: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<= /p>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_89294A6F3C6C91459E52E4128C4B02B7041C88SPQCMBX02exfocom_-- From nobody Wed Apr 23 05:59: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 13CA71A037A for ; Wed, 23 Apr 2014 05:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 9YrM4tsqBYFQ for ; Wed, 23 Apr 2014 05:59:11 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id E64A21A0377 for ; Wed, 23 Apr 2014 05:59:09 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 23 Apr 2014 13:59:12 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.56]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Wed, 23 Apr 2014 13:58:45 +0100 From: To: , , , Date: Wed, 23 Apr 2014 13:58:44 +0100 Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAJ3BgAABCGwA= Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <2845723087023D4CB5114223779FA9C8017944AE6F@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017944AE6F@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_ED51D9282D1D3942B9438CA8F3372EB72D46057200EMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/aE3FkOEZrugQPIi6iqcUBjZP2-Q 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, 23 Apr 2014 12:59:19 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72D46057200EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good to be dragged back to requirements. Certainly uniform would be the single function of choice for any load balan= cing requirement - you want uniform peak load either on the test points or = on the reporting system. If you want to test at a single point in time, uni= form distribution gives you the minimum spread of time without exceeding th= e peak allowable load. I could _maybe_ make an argument for a normal distribution. That you want t= he bulk of tests at a certain time, but want a reduced volume of outlier te= sts to say something about how the results look either side of that time. I wouldn't be unhappy about either: - Assuming function is uniform - Allowing multiple functions but only currently defining uniform. O= f course uniform doesn't need a 'spread' parameter, just upper/lower cuts s= o would probably want an eye to the future 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. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: 23 April 2014 13:47 To: Burbridge,T,Trevor,TUB8 R; timothy.carey@alcatel-lucent.com; sharam.hak= imi@exfo.com; lmap@ietf.org Subject: RE: Timer: Poisson distribution question It seems as though a good part of this exchange has been skipped-over, Tim and I clarified a lot of this last night... One function will do, discrete Uniform seems to meet the need. Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.= com Sent: Wednesday, April 23, 2014 8:41 AM To: timothy.carey@alcatel-lucent.com; sharam.hakimi@exfo.com; lmap@ietf.org Subject: Re: [lmap] 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 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. 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 cont= roller doesn't have a standard way of configuring a timer. For example - If I specify for a Uniform distribution function called "Unif= orm" you have a variable called "UpperLimit", the MA will implement the sp= ecification; the controller will implement the specification and things wor= k. If I do not specify anything for the Uniform distribution function - MA ven= dor 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 in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion to be used efficiently. BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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."po= isson_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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72D46057200EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good to be dragged back to requirements.

 

Certainly uniform w= ould be the single function of choice for any load balancing requirement &#= 8211; you want uniform peak load either on the test points or on the report= ing system. If you want to test at a single point in time, uniform distribu= tion gives you the minimum spread of time without exceeding the peak allowa= ble load.

 

I could _maybe_ make an argument for a normal distributio= n. That you want the bulk of tests at a certain time, but want a reduced vo= lume of outlier tests to say something about how the results look either si= de of that time.

 

I wouldn’t be unhappy about either:

- &= nbsp;      Assuming function is uniform

-   = ;     Allowing multiple functions but only currently defining uniform= . Of course uniform doesn’t need a ‘spread’ parameter, ju= st upper/lower cuts so would probably want an eye to the future<= /span>

 

Trevor.

=  

<= o:p> 

 

Trevor Bur= bridge
Network Infrastructure & Innovation | BT Innovate & Desig= n
Tel: 01473 645115
Fax: 01473 640929

This email contains BT information, which may b= e privileged or confidential. It's meant only for the individual(s) or enti= ty named above. If you're not the intended recipient, note that disclosing,= copying, distributing or using this information is prohibited. If you've r= eceived this email in error, please let me know immediately on the email ad= dress above. Thank you.
We monitor our email system, and may record your= emails.
British Teleco= mmunications plc
Registered office: 81 Newgate Street London EC1A 7AJRegistered in England no: 1800000

 

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'>From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] <= br>Sent: 23 April 2014 13:47
To: Burbridge,T,Trevor,TUB8 R= ; timothy.carey@alcatel-lucent.com; sharam.hakimi@exfo.com; lmap@ietf.orgSubject: RE: Timer: Poisson distribution question

 

Tim and I clarified a lot of this last= night...

 

One function will do, discrete Uniform seems to meet th= e need.

 

Al

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.= burbridge@bt.com
Sent: Wednesday, April 23, 2014 8:41 AM
To= : timothy.carey@alcatel-lucent.com; sharam.hakimi@exfo.com; lmap@ietf.o= rg
Subject: Re: [lmap] Timer: Poisson distribution question<= /o:p>

&n= bsp;

Agr= ee we need to have well defined function names. I thought you were also sug= gesting different functions needed different input parameters.

 

Trevor.

&= nbsp;

Trevor BurbridgeNetwork Infrastructure & Innovation | BT Innovate & Design
Tel:= 01473 645115
Fax: 01473 640929

This email contains BT information, which may be privile= ged 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 t= his email in error, please let me know immediately on the email address abo= ve. Thank you.
We monitor our email system, and may record your emails.<= /span>
British Telecommunicati= ons plc
Registered office: 81 Newgate Street London EC1A 7AJ
Register= ed in England no: 1800000 <= /span>

&nb= sp;

From:= Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sen= t: 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 ha= s to configure the timer for the MA.

 

If we do n= ot specify the functions and variable names, the measurement controller doe= sn’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 “Upper= Limit”, 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 i= s typed real” and maybe an “Enable” parameter for good me= asure; MA vendor 2 can call it “U” and have an attribute “= ;X that is an integer”.

 

Now put that varia= tion on steroids based on the number of MA vendors – That is why we s= pecify things, right?

 

BR,

=

Tim

 

F= rom: 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 distributi= on question

 

The measurement controller has to communicate wh= at 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 di= fferent. Maybe I am missing something.

 

&nbs= p;

 

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'>From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] <= br>Sent: Wednesday, April 23, 2014 8:16 AM
To: Sharam Haki= mi; 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 Mea= surement controller vendor.

 

From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] <= br>Sent: Wednesday, April 23, 2014 7:14 AM
To: Carey, Timo= thy (Timothy); trevor.burbridge@= bt.com; lmap@ietf.org
Subjec= t: RE: Timer: Poisson distribution question

=

 

<= p class=3DMsoNormal> <= /o:p>

I do not see why vendor A or B or C matters. They would all be under t= he 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 reportin= g and I would strongly suggest to have microsecond granularity. For reporti= ng one could choose seconds in terms of microseconds.

=

 =

Thanks,

Sharam

 

 =

=  

From= : Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Se= nt: Wednesday, April 23, 2014 8:04 AM
To: trevor.burbridge@bt.com; Sharam Hakimi; lmap@ietf.org
Subject: RE: Timer: P= oisson distribution question

 

Trevor,

 

If we don’t define the inputs for each function (leaving the inpu= ts opaque) you will have interop problems.

MA vendor 1 uses these= 2 inputs named “A” and “B”; MA vendor 2 uses 3 inp= uts 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]
Se= nt: Wednesday, April 23, 2014 2:55 AM
To: Carey, Timothy (Tim= othy); sharam.hakimi@exfo.com= ; lmap@ietf.org
Subject: RE:= Timer: Poisson distribution question

 

The random timing can be used for b= oth specifying when a test runs, or when a report is sent (or any other tas= k 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 differe= nt functions. I don’t see we need to. Also if we do, then we would ha= ve to have schema for each function to specify which inputs are expected (l= ike the measurement task registry). I’d like to avoid that.

 <= /o:p>

Trevor.<= o:p>

 

Trevor Burbridge=
Network Infrastructure & Innovation | BT Innovate & Design
T= el: 01473 645115
Fax: 01473 640929

This email contains BT information, which may be priv= ileged or confidential. It's meant only for the individual(s) or entity nam= ed above. If you're not the intended recipient, note that disclosing, copyi= ng, distributing or using this information is prohibited. If you've receive= d 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 email= s.
British Telecommunic= ations plc
Registered office: 81 Newgate Street London EC1A 7AJ
Regis= tered in England no: 1800000

=  

Fr= om: 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

<= /div>

 

Sharam,

 

We= are talking about offsets for when to report; in the world we live in mill= iseconds is sufficient – IMHO.

 

=

From: Sharam Hak= imi [mailto:sharam.hakimi@exfo.co= m]
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. Millisec= onds 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,

Shar= am

 

 

Trevor,<= /span>

<= o:p> 

The data model is extensible by vendors so we can add funct= ions and input variables as we need.

 

=

However we = have to decide on which small subset we actually want to standardize.<= /o:p>

 

You suggested the Uniform and Normal which is fine bu= t for the model we need to go farther by defining the specific function alo= ng with which inputs are used by the function to derive what random number.= Otherwise we will have 2 implementers of the same standard algorithm imple= ment different variations. – Not good.

 

So= I suggest we keep this simple.

<= span lang=3DEN-US style=3D'color:#1F497D'> 

Uniform Discrete= – input variables - maximum [positive integer]

=

Gaussian &#= 8211;input variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be milliseconds – Sprea= d would be an integer.

 

 <= /p>

This sou= nd OK?

 

BR

Tim

<= p class=3DMsoNormal> <= /o:p>

 

From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
Sent: Tuesday, April 22,= 2014 8:23 AM
To: Carey, Timothy (Timothy); lmap@ietf.org; t= revor.burbridge@bt.com
Subject: RE: Timer: Poisson distributi= on question

 

Tim,

<= span lang=3DEN-US style=3D'color:#1F497D'>I think the Periodic Timer distri= bution needs to have closer configuration control by the user and I think y= our 2nd  choice attempts to provide it but having a discret= e interval definition is a better way to go.

 

 

Sharam

 

=

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.comSent: Tuesday, April 22, 2014 4:35 AM
To: timothy.carey@alcatel-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 t= he user to decide if such functions were suitable replacements for the disc= rete Poisson function. Yes it would be a different function even if there w= as perfect fit (which they are not) as one is continuous and one is discret= e:

= http://cmscience.blogspot.co.uk/2008/04/mt-6-poisson-and-= gamma-distribution.html

http://= arxiv.org/abs/1303.5990

 

<= span style=3D'color:#1F497D'>As I tried to say the current Information Mode= l can take either discrete or continuous functions – only that there = is currently no explicit support for specifying the interval used for a dis= crete 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.

 

<= p class=3DMsoNormal>Trevor.=

 

 

From:<= /b> lmap [mailto:lmap-bounces= @ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent:= 19 April 2014 20:24
To: lmap@ie= tf.org
Subject: [lmap] Timer: Poisson distribution question

 

<= p class=3DMsoNormal>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 a= ddition questions regarding Trevors response to the Poisson distribution fo= r the Randomness of the Periodic Timer.

 

= Trevor responded:

 

“Yes this does n= eed 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 (cou= ld use mean deviation or something else but I see no advantage as long as w= e 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 uni= form distribution but useful to constrain other functions.

<= span style=3D'color:#1F497D'> 

I will make all this clear in the next release.

 

As for poisson I think there are 3 options:

-      &nb= sp; Use a cont= inuous form instead

-        = Have the discrete interval implicit= in the function choice e.g.“poisson_1_sec”

-    &nbs= p;   Add an interval to the information model.

 <= /o:p>

I was re= ally thinking about the first, but I don’t see the problem with the s= econd. 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 peopl= e looked at Trevors response there were additional questions:

=  

I don't understand what Trevor means about the P= oisson 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. &n= bsp;But what matters is that the definition is clear, not the particular di= stribution (I don't have an opinion on that).

 

&= nbsp;

Could some please clarify this for us – Are we planning some= thing other than Poisson method; better yet is there a definition for the t= ypes of distribution:

Poisson, Normal and Uniform.

&n= bsp;

Thanks,

Tim

 

= --_000_ED51D9282D1D3942B9438CA8F3372EB72D46057200EMV64UKRDdoma_-- From nobody Wed Apr 23 06:04: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 0E67C1A0388 for ; Wed, 23 Apr 2014 06:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 uyodo6Sl3yxW for ; Wed, 23 Apr 2014 06:03:52 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id D92C81A0377 for ; Wed, 23 Apr 2014 06:03:51 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 23 Apr 2014 14:03:54 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.56]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Wed, 23 Apr 2014 14:03:41 +0100 From: To: , , Date: Wed, 23 Apr 2014 14:03:40 +0100 Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAMH2AAABWvrAAAELs4A== Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7041C88@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: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72D4605720AEMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/MGe6ikGYxc5Pybc_FMA0bQBVG80 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, 23 Apr 2014 13:03:58 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72D4605720AEMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 windo= w, why not allow that to happen with the maximum resolution the MA is capab= le 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 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. 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 o= pinion. 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, UpperLi= mit, Spread) - works so far. Marc suggested a TimeStep parameter so we don't lockin on a specific micros= econd, millisecond, second thing - I am open to that. BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.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 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. 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 cont= roller doesn't have a standard way of configuring a timer. For example - If I specify for a Uniform distribution function called "Unif= orm" you have a variable called "UpperLimit", the MA will implement the sp= ecification; the controller will implement the specification and things wor= k. If I do not specify anything for the Uniform distribution function - MA ven= dor 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 in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion to be used efficiently. BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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."po= isson_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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72D4605720AEMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not sure I get the point of allowing coarser granul= arity that the MA is capable of. If I want the MA to test/report sometime w= ithin a minute window, why not allow that to happen with the maximum resolu= tion the MA is capable of?

 

Trevor.

 

Trevor Burbridge
Network Infrastructure & Innov= ation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929<= br>
This email conta= ins BT information, which may be privileged or confidential. It's meant onl= y for the individual(s) or entity named above. If you're not the intended r= ecipient, note that disclosing, copying, distributing or using this informa= tion is prohibited. If you've received this email in error, please let me k= now immediately on the email address above. Thank you.
We monitor our em= ail system, and may record your emails.
British Telecommunications plc
Registered office: 81 Ne= wgate Street London EC1A 7AJ
Registered in England no: 1800000

 

From: lmap [mailto:lmap-= bounces@ietf.org] On Behalf Of Sharam Hakimi
Sent: 23 Apri= l 2014 13:58
To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB= 8 R; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distributio= n question

 = ;

= Marc’s suggestion works for me. That allows better interoperability i= n my opinion.

 

I do agree that we need a common &= #8220;structure” and “names”.

 =

= Thanks,

Sharam

 

From: Carey, Timothy (Timot= hy) [mailto:timothy.car= ey@alcatel-lucent.com]
Sent: Wednesday, April 23, 2014 8:47 = AM
To: trevor.burbridg= e@bt.com; Sharam Hakimi; lmap@ietf.org=
Subject: RE: Timer: Poisson distribution question=

 <= /o:p>

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 locki= n on a specific microsecond, millisecond, second thing – I am open to= that.

 

BR,

Tim

=

 =

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.c= om]
Sent: Wednesday, April 23, 2014 7:41 AM
To: Ca= rey, Timothy (Timothy); sharam.ha= kimi@exfo.com; lmap@ietf.org
Subject: RE: Timer: Poisson distribution question

 

Agree we need to h= ave well defined function names. I thought you were also suggesting differe= nt functions needed different input parameters.

 

Trevor.<= /p>

 

Trevor Burbridge
Network Infras= tructure & Innovation | BT Innovate & Design
Tel: 01473 645115Fax: 01473 640929

= This email contains BT information, which may be privileged or confiden= tial. It's meant only for the individual(s) or entity named above. If you'r= e not the intended recipient, note that disclosing, copying, distributing o= r using this information is prohibited. If you've received this email in er= ror, please let me know immediately on the email address above. Thank you.<= br>We monitor our email system, and may record your emails.
British Telecommunications plc
Regi= stered office: 81 Newgate Street London EC1A 7AJ
Registered in England n= o: 1800000

 

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: 23 Apri= l 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 hav= e a standard way of configuring a timer.

 =

For exa= mple – 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 speci= fy anything for the Uniform distribution function – MA vendor 1 can c= all it “UniformDF” and “UL – which is typed real= 221; and maybe an “Enable” parameter for good measure; MA vendo= r 2 can call it “U” and have an attribute “X that is an i= nteger”.

 

<= span lang=3DEN-US style=3D'color:#1F497D'>Now put that variation on steroid= s based on the number of MA vendors – That is why we specify things, = right?

 

BR,

Tim

=

 =

From: Sharam Hakimi [mailto:shar= am.hakimi@exfo.com]
Sent: Wednesday, April 23, 2014 7:24 AM<= br>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 g= enerated, etc. Why would configuring this parameter be any different. Maybe= I am missing something.

 

 

&= nbsp;

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 c= ontroller to know the functions and inputs specifications for each possible= MA vendor; not something I would want to have to do as a Measurement contr= oller 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: Tim= er: 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 M= As in a group.

 

<= span lang=3DEN-US style=3D'color:#1F497D'> 

As Trevor also m= entioned this timer can be used for both testing and reporting and I would = strongly suggest to have microsecond granularity. For reporting one could c= hoose seconds in terms of microseconds.

 <= /p>

Thanks,<= o:p>

Sharam

 

 

 

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: Wednes= day, April 23, 2014 8:04 AM
To: trevor.burbridge@bt.com; Sharam Hakimi; lmap@ietf.org
Subject: RE: Timer: Poisson distrib= ution question

 

Trevor,

 

If we don&= #8217;t define the inputs for each function (leaving the inputs opaque) you= will have interop problems.

MA vendor 1 uses these 2 inputs name= d “A” and “B”; MA vendor 2 uses 3 inputs named R= 20;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.

<= p class=3DMsoNormal> <= /o:p>

BR,

Tim

 

=

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Wednes= day, April 23, 2014 2:55 AM
To: Carey, Timothy (Timothy); sharam.hakimi@exfo.com; lmap@ietf.org
Subject: RE: Timer: Poisso= n 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 cont= acting 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 sch= ema for each function to specify which inputs are expected (like the measur= ement task registry). I’d like to avoid that.

 

Trevor.

 =

Trevor Burbridge
Network In= frastructure & Innovation | BT Innovate & Design
Tel: 01473 6451= 15
Fax: 01473 640929

This email contains BT information, which may be privileged or conf= idential. It's meant only for the individual(s) or entity named above. If y= ou're not the intended recipient, note that disclosing, copying, distributi= ng or using this information is prohibited. If you've received this email i= n error, please let me know immediately on the email address above. Thank y= ou.
We monitor our email system, and may record your emails.
British Telecommunications plc
= Registered office: 81 Newgate Street London EC1A 7AJ
Registered in Engla= nd no: 1800000

<= /div>

 

From:= Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: 22 A= pril 2014 22:07
To: Sharam Hakimi; lmap@ietf.org; Burbridge,T,Trevor,TUB8 R
Subject: RE: Time= r: Poisson distribution question

 

Sharam,

<= span lang=3DEN-US style=3D'color:#1F497D'> 

We are talking a= bout offsets for when to report; in the world we live in milliseconds is su= fficient – IMHO.

 

=

From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
<= b>Sent: Tuesday, April 22, 2014 3:59 PM
To: Carey, Timothy (T= imothy); lmap@ietf.org; trevor.burbridge@bt.com
Subject:= RE: Timer: Poisson distribution question

=

 

Tim,

I t= hink the min/max should have microseconds granularity. Milliseconds would n= ot be accurate enough.

 

Personally, I would not t= rust my periodic tests in a large scale deployment to a random number gener= ator and would want to know exactly how and when tests would be run. <= /o:p>

 

 

Thanks,

Sharam<= /span>

<= o:p> 

From:= Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sen= t: Tuesday, April 22, 2014 3:16 PM
To: Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE: Timer: Pois= son 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.

&nbs= p;

You suggested the Uniform and Normal which is fine but for the mode= l 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 k= eep this simple.

 

Uniform Discrete – input = variables - maximum [positive integer]

Gaussian –input vari= ables – mean of min/max, spread =3D standard deviation

 

The min/max would be milliseconds – Spread would be an i= nteger.

 

 

This sound OK?

 

BR

Tim

 

=

 =

From: Sharam Hakimi [mailto:shar= am.hakimi@exfo.com]
Sent: Tuesday, April 22, 2014 8:23 AMTo: Carey, Timothy (Timothy); lmap= @ietf.org; trevor.burbridge@= bt.com
Subject: RE: Timer: Poisson distribution question=

&= nbsp;

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 defin= ition is a better way to go.

 

 <= /span>

S= haram

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.com
Sent: Tue= sday, April 22, 2014 4:35 AM
To: timothy.carey@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Pois= son distribution question

 

 

On continuous counterparts of Poisson IR= 17;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 func= tion. Yes it would be a different function even if there was perfect fit (w= hich they are not) as one is continuous and one is discrete:

http://cmscience.blogspot.co.uk/2008/04/mt-6-poisson-and-gamma-distributio= n.html

http://arxiv.org/abs/130= 3.5990

 

As I tried to say the current Information Model can take either= discrete or continuous functions – only that there is currently no e= xplicit support for specifying the interval used for a discrete function. I= was questioning the need to add this.

 

Personally I’d think that Nor= mal and Uniform distributions would cover most needs, but the framework sho= uld be flexible in this regard.

<= span style=3D'color:#1F497D'> 

Trevor.

 

 

From: lmap [<= a href=3D"mailto:lmap-bounces@ietf.org">mailto:lmap-bounces@ietf.org] <= b>On Behalf Of Carey, Timothy (Timothy)
Sent: 19 April 2014 2= 0:24
To: lmap@ietf.org
Subject: [lmap] Timer: Poisson distribution question=

 

Team,

 

The BBF is looking at standardizing the model for Timers as sugges= ted by the IETF LMAP information model.

 

= During the review of the timers we had addition question= s regarding Trevors response to the Poisson distribution for the Randomness= of the Periodic Timer.

 

Trevor responded:

 

“Yes this does need to be clar= ified. 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 de= viation or something else but I see no advantage as long as we all know wha= t it refers to) and need to change to a float. The upper and lower cuts wou= ld be in seconds +/- the mean (also needs to change to float) and are simpl= y used to trim the function – obviously needed on a uniform distribut= ion but useful to constrain other functions.

 <= /o:p>

I will m= ake all this clear in the next release.

 =

As for poisso= n I think there are 3 options:

-        Use a continuous form in= stead

=

-&nb= sp;       Have the discrete interval implicit in the functi= on choice e.g.“poisson_1_sec”

-       = ; Add an inter= val to the information model.

=  

I was really thinking a= bout 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 suppo= rting discrete functions (rather than continuous versions of them).<= span lang=3DEN-US style=3D'color:black'>

 “

 

But as people looked at Tre= vors response there were additional questions:

 

I don't understand what Trevor means about the Poisson distribu= tion.  As far as I know, it is a discrete distribution, so a "con= tinuous form" would be a different distribution and not Poisson.  = ;And I believe that we do need a continuous distribution.  But what ma= tters is that the definition is clear, not the particular distribution (I d= on't have an opinion on that).

 

 

Could = some please clarify this for us – Are we planning something other tha= n Poisson method; better yet is there a definition for the types of distrib= ution:

Poisson, Normal and Uniform.

 

Thanks= ,

Tim

 

<= /div>= --_000_ED51D9282D1D3942B9438CA8F3372EB72D4605720AEMV64UKRDdoma_-- From nobody Wed Apr 23 06:14: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 53D551A037A for ; Wed, 23 Apr 2014 06:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=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 P_QhguK8pKyC for ; Wed, 23 Apr 2014 06:14:34 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 86CFF1A0362 for ; Wed, 23 Apr 2014 06:14:33 -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, 23 Apr 2014 14:11:31 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.56]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 23 Apr 2014 14:13:35 +0100 From: To: , , , Date: Wed, 23 Apr 2014 14:13:34 +0100 Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9e9Vd/tpcIqE1NQPyHuwynay0q0gAAGpuQ Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC 4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> In-Reply-To: <20140423130603.M45776@mail.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/Ks4LRaTNniLhvJtLkcf_jbWx544 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, 23 Apr 2014 13:14:37 -0000 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 win= dow, >> why not allow that to happen with the maximum resolution the MA is capab= le >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 confident= ial. >> It's meant only for the individual(s) or entity named above. If you're n= ot the >> intended recipient, note that disclosing, copying, distributing or using= this >> information is prohibited. If you've received this email in error, pleas= e let >> me know immediately on the email address above. Thank you. We monitor ou= r >> email system, and may record your emails. British Telecommunications plc >> Registered office: 81 Newgate Street London EC1A 7AJ Registered in Engla= nd >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 m= y >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 al= so >> 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 confident= ial. >> It's meant only for the individual(s) or entity named above. If you're n= ot the >> intended recipient, note that disclosing, copying, distributing or using= this >> information is prohibited. If you've received this email in error, pleas= e let >> me know immediately on the email address above. Thank you. We monitor ou= r >> email system, and may record your emails. British Telecommunications plc >> Registered office: 81 Newgate Street London EC1A 7AJ Registered in Engla= nd >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 t= he 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 implemen= t the >> specification; the controller will implement the specification and thing= s 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 "E= nable" >> parameter for good measure; MA vendor 2 can call it "U" and have an attr= ibute >> "X that is an integer". >> >> Now put that variation on steroids based on the number of MA vendors - T= hat 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 rep= orting >> and I would strongly suggest to have microsecond granularity. For report= ing >> 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 opaq= ue) >> 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 funct= ion. >> >> I think we need to avoid that if we realistically want the Randomness fu= nction >> 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 w= hen 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 eac= h >> 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 confident= ial. >> It's meant only for the individual(s) or entity named above. If you're n= ot the >> intended recipient, note that disclosing, copying, distributing or using= this >> information is prohibited. If you've received this email in error, pleas= e let >> me know immediately on the email address above. Thank you. We monitor ou= r >> email system, and may record your emails. British Telecommunications plc >> Registered office: 81 Newgate Street London EC1A 7AJ Registered in Engla= nd >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,Trev= or, >> 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 w= ould >> not be accurate enough. >> >> Personally, I would not trust my periodic tests in a large scale deploym= ent 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 inpu= t >> 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 hav= e 2 >> implementers of the same standard algorithm implement different variatio= ns. - >> 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 deviati= on >> >> 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 configurati= on >> 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.comlucent.com>; >> lmap@ietf.org Subject: Re: [lmap] Timer: Poisson >> distribution question >> >> On continuous counterparts of Poisson I'm far from any expert and it wou= ld >> certainly be up to the user to decide if such functions were suitable >> replacements for the discrete Poisson function. Yes it would be a differ= ent >> 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 m= ost >> 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 Trev= ors >> 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 standa= rd >> deviation (could use mean deviation or something else but I see no advan= tage >> 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 cha= nge >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 v= alue >> to supporting discrete functions (rather than continuous versions of the= m). " >> >> 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 b= e a >> different distribution and not Poisson. And I believe that we do need a >> continuous distribution. But what matters is that the definition is cle= ar, >> 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) From nobody Wed Apr 23 06:15: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 622E31A039B for ; Wed, 23 Apr 2014 06:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.272] 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 0469SS-72q5U for ; Wed, 23 Apr 2014 06:15:13 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 23AA91A0362 for ; Wed, 23 Apr 2014 06:15:13 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 27744A05E7; Wed, 23 Apr 2014 09:15:07 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id D1FFBA05DB; Wed, 23 Apr 2014 09:15:06 -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; Wed, 23 Apr 2014 09:15:06 -0400 From: Sharam Hakimi To: "trevor.burbridge@bt.com" , "acmorton@att.com" , "timothy.carey@alcatel-lucent.com" , "lmap@ietf.org" Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAJ3BgAABCGwAAAKAgEA== Date: Wed, 23 Apr 2014 13:15:06 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B7041CD0@SPQCMBX02.exfo.com> References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <2845723087023D4CB5114223779FA9C8017944AE6F@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: multipart/alternative; boundary="_000_89294A6F3C6C91459E52E4128C4B02B7041CD0SPQCMBX02exfocom_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20650.007 X-TM-AS-Result: No--27.463-5.0-31-10 X-imss-scan-details: No--27.463-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20650.007 X-TMASE-Result: 10--27.462900-5.000000 X-TMASE-MatchedRID: yebcs53SkkDWKlsMlVwfQ46MisxJraxHXcpmQXLhhkQUlWIKEoGBmSv7 Z3JMHGNayHLYYwwd4zoXIJWO/t2Wjof+Ws1AFsajVU3yVpaj3QxqWHNA0obopCG8WMGwsRk0RzW p7lR8ws7/x3BOmmMKRkNofIKVAVc4E3wKomBT+waVSBCoZUyqbNCk4tpiYCdI6i5zlFx/UHTK6Q TLokP+5ugz63Yw6bKQqAwhjWRIQdu71D3eW4MsP0dAWPMBu8kQIWrhso05H/XjB19nvhZ7jQx5/ vL+v5U02bc+OIuXeVR/kgNkBhiKEA+q5PB4uzgXma6DzXaohvM31Ce+4Yv8aqXgQ/53L7AEEv86 LHWvloOSvQWuoJ9vsgbqZM3zDkF0FM5zGSLIovzC0TXpqtexIm31RVaGptEhPhYXgLJCDAirwzW 10Vkqj595phO/rhDvIRf3deankwwBJNtQGs9jFFu4M/xm4KZe9l9p8mNlkgnFJnEpmt9OE0Jmff tVAWC9PlpJqgNWyLuyZzyfv1p3zKu0PvYHrIDYHlr+M8iv6FIrHkgIan9a0STwAZwVAnOUPyq1z dmnZ/gQwDBpIvy7CF1CKzXYq1a63Mfe2WVWXDIIVoCLGbl5TzY7kSH7jlNH923RAeXUFymZLQbD hQF6WDxJ6tDTXXadOQEHOLwIiEf9+U2HqXLKI1z+axQLnAVBlavqJJda2A+nMzRhUWarpmctpsj rtVl8K4QKo0OX/WnxVP/e32E0ll7Z3uKKQ04g2MMmxTWvrZtCs7hdHoFFA2FvrBhrTi4dqRTciq SS2+PCh8kQuDm+pezX5w0ArHHEfYgoHl6iERKeAiCmPx4NwGmRqNBHmBveuNQM32UkivK1gtp05 /+9u4OUDOaVIRXSKv/9jGJcMHJQaLzkKcwLaNOE/mXkOpBEsq+5d5UmWdE= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/olWoEt8EB2ba_KTn3mWYWyWuwQw 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, 23 Apr 2014 13:15:22 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B7041CD0SPQCMBX02exfocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would suggest "Immediate" an option to allow for reporting after complet= ion of a test. This would not need any parameters as the results would be s= ent after completion of a test. Sometime it is necessary to be able to diag= nose situations based on the results, and combined results sent at later ti= mes do not allow for that. Again, That would be centrally managed through t= he Management controller. Sharam From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Wednesday, April 23, 2014 8:59 AM To: acmorton@att.com; timothy.carey@alcatel-lucent.com; Sharam Hakimi; lmap= @ietf.org Subject: RE: Timer: Poisson distribution question Good to be dragged back to requirements. Certainly uniform would be the single function of choice for any load balan= cing requirement - you want uniform peak load either on the test points or = on the reporting system. If you want to test at a single point in time, uni= form distribution gives you the minimum spread of time without exceeding th= e peak allowable load. I could _maybe_ make an argument for a normal distribution. That you want t= he bulk of tests at a certain time, but want a reduced volume of outlier te= sts to say something about how the results look either side of that time. I wouldn't be unhappy about either: - Assuming function is uniform - Allowing multiple functions but only currently defining uniform.= Of course uniform doesn't need a 'spread' parameter, just upper/lower cuts= so would probably want an eye to the future 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. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: 23 April 2014 13:47 To: Burbridge,T,Trevor,TUB8 R; timothy.carey@alcatel-lucent.com; sharam.hak= imi@exfo.com; lmap@ietf.org Subject: RE: Timer: Poisson distribution question It seems as though a good part of this exchange has been skipped-over, Tim and I clarified a lot of this last night... One function will do, discrete Uniform seems to meet the need. Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.= com Sent: Wednesday, April 23, 2014 8:41 AM To: timothy.carey@alcatel-lucent.com; sharam.hakimi@exfo.com; lmap@ietf.org Subject: Re: [lmap] 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 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. 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 cont= roller doesn't have a standard way of configuring a timer. For example - If I specify for a Uniform distribution function called "Unif= orm" you have a variable called "UpperLimit", the MA will implement the sp= ecification; the controller will implement the specification and things wor= k. If I do not specify anything for the Uniform distribution function - MA ven= dor 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 in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion to be used efficiently. BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_89294A6F3C6C91459E52E4128C4B02B7041CD0SPQCMBX02exfocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would suggest “= ;Immediate” an  option to allow for reporting after completion o= f a test. This would not need any parameters as the results would be sent a= fter completion of a test. Sometime it is necessary to be able to diagnose situations based on the results, and combined results = sent at later times do not allow for that. Again, That would be centrally m= anaged through the Management controller.

 

Sharam  

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Wednesday, April 23, 2014 8:59 AM
To: acmorton@att.com; timothy.carey@alcatel-lucent.com; Sharam Hakim= i; lmap@ietf.org
Subject: RE: Timer: Poisson distribution question<= /p>

 

Good to= be dragged back to requirements.

&n= bsp;

Certain= ly uniform would be the single function of choice for any load balancing re= quirement – you want uniform peak load either on the test points or o= n the reporting system. If you want to test at a single point in time, uniform distribution gives you the minimum spre= ad of time without exceeding the peak allowable load.

&n= bsp;

I could= _maybe_ make an argument for a normal distribution. That you want t= he bulk of tests at a certain time, but want a reduced volume of outlier te= sts to say something about how the results look either side of that time.

&n= bsp;

I would= n’t be unhappy about either:

<= span style=3D"mso-list:Ignore">-          Assuming function is uniform

<= span style=3D"mso-list:Ignore">-          Allowing multiple functions but only currently defining uniform. Of course= uniform doesn’t need a ‘spread’ parameter, just upper/lo= wer cuts so would probably want an eye to the future

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

&n= bsp;

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 infor= mation 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

&n= bsp;

From: MORTON, = ALFRED C (AL) [mailto:acmorton@att.com]
Sent: 23 April 2014 13:47
To: Burbridge,T,Trevor,TUB8 R; timothy.carey@alcatel-lucent.com; sha= ram.hakimi@exfo.com; lmap@ietf.org
Subject: RE: Timer: Poisson distribution question<= /p>

 

It seems as though a good part of this exchange has been s= kipped-over,

Tim and I clarified a lot of this last night...=

 

One function will do, discrete Uniform seems to meet the n= eed.

 

Al

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.com
Sent: Wednesday, April 23, 2014 8:41 AM
To: timothy.carey@alcatel-lucent.com; sharam.hakimi@exfo.com; lmap@i= etf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

Agree w= e need to have well defined function names. I thought you were also suggest= ing different functions needed different input parameters.

&n= bsp;

Trevor.=

&n= bsp;

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 infor= mation 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

&n= bsp;

From: Carey, T= imothy (Timothy) [mailt= o: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<= /p>

 

Its not that the Measu= rement controller has to configure the timer for the MA.

 

If we do not specify t= he functions and variable names, the measurement controller doesn’t h= ave 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 imp= lement the specification; the controller will implement the specification and things work.

 

If I do not specify an= ything for the Uniform distribution function – MA vendor 1 can call i= t “UniformDF” and “UL – which is typed real” = and maybe an “Enable” parameter for good measure; MA vendor 2 c= an call it “U” and have an attribute “X that is an integer”.<= o:p>

 

Now put that variation= on steroids based on the number of MA vendors – That is why we speci= fy things, right?

 

BR,<= /p>

Tim<= /p>

 

From: Sharam H= akimi [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<= /p>

 

The measurement contro= ller has to communicate what tests have to be run on an MA, for how long, w= hen to run them, what test results are generated, etc. Why would configurin= g this parameter be any different. Maybe I am missing something.

 

 

 

From: Carey, T= imothy (Timothy) [mailt= o: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<= /p>

 

So the burden is on th= e Measurement controller to know the functions and inputs specifications fo= r each possible MA vendor; not something I would want to have to do as a Me= asurement controller vendor.

 

From: Sharam H= akimi [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<= /p>

 

 

I do not see why vendo= r A or B or C matters. They would all be under the control of one Measureme= nt Controller which would specify what inputs to use for all MAs in a group= .

 

 

As Trevor also mention= ed this timer can be used for both testing and reporting and I would strong= ly suggest to have microsecond granularity. For reporting one could choose = seconds in terms of microseconds.

 

Thanks,

Sharam

 

 

 

From: Carey, T= imothy (Timothy) [mailt= o:timothy.carey@alcatel-lucent.com]
Sent: Wednesday, April 23, 2014 8:04 AM
To: trevor.burbridge@bt.c= om; Sharam Hakimi; lmap@ietf.org
Subject: RE: Timer: Poisson distribution question<= /p>

 

Trevor,

 

If we don’t defi= ne the inputs for each function (leaving the inputs opaque) you will have i= nterop problems.

MA vendor 1 uses these= 2 inputs named “A” and “B”; MA vendor 2 uses 3 inp= uts named “A”, “X” and “Y” for the same= function.

 

I think we need to avo= id that if we realistically want the Randomness function to be used efficie= ntly.

 

BR,<= /p>

Tim<= /p>

 

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<= /p>

 

The ran= dom timing can be used for both specifying when a test runs, or when a repo= rt is sent (or any other task such as contacting the Controller). It doesn&= #8217;t have to be used, but it can be.

&n= bsp;

I don&#= 8217;t really want different input variable for different functions. I don&= #8217;t see we need to. Also if we do, then we would have to have schema fo= r each function to specify which inputs are expected (like the measurement task registry). I’d like to avoid that.

&n= bsp;

Trevor.=

&n= bsp;

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 infor= mation 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

&n= bsp;

 

Sharam,

 

We are talking about o= ffsets for when to report; in the world we live in milliseconds is sufficie= nt – IMHO.

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the min/max sh= ould have microseconds granularity. Milliseconds would not be accurate enou= gh.

 

Personally, I would no= t trust my periodic tests in a large scale deployment to a random number ge= nerator and would want to know exactly how and when tests would be run.

 

 

Thanks,

Sharam

 

From: Carey, T= imothy (Timothy) [mailt= o: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<= /p>

 

Trevor,

 

The data model is exte= nsible by vendors so we can add functions and input variables as we need.

 

However we have to dec= ide on which small subset we actually want to standardize.

 

You suggested the Unif= orm and Normal which is fine but for the model we need to go farther by def= ining the specific function along with which inputs are used by the functio= n to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement diffe= rent variations. – Not good.

 

So I suggest we keep t= his simple.

 

Uniform Discrete ̵= 1; input variables - maximum [positive integer]

Gaussian –input = variables – mean of min/max, spread =3D standard deviation=

 

The min/max would be m= illiseconds – Spread would be an integer.

 

 

This sound OK?

 

BR

Tim<= /p>

 

 

From: Sharam H= akimi [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<= /p>

 

Tim,=

I think the Periodic T= imer distribution needs to have closer configuration control by the user an= d I think your 2nd  choice attempts to provide it but havin= g a discrete interval definition is a better way to go.

 

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Tuesday, April 22, 2014 4:35 AM
To: timothy.care= y@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Poisson distribution question<= /span>

 

&n= bsp;

On cont= inuous counterparts of Poisson I’m far from any expert and it would c= ertainly be up to the user to decide if such functions were suitable replac= ements 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-d= istribution.html

http://arxiv.org/abs/1303.5990=

&n= bsp;

As I tr= ied to say the current Information Model can take either discrete or contin= uous 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.

&n= bsp;

Persona= lly I’d think that Normal and Uniform distributions would cover most = needs, but the framework should be flexible in this regard.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

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 Ti= mers as suggested by the IETF LMAP information model.

 

During the review of the timers we had addition ques= tions regarding Trevors response to the Poisson distribution for the Random= ness 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 = 3;/- the mean (also needs to change to float) and are simply used to trim t= he function – obviously needed on a uniform distribution but useful to constrain other functions.

 <= /span>

I will = make all this clear in the next release.=

 <= /span>

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.“pois= son_1_sec”

- = ;         Add an interval to the information model.

 <= /span>

I was r= eally 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 demonstrabl= e value to supporting discrete functions (rather than continuous versions of them).

 <= /span>“

 =

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 w= hat matters is that the definition is clear, not the particular distributio= n (I don't have an opinion on that).

 =

 =

Could some please clarif= y this for us – Are we planning something other than Poisson method; = better yet is there a definition for the types of distribution:<= /span>

Poisson, Normal and Unif= orm.

 =

Thanks,

Tim

 =

--_000_89294A6F3C6C91459E52E4128C4B02B7041CD0SPQCMBX02exfocom_-- From nobody Wed Apr 23 06:18:03 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06D51A037A for ; Wed, 23 Apr 2014 06:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 PAJ6Du5pQbx8 for ; Wed, 23 Apr 2014 06:17:49 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id BB3811A0362 for ; Wed, 23 Apr 2014 06:17:48 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 23 Apr 2014 14:17:51 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.56]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Wed, 23 Apr 2014 14:17:41 +0100 From: To: , , , Date: Wed, 23 Apr 2014 14:17:40 +0100 Thread-Topic: Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAJ3BgAABCGwAAAKAgEAAAOAag Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <2845723087023D4CB5114223779FA9C8017944AE6F@njfpsrvexg8.research.att.com> <89294A6F3C6C91459E52E4128C4B02B7041CD0@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7041CD0@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: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72D46057224EMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9RFut4ob4ta9jbqO-RwbmbcWxBc 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, 23 Apr 2014 13:17:59 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72D46057224EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes we allow for 'immediate' but we were talking about the random distribut= ions that can be applied to the various timing options (immediate, periodic= , calendar, one-off). 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. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] Sent: 23 April 2014 14:15 To: Burbridge,T,Trevor,TUB8 R; acmorton@att.com; timothy.carey@alcatel-luce= nt.com; lmap@ietf.org Subject: RE: Timer: Poisson distribution question I would suggest "Immediate" an option to allow for reporting after complet= ion of a test. This would not need any parameters as the results would be s= ent after completion of a test. Sometime it is necessary to be able to diag= nose situations based on the results, and combined results sent at later ti= mes do not allow for that. Again, That would be centrally managed through t= he Management controller. Sharam From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Wednesday, April 23, 2014 8:59 AM To: acmorton@att.com; timothy.carey@alcatel-lucent= .com; Sharam Hakimi; lmap@ietf.org= Subject: RE: Timer: Poisson distribution question Good to be dragged back to requirements. Certainly uniform would be the single function of choice for any load balan= cing requirement - you want uniform peak load either on the test points or = on the reporting system. If you want to test at a single point in time, uni= form distribution gives you the minimum spread of time without exceeding th= e peak allowable load. I could _maybe_ make an argument for a normal distribution. That you want t= he bulk of tests at a certain time, but want a reduced volume of outlier te= sts to say something about how the results look either side of that time. I wouldn't be unhappy about either: - Assuming function is uniform - Allowing multiple functions but only currently defining uniform. O= f course uniform doesn't need a 'spread' parameter, just upper/lower cuts s= o would probably want an eye to the future 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. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: 23 April 2014 13:47 To: Burbridge,T,Trevor,TUB8 R; timothy.carey@alcatel-lucent.com; sharam.hakimi@exfo.com; lmap@ietf.org Subject: RE: Timer: Poisson distribution question It seems as though a good part of this exchange has been skipped-over, Tim and I clarified a lot of this last night... One function will do, discrete Uniform seems to meet the need. Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.= com Sent: Wednesday, April 23, 2014 8:41 AM To: timothy.carey@alcatel-lucent.com; sharam.hakimi@exfo.com; lmap@ietf.org Subject: Re: [lmap] 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 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. 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 cont= roller doesn't have a standard way of configuring a timer. For example - If I specify for a Uniform distribution function called "Unif= orm" you have a variable called "UpperLimit", the MA will implement the sp= ecification; the controller will implement the specification and things wor= k. If I do not specify anything for the Uniform distribution function - MA ven= dor 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 in= puts 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 co= ntrol 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 report= ing and I would strongly suggest to have microsecond granularity. For repor= ting 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 input= s named "A", "X" and "Y" for the same function. I think we need to avoid that if we realistically want the Randomness funct= ion to be used efficiently. BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.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 eac= h 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 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. 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 mi= lliseconds 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.b= urbridge@bt.com Subject: RE: Timer: Poisson distribution question Tim, I think the min/max should have microseconds granularity. Milliseconds woul= d 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 t= ests 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 v= ariables as we need. However we have to decide on which small subset we actually want to standar= dize. You suggested the Uniform and Normal which is fine but for the model we nee= d to go farther by defining the specific function along with which inputs a= re used by the function to derive what random number. Otherwise we will hav= e 2 implementers of the same standard algorithm implement different variati= ons. - 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 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.b= urbridge@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; 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 repla= cements for the discrete Poisson function. Yes it would be a different func= tion even if there was perfect fit (which they are not) as one is continuou= s 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 fo= r specifying the interval used for a discrete function. I was questioning t= he 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 (Timo= thy) 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 th= e 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 Ti= mer. Trevor responded: "Yes this does need to be clarified. I was assuming a distribution about th= e mean (i.e. the timing given is the mean). The spread would be the standar= d deviation (could use mean deviation or something else but I see no advant= age 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 neede= d 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."po= isson_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 val= ue to supporting discrete functions (rather than continuous versions of the= m). " But as people looked at Trevors response there were additional questions: I don't understand what Trevor means about the Poisson distribution. As fa= r 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 tha= n Poisson method; better yet is there a definition for the types of distrib= ution: Poisson, Normal and Uniform. Thanks, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72D46057224EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes we allow for ‘immediate’ but we were talking = about the random distributions that can be applied to the various timing op= tions (immediate, periodic, calendar, one-off).

 

Trevor.<= /p>

 

Trevor Burbridge
Network Infras= tructure & Innovation | BT Innovate & Design
Tel: 01473 645115Fax: 01473 640929

= This email contains BT information, which may be privileged or confiden= tial. It's meant only for the individual(s) or entity named above. If you'r= e not the intended recipient, note that disclosing, copying, distributing o= r using this information is prohibited. If you've received this email in er= ror, please let me know immediately on the email address above. Thank you.<= br>We monitor our email system, and may record your emails.
British Telecommunications plc
Regi= stered office: 81 Newgate Street London EC1A 7AJ
Registered in England n= o: 1800000

 

From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
Sent: 23 April = 2014 14:15
To: Burbridge,T,Trevor,TUB8 R; acmorton@att.com; timot= hy.carey@alcatel-lucent.com; lmap@ietf.org
Subject: RE: Timer: Po= isson distribution question

 

I would suggest “Immediate” an  option = to allow for reporting after completion of a test. This would not need any = parameters as the results would be sent after completion of a test. Sometim= e it is necessary to be able to diagnose situations based on the results, a= nd combined results sent at later times do not allow for that. Again, That = would be centrally managed through the Management controller.

 

Sharam  

 

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: = Wednesday, April 23, 2014 8:59 AM
To: acmorton@att.com; timothy.carey@alcatel-lucent.com; Sharam Hakimi; lmap@ietf.org
Subject: RE: Timer: Poisson = distribution question

 

Good to be dragged back to requirements.=

 

Certainly= uniform would be the single function of choice for any load balancing requ= irement – you want uniform peak load either on the test points or on = the reporting system. If you want to test at a single point in time, unifor= m distribution gives you the minimum spread of time without exceeding the p= eak allowable load.

 

I could _maybe_ make an argument for a normal= distribution. That you want the bulk of tests at a certain time, but want = a reduced volume of outlier tests to say something about how the results lo= ok either side of that time.

 

= I wouldn’t be unhappy about either:

-        Assuming function is uniform

- =        Allowing multiple functions but only currently defin= ing uniform. Of course uniform doesn’t need a ‘spread’ pa= rameter, just upper/lower cuts so would probably want an eye to the future<= o:p>

 

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 t= he email address above. Thank you.
We monitor our email system, and may = record your emails.
Bri= tish Telecommunications plc
Registered office: 81 Newgate Street London = EC1A 7AJ
Registered in England no: 1800000

 

From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: 23 April= 2014 13:47
To: Burbridge,T,Trevor,TUB8 R; timothy.carey@alcatel-lucent.com; sharam.hakimi@exfo.com; lmap@ietf.org
Subject: RE: Timer: Poisso= n distribution question

 

It seems as though a good part of= this exchange has been skipped-over,

 

One function = will do, discrete Uniform seems to meet the need.

 

Al=

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of= trevor.burbridge@bt.com=
Sent: Wednesday, April 23, 2014 8:41 AM
To: timothy.carey@alcatel-lucent.com<= /a>; sharam.hakimi@exfo.com; = lmap@ietf.org
Subject: Re: [= lmap] Timer: Poisson distribution question

 

Agree we need to have well def= ined function names. I thought you were also suggesting different functions= needed different input parameters.

 

Trevor.

 

Trevor Burbridge
Network Infrastructure &a= mp; Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 0147= 3 640929

This em= ail 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 i= ntended recipient, note that disclosing, copying, distributing or using thi= s information is prohibited. If you've received this email in error, please= let me know immediately on the email address above. Thank you.
We monit= or our email system, and may record your emails.
British Telecommunications plc
Registered offi= ce: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000<= /span>

 

From: Carey, = Timothy (Timothy) [mail= to: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 di= stribution question

<= o:p> 

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 standa= rd way of configuring a timer.

 

For example ̵= 1; If I specify for a Uniform distribution function called “Uniform&#= 8221; you have a  variable called “UpperLimit”, the MA wil= l implement the specification; the controller will implement the specificat= ion and things work.

 

If I do not specify anyth= ing for the Uniform distribution function – MA vendor 1 can call it &= #8220;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&#= 8221;.

 

Now put that variation on steroids base= d on the number of MA vendors – That is why we specify things, right?=

 

BR,

<= span lang=3DEN-US style=3D'color:#1F497D'>Tim

 

From: S= haram Hakimi [mailto:sharam.hakim= i@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=

 <= /o:p>

The measurement controller has to communicate what tests have to be ru= n 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 mi= ssing something.

 

 

 

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: Wednes= day, April 23, 2014 8:16 AM
To: Sharam Hakimi; trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: Timer: Poisson distrib= ution question

 

So the burden is on the Measurement controlle= r to know the functions and inputs specifications for each possible MA vend= or; not something I would want to have to do as a Measurement controller ve= ndor.

 

From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
Sent: Wednesd= ay, April 23, 2014 7:14 AM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: Timer: Pois= son distribution question

 

 

I do not see why = vendor A or B or C matters. They would all be under the control of one Meas= urement Controller which would specify what inputs to use for all MAs in a = group.

 

 

As Trevor also mention= ed this timer can be used for both testing and reporting and I would strong= ly suggest to have microsecond granularity. For reporting one could choose = seconds in terms of microseconds.

 

Thanks,

Sharam

 

 

 

From: C= arey, 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̵= 7;t define the inputs for each function (leaving the inputs opaque) you wil= l have interop problems.

MA vendor 1 uses these 2 inputs named &#= 8220;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 di= stribution question

<= span lang=3DEN-US> 

The random timing can be used for both specifying whe= n a test runs, or when a report is sent (or any other task such as contacti= ng the Controller). It doesn’t have to be used, but it can be.

&nbs= p;

I don= ’t really want different input variable for different functions. I do= n’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 measuremen= t task registry). I’d like to avoid that.

 

Trevor.<= /p>

 

Trevor Burbridge
Network Infras= tructure & Innovation | BT Innovate & Design
Tel: 01473 645115Fax: 01473 640929

= This email contains BT information, which may be privileged or confiden= tial. It's meant only for the individual(s) or entity named above. If you'r= e not the intended recipient, note that disclosing, copying, distributing o= r using this information is prohibited. If you've received this email in er= ror, please let me know immediately on the email address above. Thank you.<= br>We monitor our email system, and may record your emails.
British Telecommunications plc
Regi= stered office: 81 Newgate Street London EC1A 7AJ
Registered in England n= o: 1800000

 

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: 22 Apri= l 2014 22:07
To: Sharam Hakimi; = lmap@ietf.org; Burbridge,T,Trevor,TUB8 R
Subject: RE: Timer: = Poisson distribution question

 

Sharam,

 

We are talking abou= t offsets for when to report; in the world we live in milliseconds is suffi= cient – IMHO.

 

<= p class=3DMsoNormal>From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]
S= ent: Tuesday, April 22, 2014 3:59 PM
To: Carey, Timothy (Timo= thy); lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE= : Timer: Poisson distribution question

 

Tim,

I th= ink the min/max should have microseconds granularity. Milliseconds would no= t be accurate enough.

 

Personally, I would not t= rust my periodic tests in a large scale deployment to a random number gener= ator and would want to know exactly how and when tests would be run. <= /o:p>

 

 

Thanks,

Sharam<= /span>

<= o:p> 

From:= Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sen= t: Tuesday, April 22, 2014 3:16 PM
To: Sharam Hakimi; lmap@ietf.org; trevor.burbridge@bt.com
Subject: RE: Timer: Pois= son 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.

&nbs= p;

You suggested the Uniform and Normal which is fine but for the mode= l 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 k= eep this simple.

 

Uniform Discrete – input = variables - maximum [positive integer]

Gaussian –input vari= ables – mean of min/max, spread =3D standard deviation

 

The min/max would be milliseconds – Spread would be an i= nteger.

 

 

This sound OK?

 

BR

Tim

 

=

 =

From: Sharam Hakimi [mailto:shar= am.hakimi@exfo.com]
Sent: Tuesday, April 22, 2014 8:23 AMTo: Carey, Timothy (Timothy); lmap= @ietf.org; trevor.burbridge@= bt.com
Subject: RE: Timer: Poisson distribution question=

&= nbsp;

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 defin= ition is a better way to go.

 

 <= /span>

S= haram

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.com
Sent: Tue= sday, April 22, 2014 4:35 AM
To: timothy.carey@alcatel-lucent.com; lmap@ietf.org
Subject: Re: [lmap] Timer: Pois= son distribution question

 

 

On continuous counterparts of Poisson IR= 17;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 func= tion. Yes it would be a different function even if there was perfect fit (w= hich they are not) as one is continuous and one is discrete:

http://cmscience.blogspot.co.uk/2008/04/mt-6-poisson-and-gamma-distributio= n.html

http://arxiv.org/abs/130= 3.5990

 

As I tried to say the current Information Model can take either= discrete or continuous functions – only that there is currently no e= xplicit support for specifying the interval used for a discrete function. I= was questioning the need to add this.

 

Personally I’d think that Nor= mal and Uniform distributions would cover most needs, but the framework sho= uld be flexible in this regard.

<= span style=3D'color:#1F497D'> 

Trevor.

 

 

From: lmap [<= a href=3D"mailto:lmap-bounces@ietf.org">mailto:lmap-bounces@ietf.org] <= b>On Behalf Of Carey, Timothy (Timothy)
Sent: 19 April 2014 2= 0:24
To: lmap@ietf.org
Subject: [lmap] Timer: Poisson distribution question=

 

Team,

 

The BBF is looking at standardizing the model for Timers as sugges= ted by the IETF LMAP information model.

 

= During the review of the timers we had addition question= s regarding Trevors response to the Poisson distribution for the Randomness= of the Periodic Timer.

 

Trevor responded:

 

“Yes this does need to be clar= ified. 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 de= viation or something else but I see no advantage as long as we all know wha= t it refers to) and need to change to a float. The upper and lower cuts wou= ld be in seconds +/- the mean (also needs to change to float) and are simpl= y used to trim the function – obviously needed on a uniform distribut= ion but useful to constrain other functions.

 <= /o:p>

I will m= ake all this clear in the next release.

 =

As for poisso= n I think there are 3 options:

-        Use a continuous form in= stead

=

-&nb= sp;       Have the discrete interval implicit in the functi= on choice e.g.“poisson_1_sec”

-       = ; Add an inter= val to the information model.

=  

I was really thinking a= bout 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 suppo= rting discrete functions (rather than continuous versions of them).<= span lang=3DEN-US style=3D'color:black'>

 “

 

But as people looked at Tre= vors response there were additional questions:

 

I don't understand what Trevor means about the Poisson distribu= tion.  As far as I know, it is a discrete distribution, so a "con= tinuous form" would be a different distribution and not Poisson.  = ;And I believe that we do need a continuous distribution.  But what ma= tters is that the definition is clear, not the particular distribution (I d= on't have an opinion on that).

 

 

Could = some please clarify this for us – Are we planning something other tha= n Poisson method; better yet is there a definition for the types of distrib= ution:

Poisson, Normal and Uniform.

 

Thanks= ,

Tim

 

<= /div>
= --_000_ED51D9282D1D3942B9438CA8F3372EB72D46057224EMV64UKRDdoma_-- From nobody Wed Apr 23 07:00: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 B881D1A03A9 for ; Wed, 23 Apr 2014 07:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.272, 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 yvEm_SgeUv9U for ; Wed, 23 Apr 2014 07:00:05 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id 589191A020F for ; Wed, 23 Apr 2014 07:00:05 -0700 (PDT) X-ASG-Debug-ID: 1398261642-05fac1173e2ff860001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id dwWliHHYiFnFrLGB; Wed, 23 Apr 2014 17:00:42 +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 s3NDxmmB030488; Wed, 23 Apr 2014 16:59:51 +0300 From: "marc.ibrahim" To: , , , Date: Wed, 23 Apr 2014 16:59:48 +0300 X-ASG-Orig-Subj: Re: [lmap] Timer: Poisson distribution question Message-Id: <20140423133450.M64366@usj.edu.lb> In-Reply-To: References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC 4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 46.19.194.194 (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: 1398261642 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.5183 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/z8BB79lNTs31Kkpj15yt080wYRk 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, 23 Apr 2014 14:00:09 -0000 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) From nobody Wed Apr 23 07:22: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 4A99C1A02D7 for ; Wed, 23 Apr 2014 07:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=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 23Qh6rgYUINd for ; Wed, 23 Apr 2014 07:22:17 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 19CBA1A0217 for ; Wed, 23 Apr 2014 07:22:16 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 23 Apr 2014 15:22:07 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.56]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 23 Apr 2014 15:22:10 +0100 From: To: , , , Date: Wed, 23 Apr 2014 15:22:08 +0100 Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9e/FJRMEc3n92/QLK0k+A8VBFY8AAAuvYw Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC 4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> In-Reply-To: <20140423133450.M64366@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/K3eZXXNv0y9tdWCyCv1TBedFaSk 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, 23 Apr 2014 14:22:21 -0000 So the question is really do we want to design for extremely constrained de= vices? I'd argue that if this is a problem for them then they are really go= ing 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 numbe= r >of microseconds to count. So the problem is always an integer (discrete) n= umber >generation. > >Now, if the random generator can attain the maximum integer (so the maximu= m >possible random time), then, as Trevor says, no need for the timeStep I ta= lked >about, since all possible durations will be expressed as multiple of micro= seconds. > > >For example, a 32 bits random generator could generate up to a maximum val= ue >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 confid= ential. >> >> 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 param= eters. >> >> >> >> 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 confid= ential. >> >> 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 fo= r the >MA. >> >> >> >> If we do not specify the functions and variable names, the >> >> measurement controller doesn't have a standard way of configuring a t= imer. >> >> >> >> 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 inp= uts >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 confid= ential. >> >> 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 =3D 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 th= e >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 cont= inuous >versions of them). " >> >> >> >> But as people looked at Trevors response there were additional questi= ons: >> >> >> >> 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) From nobody Wed Apr 23 08:03: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 59A4F1A03DA for ; Wed, 23 Apr 2014 08:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.272, 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 7gfRALjA4yK0 for ; Wed, 23 Apr 2014 08:03:04 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id 939E31A03C4 for ; Wed, 23 Apr 2014 08:03:03 -0700 (PDT) X-ASG-Debug-ID: 1398265421-05fac110134996f0001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id FiWW1RQH5oqn1VxR; Wed, 23 Apr 2014 18:03:41 +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 s3NF2jVx010339; Wed, 23 Apr 2014 18:02:47 +0300 From: "marc.ibrahim" To: , , , Date: Wed, 23 Apr 2014 18:02:45 +0300 X-ASG-Orig-Subj: Re: [lmap] Timer: Poisson distribution question Message-Id: <20140423145224.M63656@usj.edu.lb> In-Reply-To: References: <9966516C6EB5FC4381E05BF80AA55F7719532956@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B70417CC@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F77195344C3@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041ACF@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F771953476F@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F7719534E82@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C05@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719534F79@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C1C@SPQCMBX02.exfo.com> <9966516C6EB5FC4381E05BF80AA55F7719535085@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC 4381E05BF80AA55F771953515B@US70UWXCHMBA05.zam.alcatel-lucent.com> <89294A6F3C6C91459E52E4128C4B02B7041C88@SPQCMBX02.exfo.com> <20140423130603.M45776@mail.usj.edu.lb> <20140423133450.M64366@usj.edu.lb> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 46.19.194.194 (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: 1398265421 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.5185 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/iPRLKMJa4VMWSoe_YURei0DuoDo 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, 23 Apr 2014 15:03:08 -0000 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) From nobody Wed Apr 23 08:11:50 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DA51A03EB for ; Wed, 23 Apr 2014 08:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.272] 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 k2Ms1KmxxYTb for ; Wed, 23 Apr 2014 08:11:23 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9B60E1A03EC for ; Wed, 23 Apr 2014 08:11:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 56BB4F6D; Wed, 23 Apr 2014 17:11:08 +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 k1XIE01QTcFZ; Wed, 23 Apr 2014 17:11:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Apr 2014 17:11:05 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2926620013; Wed, 23 Apr 2014 17:11:05 +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 Dm8SJAmH0fl4; Wed, 23 Apr 2014 17:11:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE06620017; Wed, 23 Apr 2014 17:10:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AD3112CA7455; Wed, 23 Apr 2014 17:10:59 +0200 (CEST) Date: Wed, 23 Apr 2014 17:10:59 +0200 From: Juergen Schoenwaelder To: "marc.ibrahim" Message-ID: <20140423151059.GE1056@elstar.local> Mail-Followup-To: "marc.ibrahim" , trevor.burbridge@bt.com, sharam.hakimi@exfo.com, timothy.carey@alcatel-lucent.com, lmap@ietf.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140423145224.M63656@usj.edu.lb> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ziwZPu8mcI-ZKBq3Xhicf2wD67s Cc: sharam.hakimi@exfo.com, timothy.carey@alcatel-lucent.com, 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 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, 23 Apr 2014 15:11:39 -0000 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 From nobody Wed Apr 23 08:33: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 7045F1A02A0 for ; Wed, 23 Apr 2014 08:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.372 X-Spam-Level: X-Spam-Status: No, score=-0.372 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.272] 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 XRbznrd7EpAA for ; Wed, 23 Apr 2014 08:33:36 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE3C1A028D for ; Wed, 23 Apr 2014 08:33:35 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 10EBAA05E9; Wed, 23 Apr 2014 11:33:29 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id C7D36A05E5; Wed, 23 Apr 2014 11:33:28 -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; Wed, 23 Apr 2014 11:33:28 -0400 From: Sharam Hakimi To: Juergen Schoenwaelder , marc.ibrahim Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgB/z8rwAAooPAAAA2hHUAAMigdwAABX6rAAFr6xAAAIqKRAAABTWsAAADE5sAAAJBFwAAA4CsAAAIZqsAAAMH2AAABWvrAAAELs4AAIod6AAAAj6gAAAZ1bAAAAx60AAAFrJIAAAEmdgAAIBF/A Date: Wed, 23 Apr 2014 15:33:27 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.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> In-Reply-To: <20140423151059.GE1056@elstar.local> 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-20652.000 X-TM-AS-Result: No--38.997-5.0-31-10 X-imss-scan-details: No--38.997-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20652.000 X-TMASE-Result: 10--38.996800-5.000000 X-TMASE-MatchedRID: 8HTFlOrbAtGjZne6WKfprTOb4QjG+dWPdyBAyOK4U803Z3efQH+wjx3t KdsNga2wWxwLlsLfqJhSE8o5N01WDJhk6IRLM4jHRxVrKtb83dQZskwWqoib3PgnJH5vm2+gAuE K/vInhEvEvrvwG0tz0OxwRthHX+IkJoswqQpTupzx5KZMlKYS/a3iVpZ0luwMRhKqIiS66sg4+q rsHfOFPCG9vs7eiyWBehoxcc3WIFrNkOxTi82/cmOho7buv7d90i/hFXziUdOabdGI7KtMTZUKc zlba69Ab0jonYxZ6O2FOHGHfL88MvZomtZBUIXQSDkh6bW+bcexD5+pk86RnNjMkXSUYVg8Orux vvk+gJGDYtCGpfgSduygflXB4NBLe2c/FCGaWPt99e0rIz5z613KZkFy4YZENrcZbPZsjrLbIvD sfrmY13WVib4qoeH91q8Mf7GLK80wL3UDzEgtc8rT39PoDNtWY9JlLwL1dg3KY//WmIj/ofWR+i REHN2r2bc+OIuXeVR/kgNkBhiKEA+q5PB4uzgXma6DzXaohvM31Ce+4Yv8aqXgQ/53L7AEEv86L HWvloM77YAfpQmyVMRab/kqwX/XwpXPYDaNp6pswYo64ufkVfqZGJlZc2fLWabPstVV86kHn+Ra CrVBs595phO/rhDvbod9/2o2MbBYavwdGWcieJVIEKhlTKpsj5hUmqusTPjjsTquy0JRi9ozbeO DnXplFNaqt6RIp6hn/7qHet1OouOu3vYITKKwe0i2wcB24/HRm6N++KG8MP8O4MqQQv1PfMCJgU F9i/8e8nDJdakWE7bbUvdJhGXpKnH/YRHng1ieAiCmPx4NwMidYBYDjITpooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/yQ9sDI02wPVCI0EiKKTfk8-w9NU Cc: "timothy.carey@alcatel-lucent.com" , "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: Wed, 23 Apr 2014 15:33:39 -0000 It depends what the performance goal of the measurement is. A ping packet i= n 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 millise= conds. 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]=20 Sent: Wednesday, April 23, 2014 11:11 AM To: marc.ibrahim Cc: trevor.burbridge@bt.com; Sharam Hakimi; timothy.carey@alcatel-lucent.co= m; 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 const= raints on both=20 > timer granularity and generator capacity.=20 >=20 > I still don't see a real measurement example where few microseconds would= really matter. >=20 > Practically, can a program deal with microseconds timers in computers and= 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 constraine= d=20 > > devices? I'd argue that if this is a problem for them then they are rea= lly=20 > > going to struggle with the Instruction information or measurement resul= ts. > >=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; > > >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 microseco= nds scale > > >means that the MA timer increment each microsecond. > > > > > >When MA wants to generate a random time, he has to choose an integer n= umber > > >of microseconds to count. So the problem is always an integer (discret= e) number > > >generation. > > > > > >Now, if the random generator can attain the maximum integer (so the ma= ximum > > >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 m= icroseconds. > > > > > > > > >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 co= nfidential. > > >> >> 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 t= he > > >> >> 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 interoperabili= ty > > >> >> 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; Shar= am > > >> >Hakimi; > > >> >lmap@ietf.org > > >> >> Subject: RE: Timer: Poisson distribution question > > >> >> > > >> >> Trevor, > > >> >> > > >> >> No - I am using the variable of your Information Model (LowerLimi= t, > > >> >UpperLimit, > > >> >> Spread) - works so far. Marc suggested a TimeStep parameter so w= e > > >> >> 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 p= arameters. > > >> >> > > >> >> 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 co= nfidential. > > >> >> 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 t= he > > >> >> 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 time= r 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 t= he > > >specification and things work. > > >> >> > > >> >> If I do not specify anything for the Uniform distribution functio= n > > >> >> - MA vendor > > >> >> 1 can call it "UniformDF" and "UL - which is typed real" and mayb= e 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 control= ler > > >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 speci= fy > > >> >> 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; Shar= am > > >> >Hakimi; > > >> >lmap@ietf.org > > >> >> Subject: RE: Timer: Poisson distribution question > > >> >> > > >> >> Trevor, > > >> >> > > >> >> If we don't define the inputs for each function (leaving the inpu= ts > > >> >> 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 sam= e > > >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 run= s, > > >> >> or when a report is sent (or any other task such as contacting th= e > > >> >> 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 co= nfidential. > > >> >> 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 t= he > > >> >> 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 a= nd > > >> >> 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 alo= ng > > >> >> with which inputs are used by the function to derive what random > > >> >> number. Otherwise we will have 2 implementers of the same standar= d > > >> >> 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 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.599= 0 > > >> >> > > >> >> As I tried to say the current Information Model can take either > > >> >> discrete or continuous functions - only that there is currently n= o > > >> >> 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 re= gard. > > >> >> > > >> >> 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 regardi= ng > > >> >> Trevors response to the Poisson distribution for the Randomness o= f the > > >Periodic Timer. > > >> >> > > >> >> Trevor responded: > > >> >> > > >> >> "Yes this does need to be clarified. I was assuming a distributio= n > > >> >> 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 neede= d > > >> >> 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 choi= ce > > >> >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 proble= m > > >> >> 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 qu= estions: > > >> >> > > >> >> I don't understand what Trevor means about the Poisson > > >> >> distribution. As far as I know, it is a discrete distribution, s= o > > >> >> 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 partic= ular=20 > 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 t= he > > >> >> 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 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 Apr 23 08:42:50 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BB81A0354 for ; Wed, 23 Apr 2014 08:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.272, 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 KzPvm8snc-a9 for ; Wed, 23 Apr 2014 08:42:42 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id D05191A035C for ; Wed, 23 Apr 2014 08:42:41 -0700 (PDT) X-ASG-Debug-ID: 1398267798-05fac1101349b180001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id Wpt4GaETP6e6HsmA; Wed, 23 Apr 2014 18:43:18 +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 s3NFgPoi015959; Wed, 23 Apr 2014 18:42:27 +0300 From: "marc.ibrahim" To: Sharam Hakimi , Juergen Schoenwaelder Date: Wed, 23 Apr 2014 18:42:25 +0300 X-ASG-Orig-Subj: Re: [lmap] Timer: Poisson distribution question Message-Id: <20140423153500.M7578@usj.edu.lb> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.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> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 46.19.194.194 (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: 1398267798 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.5185 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/xxs3AZ_ESGsC9fh5y673LLgThBc Cc: "timothy.carey@alcatel-lucent.com" , "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: Wed, 23 Apr 2014 15:42:46 -0000 As JS stated, we are talking about randomizing reporting and measurement start times. It is not about randomizing inter-packet intervals inside a given measurement. BR, Marc. On Wed, 23 Apr 2014 15:33:27 +0000, Sharam Hakimi wrote > 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 -- Open WebMail Project (http://openwebmail.org) From nobody Wed Apr 23 11:58:42 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068CB1A04B4 for ; Wed, 23 Apr 2014 11:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, 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 MUwI7kNdRb3e for ; Wed, 23 Apr 2014 11:58:37 -0700 (PDT) Received: from p02c12o149.mxlogic.net (p02c12o149.mxlogic.net [208.65.145.82]) by ietfa.amsl.com (Postfix) with ESMTP id BF49E1A049D for ; Wed, 23 Apr 2014 11:58:34 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c12o149.mxlogic.net(mxl_mta-8.0.0-0) with ESMTP id 75d08535.2b3e7a803940.4710.00-547.12448.p02c12o149.mxlogic.net (envelope-from ); Wed, 23 Apr 2014 12:58:31 -0600 (MDT) X-MXL-Hash: 53580d573db06323-7bf9ffb38971ed147dd870a2982bf52f56df14bf Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c12o149.mxlogic.net(mxl_mta-8.0.0-0) over TLS secured channel with ESMTP id dac08535.0.2444.00-335.6098.p02c12o149.mxlogic.net (envelope-from ); Wed, 23 Apr 2014 12:55:53 -0600 (MDT) X-MXL-Hash: 53580cb96abf0fa1-c3f09c4118b66409e4a5e8d736a06a72ef71687c 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, 23 Apr 2014 13:55:40 -0500 From: KEN KO To: Sharam Hakimi , Juergen Schoenwaelder , marc.ibrahim Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgAAGpuQAMg7ywAAAMetAAABaySAAABJnYAAAMjegAAEULew Date: Wed, 23 Apr 2014 18:55:39 +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> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=Qazov6rv c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:17 a=7JF6gnM3VwMA:10 a=qZHQZMT3apYA:10 a=cRzl_kMyrCAA:10 ] X-AnalysisOut: [a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJ] X-AnalysisOut: [NrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:8 a=gxZvrgisA] X-AnalysisOut: [AAA:8 a=e9qsufxtAAAA:8 a=pTHmISxBAAAA:8 a=Rg5jOeRUAAAA:8 a] X-AnalysisOut: [=QZam-5MpAAAA:8 a=EWPDJS0nAAAA:8 a=NMdtWtFZAAAA:8 a=j3Z76c] X-AnalysisOut: [jpAAAA:8 a=l4eDdyxRxiiM2c9wQL0A:9 a=lFWmJFD1Tu2PeVHx:21 a=] X-AnalysisOut: [BeioRqLftXt7ZpEy:21 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=] X-AnalysisOut: [JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=3FZX-ydVlcEA:10 a=W1qU] X-AnalysisOut: [_X6G3J8A:10 a=zeshHG33Dl4A:10 a=DAs2C8GDBtAA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014042319); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/88-iK3HW2fFGQIMHKH4BZDpbkzM Cc: "timothy.carey@alcatel-lucent.com" , "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: Wed, 23 Apr 2014 18:58:41 -0000 This example confuses resolution of the measurement result with resolution = and accuracy of the time at which the measurement is initiated. Measuring r= ound trip latencies on a Gigabit LAN may well require microsecond resolutio= n, which could be within the capabilities of a higher end MA. But that does= n't require microsecond resolution of the time at which the measurement is = initiated. In addition, for microsecond resolution on the Timer to be meani= ngful 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 mi= lliseconds. -----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.or= g Subject: Re: [lmap] Timer: Poisson distribution question It depends what the performance goal of the measurement is. A ping packet i= n 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 millise= conds. 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.co= m; 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 ti= mers. But for the randomization of the start of measurement tasks or the se= nding of reports, milliseconds seem to be sufficient (since there will be l= ikely 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=20 > constraints on both timer granularity and generator capacity. >=20 > I still don't see a real measurement example where few microseconds would= really matter. >=20 > Practically, can a program deal with microseconds timers in computers and= 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 information= or 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 microsecond. > > > > > >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 expr= essed as 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 th= an 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 generator= . > > >> >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 co= nfidential. > > >> >> 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 inp= ut 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 co= nfidential. > > >> >> 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 configuring= 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 ca= n 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 lik= e 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 co= nfidential. > > >> >> 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. - No= t 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 one= is 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 t= his 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 fu= nctions. > > >> >> > > >> >> 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 choi= ce > > >> >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 qu= estions: > > >> >> > > >> >> 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 co= ntinuous 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 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Apr 23 16:08: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 78B2A1A072D for ; Wed, 23 Apr 2014 16:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.827 X-Spam-Level: X-Spam-Status: No, score=0.827 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, RP_MATCHES_RCVD=-0.272, 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 u_OVChxsmGLI for ; Wed, 23 Apr 2014 16:08:15 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id EF3F51A072A for ; Wed, 23 Apr 2014 16:08:14 -0700 (PDT) X-ASG-Debug-ID: 1398294525-05fac110134a6d10001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id eKxtD3qhFXtDd5hM; Thu, 24 Apr 2014 02:08:45 +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 s3NN7j1O020499; Thu, 24 Apr 2014 02:07:48 +0300 From: "marc.ibrahim" To: KEN KO , Sharam Hakimi , Juergen Schoenwaelder Date: Thu, 24 Apr 2014 02:07:45 +0300 X-ASG-Orig-Subj: Re: [lmap] Timer: Poisson distribution question Message-Id: <20140423221748.M2036@usj.edu.lb> In-Reply-To: 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> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 46.19.194.194 (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: 1398294525 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.5199 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/KDssoqdW7I88rnt2GAVudBSBMtc Cc: "timothy.carey@alcatel-lucent.com" , "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: Wed, 23 Apr 2014 23:08:19 -0000 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) From nobody Wed Apr 23 17:55: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 BB3461A02BE for ; Wed, 23 Apr 2014 17:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 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_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_HELO_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 n9VYsJ5u0_DS for ; Wed, 23 Apr 2014 17:55:35 -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 366191A02BB for ; Wed, 23 Apr 2014 17:55:35 -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 99A80554144; Wed, 23 Apr 2014 20:55:56 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id 39B57E0102; Wed, 23 Apr 2014 20:55:22 -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; Wed, 23 Apr 2014 20:55:28 -0400 From: "MORTON, ALFRED C (AL)" To: marc.ibrahim , KEN KO , Sharam Hakimi , Juergen Schoenwaelder Date: Wed, 23 Apr 2014 20:55:18 -0400 Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9fSPQ181LBklYIQJKDgWFOBGHobQADoo+Q Message-ID: <2845723087023D4CB5114223779FA9C8017944AFCF@njfpsrvexg8.research.att.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: <20140423221748.M2036@usj.edu.lb> 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/hAVumKT_n4Ye3b0YtMklRwzTEPo Cc: "timothy.carey@alcatel-lucent.com" , "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: Thu, 24 Apr 2014 00:55:40 -0000 ... > Then the MA has to define a function UNIF(Xmin, Xmax) or equivalently UNI= F(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 (Xm= in, spread) to > the MA in the timing object. > > In this minimalist approach, no need to specify the nature of distributio= n in the timing > object since it is assumed to be the uniform one. > > BR, > Marc. Great, that's where we ended-up last night, too. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of marc.ibrahim > 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 distributio= n > 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 woul= d > > require synchronization to that resolution across different MAs in the > network. > > > > I'm in favor of keeping things simple and specifying Timer resolution i= n > 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 woul= d > 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 precis= e > > timers. But for the randomization of the start of measurement tasks or > the > > sending of reports, milliseconds seem to be sufficient (since there wil= l > be > > likely other delays introduced by the operating system that may get int= o > 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 th= e > > > > >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 les= s > 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 o= r > 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 o= r > 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 functio= n > > > > >> >> called "Uniform" you have a variable called "UpperLimit", th= e > > > > >> >> 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 b= e > > > > >> >> 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 i= t > 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 o= r > 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 th= e > > > > >> >> 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 > 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 choic= e > > > > >> >> 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 use= d > > > > >> >> 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 th= e > > > > >> >> 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 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 > > > > >> >> 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 additiona= l > 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) > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Apr 24 05:21: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 5A2E61A01AF for ; Thu, 24 Apr 2014 05:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 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_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 jm-goSsYniRr for ; Thu, 24 Apr 2014 05:21:25 -0700 (PDT) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) by ietfa.amsl.com (Postfix) with ESMTP id D2A931A0188 for ; Thu, 24 Apr 2014 05:21:24 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p01c11o144.mxlogic.net(mxl_mta-8.0.0-0) with ESMTP id fb109535.2aed7ca40940.76093.00-529.157025.p01c11o144.mxlogic.net (envelope-from ); Thu, 24 Apr 2014 06:21:19 -0600 (MDT) X-MXL-Hash: 535901bf3181b6cc-7fd154605aadf26b76adc6e64025a2af039c8e9b Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p01c11o144.mxlogic.net(mxl_mta-8.0.0-0) over TLS secured channel with ESMTP id 1c009535.0.73809.00-350.152096.p01c11o144.mxlogic.net (envelope-from ); Thu, 24 Apr 2014 06:17:14 -0600 (MDT) X-MXL-Hash: 535900ca0d27dd85-767ad8cc62a423eb861bc84b3090f003a96628c9 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, 24 Apr 2014 07:17:05 -0500 From: KEN KO To: marc.ibrahim , Sharam Hakimi , Juergen Schoenwaelder Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9cBNkIlcnjl+MWT9eG+H5X+dgZMgAAGpuQAMg7ywAAAMetAAABaySAAABJnYAAAMjegAAEULewAAuNC4AAEP0W4A== Date: Thu, 24 Apr 2014 12:17:05 +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> In-Reply-To: <20140423221748.M2036@usj.edu.lb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=Fq+L/gbq c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:17 a=7JF6gnM3VwMA:10 a=qZHQZMT3apYA:10 a=cRzl_kMyrCAA:10 ] X-AnalysisOut: [a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJ] X-AnalysisOut: [NrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=gxZvrgisAAAA:8 a=e9qsufxtA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=pTHmISxBAAAA:8 a=Rg5jOeRUAAAA:8 a] X-AnalysisOut: [=QZam-5MpAAAA:8 a=EWPDJS0nAAAA:8 a=NMdtWtFZAAAA:8 a=j3Z76c] X-AnalysisOut: [jpAAAA:8 a=-DEuOEZd4m0VQlvgNksA:9 a=THJPTyzDqv_csVME:21 a=] X-AnalysisOut: [lKvJqy1EIAC3qqa0:21 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=] X-AnalysisOut: [JrSEOxZJtCQA:10 a=3FZX-ydVlcEA:10 a=W1qU_X6G3J8A:10 a=lZB8] X-AnalysisOut: [15dzVvQA:10 a=zeshHG33Dl4A:10 a=DAs2C8GDBtAA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014042413); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/sSTnUq19zJq2yf3bHUsLDE0bkeI Cc: "timothy.carey@alcatel-lucent.com" , "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: Thu, 24 Apr 2014 12:21:29 -0000 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 Thu Apr 24 07:33: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 2B1AF1A02BA for ; Thu, 24 Apr 2014 07:33:06 -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 twzyi-CzvKSb for ; Thu, 24 Apr 2014 07:33:03 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAE31A0266 for ; Thu, 24 Apr 2014 07:33:02 -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; Thu, 24 Apr 2014 15:30:01 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Thu, 24 Apr 2014 15:32:31 +0100 From: To: , , Date: Thu, 24 Apr 2014 15:32:31 +0100 Thread-Topic: framework comments Thread-Index: Ac9cl9SeoAXxoO+sT62j3uhhwzLuTwAn4/lgAKQdm3A= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C7B5B44@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C7B5B44@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/L6LYphK_c3vS8yedNfLvwy34VcU 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: Thu, 24 Apr 2014 14:33:06 -0000 Looking at the i-d, I think all of the currently ambiguous text about "scop= e" falls into the category of "out of scope of LMAP WG" (rather than "out o= f scope of the first phase of the LMAP work") Am currently updating the i-d, based on the WBLC comments and discussions phil > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > Sent: 21 April 2014 09:08 > To: STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] framework comments >=20 > Hi, >=20 > One observation about general comment #1. I understand the comment and > I agree to a large extent with the intent. We need to be clear about > the places when we are talking about the broader scope of LMAP (like > when tracing the delineation line between what LMAP does and what IPPM > or other groups or organization do) and the places where we refer to > the current charter. This document may contain both (broader and > narrower) scope items, as a framework may draw lines for work beyond > the current charter. We just need to be clear. >=20 > Having said this, I do not believe that we should talk explicitly about > the LMAP WG charter in this document, and this is for two reasons. One > is that WGs come and go, while RFCs stay, so we would like to write the > document in a language that is meaningful even after the WG has > completed work. Second is that the LMAP charter may and probably will > change in time, so talking about "the current LMAP WG charter" may > point to something different in the future. I would suggest to use a > more neutral term, like "the first phase of the LMAP work". >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA > > H > > Sent: Sunday, April 20, 2014 4:00 PM > > To: lmap@ietf.org > > Subject: [lmap] framework comments > > > > First let me apologize for not having gotten my comments in before > the > > deadline. I left for vacation shortly after the start of WGLC and > have > > had very, very limited email and Internet access, or time for > > non-vacation activities. > > Barbara > > > > General comments > > 1. I'm concerned about descriptions of "the scope of LMAP" vs. "the > > scope of LMAP WG" vs. "the scope of this framework for LMAP" vs. "the > > scope of the LMAP WG charter". I think that what we chartered the > LMAP > > WG to do limits the scope of this framework for large-scale > > measurement platforms (LMAP) at this time. It does not limit the > scope > > of all possible LMAPs (future WG charters or all large-scale > > measurement platforms) for all time. Where there is distinction > > described between "LMAP" and "IPPM" scope (so that LMAP is really the > > WG more than the term), I agree with the description of "out-of- > > scope" for LMAP (WG) being permanent. Where we could conceive of the > > LMAP WG possibly being re-chartered in the future to take on > > additional tasks, or other organizations describing large-scale > > measurement platforms that encompass more, I think we should describe > > the restriction as being out- of-scope of this framework for LMAP, or > > out-of-scope of the current LMAP WG charter, rather than out-of-sc > > ope of (all) large-scale measurement platforms (LMAP) or the LMAP WG > > (forever). Part of the problem for me does seem to be that LMAP is > both the WG and a term, and it's sometimes hard to tell which is being > referred to. > > I suggest doing a search for "scope" and making the object of scoping > > "LMAP WG", "the current LMAP WG charter", or "this framework for > > LMAP", as appropriate. > > From nobody Thu Apr 24 07:57: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 6FB781A02A6; Thu, 24 Apr 2014 07:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 v2DxAHnJsPqZ; Thu, 24 Apr 2014 07:57:32 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 336B51A02A4; Thu, 24 Apr 2014 07:57:32 -0700 (PDT) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 0FF561A06A1; Thu, 24 Apr 2014 16:56:54 +0200 (CEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_D560875B-572C-485E-8F8A-D697615BA4DE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 24 Apr 2014 16:56:53 +0200 Message-Id: To: ippm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/SZ4lff_kcdLOr_hN4UWy-20uyr4 Cc: lmap@ietf.org Subject: [lmap] 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: Thu, 24 Apr 2014 14:57:34 -0000 --Apple-Mail=_D560875B-572C-485E-8F8A-D697615BA4DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 and = provide comments to ippm@ietf.org. Many thanks, best regards, Brian Trammell --Apple-Mail=_D560875B-572C-485E-8F8A-D697615BA4DE 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 iQEcBAEBCgAGBQJTWSY1AAoJENt3nsOmbNJcHeUH/ihZCag2vpbfS1BS5ITPiqw5 LqjUY5Z7Uiiq3llVVddeMYji0M+H3z+bjJYlpzXgm7hFbsM8J2FKX26/7pdOyvvE T+tZXj8x2bmFWBKvT8xH0NX6OL7W8paAJGDDEZogYoO7Rln2rpLm3QMZoNV9fJRK f9SJY5dG9ukvwerygQ5asjqvkh9vQ8KDtLKXAadi69PlYK6BLpF8S98JdYoG3Qeb TawfcO/JLACxpkbMeIKT1syjvgGvnTcyQh8M6k6rxBBm5zThvX0JIfD1fWssTMWz ygelV3ZCWkwo1LGWxPLz7rA0Ynt9Itrh01cusRvYmGAqA6tPNSU1TM3BXpwVc8U= =0M2y -----END PGP SIGNATURE----- --Apple-Mail=_D560875B-572C-485E-8F8A-D697615BA4DE-- From nobody Thu Apr 24 10:04: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 96FAB1A0229; Thu, 24 Apr 2014 10:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.968 X-Spam-Level: * X-Spam-Status: No, score=1.968 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, T_FILL_THIS_FORM_SHORT=0.01] 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 nQgg9j0n2tTl; Thu, 24 Apr 2014 10:04:09 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD5A1A02BA; Thu, 24 Apr 2014 10:04:08 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s3OH40x8015726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Apr 2014 12:04:01 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 73AF71E0065; Thu, 24 Apr 2014 11:03:55 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 1E42B1E005E; Thu, 24 Apr 2014 11:03:55 -0600 (MDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s3OH3sVE001205; Thu, 24 Apr 2014 12:03:54 -0500 (CDT) Received: from [10.188.201.94] (x1069818.dhcp.intranet [10.188.201.94]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s3OH3oEt001075; Thu, 24 Apr 2014 12:03:50 -0500 (CDT) Message-ID: <535943F6.80904@centurylink.com> Date: Thu, 24 Apr 2014 11:03:50 -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: Brian Trammell References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------050302010308020803010000" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/l_4IlaeapB5lqLoFnZZKrkthA5Q Cc: lmap@ietf.org, ippm@ietf.org Subject: Re: [lmap] WGLC on draft-ietf-ippm-lmap-path 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, 24 Apr 2014 17:04:14 -0000 This is a multi-part message in MIME format. --------------050302010308020803010000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian, This is the first time I have read the draft, so I have several comments. Most of my comments are asking for clarifications to be added to the text. Here are my comments: Section 5 The numbering for measurement points (mpNNN ) allows for considerable local use of unallocated numbers. Is the numbering (mpNNN) arbitrary? Should there be rules so that it is known where the mp is based on the number? o Some use the terminology "on-net" and "off-net" when referring to Internet Service Provider (ISP) measurement coverage. With respect to the reference path, tests between mp100 and mp190 are "on-net". "on-net" and "off-net" are terms relative to the perspective of the network of interest. Mp100 and mp190 would only be "on-net" relative to the Access Service Provider. They would be "off-net" relative to a Transport Service Provider. There is probably a better way to address "on-net" and "off-net". o Widely deployed broadband access measurements have used pass- through devices[SK] (at the subscriber's location) directly connected to the service demarcation point: this would be located at mp100. What is [SK]? o The networking technology used at all measurement points must be indicated, especially the interface standard and configured speed. Please explain why the "must". A person doing an end-to-end measurement does not care what the technology is. However, if the measurement result is to be compared to another measurement result, it is essential that the technology is known in order to understand whether the results are comparable. If the "must" is to facilitate comparability, we should add that to the bullet. o If it can be shown that a link connecting to a measurement point has reliably deterministic or negligible performance , then the remote end of the connecting link is an equivalent point for some methods of measurement (To Be Specified Elsewhere). In any case, the presence of such a link must be reported. "negligible performance" does not make sense. You never want performance to be negligible. Clarification is needed here on what conditions result in an intermediate point being equivalent to the remote end. o Many access network architectures have a traffic aggregation point (e.g., CMTS or DSLAM ) between mp100 and mp150. We designate this point mp120, but it won't currently fit in the figure. Maybe more examples are needed. When I first looked at the mp figure, I assumed that mp150 would be a DSLAM or OLT. Are you saying the mp150 is an NPE (Network Provider Edge) switch? o In the case that a private address space is used in an access architecture, then mp100 may need to use the same address space as its remote measurement point counterpart , so that a test between these points produces a useful assessment of network performance. Tests between mp000 and mp100 could use private address space, and when the egress side of a CGN is at mp150, then the private address side of the CGN could be designated mp149 for tests with mp100. When you say "remote measurement point counterpart" that sounds like it should be between mp800 and mp900. Some clarification as to the example being discussed is needed. It appears that rather than a remote counterpoint, that you are talking about two devices in the same private network. o Measurement points at Transit GRA GWs are numbered mpX00 and mpX90, where X is the lowest positive integer not already used in the path. This is not consistent with the drawing. mpX00 could be mistaken for mp000 or mp100. Consider starting at mp200 and incrementing to mp290. ***My real comment is that I believe it would be much clearer to have a section detailing the numbering rules to ensure consistency. 6. Translation Between Ref. Path and Tech . X What is "Tech."? May be better to spell out. I don't recall seeing "Tech." defined. After further reading, this should probably be "Technology". Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit device Net #1 Net #2 Demarc. Access GW GRA GW mp000 mp100 mp150 mp190 mp200 |--UE--|------------CPE/NAT--------|-------|BRAS -|------| |----Access Network--| |_______Un-managed sub-path________|__Managed sub-path__| Where you have BRAS is where the DSLAM would be. The BRAS would typically be behind the GRA GW and sometimes behind the Transit GRA GW. Only if a distributed BRAS is used would it possibly be at mp150. Because of the variety to topologies that could be used, it may be useful to consider mps at domain boundaries. These could be Domain mps, and Intra-Domain mps. We may need some more thinking in regarding the identification of measurement points. Also, why does "Access Network" need to be shown? Section 7 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit device Net #1 Net #2 Demarc. Access GW GRA GW mp000 mp100 mp150 mp190 mp200 |--UE--|------------CPE/NAT--------|------|-CGN-|------| Wi-Fi wired |---Access Network--| |-Shared--|RT|------Dedicated------| RT |-----Shared------... |_______Un-managed sub-path________|_Managed sub-path__| I have been asking why we need to indicate "Access Network". From the figure for the example is Section 7, I'm thinking rather than say "Access Network" maybe it should be "DSL" or "GPON" to indicated the technology. "Wired" would be 1000BASE-T. That would make this row in the figure the Technology row in defining the path. Thanks for your efforts in putting together this draft. Regards, Charles Cook On 4/24/2014 8:56 AM, 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 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 and provide comments to ippm@ietf.org. > > Many thanks, best regards, > > Brian Trammell > > > _______________________________________________ > 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 --------------050302010308020803010000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

This is the first time I have read the draft, so I have several comments.  Most of my comments are asking for clarifications to be added to the text.  Here are my comments:

Section 5
   The numbering for measurement points (mpNNN ) allows for considerable
   local use of unallocated numbers.

Is the numbering (mpNNN) arbitrary?  Should there be rules so that it is known where the mp is based on the number?

   o  Some use the terminology "on-net" and "off-net"  when referring to
      Internet Service Provider (ISP) measurement coverage.  With
      respect to the reference path, tests between mp100 and mp190 are
      "on-net".

“on-net” and “off-net” are terms relative to the perspective of the network of interest.  Mp100 and mp190 would only be “on-net” relative to the Access Service Provider.  They would be “off-net” relative to a Transport Service Provider.  There is probably a better way to address “on-net” and “off-net”.

   o  Widely deployed broadband access measurements have used pass-
      through devices[SK]  (at the subscriber's location) directly
      connected to the service demarcation point: this would be located
      at mp100.

What is [SK]?


   o  The networking technology used at all measurement points must  be
      indicated, especially the interface standard and configured speed.

Please explain why the "must".  A person doing an end-to-end measurement does not care what the technology is.  However, if the measurement result is to be compared to another measurement result, it is essential that the technology is known in order to understand whether the results are comparable.  If the "must" is to facilitate comparability, we should add that to the bullet.

   o  If it can be shown that a link connecting to a measurement point
      has reliably deterministic or negligible performance , then the
      remote end of the connecting link is an equivalent point for some
      methods of measurement (To Be Specified Elsewhere).  In any case,
      the presence of such a link must be reported.

"negligible performance" does not make sense.  You never want performance to be negligible.  Clarification is needed here on what conditions result in an intermediate point being equivalent to the remote end.

   o  Many access network architectures have a traffic aggregation point
      (e.g., CMTS or DSLAM ) between mp100 and mp150.  We designate this
      point mp120, but it won't currently fit in the figure.

Maybe more examples are needed.  When I first looked at the mp figure, I assumed that mp150 would be a DSLAM or OLT.  Are you saying the mp150 is an NPE (Network Provider Edge) switch?

   o  In the case that a private address space is used in an access
      architecture, then mp100 may need to use the same address space as
      its remote measurement point counterpart , so that a test between
      these points produces a useful assessment of network performance.
      Tests between mp000 and mp100 could use private address space, and
      when the egress side of a CGN is at mp150, then the private
      address side of the CGN could be designated mp149 for tests with
      mp100.

When you say “remote measurement point counterpart” that sounds like it should be between mp800 and mp900.  Some clarification as to the example being discussed is needed.  It appears that rather than a remote counterpoint, that you are talking about two devices in the same private network. 

   o  Measurement points at Transit GRA GWs are numbered mpX00  and
      mpX90, where X is the lowest positive integer not already used in
      the path.

This is not consistent with the drawing.  mpX00 could be mistaken for mp000 or mp100.  Consider starting at mp200 and incrementing to mp290.  ***My real comment is that I believe it would be much clearer to have a section detailing the numbering rules to ensure consistency.

6.  Translation Between Ref. Path and Tech .  X

What is “Tech.”?  May be better to spell out.  I don’t recall seeing “Tech.” defined.  After further reading, this should probably be "Technology".

   Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
   device     Net #1     Net #2    Demarc.    Access     GW     GRA GW
   mp000                            mp100      mp150    mp190    mp200
   |--UE--|------------CPE/NAT--------|-------|BRAS -|------|
                                      |----Access Network--|
   |_______Un-managed sub-path________|__Managed sub-path__|

Where you have BRAS is where the DSLAM would be.  The BRAS would typically be behind the GRA GW and sometimes behind the Transit GRA GW.  Only if a distributed BRAS is used would it possibly be at mp150.

 

Because of the variety to topologies that could be used, it may be useful to consider mps at domain boundaries.  These could be Domain mps, and Intra-Domain mps.  We may need some more thinking in regarding the identification of measurement points.

Also, why does “Access Network” need to be shown?  

Section 7
   Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
   device     Net #1     Net #2    Demarc.    Access     GW     GRA GW
   mp000                            mp100      mp150    mp190    mp200
   |--UE--|------------CPE/NAT--------|------|-CGN-|------|
              Wi-Fi      wired        |---Access Network--|

          |-Shared--|RT|------Dedicated------| RT  |-----Shared------...
   |_______Un-managed sub-path________|_Managed sub-path__|

I have been asking why we need to indicate "Access Network".  From the figure for the example is Section 7, I’m thinking rather than say “Access Network” maybe it should be “DSL” or “GPON” to indicated the technology.  “Wired” would be 1000BASE-T.  That would make this row in the figure the Technology row in defining the path.


Thanks for your efforts in putting together this draft.

Regards,
Charles Cook


On 4/24/2014 8:56 AM, 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 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 and provide comments to ippm@ietf.org.

Many thanks, best regards,

Brian Trammell



_______________________________________________
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
--------------050302010308020803010000-- From nobody Sun Apr 27 12:14: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 59C3F1A0693 for ; Sun, 27 Apr 2014 12:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.949 X-Spam-Level: * X-Spam-Status: No, score=1.949 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=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 4pUr4_OB143s for ; Sun, 27 Apr 2014 12:14:35 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id ACC321A0675 for ; Sun, 27 Apr 2014 12:14:35 -0700 (PDT) Received: from [192.168.43.134] ([172.56.38.125]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s3RJEJox008108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 27 Apr 2014 19:14:22 GMT (envelope-from joelja@bogus.com) Message-ID: <535D570F.50909@bogus.com> Date: Sun, 27 Apr 2014 12:14:23 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: Sharam Hakimi , Juergen Schoenwaelder , "marc.ibrahim" 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> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7041DD1@SPQCMBX02.exfo.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="APjUlJsQLX7p8DxR88l7Vv5lxje14C6s1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sun, 27 Apr 2014 19:14:25 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/hlN5nGifSyQt07vtU-yvrwxKP88 Cc: "timothy.carey@alcatel-lucent.com" , "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: Sun, 27 Apr 2014 19:14:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --APjUlJsQLX7p8DxR88l7Vv5lxje14C6s1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 4/23/14, 8:33 AM, Sharam Hakimi wrote: > 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. It's pretty easy to send a packet before it arrives with respect to measurement. increasing the precision of your measurement doesn't actually help you if can't recover the state of the clocks. > 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. http://i.imgur.com/AkDRs9D.png if you want to watch the microsecond precision clock generation in two cross country routers drift past each other over 10gig links... the top line is the rtt measured by the sender. There's no reason to assume that consumer level connectivity won't in the future employ faster link layers. > Sharam >=20 >=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; lmap@ietf.org=20 > Subject: Re: [lmap] Timer: Poisson distribution question >=20 > I believe randomization with a granularity of milliseconds is good=20 > enough. Within an implementation of a measurement task, one may use=20 > more precise timers. But for the randomization of the start of=20 > measurement tasks or the sending of reports, milliseconds seem to be=20 > sufficient (since there will be likely other delays introduced by > the operating system that may get into the some order for starting a=20 > 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 >> constraints on both timer granularity and generator capacity. >>=20 >> I still don't see a real measurement example where few microseconds >> would really matter. >>=20 >> Practically, can a program deal with microseconds timers in >> computers and smartphones? 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 >>> 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. >>>=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 >>>>=20 >>>> Here is how I see the problem. >>>>=20 >>>> First we have to separate time granularity and random >>>> generation. >>>>=20 >>>> Time granularity depends on the timer running on the MA. e.g >>>> microseconds scale means that the MA timer increment each >>>> microsecond. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> It all depends on the capacity of the generator. Marc. >>>>=20 >>>>=20 >>>> On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote >>>>> So what is the argument for the latter (discrete) option? >>>>>=20 >>>>> Trevor. >>>>>=20 >>>>>> -----Original Message----- From: marc.ibrahim >>>>>> [mailto:marc.ibrahim@usj.edu.lb] Sent: 23 April 2014 14:10=20 >>>>>> 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 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> BR, >>>>>>=20 >>>>>> Marc. >>>>>>=20 >>>>>>=20 >>>>>> 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? >>>>>>>=20 >>>>>>> Trevor. >>>>>>>=20 >>>>>>> Trevor Burbridge Network Infrastructure & Innovation | BT >>>>>>> Innovate & Design Tel: 01473 645115 Fax: 01473 640929 >>>>>>>=20 >>>>>>> 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,=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> 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;=20 >>>>>>> lmap@ietf.org Subject: Re: [lmap] Timer: Poisson >>>>>>> distribution question >>>>>>>=20 >>>>>>> Marc's suggestion works for me. That allows better >>>>>>> interoperability in my >>>>>> opinion. >>>>>>>=20 >>>>>>> I do agree that we need a common "structure" and >>>>>>> "names". >>>>>>>=20 >>>>>>> Thanks, Sharam >>>>>>>=20 >>>>>>> From: Carey, Timothy (Timothy)=20 >>>>>>> [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 >>>>>>>=20 >>>>>>> Trevor, >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> BR, Tim >>>>>>>=20 >>>>>>> From: >>>>>>> trevor.burbridge@bt.com >>>>>> [mailto:trevor.burbridge@bt.com] >>>>>>> Sent: Wednesday, April 23, 2014 7:41 AM To: Carey, >>>>>>> Timothy (Timothy);=20 >>>>>>> sharam.hakimi@exfo.com; >>>>>> lmap@ietf.org >>>>>>> Subject: RE: Timer: Poisson distribution question >>>>>>>=20 >>>>>>> Agree we need to have well defined function names. I >>>>>>> thought you were also suggesting different functions >>>>>>> needed different input parameters. >>>>>>>=20 >>>>>>> Trevor. >>>>>>>=20 >>>>>>> Trevor Burbridge Network Infrastructure & Innovation | BT >>>>>>> Innovate & Design Tel: 01473 645115 Fax: 01473 640929 >>>>>>>=20 >>>>>>> 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,=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> Its not that the Measurement controller has to configure >>>>>>> the timer for the >>>> MA. >>>>>>>=20 >>>>>>> If we do not specify the functions and variable names, >>>>>>> the measurement controller doesn't have a standard way of >>>>>>> configuring a timer. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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". >>>>>>>=20 >>>>>>> Now put that variation on steroids based on the number of >>>>>>> MA vendors - That is why we specify things, right? >>>>>>>=20 >>>>>>> BR, Tim >>>>>>>=20 >>>>>>> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] Sent: >>>>>>> Wednesday, April 23, 2014 7:24 AM To: Carey, Timothy >>>>>>> (Timothy);=20 >>>>>>> trevor.burbridge@bt.com; >>>>>> lmap@ietf.org >>>>>>> Subject: RE: Timer: Poisson distribution question >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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;=20 >>>>>> lmap@ietf.org >>>>>>> Subject: RE: Timer: Poisson distribution question >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] Sent: >>>>>>> Wednesday, April 23, 2014 7:14 AM To: Carey, Timothy >>>>>>> (Timothy);=20 >>>>>>> trevor.burbridge@bt.com; >>>>>> lmap@ietf.org >>>>>>> Subject: RE: Timer: Poisson distribution question >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Thanks, Sharam >>>>>>>=20 >>>>>>> From: Carey, Timothy (Timothy)=20 >>>>>>> [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 >>>>>>>=20 >>>>>>> Trevor, >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> I think we need to avoid that if we realistically want >>>>>>> the Randomness function to be used efficiently. >>>>>>>=20 >>>>>>> BR, Tim >>>>>>>=20 >>>>>>> From: >>>>>>> trevor.burbridge@bt.com >>>>>> [mailto:trevor.burbridge@bt.com] >>>>>>> Sent: Wednesday, April 23, 2014 2:55 AM To: Carey, >>>>>>> Timothy (Timothy);=20 >>>>>>> sharam.hakimi@exfo.com; >>>>>> lmap@ietf.org >>>>>>> Subject: RE: Timer: Poisson distribution question >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Trevor. >>>>>>>=20 >>>>>>> Trevor Burbridge Network Infrastructure & Innovation | BT >>>>>>> Innovate & Design Tel: 01473 645115 Fax: 01473 640929 >>>>>>>=20 >>>>>>> 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,=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> 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,=20 >>>>>>> TUB8 R Subject: RE: Timer: Poisson distribution question >>>>>>>=20 >>>>>>> Sharam, >>>>>>>=20 >>>>>>> We are talking about offsets for when to report; in the >>>>>>> world we live in milliseconds is sufficient - IMHO. >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> Tim, I think the min/max should have microseconds >>>>>>> granularity. Milliseconds would not be accurate enough. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Thanks, Sharam >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> Trevor, >>>>>>>=20 >>>>>>> The data model is extensible by vendors so we can add >>>>>>> functions and input variables as we need. >>>>>>>=20 >>>>>>> However we have to decide on which small subset we >>>>>>> actually want to >>>>>> standardize. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> So I suggest we keep this simple. >>>>>>>=20 >>>>>>> Uniform Discrete - input variables - maximum [positive >>>>>>> integer] Gaussian -input variables - mean of min/max, >>>>>>> spread =3D standard deviation >>>>>>>=20 >>>>>>> The min/max would be milliseconds - Spread would be an >>>>>>> integer. >>>>>>>=20 >>>>>>> This sound OK? >>>>>>>=20 >>>>>>> BR Tim >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Sharam >>>>>>>=20 >>>>>>> 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>>>>> >>>>>>>=20 lucent.com>; >>>>>>> lmap@ietf.org Subject: Re: [lmap] >>>>>>> Timer: Poisson distribution question >>>>>>>=20 >>>>>>> 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:=20 >>>>>>> http://cmscience.blogspot.co.uk/2008/04/mt- >>>>>> 6- >>>>>>> poisson-and-gamma-distribution.html >>>>>>> http://arxiv.org/abs/1303.5990 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Personally I'd think that Normal and Uniform >>>>>>> distributions would cover most needs, but the framework >>>>>>> should be flexible in this regard. >>>>>>>=20 >>>>>>> Trevor. >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> Team, >>>>>>>=20 >>>>>>> The BBF is looking at standardizing the model for Timers >>>>>>> as suggested by the IETF LMAP information model. >>>>>>>=20 >>>>>>> During the review of the timers we had addition questions >>>>>>> regarding Trevors response to the Poisson distribution >>>>>>> for the Randomness of the >>>> Periodic Timer. >>>>>>>=20 >>>>>>> Trevor responded: >>>>>>>=20 >>>>>>> "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. >>>>>>>=20 >>>>>>> I will make all this clear in the next release. >>>>>>>=20 >>>>>>> As for poisson I think there are 3 options: >>>>>>>=20 >>>>>>> - Use a continuous form instead >>>>>>>=20 >>>>>>> - Have the discrete interval implicit in the >>>>>>> function choice >>>>>> e.g."poisson_1_sec" >>>>>>>=20 >>>>>>> - Add an interval to the information model. >>>>>>>=20 >>>>>>> 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). " >>>>>>>=20 >>>>>>> But as people looked at Trevors response there were >>>>>>> additional questions: >>>>>>>=20 >>>>>>> I don't understand what Trevor means about the Poisson=20 >>>>>>> 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). >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Thanks, Tim >>>>>>=20 >>>>>>=20 >>>>>> -- Open WebMail Project (http://openwebmail.org) >>>>>=20 >>>>> _______________________________________________ lmap mailing >>>>> list lmap@ietf.org=20 >>>>> 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 >> -- Open WebMail Project (http://openwebmail.org) >>=20 >> _______________________________________________ lmap mailing list=20 >> lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap >=20 --APjUlJsQLX7p8DxR88l7Vv5lxje14C6s1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNdVw8ACgkQ8AA1q7Z/VrK0AwCfa13LZ+HWrQDMmQup6PtIld1R idsAn2vd3HihNu2yqoGE6N5PO73xJtCd =di97 -----END PGP SIGNATURE----- --APjUlJsQLX7p8DxR88l7Vv5lxje14C6s1-- From nobody Sun Apr 27 13:04: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 9B71C1A03B1 for ; Sun, 27 Apr 2014 13:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.299 X-Spam-Level: ** X-Spam-Status: No, score=2.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=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 YozZO4YLqJuU for ; Sun, 27 Apr 2014 13:03:53 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 14E681A03C5 for ; Sun, 27 Apr 2014 13:03:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B4EBFA80; Sun, 27 Apr 2014 22:03:51 +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 M_9Umgs4Guha; Sun, 27 Apr 2014 22:03:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 27 Apr 2014 22:03:48 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0400B20017; Sun, 27 Apr 2014 22:03:48 +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 XinXPSRyKYqs; Sun, 27 Apr 2014 22:03:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7743A20013; Sun, 27 Apr 2014 22:03:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9006A2CC239B; Sun, 27 Apr 2014 22:03:40 +0200 (CEST) Date: Sun, 27 Apr 2014 22:03:39 +0200 From: Juergen Schoenwaelder To: joel jaeggli Message-ID: <20140427200339.GA22985@elstar.local> Mail-Followup-To: joel jaeggli , Sharam Hakimi , "marc. ibrahim" , "timothy.carey@alcatel-lucent.com" , "trevor.burbridge@bt.com" , "lmap@ietf.org" References: <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> <535D570F.50909@bogus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535D570F.50909@bogus.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/eG0jkStb7xxRG1uqn3sM28MgOG4 Cc: Sharam Hakimi , "timothy.carey@alcatel-lucent.com" , "trevor.burbridge@bt.com" , "marc. ibrahim" , "lmap@ietf.org" Subject: Re: [lmap] Timer: Poisson distribution question 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: Sun, 27 Apr 2014 20:03:56 -0000 Are we still talking about the randomization of the start of measurement tasks or reports? /js On Sun, Apr 27, 2014 at 12:14:23PM -0700, joel jaeggli wrote: > On 4/23/14, 8:33 AM, Sharam Hakimi wrote: > > 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. > > It's pretty easy to send a packet before it arrives with respect to > measurement. increasing the precision of your measurement doesn't > actually help you if can't recover the state of the clocks. > > > 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. > > http://i.imgur.com/AkDRs9D.png > > if you want to watch the microsecond precision clock generation in two > cross country routers drift past each other over 10gig links... the top > line is the rtt measured by the sender. > > There's no reason to assume that consumer level connectivity won't in > the future employ faster link layers. > > > > 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 > > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Apr 27 13:12: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 C56121A063B for ; Sun, 27 Apr 2014 13:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_91=0.6, 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 dnBOvxpmFlQW for ; Sun, 27 Apr 2014 13:11:59 -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 65CA51A03B1 for ; Sun, 27 Apr 2014 13:11:59 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 113DA120427; Sun, 27 Apr 2014 16:12:37 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-azure.research.att.com (Postfix) with ESMTP id 967D7E0102; Sun, 27 Apr 2014 16:11:58 -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; Sun, 27 Apr 2014 16:11:58 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , joel jaeggli Date: Sun, 27 Apr 2014 16:11:56 -0400 Thread-Topic: [lmap] Timer: Poisson distribution question Thread-Index: Ac9iU93CY5143O6RSWem9l4iZ8MkFQAAAw/A Message-ID: <2845723087023D4CB5114223779FA9C801795CCA89@njfpsrvexg8.research.att.com> References: <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> <535D570F.50909@bogus.com> <20140427200339.GA22985@elstar.local> In-Reply-To: <20140427200339.GA22985@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/wWkSp6EACLZUcwe8CgIUp5Msgng Cc: Sharam Hakimi , "timothy.carey@alcatel-lucent.com" , "trevor.burbridge@bt.com" , "marc. ibrahim" , "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: Sun, 27 Apr 2014 20:12:04 -0000 This thread spilt into two topics sometime last Thursday, with a misunderstanding about the resolution of start times: someone thought we were talking about packet scheduling within a stream and that discussion mixed-in here too. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Sunday, April 27, 2014 4:04 PM > To: joel jaeggli > Cc: Sharam Hakimi; timothy.carey@alcatel-lucent.com; > trevor.burbridge@bt.com; marc. ibrahim; lmap@ietf.org > Subject: Re: [lmap] Timer: Poisson distribution question > > Are we still talking about the randomization of the start of > measurement tasks or reports? > > /js > > On Sun, Apr 27, 2014 at 12:14:23PM -0700, joel jaeggli wrote: > > On 4/23/14, 8:33 AM, Sharam Hakimi wrote: > > > 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. > > > > It's pretty easy to send a packet before it arrives with respect to > > measurement. increasing the precision of your measurement doesn't > > actually help you if can't recover the state of the clocks. > > > > > 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. > > > > http://i.imgur.com/AkDRs9D.png > > > > if you want to watch the microsecond precision clock generation in two > > cross country routers drift past each other over 10gig links... the top > > line is the rtt measured by the sender. > > > > There's no reason to assume that consumer level connectivity won't in > > the future employ faster link layers. > > > > > > > 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 =3D 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 > > > > > > > > > > > > _______________________________________________ > > 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 From nobody Mon Apr 28 09: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 4BD621A08C5 for ; Mon, 28 Apr 2014 09:26:29 -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 od4ChUlcqOO0 for ; Mon, 28 Apr 2014 09:26:26 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 742B41A0943 for ; Mon, 28 Apr 2014 09:26:25 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 28 Apr 2014 17:26:26 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 28 Apr 2014 17:26:23 +0100 From: To: Date: Mon, 28 Apr 2014 17:26:21 +0100 Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: Ac9OVf6d2SR29el4QFikBhDM41TwrgUp+2xg Message-ID: References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> <20140401132852.GA74000@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> <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> In-Reply-To: <20140402092859.GA76386@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/SJ6p2s2qyWrIaB8ga8AHpdu4BKQ Cc: 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: Mon, 28 Apr 2014 16:26:29 -0000 Not sure this discussion (about suppression) reached a conclusion.=20 At the moment, the default is that suppression stops all new active measure= ment tasks and the impact on other tasks (including passive measurements an= d reporting) is left up to the implementation. Please re-start the discussion if you think this needs to be adjusted Thanks phil > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: 02 April 2014 10:29 > To: Eardley,PL,Philip,TUB8 R > Cc: bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- > framework-04.txt >=20 > Phil, >=20 > I think what you have in mind (the mini firewall) is not exactly what I > would understand from "must stop new active measurement tasks from > starting". Your notion of suppressiong is blocking measurement traffic, > you are not starting or stopping or not starting anything. >=20 > If this is what suppression is meant to be (and I think this is close > to Barbara's ideas), then we need to spell this out more clearly I > think. >=20 > Is it simple to implement? I think one would need for each measurement > task a filter that can be injected and removed and the filters would > have to be designed such that they do not cause side effects affecting > other things going on. In other words, this sets up a requirement for > measurement task implementations, not so much for the generic > infrastructure (that would simply inject and remove such filters). >=20 > Anyway, as useful as this might be, the current text seems to say > something different. >=20 > /js >=20 > On Wed, Apr 02, 2014 at 10:06:45AM +0100, philip.eardley@bt.com wrote: > > Can I suggest we discuss S5.2.1.1 first and get the definition of > Suppression right after that. > > > > Just to confirm what the current 5.2.1.1 is intended to mean: > > Suppression must stop new active measurement tasks from starting. > > The impact is undefined (left to the implementer /deployer) on other > things like passive measurement tasks and on-going active tasks. > > Suppression is intended to be temporary - if you want to stop all the > > active tasks permanently, then it's suggested you send a new schedule > > [but I guess there's nothing to stop you 'abusing' suppression as a > > permanent stop] > > > > 5.2.1.1 doesn't talk about the impact on Data Transfer Tasks. Not > sure we've discussed this. I suppose at the moment the implication is > that Data Transfer Tasks (including reporting) continues to run. > > > > -- > > > > In terms of implementation, the way I thought about it is that the MA > would have a mini-firewall that would block all outgoing traffic > associated with a measurement task; there's at least some traffic it > mustn't block, such as capabilities & logging info sent in response to > a request from the controller. Is this easy to implement? > > I don't think the MA needs to understand any classification of > different measurement tasks. However, the measurement system would > probably like to understand the impact of this mini-firewall function > for non-obvious cases like a measurement task that simply modifies the > header of end-user traffic. > > > > -- > > > > > we can either introduce a classification of all measurement tasks > > > (where is this coming from?) or we could make this explicit config > > > (this way I know which tasks will be stopped if someone hits the > > > button). > > I don't like classification. This is work, requires extra state in > controller and MA, and what happens if there's a classification > mistake. > > Explicit config. This basically means 'send a new schedule' (actually > > my personal view but not the consensus) > > > > Phil > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: 02 April 2014 06:56 > > > To: STARK, BARBARA H > > > Cc: Eardley,PL,Philip,TUB8 R; lmap@ietf.org > > > Subject: Re: [lmap] FW: New Version Notification for > > > draft-ietf-lmap- framework-04.txt > > > > > > Barbara, > > > > > > I disagree. If I hit the supression button, I like to know what the > > > consequence of this is. Leaving this partially up to > implementations > > > is in my view the worst of all choices. Looking at the current ID, > > > my understanding is that a suppression without parameters > suppresses > > > a certain set of measurement tasks, takes effect immediately, and > > > supression ends when the unsuppress button is hit. I assume the > > > suppress ongoing task bit defaults to false (but this is less > > > clearly spelled out). > > > > > > To define the set of measurement tasks that is affected if no set > is > > > specified, we can either introduce a classification of all > > > measurement tasks (where is this coming from?) or we could make > this > > > explicit config (this way I know which tasks will be stopped if > > > someone hits the button). Both could work for me. But, a definition > > > of 'a certain set of measurement tasks plus additional tasks that > > > are implementation specific' is in my view not a desirable outcome. > > > > > > /js > > > > > > On Tue, Apr 01, 2014 at 06:34:00PM +0000, STARK, BARBARA H wrote: > > > > > > I agree with you that "Active" does not belong in the > definition. > > > > > > I disagree > > > > > that internal collection of passive measurements must cease, or > > > that > > > > > reporting must cease. They may cease in a particular > > > implementation, > > > > > but all implementations are not required to cause them to > cease. > > > > > Only originated measurement traffic must cease. > > > > > > > > > > I am having a problem with 'may in some implementations'. This > > > > > is not interoperable. > > > > > > > > In my experience, it's impossible to define a function so > > > > thoroughly > > > that there are no unknowns about what it will do in a certain > > > situation, and no decisions left up to the implementer. > > > > > > > > But let's say hypothetically that all collection of passive > > > measurements *are* "stopped". We've defined internal measuring of > > > CPU utilization and memory resources and general device health > > > checking as "passive measurements". So this means they all have to > > > stop. Firewall logging is a passive measurement. It must stop. Link > > > resource utilization to be used in active queue management is a > > > passive measurement. It must stop. But why is it an > interoperability "issue" > > > whether these passive measurement processes continue to run or not? > > > I really don't understand how they impact interoperability. > > > > > > > > As for reporting, we've defined sending log info (e.g. > measurement > > > tasks successfully run, suppressed, etc.) to the Controller as a > > > report. Let's say we expect Suppression to stop all reports. That > > > means it must not send the Controller any logs. > > > > > > > > Anyway, I was illustrating just a few examples of unknowns wrt > > > impacts of Suppression. There are many more unknowns. My proposed > > > definition of Suppression has no 'may' statements. > > > > > > > > Suppression: the cessation of measurement traffic originated by > > > > the > > > MA. > > > > > > > > If we wanted to explicitly say that suppression shall not impact > > > collection of passive measurements or reporting, I would be fine > > > with that, since I think that's the better design and I think it's > > > easily achieved. But others thought it would be complex to do and > > > that it would be simpler for them to "kill all measurement tasks". > > > As long as I'm not obliged to implement Suppression as "kill all > > > tasks" I'm fine with giving others the freedom to do so in their > implementations. > > > > Barbara > > > > > > -- > > > 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 From nobody Mon Apr 28 12:29: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 601D31A802C for ; Mon, 28 Apr 2014 12:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_72=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 jonOZLyVoFho for ; Mon, 28 Apr 2014 12:29:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id D87E31A7031 for ; Mon, 28 Apr 2014 12:29:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8A45A8D0; Mon, 28 Apr 2014 21:29:03 +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 6lv2WAJGyAn7; Mon, 28 Apr 2014 21:29: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; Mon, 28 Apr 2014 21:29:01 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D36A320017; Mon, 28 Apr 2014 21:29: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 Z5OlAcmqE6tR; Mon, 28 Apr 2014 21:28:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26EAB20013; Mon, 28 Apr 2014 21:28:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A161F2CC3178; Mon, 28 Apr 2014 21:28:57 +0200 (CEST) Date: Mon, 28 Apr 2014 21:28:56 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20140428192856.GA25535@elstar.local> Mail-Followup-To: philip.eardley@bt.com, bs7652@att.com, lmap@ietf.org References: <20140401132852.GA74000@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> <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> 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/ZwDHvvMYILQQQDtu9f4BhyTkIUQ Cc: 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: Mon, 28 Apr 2014 19:29:07 -0000 Phil, during the discussion, I heard two very different interpretations of 'suppression' and I think we need to pick between the two possible but fundamentally different interpretations: a) Suppressions means that (active) measurement tasks are not started anymore - so it is essentially a filter applied to the scheduler (analogous to commenting out scheduled (active) tasks). b) Suppression means a filter applied that drop the measurement traffic generated by measurement tasks. In this case, the scheduling is not really effected and measurement tasks keep getting started but the traffic they inject is filtered away. It seems that a) is just a short cut to temporarily change the scheduling while b) is really a different function since measurment tasks would have to come with appropriate filters that can suppress the traffic generated by the tasks. /js On Mon, Apr 28, 2014 at 05:26:21PM +0100, philip.eardley@bt.com wrote: > Not sure this discussion (about suppression) reached a conclusion. > > At the moment, the default is that suppression stops all new active measurement tasks and the impact on other tasks (including passive measurements and reporting) is left up to the implementation. > > Please re-start the discussion if you think this needs to be adjusted > > Thanks > phil > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: 02 April 2014 10:29 > > To: Eardley,PL,Philip,TUB8 R > > Cc: bs7652@att.com; lmap@ietf.org > > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- > > framework-04.txt > > > > Phil, > > > > I think what you have in mind (the mini firewall) is not exactly what I > > would understand from "must stop new active measurement tasks from > > starting". Your notion of suppressiong is blocking measurement traffic, > > you are not starting or stopping or not starting anything. > > > > If this is what suppression is meant to be (and I think this is close > > to Barbara's ideas), then we need to spell this out more clearly I > > think. > > > > Is it simple to implement? I think one would need for each measurement > > task a filter that can be injected and removed and the filters would > > have to be designed such that they do not cause side effects affecting > > other things going on. In other words, this sets up a requirement for > > measurement task implementations, not so much for the generic > > infrastructure (that would simply inject and remove such filters). > > > > Anyway, as useful as this might be, the current text seems to say > > something different. > > > > /js > > > > On Wed, Apr 02, 2014 at 10:06:45AM +0100, philip.eardley@bt.com wrote: > > > Can I suggest we discuss S5.2.1.1 first and get the definition of > > Suppression right after that. > > > > > > Just to confirm what the current 5.2.1.1 is intended to mean: > > > Suppression must stop new active measurement tasks from starting. > > > The impact is undefined (left to the implementer /deployer) on other > > things like passive measurement tasks and on-going active tasks. > > > Suppression is intended to be temporary - if you want to stop all the > > > active tasks permanently, then it's suggested you send a new schedule > > > [but I guess there's nothing to stop you 'abusing' suppression as a > > > permanent stop] > > > > > > 5.2.1.1 doesn't talk about the impact on Data Transfer Tasks. Not > > sure we've discussed this. I suppose at the moment the implication is > > that Data Transfer Tasks (including reporting) continues to run. > > > > > > -- > > > > > > In terms of implementation, the way I thought about it is that the MA > > would have a mini-firewall that would block all outgoing traffic > > associated with a measurement task; there's at least some traffic it > > mustn't block, such as capabilities & logging info sent in response to > > a request from the controller. Is this easy to implement? > > > I don't think the MA needs to understand any classification of > > different measurement tasks. However, the measurement system would > > probably like to understand the impact of this mini-firewall function > > for non-obvious cases like a measurement task that simply modifies the > > header of end-user traffic. > > > > > > -- > > > > > > > we can either introduce a classification of all measurement tasks > > > > (where is this coming from?) or we could make this explicit config > > > > (this way I know which tasks will be stopped if someone hits the > > > > button). > > > I don't like classification. This is work, requires extra state in > > controller and MA, and what happens if there's a classification > > mistake. > > > Explicit config. This basically means 'send a new schedule' (actually > > > my personal view but not the consensus) > > > > > > Phil > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > > university.de] > > > > Sent: 02 April 2014 06:56 > > > > To: STARK, BARBARA H > > > > Cc: Eardley,PL,Philip,TUB8 R; lmap@ietf.org > > > > Subject: Re: [lmap] FW: New Version Notification for > > > > draft-ietf-lmap- framework-04.txt > > > > > > > > Barbara, > > > > > > > > I disagree. If I hit the supression button, I like to know what the > > > > consequence of this is. Leaving this partially up to > > implementations > > > > is in my view the worst of all choices. Looking at the current ID, > > > > my understanding is that a suppression without parameters > > suppresses > > > > a certain set of measurement tasks, takes effect immediately, and > > > > supression ends when the unsuppress button is hit. I assume the > > > > suppress ongoing task bit defaults to false (but this is less > > > > clearly spelled out). > > > > > > > > To define the set of measurement tasks that is affected if no set > > is > > > > specified, we can either introduce a classification of all > > > > measurement tasks (where is this coming from?) or we could make > > this > > > > explicit config (this way I know which tasks will be stopped if > > > > someone hits the button). Both could work for me. But, a definition > > > > of 'a certain set of measurement tasks plus additional tasks that > > > > are implementation specific' is in my view not a desirable outcome. > > > > > > > > /js > > > > > > > > On Tue, Apr 01, 2014 at 06:34:00PM +0000, STARK, BARBARA H wrote: > > > > > > > I agree with you that "Active" does not belong in the > > definition. > > > > > > > I disagree > > > > > > that internal collection of passive measurements must cease, or > > > > that > > > > > > reporting must cease. They may cease in a particular > > > > implementation, > > > > > > but all implementations are not required to cause them to > > cease. > > > > > > Only originated measurement traffic must cease. > > > > > > > > > > > > I am having a problem with 'may in some implementations'. This > > > > > > is not interoperable. > > > > > > > > > > In my experience, it's impossible to define a function so > > > > > thoroughly > > > > that there are no unknowns about what it will do in a certain > > > > situation, and no decisions left up to the implementer. > > > > > > > > > > But let's say hypothetically that all collection of passive > > > > measurements *are* "stopped". We've defined internal measuring of > > > > CPU utilization and memory resources and general device health > > > > checking as "passive measurements". So this means they all have to > > > > stop. Firewall logging is a passive measurement. It must stop. Link > > > > resource utilization to be used in active queue management is a > > > > passive measurement. It must stop. But why is it an > > interoperability "issue" > > > > whether these passive measurement processes continue to run or not? > > > > I really don't understand how they impact interoperability. > > > > > > > > > > As for reporting, we've defined sending log info (e.g. > > measurement > > > > tasks successfully run, suppressed, etc.) to the Controller as a > > > > report. Let's say we expect Suppression to stop all reports. That > > > > means it must not send the Controller any logs. > > > > > > > > > > Anyway, I was illustrating just a few examples of unknowns wrt > > > > impacts of Suppression. There are many more unknowns. My proposed > > > > definition of Suppression has no 'may' statements. > > > > > > > > > > Suppression: the cessation of measurement traffic originated by > > > > > the > > > > MA. > > > > > > > > > > If we wanted to explicitly say that suppression shall not impact > > > > collection of passive measurements or reporting, I would be fine > > > > with that, since I think that's the better design and I think it's > > > > easily achieved. But others thought it would be complex to do and > > > > that it would be simpler for them to "kill all measurement tasks". > > > > As long as I'm not obliged to implement Suppression as "kill all > > > > tasks" I'm fine with giving others the freedom to do so in their > > implementations. > > > > > Barbara > > > > > > > > -- > > > > 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 -- 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 Apr 28 13:15: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 507CC1A064C for ; Mon, 28 Apr 2014 13:15:54 -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 rAmjgNObGfax for ; Mon, 28 Apr 2014 13:15:52 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 701401A03FC for ; Mon, 28 Apr 2014 13:15:52 -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 s3SKFj7R025791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Apr 2014 15:15:45 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id D81C01E0075; Mon, 28 Apr 2014 14:15:39 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id AD2F81E004D; Mon, 28 Apr 2014 14:15:39 -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 s3SKFdVU023114; Mon, 28 Apr 2014 15:15:39 -0500 (CDT) Received: from [10.141.78.119] (x1069818.dhcp.intranet [10.141.78.119]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s3SKFcN9023071; Mon, 28 Apr 2014 15:15:38 -0500 (CDT) Message-ID: <535EB6EA.5020402@centurylink.com> Date: Mon, 28 Apr 2014 14:15:38 -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, bs7652@att.com, lmap@ietf.org References: <20140401132852.GA74000@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130416792@GAALPA1MSGUSR9L.ITServices.sbc.com> <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> In-Reply-To: <20140428192856.GA25535@elstar.local> 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/whlIP5m-rR5cvelnUvhWlnpduSM 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: charles.cook2@centurylink.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:15:54 -0000 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 don't recall anything being said about what happens to a Measurement Task (that according to schedule) would be in process if a Suppression had not been received. I DO recall that IF the MA reports results of a Measurement Task that has been suppressed any time during its execution, the MA must report that the results are not valid. I don't recall that we specified that an MA needs to report Results if it has been impacted by a Suppression. At this stage, my interpretation is that it is an implementation choice of whether the MA continues to run Measurement Tasks (and does not let any generated traffic leak into the network) during a period of Suppression. So depending on implementation, filters may not be necessary. If we believe filtering is required, then we need to specify that. My belief is that the simpler the better. Charles On 4/28/2014 1:28 PM, Juergen Schoenwaelder wrote: > Phil, > > during the discussion, I heard two very different interpretations of > 'suppression' and I think we need to pick between the two possible but > fundamentally different interpretations: > > a) Suppressions means that (active) measurement tasks are not started > anymore - so it is essentially a filter applied to the scheduler > (analogous to commenting out scheduled (active) tasks). > > b) Suppression means a filter applied that drop the measurement > traffic generated by measurement tasks. In this case, the > scheduling is not really effected and measurement tasks keep > getting started but the traffic they inject is filtered away. > > It seems that a) is just a short cut to temporarily change the > scheduling while b) is really a different function since measurment > tasks would have to come with appropriate filters that can suppress > the traffic generated by the tasks. > > /js > > On Mon, Apr 28, 2014 at 05:26:21PM +0100, philip.eardley@bt.com wrote: >> Not sure this discussion (about suppression) reached a conclusion. >> >> At the moment, the default is that suppression stops all new active measurement tasks and the impact on other tasks (including passive measurements and reporting) is left up to the implementation. >> >> Please re-start the discussion if you think this needs to be adjusted >> >> Thanks >> phil >> >>> -----Original Message----- >>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- >>> university.de] >>> Sent: 02 April 2014 10:29 >>> To: Eardley,PL,Philip,TUB8 R >>> Cc: bs7652@att.com; lmap@ietf.org >>> Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- >>> framework-04.txt >>> >>> Phil, >>> >>> I think what you have in mind (the mini firewall) is not exactly what I >>> would understand from "must stop new active measurement tasks from >>> starting". Your notion of suppressiong is blocking measurement traffic, >>> you are not starting or stopping or not starting anything. >>> >>> If this is what suppression is meant to be (and I think this is close >>> to Barbara's ideas), then we need to spell this out more clearly I >>> think. >>> >>> Is it simple to implement? I think one would need for each measurement >>> task a filter that can be injected and removed and the filters would >>> have to be designed such that they do not cause side effects affecting >>> other things going on. In other words, this sets up a requirement for >>> measurement task implementations, not so much for the generic >>> infrastructure (that would simply inject and remove such filters). >>> >>> Anyway, as useful as this might be, the current text seems to say >>> something different. >>> >>> /js >>> >>> On Wed, Apr 02, 2014 at 10:06:45AM +0100, philip.eardley@bt.com wrote: >>>> Can I suggest we discuss S5.2.1.1 first and get the definition of >>> Suppression right after that. >>>> Just to confirm what the current 5.2.1.1 is intended to mean: >>>> Suppression must stop new active measurement tasks from starting. >>>> The impact is undefined (left to the implementer /deployer) on other >>> things like passive measurement tasks and on-going active tasks. >>>> Suppression is intended to be temporary - if you want to stop all the >>>> active tasks permanently, then it's suggested you send a new schedule >>>> [but I guess there's nothing to stop you 'abusing' suppression as a >>>> permanent stop] >>>> >>>> 5.2.1.1 doesn't talk about the impact on Data Transfer Tasks. Not >>> sure we've discussed this. I suppose at the moment the implication is >>> that Data Transfer Tasks (including reporting) continues to run. >>>> -- >>>> >>>> In terms of implementation, the way I thought about it is that the MA >>> would have a mini-firewall that would block all outgoing traffic >>> associated with a measurement task; there's at least some traffic it >>> mustn't block, such as capabilities & logging info sent in response to >>> a request from the controller. Is this easy to implement? >>>> I don't think the MA needs to understand any classification of >>> different measurement tasks. However, the measurement system would >>> probably like to understand the impact of this mini-firewall function >>> for non-obvious cases like a measurement task that simply modifies the >>> header of end-user traffic. >>>> -- >>>> >>>>> we can either introduce a classification of all measurement tasks >>>>> (where is this coming from?) or we could make this explicit config >>>>> (this way I know which tasks will be stopped if someone hits the >>>>> button). >>>> I don't like classification. This is work, requires extra state in >>> controller and MA, and what happens if there's a classification >>> mistake. >>>> Explicit config. This basically means 'send a new schedule' (actually >>>> my personal view but not the consensus) >>>> >>>> Phil >>>> >>>>> -----Original Message----- >>>>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- >>>>> university.de] >>>>> Sent: 02 April 2014 06:56 >>>>> To: STARK, BARBARA H >>>>> Cc: Eardley,PL,Philip,TUB8 R; lmap@ietf.org >>>>> Subject: Re: [lmap] FW: New Version Notification for >>>>> draft-ietf-lmap- framework-04.txt >>>>> >>>>> Barbara, >>>>> >>>>> I disagree. If I hit the supression button, I like to know what the >>>>> consequence of this is. Leaving this partially up to >>> implementations >>>>> is in my view the worst of all choices. Looking at the current ID, >>>>> my understanding is that a suppression without parameters >>> suppresses >>>>> a certain set of measurement tasks, takes effect immediately, and >>>>> supression ends when the unsuppress button is hit. I assume the >>>>> suppress ongoing task bit defaults to false (but this is less >>>>> clearly spelled out). >>>>> >>>>> To define the set of measurement tasks that is affected if no set >>> is >>>>> specified, we can either introduce a classification of all >>>>> measurement tasks (where is this coming from?) or we could make >>> this >>>>> explicit config (this way I know which tasks will be stopped if >>>>> someone hits the button). Both could work for me. But, a definition >>>>> of 'a certain set of measurement tasks plus additional tasks that >>>>> are implementation specific' is in my view not a desirable outcome. >>>>> >>>>> /js >>>>> >>>>> On Tue, Apr 01, 2014 at 06:34:00PM +0000, STARK, BARBARA H wrote: >>>>>>>> I agree with you that "Active" does not belong in the >>> definition. >>>>>>>> I disagree >>>>>>> that internal collection of passive measurements must cease, or >>>>> that >>>>>>> reporting must cease. They may cease in a particular >>>>> implementation, >>>>>>> but all implementations are not required to cause them to >>> cease. >>>>>>> Only originated measurement traffic must cease. >>>>>>> >>>>>>> I am having a problem with 'may in some implementations'. This >>>>>>> is not interoperable. >>>>>> In my experience, it's impossible to define a function so >>>>>> thoroughly >>>>> that there are no unknowns about what it will do in a certain >>>>> situation, and no decisions left up to the implementer. >>>>>> But let's say hypothetically that all collection of passive >>>>> measurements *are* "stopped". We've defined internal measuring of >>>>> CPU utilization and memory resources and general device health >>>>> checking as "passive measurements". So this means they all have to >>>>> stop. Firewall logging is a passive measurement. It must stop. Link >>>>> resource utilization to be used in active queue management is a >>>>> passive measurement. It must stop. But why is it an >>> interoperability "issue" >>>>> whether these passive measurement processes continue to run or not? >>>>> I really don't understand how they impact interoperability. >>>>>> As for reporting, we've defined sending log info (e.g. >>> measurement >>>>> tasks successfully run, suppressed, etc.) to the Controller as a >>>>> report. Let's say we expect Suppression to stop all reports. That >>>>> means it must not send the Controller any logs. >>>>>> Anyway, I was illustrating just a few examples of unknowns wrt >>>>> impacts of Suppression. There are many more unknowns. My proposed >>>>> definition of Suppression has no 'may' statements. >>>>>> Suppression: the cessation of measurement traffic originated by >>>>>> the >>>>> MA. >>>>>> If we wanted to explicitly say that suppression shall not impact >>>>> collection of passive measurements or reporting, I would be fine >>>>> with that, since I think that's the better design and I think it's >>>>> easily achieved. But others thought it would be complex to do and >>>>> that it would be simpler for them to "kill all measurement tasks". >>>>> As long as I'm not obliged to implement Suppression as "kill all >>>>> tasks" I'm fine with giving others the freedom to do so in their >>> implementations. >>>>>> Barbara >>>>> -- >>>>> 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 -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com From nobody Mon Apr 28 13:23: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 988A01A710D for ; Mon, 28 Apr 2014 13:23: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 EkXUBWq4jzx6 for ; Mon, 28 Apr 2014 13:23:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 766951A6FBA for ; Mon, 28 Apr 2014 13:23: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 724C4A9D; Mon, 28 Apr 2014 22:23:39 +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 Tv-Cu9keBjOE; Mon, 28 Apr 2014 22:23:38 +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, 28 Apr 2014 22:23:38 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C786B20017; Mon, 28 Apr 2014 22:23:38 +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 smE0z3WSM5fX; Mon, 28 Apr 2014 22:23:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5E4B20013; Mon, 28 Apr 2014 22:23:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CCF462CC3370; Mon, 28 Apr 2014 22:23:35 +0200 (CEST) Date: Mon, 28 Apr 2014 22:23:35 +0200 From: Juergen Schoenwaelder To: Charles Cook Message-ID: <20140428202335.GF25535@elstar.local> Mail-Followup-To: Charles Cook , philip.eardley@bt.com, bs7652@att.com, lmap@ietf.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535EB6EA.5020402@centurylink.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/q6edcyCuooeOqZnrcBOUTc1gaoU Cc: philip.eardley@bt.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 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, 28 Apr 2014 20:23:42 -0000 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 From nobody Tue Apr 29 01:13: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 9019E1A0774 for ; Tue, 29 Apr 2014 01:13:31 -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 1FM2JeCOv7ZQ for ; Tue, 29 Apr 2014 01:13:29 -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 D1E971A076C for ; Tue, 29 Apr 2014 01:13:28 -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 82f5f535.2b5fe168e940.5534146.00-2497.15485814.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 29 Apr 2014 08:13:28 +0000 (UTC) X-MXL-Hash: 535f5f285be5a4d0-c78749b6568fc6b08643e0d0b8450dbcfcc4e048 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 42f5f535.0.5534140.00-2014.15485788.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 29 Apr 2014 08:13:26 +0000 (UTC) X-MXL-Hash: 535f5f2602492d5a-3c3f2b56f8cee41b7f8549f6dd403af4d02a22c3 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 s3T8DOjQ024836; Tue, 29 Apr 2014 04:13:24 -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 s3T8DHu9024795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 04:13:21 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (GAALPA1MSGHUB9D.itservices.sbc.com [130.8.36.90]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 29 Apr 2014 08:13:03 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; Tue, 29 Apr 2014 04:13:03 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: framework comments Thread-Index: Ac9cl9SeoAXxoO+sT62j3uhhwzLuTwBfuc6wASn/ldA= Date: Tue, 29 Apr 2014 08:13:03 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130429D2C@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61130425DAF@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.249.32] 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=dnkKX9xZHAQA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=Ce7U-UY3P] X-AnalysisOut: [0ka4JPOCYkA:9 a=CjuIK1q_8ugA:10 a=twXrSuDpzK1IF1xf:21 a=c9] X-AnalysisOut: [3dA7NJeLkErpOb:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/BBt0K5xgdtp1uqAkZ_Y4-slKEPg 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, 29 Apr 2014 08:13:31 -0000 Hi Phil. Snipping out parts where I have nothing else to say and I agree with what y= ou propose. Barbara > > 2. Location of MA: This framework seems to assume the MA is always > > within a customer premises network. Is that necessarily true? > > Use-cases doesn't seem to indicate this. For example, in the case > > where measurements are done in an ONT (fiber termination point, which > > may be dedicated to a single subscriber or serve many in a MDU), the > > MA would be fully within the ISP network. Or it could be in a DSLAM > > and not specific to a single subscriber. If we consider the > > non-regulatory, ISP-controlled, trouble-shooting use case (which I > > thought was included in scope and is described in use-cases) then it > > doesn't seem like an MA > > *always* is associated with a single subscriber. But this case does > > not seem to be covered by this framework, because there are many > > statements that assume MA-to-subscriber association is part of the > > basic framework. Note that BBF use of MA does not restrict it to being > > internal to or at edge of subscriber network, or to having a necessary > > subscriber relationship. Following > > are some statements where I would recommend expanding the > > description to include elements outside the customer premises: > > 1. Introduction: "These devices could be software based agents on PCs, > > embedded agents in consumer devices (e.g. blu-ray players), service > > provider controlled devices such as set-top players and home gateways, > > or simply dedicated probes." > > 6.2. Measurement Agent [this section should have examples of MAs > > located elsewhere in ISP networks and such.] >=20 > [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 b= e > very helpful. Yes, I'll propose some additional text. I'll do that in a separate em= ail later this week. > > ---------------------------------------------- > > 3. Terminology > > Subscriber: An entity (associated with one or more users) that is > > engaged in a subscription with a service provider. The Subscriber > > is > > allowed to subscribe and un-subscribe services, and to register a > > user or a list of users authorized to enjoy these services. > > [Q1741]. > > Both the Subscriber and service provider are allowed to set the > > limits relative to the use that associated users make of subscribed > > services. > > Comment: The reference is to a 3GPP document and the last 2 sentences > > are very 3GPP-specific and not relevant to the concept of a wireline > > subscriber. I recommend deleting the last 2 sentences from this > > definition. >=20 > [phil] I think the definition is copied from Q.1741. personally am ok wit= h > deleting the last 2 sentences. Right, I see that Q.1741 is not a 3GPP document -- it's an ITU-T docu= ment entitled "GSM-evolved UMTS core network". I would still prefer to dele= te the last 2 sentences, but if others want to propose modifying them to in= dicate that they *may* be true, that could be ok, too. =20 =20 > > ....... > > 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. >=20 > [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 a= s to what others think. >=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. >=20 > 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 Contro= l > Protocol info. Or the "underlying" layer may be push or even multicast. >=20 > "transport" didn't mean layer 4 but something transporting the LMAP info. >=20 > 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 (ef= fectively 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.=20 However, http does not necessarily imply "Pull". Just because 2 endpoints a= re in a client/server relationship for a Control or Report Protocol, doesn'= t mean that they maintain that same client/server relationship as it relate= s 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 purpos= e of sending a "connect to your config server ASAP" message. But only the T= R-069 client can initiate a http session for purpose of receiving configura= tion info (in which case the TR-069 client is the http client and the TR-06= 9 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 def= ines 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".=20 I agree that multicast is inherited. > > ....................................................................... > > ..... > > 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)? >=20 > [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, whic= h was why I very much agreed with the "one Controller" restriction. But we = have a lot of experience in coordinating between person-directed local conf= iguration and remote automated configuration on various devices. Which is w= hy I don't see it necessary to forbid this. > > 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? >=20 > [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 multipl= e 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 outboun= d TCP and UDP packets. Because pinholes configured through PCP and UPnP IG= D do expire after a while, and are created on an "as needed" basis, they te= nd 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 t= o: The Measurement Agent could also be embedded behind a NAT, a stateful-packet inspection firewall, or both. In this case the Controlle= r may not be able to unilaterally contact the Measurement Agent unless configured or dynamicall= y-generated pinholes exist. =20 Protocols such as PCP [RFC6887], CWMP [TR-069] or UPnP IGD [UPnP IGD] can be used to configure pinholes. For pinholes that are dynam= ically-generated as a result of outbound TCP or UDP packets,=20 the Measurement Agent could send keepalives, such as those of the STUN protocol [STUN], towards the Co= ntroller 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 protoc= ol described in TR-069 "CWMP". =20 > > -------------------------------- > > 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 ,..." >=20 > [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-generat= ed Active Measurement traffic to be user traffic. For MAs located outside t= he customer premises, it is also possible for an ISP to measure management = traffic (between its network elements and systems). From nobody Tue Apr 29 03:31: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 CD3A31A0762 for ; Tue, 29 Apr 2014 03:31:31 -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 y3kznP8zrYpM for ; Tue, 29 Apr 2014 03:31:29 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id BE6C91A014C for ; Tue, 29 Apr 2014 03:31:28 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 29 Apr 2014 11:31:33 +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, 29 Apr 2014 11:31:24 +0100 From: To: , Date: Tue, 29 Apr 2014 11:31:23 +0100 Thread-Topic: framework comments Thread-Index: Ac9cl9SeoAXxoO+sT62j3uhhwzLuTwBfuc6wASn/ldAANLjhAA== Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130429D2C@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130429D2C@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/VSyb1YmFECaQzHJcyW8UaE6Zqlo 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, 29 Apr 2014 10:31:31 -0000 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. >=20 > 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. >=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? >=20 > 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. >=20 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 exa= mple, 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. >=20 > 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. >=20 > > > 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" >=20 > 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). >=20 > I recommend referencing UPnP IGD, and not just UPnP. And calling the > protocol described in TR-069 "CWMP". Wfm. Thanks for the text. >=20 > > > -------------------------------- > > > 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") >=20 > 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. From nobody Tue Apr 29 05:11: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 A0DC81A078B for ; Tue, 29 Apr 2014 05:11:37 -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 Mz_gQc0caFdC for ; Tue, 29 Apr 2014 05:11:32 -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 1E82A1A06D7 for ; Tue, 29 Apr 2014 05:11:32 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 67312120152; Tue, 29 Apr 2014 08:12:14 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-azure.research.att.com (Postfix) with ESMTP id E6ED1E01E7; Tue, 29 Apr 2014 08:11:30 -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; Tue, 29 Apr 2014 08:11:30 -0400 From: "MORTON, ALFRED C (AL)" To: "philip.eardley@bt.com" , "STARK, BARBARA H" , "lmap@ietf.org" Date: Tue, 29 Apr 2014 08:11:26 -0400 Thread-Topic: framework comments Thread-Index: Ac9cl9SeoAXxoO+sT62j3uhhwzLuTwBfuc6wASn/ldAANLjhAAAENXkA Message-ID: <2845723087023D4CB5114223779FA9C801795CCC8E@njfpsrvexg8.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E61130425DAF@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130429D2C@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/PG_VERZPdJ8mVSNsB2X69pdaCa8 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, 29 Apr 2014 12:11:37 -0000 comments on the last point: > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: Tuesday, April 29, 2014 6:31 AM > To: STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] framework comments >=20 ... > > > > -------------------------------- > > > > 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). >=20 > Good point. >=20 > Thanks > Phil. >=20 When active measurement traffic is only observed (passively), we call that = a *hybrid* measurement, a combination of active and passive. In the IPPM working group discussions (the registry, new metrics, etc.) we keep=20 active and passive measurements at opposite ends of the continuum and the various combinations which are between the ends are hybrid measurem= ents. We're talking about pure passive measurements here, and we've currently clarified the text like this: Passive Measurement Tasks are conducted on one or more user's traffic,=20 such that sensitive information is present and stored in the=20 measurement system (however briefly this storage may be). hope this helps (but we may need to mention hybrid measurements here now, like we added recently in the core registry draft). Al From nobody Tue Apr 29 08:55: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 4BD291A0922 for ; Tue, 29 Apr 2014 08:55:29 -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 rHcb2Kco35Z0 for ; Tue, 29 Apr 2014 08:55:26 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 48EF11A08DB for ; Tue, 29 Apr 2014 08:55:26 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s3TFtJrC009848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 09:55:19 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id EE32E1E007D; Tue, 29 Apr 2014 09:55:13 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id D2EAE1E006B; Tue, 29 Apr 2014 09:55:13 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s3TFtDWd020058; Tue, 29 Apr 2014 09:55:13 -0600 (MDT) Received: from [10.141.78.119] (x1069818.dhcp.intranet [10.141.78.119]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s3TFtCvw020034; Tue, 29 Apr 2014 09:55:13 -0600 (MDT) Message-ID: <535FCB60.9040304@centurylink.com> Date: Tue, 29 Apr 2014 09:55:12 -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> 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/8XO2lH_tziB_XA4ygaC_txvQTZ4 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: Tue, 29 Apr 2014 15:55:29 -0000 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 From nobody Wed Apr 30 03:37: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 60CD61A0744 for ; Wed, 30 Apr 2014 03:37: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_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 4_K4Spz5zFwJ for ; Wed, 30 Apr 2014 03:37:12 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 586D51A0118 for ; Wed, 30 Apr 2014 03:37:11 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 30 Apr 2014 11:34:15 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.49]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Wed, 30 Apr 2014 11:36:56 +0100 From: To: , Date: Wed, 30 Apr 2014 11:36:55 +0100 Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: Ac9jH776OEbVyROuTxyWAhzanYLWtABPtb9g Message-ID: 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> In-Reply-To: <20140428202335.GF25535@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/Txt2kU75pQ9kMs6Y-dALwMqup_s Cc: 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: Wed, 30 Apr 2014 10:37:20 -0000 I agree it would be better to have a precise definition of suppression. I a= gree that a) and b) are not completely the same.=20 I tend to favour a) - ie suppression means the task is not run. I think this is simpler and fits better with the information model.=20 For example, we talked about the idea of suppressing particular tasks (mayb= e ones that are generating a lot of traffic, or ones that are suspected of = having a bug) and suppressing a particular schedule (maybe one with less im= portant tasks) - a) fits better with that. Also, after our London discussio= ns, the information model will talk in terms of generic Tasks (which may be= measurements, data transfer tasks or even other sorts), so it makes sense = to suppress Tasks - then we get the choice (or not) of suppressing Reports = as well as active measurement tasks say. phil > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: 28 April 2014 21:24 > To: Charles Cook > Cc: Eardley,PL,Philip,TUB8 R; bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- > framework-04.txt >=20 > 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). > > >=20 > 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. >=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 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: 28 April 2014 20:29 To: Eardley,PL,Philip,TUB8 R Cc: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framew= ork-04.txt Phil, during the discussion, I heard two very different interpretations of 'suppr= ession' and I think we need to pick between the two possible but fundamenta= lly different interpretations: a) Suppressions means that (active) measurement tasks are not started anymore - so it is essentially a filter applied to the scheduler (analogous to commenting out scheduled (active) tasks). b) Suppression means a filter applied that drop the measurement traffic generated by measurement tasks. In this case, the scheduling is not really effected and measurement tasks keep getting started but the traffic they inject is filtered away. It seems that a) is just a short cut to temporarily change the scheduling w= hile b) is really a different function since measurment tasks would have to= come with appropriate filters that can suppress the traffic generated by t= he tasks. /js On Mon, Apr 28, 2014 at 05:26:21PM +0100, philip.eardley@bt.com wrote: > Not sure this discussion (about suppression) reached a conclusion. From nobody Wed Apr 30 05:18:50 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900181A6F5B for ; Wed, 30 Apr 2014 05:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=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 mVjO3YBLXsad for ; Wed, 30 Apr 2014 05:18:33 -0700 (PDT) Received: from p02c12o141.mxlogic.net (p02c12o141.mxlogic.net [208.65.145.74]) by ietfa.amsl.com (Postfix) with ESMTP id E8BE61A6F61 for ; Wed, 30 Apr 2014 05:18:32 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c12o141.mxlogic.net(mxl_mta-8.0.0-0) with ESMTP id 71ae0635.2ac653244940.74987.00-571.179954.p02c12o141.mxlogic.net (envelope-from ); Wed, 30 Apr 2014 06:18:31 -0600 (MDT) X-MXL-Hash: 5360ea17607a722e-d72632c8389beccb1c192d75033187e3e1e4fc80 Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c12o141.mxlogic.net(mxl_mta-8.0.0-0) over TLS secured channel with ESMTP id 449e0635.0.73480.00-373.176162.p02c12o141.mxlogic.net (envelope-from ); Wed, 30 Apr 2014 06:15:10 -0600 (MDT) X-MXL-Hash: 5360e94e51325401-990fd0050aa64bf154879954131406bde6c4be6d 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, 30 Apr 2014 07:15:00 -0500 From: KEN KO To: "philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" , "charles.cook2@centurylink.com" Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: AQHPTa5blgN1e9pGK0+mEIRlZdfeXJr9NyqAgAACDQCAAAXugIAAB7kAgAAjfACAAL53AIAANWGAgAAGNoCAKVE6gIAAMwQAgAANDACAAAI5gIACgMCA///HmnA= Date: Wed, 30 Apr 2014 12:14:59 +0000 Message-ID: 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> 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.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=OpTBykPt c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:17 a=Rl04TdHA3a4A:10 a=qZHQZMT3apYA:10 a=cRzl_kMyrCAA:10 ] X-AnalysisOut: [a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJ] X-AnalysisOut: [NrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtA] X-AnalysisOut: [AAA:8 a=J_N6KFswAAAA:8 a=zQP7CpKOAAAA:8 a=j3Z76cjpAAAA:8 a] X-AnalysisOut: [=Cx37VHcffI1-cfAQv2oA:9 a=uvqSV4iSdv9c3LAp:21 a=b5H4vZ8x4E] X-AnalysisOut: [0p_vxD:21 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtC] X-AnalysisOut: [QA:10 a=4CLKj2Bp5_UA:10 a=lZB815dzVvQA:10 a=W1qU_X6G3J8A:1] X-AnalysisOut: [0 a=zeshHG33Dl4A:10 a=Pwbduc0PQ3sA:10 a=Hz7IrDYlS0cA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014043006); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/StGEMaErO9lG5hXMhNgeh4Onpu0 Cc: "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: Wed, 30 Apr 2014 12:18:40 -0000 I favor a) as well. -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Wednesday, April 30, 2014 6:37 AM To: j.schoenwaelder@jacobs-university.de; charles.cook2@centurylink.com Cc: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framew= ork-04.txt I agree it would be better to have a precise definition of suppression. I a= gree that a) and b) are not completely the same.=20 I tend to favour a) - ie suppression means the task is not run. I think this is simpler and fits better with the information model.=20 For example, we talked about the idea of suppressing particular tasks (mayb= e ones that are generating a lot of traffic, or ones that are suspected of = having a bug) and suppressing a particular schedule (maybe one with less im= portant tasks) - a) fits better with that. Also, after our London discussio= ns, the information model will talk in terms of generic Tasks (which may be= measurements, data transfer tasks or even other sorts), so it makes sense = to suppress Tasks - then we get the choice (or not) of suppressing Reports = as well as active measurement tasks say. phil > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 > university.de] > Sent: 28 April 2014 21:24 > To: Charles Cook > Cc: Eardley,PL,Philip,TUB8 R; bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-=20 > framework-04.txt >=20 > 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=20 > > saying the same as what Juergen is saying in b), but my=20 > > understanding > is that: > > > > Default Suppression means that all Measurement Tasks that generate=20 > > traffic are suppressed (however the MA decides how to do that -=20 > > filtering at the MA so that no traffic is generated could be one way=20 > > to do it, cancelling the current instance of the Measurement Task=20 > > could be another way to do it). Schedules stay in place such that=20 > > if an un-Suppression is received, that a scheduled Measurement Task=20 > > will commence when the time comes (as long as the scheduled time for=20 > > the Measurement Task to be executed occurs after the un-Suppression=20 > > has been received). > > >=20 > I prefer to have a precise definition what suppression means. I can=20 > easily picture measurement tasks where leaving the task running while=20 > temporarily block the traffic leads to different results compared to=20 > stopping the task and restarting it later. In terms of the traffic=20 > generated during suppression, the result may be the same but a restart=20 > causes measurement task internal context information to get lost,=20 > which can be more disruptive to the measurement. >=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 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: 28 April 2014 20:29 To: Eardley,PL,Philip,TUB8 R Cc: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framew= ork-04.txt Phil, during the discussion, I heard two very different interpretations of 'suppr= ession' and I think we need to pick between the two possible but fundamenta= lly different interpretations: a) Suppressions means that (active) measurement tasks are not started anymore - so it is essentially a filter applied to the scheduler (analogous to commenting out scheduled (active) tasks). b) Suppression means a filter applied that drop the measurement traffic generated by measurement tasks. In this case, the scheduling is not really effected and measurement tasks keep getting started but the traffic they inject is filtered away. It seems that a) is just a short cut to temporarily change the scheduling w= hile b) is really a different function since measurment tasks would have to= come with appropriate filters that can suppress the traffic generated by t= he tasks. /js On Mon, Apr 28, 2014 at 05:26:21PM +0100, philip.eardley@bt.com wrote: > Not sure this discussion (about suppression) reached a conclusion. _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Apr 30 06:01: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 B82631A081B for ; Wed, 30 Apr 2014 06:01:37 -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_72=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 ChDSHE7VdsLR for ; Wed, 30 Apr 2014 06:01:33 -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 4E24F1A6F66 for ; Wed, 30 Apr 2014 06:01: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 c24f0635.2b5fa6a30940.6308439.00-2434.17649032.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 30 Apr 2014 13:01:32 +0000 (UTC) X-MXL-Hash: 5360f42c338dcdd9-37d5457395f41b4949c4a4580036e7716d904e40 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 f04f0635.0.6307870.00-2083.17647407.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 30 Apr 2014 13:01:05 +0000 (UTC) X-MXL-Hash: 5360f4110706730d-62f88b065efa2beccee3719f81fe1da0011433a3 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 s3UD12q7002190; Wed, 30 Apr 2014 09:01:03 -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 s3UD0tod001972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2014 09:00:57 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (GAALPA1MSGHUB9E.itservices.sbc.com [130.8.36.91]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 30 Apr 2014 13:00:49 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.03.0174.001; Wed, 30 Apr 2014 09:00:48 -0400 From: "STARK, BARBARA H" To: KEN KO , "philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" , "charles.cook2@centurylink.com" Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: AQHPTa5oNbL2T7afa0y+RLVxrVkjW5r82qXwgABNzwD//7/HIIAATeAA//++EYCAASPiAIAANWGAgAAGNoCAKVE6gIAAMwMAgAANDACAAAI5gIACgMCAgAAbZoD//8IlcA== Date: Wed, 30 Apr 2014 13:00:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113042A45E@GAALPA1MSGUSR9L.ITServices.sbc.com> 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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.158.198] 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: [=jB7aAHWnCvcA:10 a=ofMgfj31e3cA:10 a=ioxHA6Yf8nkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=eJNrpioGAAAA:8 a=e9qsufxtAAAA:8 a=J_N6KFswAAAA:8 ] X-AnalysisOut: [a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=c5Y57TvmBSSkhgLO6sUA:9] X-AnalysisOut: [ a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=4] X-AnalysisOut: [CLKj2Bp5_UA:10 a=DvnSUQUdWHYA:10 a=W1qU_X6G3J8A:10 a=zeshH] X-AnalysisOut: [G33Dl4A:10 a=Pwbduc0PQ3sA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS] X-AnalysisOut: [0cA:10 a=ub-iOD-wsEsAcAai:21 a=ZclwLHG4S2p7Jg6d:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/0Yoj8ZrcO9U1kVmYiKmgh0uDB1A Cc: "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: Wed, 30 Apr 2014 13:01:38 -0000 Just to quibble a bit. I dislike requirements that cannot be easily externally verified. So for me= , I don't care if processes run or don't run, or whether or not there are f= ilters. I care about whether I can see any external evidence of those proce= sses. For me, such external evidence is measurement traffic. If I can put a= sniffer outside the MA's device and see measurement traffic, then the meas= urement tasks causing that traffic are not being suppressed. If I've asked = for certain measurement tasks to be suppressed and I don't see any traffic = associated with those measurements, then I'm satisfied that the measurement= s have effectively been suppressed. I don't care if that was done by a filt= er or killing a process or causing a special part of the measurement task c= ode to run that runs only when suppression is invoked.=20 This is why I would prefer to define Suppression in terms of the external b= ehavior we expect to see (or not see) as opposed to internal ways of causin= g these external behaviors to occur. The goal of Suppression was to prevent (certain) measurement traffic. The o= riginal goal had nothing to do with internal processes or filters, and I'm = at a loss to understand why we care how external traffic is prevented. Barbara > From: KEN KO [mailto:KEN.KO@adtran.com] > Sent: Wednesday, April 30, 2014 8:15 AM > To: philip.eardley@bt.com; j.schoenwaelder@jacobs-university.de; > charles.cook2@centurylink.com > Cc: STARK, BARBARA H; lmap@ietf.org > Subject: RE: [lmap] FW: New Version Notification for draft-ietf-lmap- > framework-04.txt >=20 > I favor a) as well. >=20 > From: philip.eardley@bt.com >=20 > I agree it would be better to have a precise definition of suppression. I= agree > that a) and b) are not completely the same. >=20 > I tend to favour a) - ie suppression means the task is not run. >=20 > I think this is simpler and fits better with the information model. > For example, we talked about the idea of suppressing particular tasks > (maybe ones that are generating a lot of traffic, or ones that are suspec= ted of > having a bug) and suppressing a particular schedule (maybe one with less > important tasks) - a) fits better with that. Also, after our London discu= ssions, > the information model will talk in terms of generic Tasks (which may be > measurements, data transfer tasks or even other sorts), so it makes sense= to > suppress Tasks - then we get the choice (or not) of suppressing Reports a= s > well as active measurement tasks say. >=20 > phil >=20 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: 28 April 2014 21:24 > > To: Charles Cook > > Cc: Eardley,PL,Philip,TUB8 R; bs7652@att.com; lmap@ietf.org > > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- > > framework-04.txt > > > > 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 >=20 >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: 28 April 2014 20:29 > To: Eardley,PL,Philip,TUB8 R > Cc: bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- > framework-04.txt >=20 > Phil, >=20 > during the discussion, I heard two very different interpretations of > 'suppression' and I think we need to pick between the two possible but > fundamentally different interpretations: >=20 > a) Suppressions means that (active) measurement tasks are not started > anymore - so it is essentially a filter applied to the scheduler > (analogous to commenting out scheduled (active) tasks). >=20 > b) Suppression means a filter applied that drop the measurement > traffic generated by measurement tasks. In this case, the > scheduling is not really effected and measurement tasks keep > getting started but the traffic they inject is filtered away. >=20 > It seems that a) is just a short cut to temporarily change the scheduling= while > b) is really a different function since measurment tasks would have to co= me > with appropriate filters that can suppress the traffic generated by the t= asks. >=20 > /js >=20 > On Mon, Apr 28, 2014 at 05:26:21PM +0100, philip.eardley@bt.com wrote: > > Not sure this discussion (about suppression) reached a conclusion. >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Apr 30 06:14: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 28C161A6F82 for ; Wed, 30 Apr 2014 06:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=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 2jgiLo8Q67fM for ; Wed, 30 Apr 2014 06:14:39 -0700 (PDT) Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) by ietfa.amsl.com (Postfix) with ESMTP id BF42A1A6F77 for ; Wed, 30 Apr 2014 06:14:38 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p01c12o149.mxlogic.net(mxl_mta-8.0.0-0) with ESMTP id d37f0635.2abfab451940.99286.00-502.245521.p01c12o149.mxlogic.net (envelope-from ); Wed, 30 Apr 2014 07:14:37 -0600 (MDT) X-MXL-Hash: 5360f73d70e29021-3ba2f508d8b2a23be480a2f328ea89fa258ad37e Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p01c12o149.mxlogic.net(mxl_mta-8.0.0-0) over TLS secured channel with ESMTP id 8a6f0635.0.97944.00-255.241946.p01c12o149.mxlogic.net (envelope-from ); Wed, 30 Apr 2014 07:12:16 -0600 (MDT) X-MXL-Hash: 5360f6b078639001-a0f4d6a0bcd0fcebb6d6d00bcb9076acfa6269be 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, 30 Apr 2014 08:12:07 -0500 From: KEN KO To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" , "charles.cook2@centurylink.com" Thread-Topic: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: AQHPTa5blgN1e9pGK0+mEIRlZdfeXJr9NyqAgAACDQCAAAXugIAAB7kAgAAjfACAAL53AIAANWGAgAAGNoCAKVE6gIAAMwQAgAANDACAAAI5gIACgMCA///HmnCAAGCYgP//rqwg Date: Wed, 30 Apr 2014 13:12:06 +0000 Message-ID: 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> <2D09D61DDFA73D4C884805CC7865E6113042A45E@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113042A45E@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.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=b+88472x c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:17 a=Rl04TdHA3a4A:10 a=qZHQZMT3apYA:10 a=cRzl_kMyrCAA:10 ] X-AnalysisOut: [a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJ] X-AnalysisOut: [NrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=zQP7CpKOAAAA:8 a=e9qsufxtA] X-AnalysisOut: [AAA:8 a=J_N6KFswAAAA:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a] X-AnalysisOut: [=NQnjORC-4ByF0eP55OAA:9 a=4g-95Ts11n9YueAo:21 a=SgX5oU_-Wc] X-AnalysisOut: [WXSCne:21 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtC] X-AnalysisOut: [QA:10 a=4CLKj2Bp5_UA:10 a=Hz7IrDYlS0cA:10 a=W1qU_X6G3J8A:1] X-AnalysisOut: [0 a=zeshHG33Dl4A:10 a=Pwbduc0PQ3sA:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [DvnSUQUdWHYA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014043008); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/picB8hxRHEXoXDzqwgeqTTqJKfg Cc: "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: Wed, 30 Apr 2014 13:14:43 -0000 But to return to Juergen's mail ... if preventing the task entirely results= in one set of measurement results and simply suppressing traffic results i= n a different set, that is an externally verified difference. I think he ha= s a good point. -----Original Message----- From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Wednesday, April 30, 2014 9:01 AM To: KEN KO; philip.eardley@bt.com; j.schoenwaelder@jacobs-university.de; ch= arles.cook2@centurylink.com Cc: lmap@ietf.org Subject: RE: [lmap] FW: New Version Notification for draft-ietf-lmap-framew= ork-04.txt Just to quibble a bit. I dislike requirements that cannot be easily externally verified. So for me= , I don't care if processes run or don't run, or whether or not there are f= ilters. I care about whether I can see any external evidence of those proce= sses. For me, such external evidence is measurement traffic. If I can put a= sniffer outside the MA's device and see measurement traffic, then the meas= urement tasks causing that traffic are not being suppressed. If I've asked = for certain measurement tasks to be suppressed and I don't see any traffic = associated with those measurements, then I'm satisfied that the measurement= s have effectively been suppressed. I don't care if that was done by a filt= er or killing a process or causing a special part of the measurement task c= ode to run that runs only when suppression is invoked.=20 This is why I would prefer to define Suppression in terms of the external b= ehavior we expect to see (or not see) as opposed to internal ways of causin= g these external behaviors to occur. The goal of Suppression was to prevent (certain) measurement traffic. The o= riginal goal had nothing to do with internal processes or filters, and I'm = at a loss to understand why we care how external traffic is prevented. Barbara > From: KEN KO [mailto:KEN.KO@adtran.com] > Sent: Wednesday, April 30, 2014 8:15 AM > To: philip.eardley@bt.com; j.schoenwaelder@jacobs-university.de; > charles.cook2@centurylink.com > Cc: STARK, BARBARA H; lmap@ietf.org > Subject: RE: [lmap] FW: New Version Notification for draft-ietf-lmap-=20 > framework-04.txt >=20 > I favor a) as well. >=20 > From: philip.eardley@bt.com >=20 > I agree it would be better to have a precise definition of=20 > suppression. I agree that a) and b) are not completely the same. >=20 > I tend to favour a) - ie suppression means the task is not run. >=20 > I think this is simpler and fits better with the information model. > For example, we talked about the idea of suppressing particular tasks=20 > (maybe ones that are generating a lot of traffic, or ones that are=20 > suspected of having a bug) and suppressing a particular schedule=20 > (maybe one with less important tasks) - a) fits better with that.=20 > Also, after our London discussions, the information model will talk in=20 > terms of generic Tasks (which may be measurements, data transfer tasks=20 > or even other sorts), so it makes sense to suppress Tasks - then we=20 > get the choice (or not) of suppressing Reports as well as active measurem= ent tasks say. >=20 > phil >=20 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 > > university.de] > > Sent: 28 April 2014 21:24 > > To: Charles Cook > > Cc: Eardley,PL,Philip,TUB8 R; bs7652@att.com; lmap@ietf.org > > Subject: Re: [lmap] FW: New Version Notification for=20 > > draft-ietf-lmap- framework-04.txt > > > > 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=20 > > > saying the same as what Juergen is saying in b), but my=20 > > > understanding > > is that: > > > > > > Default Suppression means that all Measurement Tasks that generate=20 > > > traffic are suppressed (however the MA decides how to do that -=20 > > > filtering at the MA so that no traffic is generated could be one=20 > > > way to do it, cancelling the current instance of the Measurement=20 > > > Task could be another way to do it). Schedules stay in place such=20 > > > that if an un-Suppression is received, that a scheduled=20 > > > Measurement Task will commence when the time comes (as long as the=20 > > > scheduled time for the Measurement Task to be executed occurs=20 > > > after the un-Suppression has been received). > > > > > > > I prefer to have a precise definition what suppression means. I can=20 > > easily picture measurement tasks where leaving the task running=20 > > while temporarily block the traffic leads to different results=20 > > compared to stopping the task and restarting it later. In terms of=20 > > the traffic generated during suppression, the result may be the same=20 > > but a restart causes measurement task internal context information=20 > > 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 >=20 >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: 28 April 2014 20:29 > To: Eardley,PL,Philip,TUB8 R > Cc: bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-=20 > framework-04.txt >=20 > Phil, >=20 > during the discussion, I heard two very different interpretations of=20 > 'suppression' and I think we need to pick between the two possible but=20 > fundamentally different interpretations: >=20 > a) Suppressions means that (active) measurement tasks are not started > anymore - so it is essentially a filter applied to the scheduler > (analogous to commenting out scheduled (active) tasks). >=20 > b) Suppression means a filter applied that drop the measurement > traffic generated by measurement tasks. In this case, the > scheduling is not really effected and measurement tasks keep > getting started but the traffic they inject is filtered away. >=20 > It seems that a) is just a short cut to temporarily change the=20 > scheduling while > b) is really a different function since measurment tasks would have to=20 > come with appropriate filters that can suppress the traffic generated by = the tasks. >=20 > /js >=20 > On Mon, Apr 28, 2014 at 05:26:21PM +0100, philip.eardley@bt.com wrote: > > Not sure this discussion (about suppression) reached a conclusion. >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Apr 30 07:00: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 B70A81A08D0 for ; Wed, 30 Apr 2014 07:00:06 -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 CP5am7pO0Uzg for ; Wed, 30 Apr 2014 07:00:04 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 696121A08DC for ; Wed, 30 Apr 2014 07:00:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 97E4199; Wed, 30 Apr 2014 16:00: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 7RU5zt28dWYE; Wed, 30 Apr 2014 16:00: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, 30 Apr 2014 16:00:01 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B69620031; Wed, 30 Apr 2014 16:00: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 MzhBFMBjOBuv; Wed, 30 Apr 2014 16:00:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 633D020017; Wed, 30 Apr 2014 15:59:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 657BA2CC6122; Wed, 30 Apr 2014 15:59:58 +0200 (CEST) Date: Wed, 30 Apr 2014 15:59:57 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140430135957.GA31092@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , KEN KO , "philip.eardley@bt.com" , "charles.cook2@centurylink.com" , "lmap@ietf.org" References: <20140402055542.GA75833@elstar.local> <20140402092859.GA76386@elstar.local> <20140428192856.GA25535@elstar.local> <535EB6EA.5020402@centurylink.com> <20140428202335.GF25535@elstar.local> <2D09D61DDFA73D4C884805CC7865E6113042A45E@GAALPA1MSGUSR9L.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113042A45E@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Fk0QITbTwg511qeTS6RptA5Rd40 Cc: "philip.eardley@bt.com" , "charles.cook2@centurylink.com" , KEN KO , "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: Wed, 30 Apr 2014 14:00:06 -0000 On Wed, Apr 30, 2014 at 01:00:47PM +0000, STARK, BARBARA H wrote: > > The goal of Suppression was to prevent (certain) measurement > traffic. The original goal had nothing to do with internal processes > or filters, and I'm at a loss to understand why we care how external > traffic is prevented. Because the way it is implemented does impact the measurements. There can be a big difference between keeping the a measurement task running and merely suppressing its traffic and stopping and restarting a measurement task. If we assume that agreement is that supression affects the tasks running, then suppression is like a scheduled change of the scheduled tasks (and the generalization would be a scheduled change of any aspect of the 'instructions', that is, have named sets of instructions and a schedule that says which set is activated when - ok, we probably do not want to go there in LMAP 1.0). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103