From nobody Fri Oct 10 02:07: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 E14D61A6FC1 for ; Fri, 10 Oct 2014 02:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.686 X-Spam-Level: X-Spam-Status: No, score=-7.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tkya0ebwvTHd for ; Fri, 10 Oct 2014 02:07:08 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6821A7030 for ; Fri, 10 Oct 2014 02:07:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiENAAqhN1TGmAcV/2dsb2JhbABggmsjU1gEt28BAQEBAQEGkxMfCodNAoEIFgEBcQmEAwEBAQEDAQEBDyg0FwQCAQgNBAQBAQsUBQQHJwsUBwEBBQMCBBMIGogcAQyjE59hAQEBAQYBAQEBAQEBG4YgiXM4BoMngR4FkXmEQoh6hiWOAoI0gUNsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,690,1406606400"; d="scan'208";a="86444439" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Oct 2014 05:07:07 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Oct 2014 05:07:06 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 11:07:05 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [ippm] Document Action: 'A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance' to Informational RFC (draft-ietf-ippm-lmap-path-07.txt) Thread-Index: AQHP48fjMwdBVvX7OEqLI9CXGammepwpC3pg Date: Fri, 10 Oct 2014 09:07:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8C5CDB@AZ-FFEXMB04.global.avaya.com> References: <20141009134848.14423.76522.idtracker@ietfa.amsl.com> In-Reply-To: <20141009134848.14423.76522.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/UHOtWbbKQk2ndD78KUec6NAbHzQ Subject: [lmap] FW: [ippm] Document Action: 'A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance' to Informational RFC (draft-ietf-ippm-lmap-path-07.txt) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 09:07:10 -0000 > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of The IESG > Sent: Thursday, October 09, 2014 4:49 PM > To: IETF-Announce > Cc: ippm mailing list; ippm chair; RFC Editor > Subject: [ippm] Document Action: 'A Reference Path and Measurement > Points for Large-Scale Measurement of Broadband Performance' to > Informational RFC (draft-ietf-ippm-lmap-path-07.txt) >=20 > The IESG has approved the following document: > - 'A Reference Path and Measurement Points for Large-Scale Measurement > of > Broadband Performance' > (draft-ietf-ippm-lmap-path-07.txt) as Informational RFC >=20 > This document is the product of the IP Performance Metrics Working Group. >=20 > The IESG contact persons are Spencer Dawkins and Martin Stiemerling. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-ippm-lmap-path/ >=20 >=20 >=20 >=20 >=20 > Technical Summary >=20 > This document defines a reference path for Large-scale Measurement of > Broadband Access Performance (LMAP) and measurement points for > commonly used performance metrics. The methods for measurement > point > location may be applicable to similar measurement projects using the > extensions described here. >=20 > Working Group Summary >=20 > The document has had broad review within the IPPM and LMAP working > groups. Many comments were received during first WGLC resulting in a > substantial revision and a second WGLC. There is consensus within the > IPPM working group (including participants from LMAP) to publish the > document. >=20 > Document Quality >=20 > This document defines the reference path to be used in > metric definitions and provides other guidance on how to use and deplo= y > IPPM metrics in an LMAP context. >=20 > Personnel >=20 > The document shepherd is Brian Trammell. > The responsible Area Director is Spencer Dawkins. >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Fri Oct 10 12:43: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 CC5101ACF06 for ; Fri, 10 Oct 2014 12:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.15 X-Spam-Level: ** X-Spam-Status: No, score=2.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, 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 0u-Ks96jX28V for ; Fri, 10 Oct 2014 12:43:17 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 56DE01ACEF2 for ; Fri, 10 Oct 2014 12:43:17 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,693,1406606400"; d="scan'208,217";a="541595305" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 10 Oct 2014 15:38:24 -0400 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.33]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 10 Oct 2014 15:43:16 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Date: Fri, 10 Oct 2014 15:43:15 -0400 Thread-Topic: Interim Minutes Online Thread-Index: Ac/kwm9ijsdPUdZ7S0WZH/UcIgI8rg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D05DAF13372B2jasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/4k7QQGlirql1WRAe1RxJKBBnH5g Subject: [lmap] Interim Minutes Online X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Oct 2014 19:43:19 -0000 --_000_D05DAF13372B2jasonweiltwcablecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable LMAP, I have placed the notes from the Interim meeting on September 15th online. = For this session we experimented with tag-team notetakers so that one perso= n wasn=92t stuck with the job throughout the entire session. If any of the = notetakers want to provide corrections or other members have questions with= the notes feel free to let me know. The minutes can be found here: http://www.ietf.org/proceedings/interim/2014= /09/15/lmap/minutes/minutes-interim-2014-lmap-1 Thanks, Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D05DAF13372B2jasonweiltwcablecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
LMAP,

I have placed the notes from the Interim meeting on September 15th onl= ine. For this session we experimented with tag-team notetakers so that one = person wasn=92t stuck with the job throughout the entire session. If any of= the notetakers want to provide corrections or other members have questions with the notes feel free to let me know.


Thanks,

Jason

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_D05DAF13372B2jasonweiltwcablecom_-- From nobody Tue Oct 14 03:09:33 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CE61A701D for ; Tue, 14 Oct 2014 03:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.686 X-Spam-Level: X-Spam-Status: No, score=-7.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSty6S3t8pXK for ; Tue, 14 Oct 2014 03:09:29 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603111A7023 for ; Tue, 14 Oct 2014 03:09:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApALANH1PFSHCzIm/2dsb2JhbABbgmsjU1gEgwK1bJM8h00CG3oWAQFxC4QCAQEBAQIBEhERUQQCAQgNBAQBAQMCBgsSAwICAjAUAQYBAQUDAgQTCAwOiBQIAQymIYpPlQ8BAQEBAQUBAQEBAQEBAQEZgSyEdIZnglwRAR84BgSCbTaBHgWReYRCgXaGSDyDCoMbhEWFP4N+g3dsgQ85gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,716,1406606400"; d="scan'208";a="89646638" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 Oct 2014 06:09:27 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 14 Oct 2014 06:09:26 -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; Tue, 14 Oct 2014 12:09:25 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: NOMCOM 2014 - nominations extended for RAI, OAM, TSV and INT - Oct 20 Thread-Index: AQHP5vcgEP1T24P/1kyFKwj3wTVzPJwvX1aQ Date: Tue, 14 Oct 2014 10:09:25 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8CB443@AZ-FFEXMB04.global.avaya.com> References: <20141013150506.31387.47470.idtracker@ietfa.amsl.com> In-Reply-To: <20141013150506.31387.47470.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/QBP70S2WJLoSTzq1OJC8fD5_xZ0 Subject: [lmap] FW: NOMCOM 2014 - nominations extended for RAI, OAM, TSV and INT - Oct 20 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Oct 2014 10:09:32 -0000 QSBtZXNzYWdlIGZyb20gdGhlIE5PTUNPTSBjaGFpci4gUGxlYXNlIGNvbnNpZGVyIGhlbHBpbmcg Tk9NQ09NIGluIHRoZWlyIGltcG9ydGFudCB0YXNrLiANCg0KUmVnYXJkcywNCg0KRGFuDQoNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpZXRmIFttYWlsdG86aWV0Zi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTm9tQ29tIENoYWlyIDIwMTQNCj4gU2VudDog TW9uZGF5LCBPY3RvYmVyIDEzLCAyMDE0IDY6MDUgUE0NCj4gVG86IFdvcmtpbmcgR3JvdXAgQ2hh aXJzDQo+IENjOiBpZXRmQGlldGYub3JnDQo+IFN1YmplY3Q6IE5PTUNPTSAyMDE0IC0gbm9taW5h dGlvbnMgZXh0ZW5kZWQgZm9yIFJBSSwgT0FNLCBUU1YgYW5kIElOVCAtDQo+IE9jdCAyMA0KPiAN Cj4ge2Fwb2xvZ2llcyBpZiB5b3Ugc2VlIHRoaXMgbXVsdGlwbGUgdGltZXN9DQo+IA0KPiBUaGUg MjAxNC0xNSBOb21pbmF0aW5nIENvbW1pdHRlZSAoTm9tY29tKSB3aWxsIHN0aWxsIGFjY2VwdCBu b21pbmF0aW9ucw0KPiBmcm9tIG5vdyB1bnRpbCBPY3RvYmVyIDIwLCAyMDE0IEFUIE1JRE5JR0hU IEVEVCBmb3IgdGhlIElFU0cgcG9zaXRpb25zIG9mDQo+IEFyZWEgRGlyZWN0b3IgZm9yOg0KPiAg ICAtIFJBSSAtIDINCj4gICAgLSBPQU0gLSAxDQo+ICAgIC0gVFNWIC0gMQ0KPiAgICAtIElOVCAt IDINCj4gICAgLSBHRU4gLSAxICAgIChJRVRGIENoYWlyKQ0KPiANCj4gYXJlYS4gIFdoaWxlIGlu IGVhY2ggY2FzZSB3ZSBoYXZlIGFuIGluY3VtYmVudCB3aG8gaXMgd2lsbGluZyB0byBjb250aW51 ZSwNCj4gYW5kIGluIHR3byBvZiB0aG9zZSBhcmVhcyB3ZSBoYXZlIG9uZSBhZGRpdGlvbmFsIGNh bmRpZGF0ZTsgd2Ugd291bGQgZGVhcmx5DQo+IGxpa2UgdG8gYmUgYmUgc2VsZWN0aW5nIGZyb20g YSBzbGlnaHRseSBsYXJnZXIgZmllbGQuDQo+IA0KPiBJdCBpcyBpbXBvc3NpYmxlIGZvciB0aGUg Tk9NQ09NIHRvIGJlIHN1cmUgdGhhdCB3ZSBoYXZlIHRoZSBiZXN0IGNhbmRpZGF0ZQ0KPiBpZiB3 ZSBoYXZlIG9ubHkgb25lIHBvc3NpYmxlIGNhbmRpZGF0ZS4gRXZlbiBpZiB0aGUgeW91IHRoaW5r IHRoZSBpbmN1bWJlbnQNCj4gaXMgdGhlIGJlc3QgcGVyc29uIGZvciB0aGUgam9iLCBpdCBpcyBp bXBvcnRhbnQsIGlmIG9ubHkgZm9yIHN1Y2Nlc3Npb24gcGxhbm5pbmcsDQo+IHRvIGtub3cgd2hv IGVsc2UgY291bGQgZG8gdGhlIGpvYi4NCj4gDQo+IEF0IGxlYXN0IG9uZSBvZiB0aGVzZSBpbmN1 bWJlbnRzIGhhdmUgc2FpZCBjbGVhcmx5IHRoYXQgdGhpcyByZWFsbHkgaGFzIGJlY29tZQ0KPiBh IDUwJSBjb21taXRtZW50IG9mIGEgNDAgaG91ciB3ZWVrLCBpLmUuIGl0IGlzIHBvc3NpYmxlIHRv IGRvIHNpZ25pZmljYW50IHdvcmsNCj4gb24gYSAiZGF5IGpvYiINCj4gDQo+IEZvciB0aGUgYWJv dmUgZml2ZSBwb3NpdGlvbnMgdGhlcmUgYXJlIDkgbm9taW5lZXMgd2hvIGhhdmUgbmVpdGhlcg0K PiBhY2NlcHRlZCBub3IgZGVjbGluZWQuICBJZiB5b3Ugbm9taW5hdGVkIHNvbWVvbmUgYW5kIHRo ZWlyIG5hbWUgZG9lcyBub3QNCj4gYXBwZWFyIGF0Og0KPiAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9ub21jb20vMjAxNC9mZWVkYmFjay8gDQo+IHRoYXQncyBiZWNhdXNlIHRoZXkgaGF2 ZSBlaXRoZXIgZGVjbGluZWQsIG9yIHRoZXkgaGF2ZSBub3QgaW5kaWNhdGVkDQo+IHRoaW5ncyBv bmUgd2F5IG9yIG90aGVyLiAgIFBlcmhhcHMgdGhleSBhcmUgc3RpbGwgZGVjaWRpbmcsIG9yIHBl cmhhcHMNCj4gdGhleSBuZXZlciBnb3QgdGhlIGVtYWlsLCB5b3UgY2FuIGhlbHAgdGhlIG5vbWNv bSBieSBjb25maXJtaW5nIHdpdGgNCj4gdGhlbS4NCj4gDQo+ID09PT0NCj4gDQo+IE5vbWluYXRp b25zIG1heSBiZSBtYWRlIGJ5IHNlbGVjdGluZyB0aGUgTm9taW5hdGUgbGluayBhdCB0aGUgdG9w IG9mIHRoZQ0KPiBOb21jb20gMjAxNCBob21lIHBhZ2UsIG9yIGJ5IHZpc2l0aW5nIHRoZSBmb2xs b3dpbmcgVVJMOg0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAx NC9ub21pbmF0ZS8NCj4gDQo+ICAge05vdGUgdGhhdCBub21pbmF0aW9ucyBtYWRlIHVzaW5nIHRo ZSB3ZWIgdG9vbCByZXF1aXJlIGFuIGlldGYub3JnDQo+ICAgIGRhdGF0cmFja2VyIGFjY291bnQu IFlvdSBjYW4gY3JlYXRlIGEgZGF0YXRyYWNrZXIgaWV0Zi5vcmcgYWNjb3VudA0KPiAgICBpZiB5 b3UgZG9uJ3QgaGF2ZSBvbmUgYWxyZWFkeSBieSB2aXNpdGluZyB0aGUgZm9sbG93aW5nIFVSTDoN Cj4gICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9hY2NvdW50cy9jcmVhdGUvIH0N Cj4gDQo+IE5vbWluYXRpb25zIG1heSBhbHNvIGJlIG1hZGUgYnkgZW1haWwgdG8gbm9tY29tMTRA aWV0Zi5vcmcuDQo+IA0KPiBJZiB1c2UgZW1haWwsIHBsZWFzZSBpbmNsdWRlIHRoZSB3b3JkICJO b21pbmF0ZSIgaW4gdGhlIFN1YmplY3QgYW5kIGluZGljYXRlDQo+IGluIHRoZSBlbWFpbCB3aG8g aXMgYmVpbmcgbm9taW5hdGVkLCB0aGVpciBlbWFpbCBhZGRyZXNzICh0byBjb25maXJtDQo+IGFj Y2VwdGFuY2Ugb2YgdGhlIG5vbWluYXRpb24pLCBhbmQgdGhlIHBvc2l0aW9uIGZvciB3aGljaCB5 b3UgYXJlIG1ha2luZw0KPiB0aGUgbm9taW5hdGlvbi4gSWYgeW91IHdpc2ggdG8gbm9taW5hdGUg c29tZW9uZSB2aWEgZW1haWwgZm9yIG1vcmUgdGhhbg0KPiBvbmUgcG9zaXRpb24sIHBsZWFzZSB1 c2Ugc2VwYXJhdGUgZW1haWxzIHRvIGRvIHNvLg0KPiANCj4gU2VsZi1ub21pbmF0aW9uIGlzIHdl bGNvbWUhDQo+IA0KPiBOb21Db20gMjAxNC0xNSB3aWxsIGZvbGxvdyB0aGUgcG9saWN5IGZvciAi T3BlbiBEaXNjbG9zdXJlIG9mIFdpbGxpbmcNCj4gTm9taW5lZXMiIGRlc2NyaWJlZCBpbiBSRkMg NTY4MC4gIEFzIHN0YXRlZCBpbiBSRkMgNTY4MDogIlRoZSBsaXN0IG9mDQo+IG5vbWluZWVzIHdp bGxpbmcgdG8gYmUgY29uc2lkZXJlZCBmb3IgcG9zaXRpb25zIHVuZGVyIHJldmlldyBpbiB0aGUg Y3VycmVudA0KPiBOb21jb20gY3ljbGUgaXMgbm90IGNvbmZpZGVudGlhbCIuIFdpbGxpbmcgbm9t aW5lZXMgZm9yIGVhY2ggcG9zaXRpb24gd2lsbCBiZQ0KPiBsaXN0ZWQgaW4gYSBwdWJsaWNseSBh Y2Nlc3NpYmxlIHdheSAtIGFueW9uZSB3aXRoIGEgZGF0YXRyYWNrZXIgYWNjb3VudCBtYXkNCj4g YWNjZXNzIHRoZSBsaXN0cy4gIEluIGFsbCBvdGhlciB3YXlzLCB0aGUgY29uZmlkZW50aWFsaXR5 IHJlcXVpcmVtZW50cyBvZiBSRkMNCj4gMzc3Ny9CQ1AxMCByZW1haW4gaW4gZWZmZWN0LiAgQWxs IGZlZWRiYWNrIGFuZCBhbGwgTm9tY29tIGRlbGliZXJhdGlvbnMgd2lsbA0KPiByZW1haW4gY29u ZmlkZW50aWFsIGFuZCB3aWxsIG5vdCBiZSBkaXNjbG9zZWQuDQo+IA0KPiBQbGVhc2Ugc3VibWl0 IHlvdXIgbm9taW5hdGlvbnMgYXMgZWFybHkgYXMgcG9zc2libGUgZm9yIHRoZSBzYWtlIG9mIHlv dXINCj4gbm9taW5lZXMuIE5vdGUgdGhhdCBub21pbmF0aW9ucyBzaG91bGQgbm90IHdhaXQgZm9y IG1hbmFnZW1lbnQNCj4gcGVybWlzc2lvbiwgYXMgaXQgaXMgZWFzaWVyIHRvIGRlY2xpbmUgdGhl IG5vbWluYXRpb24sIHRoYW4gcHV0IG9uZSBpbiBsYXRlLg0KPiBXZSd2ZSBzZXQgdGhlIHF1ZXN0 aW9ubmFpcmUgc3VibWlzc2lvbiBkZWFkbGluZSBmb3IgT2N0b2JlciAyNSwgMjAxNC4NCj4gDQo+ IFRoZSBOb21jb20gYXBwb2ludHMgaW5kaXZpZHVhbHMgdG8gZmlsbCB0aGUgb3BlbiBzbG90cyBv biB0aGUgSUFPQywgdGhlIElBQiwNCj4gYW5kIHRoZSBJRVNHLiBUaGUgbGlzdCBvZiBwZW9wbGUg YW5kIHBvc3RzIHdob3NlIHRlcm1zIGVuZCB3aXRoIHRoZSBNYXJjaA0KPiAyMDE1IElFVEYgbWVl dGluZywgYW5kIHRodXMgdGhlIHBvc2l0aW9ucyBmb3Igd2hpY2ggdGhpcyBOb21jb20gaXMNCj4g cmVzcG9uc2libGUsIGZvbGxvd3M6DQo+IA0KPiBJQU9DOg0KPiBSYW5keSBCdXNoDQo+IA0KPiBJ QUI6DQo+IEpvZWwgSGFscGVybioNCj4gUnVzcyBIb3VzbGV5DQo+IEVsaW90IExlYXINCj4gWGlu ZyBMaQ0KPiBBbmRyZXcgU3VsbGl2YW4NCj4gRGF2ZSBUaGFsZXINCj4gDQo+IElFU0c6DQo+IFBl dGUgUmVzbmljayogKEFwcGxpY2F0aW9ucykNCj4gVGVkIExlbW9uIChJbnRlcm5ldCkNCj4gSm9l bCBKYWVnZ2xpIChPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50KSBSaWNoYXJkIEJhcm5lcyAoUkFJ KSBBZHJpYW4NCj4gRmFycmVsKiAoUm91dGluZykgU3RlcGhlbiBGYXJyZWxsIChTZWN1cml0eSkg U3BlbmNlciBEYXdraW5zIChUcmFuc3BvcnQpIEphcmkNCj4gQXJra28gKEdlbikNCj4gDQo+ICot IGtub3duIHRvIGhhdmUgZGVjbGluZSB0byBydW4gYWdhaW4uDQo+IA0KPiBQTEVBU0UgTk9URSBU SEFUIElUIElTIExJS0VMWSBUSEFUIEFQUExJQ0FUSU9OUyBBUkVBIFdJTEwgTk9UIEJFDQo+IEZJ TExFRCBBVCBUSEUgSUVTRyBSRVFVRVNULg0KPiANCj4gUGxlYXNlIGJlIHJlc291cmNlZnVsIGlu IGlkZW50aWZ5aW5nIHBvc3NpYmxlIGNhbmRpZGF0ZXMgZm9yIHRoZXNlIHBvc2l0aW9ucywNCj4g YXMgZGV2ZWxvcGluZyBvdXIgdGFsZW50IGlzIGEgdmVyeSBjcnVjaWFsIHJlcXVpcmVtZW50IGZv ciB0aGUgSUVURiwgYW5kIGFsc28sDQo+IHBsZWFzZSBjb25zaWRlciBhY2NlcHRpbmcgYSBub21p bmF0aW9uLiAgWW91J2xsIGZpbmQgZXh0ZW5zaXZlIGluZm9ybWF0aW9uDQo+IGFib3V0IHNwZWNp ZmljIHBvc2l0aW9ucywgZGV2ZWxvcGVkIGJ5IHRoZSBJQUIsIElFU0csIGFuZCBJQU9DLCB1bmRl cg0KPiBpbmRpdmlkdWFsIHRhYnMgYXQ6DQo+IA0KPiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbm9tY29tLzIwMTQvcmVxdWlyZW1lbnRzLw0KPiANCj4gSW4gYWRkaXRpb24gdG8gbm9t aW5hdGlvbnMsIHRoZSBOb21jb20gc2Vla3MgY29tbXVuaXR5IGlucHV0IG9uIHRoZQ0KPiBwb3Np dGlvbnMgdGhlbXNlbHZlcy4gIFdlIG5lZWQgYW5kIHdlbGNvbWUgdGhlIGNvbW11bml0eSdzIHZp ZXdzIGFuZA0KPiBpbnB1dCBvbiB0aGUgam9icyB3aXRoaW4gZWFjaCBvcmdhbml6YXRpb24uIElm IHlvdSBoYXZlIGlkZWFzIG9uIHRoZSBwb3NpdGlvbnMnDQo+IHJlc3BvbnNpYmlsaXRpZXMgKG1v cmUsIGxlc3MsIGRpZmZlcmVudCksIHBsZWFzZSBsZXQgdXMga25vdy4NCj4gDQo+IFBsZWFzZSBz ZW5kIHN1Z2dlc3Rpb25zIGFuZCBmZWVkYmFjayBhYm91dCB0aGlzIHRvIG5vbWNvbTE0QGlldGYu b3JnLg0KPiANCj4gVGhhbmsgeW91IGZvciB5b3VyIGhlbHAgaW4gaWRlbnRpZnlpbmcgcXVhbGlm aWVkIG5vbWluZWVzIQ0KPiANCj4gTWljaGFlbCBSaWNoYXJkc29uDQo+IE5vbWNvbSBDaGFpciAy MDE0LTE1DQo+IG5vbWNvbS1jaGFpci0yMDE0QGlldGYub3JnLCBtY3Irbm9tY29tQHNhbmRlbG1h bi5jYQ0KDQo= From nobody Tue Oct 14 04:48: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 9E6DA1A8714 for ; Tue, 14 Oct 2014 04:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.685 X-Spam-Level: X-Spam-Status: No, score=-7.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3RDDc7vzf7S for ; Tue, 14 Oct 2014 04:48:36 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AB01A86FA for ; Tue, 14 Oct 2014 04:48:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcLADwNPVTGmAcV/2dsb2JhbABbgkgjI1NYBLhsBpsJAoEVFgEBcQuEAgEBAQEDEgsQXAIBCA0EBAEBCx0HMhQJCAEBBBMIGogcAaY4n2ABAQEBAQEBAQEBAQEBAQEBAQEBAQEXhiCJdDcBgy2BHgWReY0Ag0aDG4oEg36Dd2yBSIECAQEB X-IronPort-AV: E=Sophos; i="5.04,716,1406606400"; d="scan'208,217"; a="89663221" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 Oct 2014 07:48:34 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 14 Oct 2014 07:48:34 -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; Tue, 14 Oct 2014 13:48:33 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: IETF 91: call for agenda items Thread-Index: Ac/bWY7HzxXyycm1Rd+Joeee9HSe7wMSut6Q Date: Tue, 14 Oct 2014 11:48:32 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8CB5F1@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8AF7D6@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8AF7D6@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_9904FB1B0159DA42B0B887B7FA8119CA5C8CB5F1AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/OW6_DQOqOFb3aCXYUCjYRLoD1co Subject: Re: [lmap] IETF 91: call for agenda items X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 11:48:37 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8CB5F1AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The preliminary agenda for IETF-91 was published and the scheduling of the = LMAP WG is: THURSDAY, November 13, 2014 0900-1130 Morning Session I Kahili 1/2 OPS lmap Large-Scale Measurement of Br= oadband Performance WG Note that this schedule is subject to change. Please send your requests for agenda time and proposals about how to use be= st the meeting time. Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Sunday, September 28, 2014 11:20 PM To: lmap@ietf.org Subject: [lmap] IETF 91: call for agenda items Hi, We have entered a request for a meeting at IETF 91, same duration as at IET= F 90. Please send your requests and proposals for the agenda. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8CB5F1AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The preliminary agenda= for IETF-91 was published and the scheduling of the LMAP WG is:

 

THURSDAY, November 13, 2014<= /p>

0900-1130  Morning Session I

Kahili 1/2       = ;      OPS     lmap  &nbs= p;        Large-Scale Measurement of Broadban= d Performance WG

 

Note that this schedul= e is subject to change.

 

Please send your reque= sts for agenda time and proposals about how to use best the meeting time.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Sunday, September 28, 2014 11:20 PM
To: lmap@ietf.org
Subject: [lmap] IETF 91: call for agenda items

 

Hi,

 

We have entered a request for a meeting at IETF 91, = same duration as at IETF 90.

 

Please send your requests and proposals for the agen= da.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8CB5F1AZFFEXMB04globa_-- From nobody Wed Oct 15 06:18: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 AF7701A1AC3 for ; Wed, 15 Oct 2014 06:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 NSBz2pnBOZjk for ; Wed, 15 Oct 2014 06:18:46 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CEEB1A1ABE for ; Wed, 15 Oct 2014 06:18:45 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 15 Oct 2014 14:18:48 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.36]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Wed, 15 Oct 2014 14:18:26 +0100 From: To: Date: Wed, 15 Oct 2014 14:18:26 +0100 Thread-Topic: Information Model: Task Configuration Thread-Index: Ac/oeoC97VTH0qryQHqyqrB5AyP6JA== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72E45CE6071EMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/EEn4hc4yQz1bvIXRNmpnv_AVYl0 Subject: [lmap] Information Model: Task Configuration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Oct 2014 13:18:49 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72E45CE6071EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During Dublin we debated (but didn't come to a strong conclusion on) two ke= y topics. This is the first of those topics. Currently we have a concept of a Task Configuration where task parameters c= an be configured. The same Task Configuration can then be referenced multip= le times from number of different Schedules. It was pointed out that this can be very inefficient if we want to run basi= cally the same task with just one parameter changing each time such as the = test target. E.g. if we are running against 10 different targets then we la= rgely have to reproduce and transmit to the MA 10 very similar Task Configu= rations. The options as I understand them are: - Specify all parameters in Task Configurations is fine. Conceptuall= y simple is more important than efficiency - Allow a hierarchical inheritance of Task Configurations. I.e. defi= ne a general Task Configuration and the specialise for 10 different targets= . May be very confusing for people not familiar with such concepts especial= ly at the data model level. - Allow task parameters to be specified either by using/referencing = a Task Configuration or by supplying them within a Schedule. E.g. this woul= d allow a general Task Configuration to be used but the target could be sup= plied within the Schedule. Conceptually clean, flexible and allows the opti= mum balance. All options are as powerful as each other so it comes down to which is easi= er to understand and which is more efficient. Before someone asks, the current model is not quite as clean as the first o= ption on this list since we have Channel selection within the Schedule. I t= hink the agreement was that this shouldn't be treated as a special case so = this will change regardless of the decision above. Trevor --_000_ED51D9282D1D3942B9438CA8F3372EB72E45CE6071EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During Dublin we debated (but didn’t come to a strong c= onclusion on) two key topics. This is the first of those topics.=

 

Currently= we have a concept of a Task Configuration where task parameters can be con= figured. The same Task Configuration can then be referenced multiple times = from  number of different Schedules.

 

It was pointed out that this can= be very inefficient if we want to run basically the same task with just on= e parameter changing each time such as the test target. E.g. if we are runn= ing against 10 different targets then we largely have to reproduce and tran= smit to the MA 10 very similar Task Configurations.

 

The options as I under= stand them are:

-        Specify all parameters = in Task Configurations is fine. Conceptually simple is more important than = efficiency

-        = Allow a hierarchical inherit= ance of Task Configurations. I.e. define a general Task Configuration and t= he specialise for 10 different targets. May be very confusing for people no= t familiar with such concepts especially at the data model level.

-&n= bsp;       Allow task parameters to be specified either by = using/referencing a Task Configuration or by supplying them within a Schedu= le. E.g. this would allow a general Task Configuration to be used but the t= arget could be supplied within the Schedule. Conceptually clean, flexible a= nd allows the optimum balance.

 

All options are as powerful as each other s= o it comes down to which is easier to understand and which is more efficien= t.

=  

Before someone asks, the current model is not quite as clean as the fir= st option on this list since we have Channel selection within the Schedule.= I think the agreement was that this shouldn’t be treated as a specia= l case so this will change regardless of the decision above.

 

Trevor

= --_000_ED51D9282D1D3942B9438CA8F3372EB72E45CE6071EMV64UKRDdoma_-- From nobody Wed Oct 15 06:33: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 09C571A1B7B for ; Wed, 15 Oct 2014 06:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj4OsjckFXIN for ; Wed, 15 Oct 2014 06:33:16 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B43A1A6FD2 for ; Wed, 15 Oct 2014 06:33:03 -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.181.6; Wed, 15 Oct 2014 14:33:10 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.36]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Wed, 15 Oct 2014 14:32:36 +0100 From: To: Date: Wed, 15 Oct 2014 14:32:35 +0100 Thread-Topic: Information Model: Connecting Tasks Thread-Index: Ac/ofHtSaYdiY6Y/R4mNbjroR+i0Bg== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72E45CE6097EMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/jSp2vFGVcuG5YflKki3mcGs99XE Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 13:33:20 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72E45CE6097EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During Dublin we debated (but didn't come to a strong conclusion on) two ke= y topics. This is the second of those topics. We currently allow Task outputs to be directed to other Tasks. There is a m= istake in the current draft but conceptually the way it should have been ex= pressed was that the output of a Scheduled Task can be directed to another = Scheduled Task. This is achieved by specifying the destination Scheduled Ta= sk as part of the origin Scheduled Task. We've gone through a few tweaks ar= ound this theme and people still find it hard to understand. Therefore an option was put on the table to make the concept of queues betw= een Scheduled Tasks explicit. A Scheduled Task would output to a queue. Ano= ther Scheduled Task would input from a queue. The advantage was debated to be: - Guides implementation - Queue object now or in future can have parameters defining its beh= aviour (e.g. maximum size, drop oldest or latest data when full etc.). Even= if such parameters were not desired today the queue object would enable su= ch parameters to be added in future It would be good to repeat the debate and get comments from others who were= n't in Dublin. Trevor. --_000_ED51D9282D1D3942B9438CA8F3372EB72E45CE6097EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During Dublin we debated (but didn’t come to a strong c= onclusion on) two key topics. This is the second of those topics.

 <= /o:p>

We curre= ntly allow Task outputs to be directed to other Tasks. There is a mistake i= n the current draft but conceptually the way it should have been expressed = was that the output of a Scheduled Task can be directed to another Schedule= d Task. This is achieved by specifying the destination Scheduled Task as pa= rt of the origin Scheduled Task. We’ve gone through a few tweaks arou= nd this theme and people still find it hard to understand.

 

Therefore an op= tion was put on the table to make the concept of queues between Scheduled T= asks explicit. A Scheduled Task would output to a queue. Another Scheduled = Task would input from a queue.

 

The advantage was debated to be:=

-&nb= sp;       Guides implementation

-   &n= bsp;    Queue object now or in future can have parameters defining its beh= aviour (e.g. maximum size, drop oldest or latest data when full etc.). Even= if such parameters were not desired today the queue object would enable su= ch parameters to be added in future

 

It would be good to repeat the debate = and get comments from others who weren’t in Dublin.=

 

Trevor.

 =

= --_000_ED51D9282D1D3942B9438CA8F3372EB72E45CE6097EMV64UKRDdoma_-- From nobody Wed Oct 15 07:02:45 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE4B1A7033 for ; Wed, 15 Oct 2014 07:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8RqCNLui4nh for ; Wed, 15 Oct 2014 07:02:36 -0700 (PDT) Received: from p02c12o141.mxlogic.net (p02c12o141.mxlogic.net [208.65.145.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA3B1A040B for ; Wed, 15 Oct 2014 07:02:27 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o141.mxlogic.net(mxl_mta-8.2.0-0) with ESMTP id 47e7e345.2b7beb63e940.115132.00-520.308143.p02c12o141.mxlogic.net (envelope-from ); Wed, 15 Oct 2014 08:02:28 -0600 (MDT) X-MXL-Hash: 543e7e74062b1345-2e8b3bf78db7699a4ff213ea8da6cea5af0ab132 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o141.mxlogic.net(mxl_mta-8.2.0-0) over TLS secured channel with ESMTP id 85e7e345.0.114835.00-285.307255.p02c12o141.mxlogic.net (envelope-from ); Wed, 15 Oct 2014 08:02:06 -0600 (MDT) X-MXL-Hash: 543e7e5e61f42a17-a277381f37a2eabcf721c15cd51b21c99ce7881a 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.0210.002; Wed, 15 Oct 2014 09:02:00 -0500 From: KEN KO To: "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Information Model: Task Configuration Thread-Index: Ac/oeoC97VTH0qryQHqyqrB5AyP6JAABbRkw Date: Wed, 15 Oct 2014 14:01:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.179.199] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB78581556Aexmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=cO30szuN c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=qZHQZMT3apYA:10 a=Lil] X-AnalysisOut: [mCj0MqxoA:10 a=BLceEmwcHowA:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8] X-AnalysisOut: [ a=Pv665JgaBZN_AIhdlOcA:9 a=8WjOoNV3Q9VJQUm0:21 a=cpX3tFwu] X-AnalysisOut: [uXrCeotd:21 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=W1qU_X6G] X-AnalysisOut: [3J8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=S7Cr2bAOV3mlhc] X-AnalysisOut: [qz-NwA:9 a=DDWJJ0wyw9CkthTr:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4] X-AnalysisOut: [-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014101509); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Jy52PWfGeHLGg4bVA5195e-047Q Subject: Re: [lmap] Information Model: Task Configuration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Oct 2014 14:02:42 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB78581556Aexmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You probably want to hear views from a wider community, but I'll repeat my = preference from Dublin. I think the last option listed is preferable. Speci= fically, all parameters should be specifiable at the Task Configuration lev= el but over-rideable at the Schedule level where they are instantiated. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.= com Sent: Wednesday, October 15, 2014 7:18 AM To: lmap@ietf.org Subject: [lmap] Information Model: Task Configuration During Dublin we debated (but didn't come to a strong conclusion on) two ke= y topics. This is the first of those topics. Currently we have a concept of a Task Configuration where task parameters c= an be configured. The same Task Configuration can then be referenced multip= le times from number of different Schedules. It was pointed out that this can be very inefficient if we want to run basi= cally the same task with just one parameter changing each time such as the = test target. E.g. if we are running against 10 different targets then we la= rgely have to reproduce and transmit to the MA 10 very similar Task Configu= rations. The options as I understand them are: - Specify all parameters in Task Configurations is fine. Conceptuall= y simple is more important than efficiency - Allow a hierarchical inheritance of Task Configurations. I.e. defi= ne a general Task Configuration and the specialise for 10 different targets= . May be very confusing for people not familiar with such concepts especial= ly at the data model level. - Allow task parameters to be specified either by using/referencing = a Task Configuration or by supplying them within a Schedule. E.g. this woul= d allow a general Task Configuration to be used but the target could be sup= plied within the Schedule. Conceptually clean, flexible and allows the opti= mum balance. All options are as powerful as each other so it comes down to which is easi= er to understand and which is more efficient. Before someone asks, the current model is not quite as clean as the first o= ption on this list since we have Channel selection within the Schedule. I t= hink the agreement was that this shouldn't be treated as a special case so = this will change regardless of the decision above. Trevor --_000_D14B7E40AEBFD54EA3AD964902DD7CB78581556Aexmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You probably want to h= ear views from a wider community, but I’ll repeat my preference from = Dublin. I think the last option listed is preferable. Specifically, all par= ameters should be specifiable at the Task Configuration level but over-rideable at the Schedule level where they are= instantiated.

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.com
Sent: Wednesday, October 15, 2014 7:18 AM
To: lmap@ietf.org
Subject: [lmap] Information Model: Task Configuration

 

During Dublin we debated (but didn’t come to a st= rong conclusion on) two key topics. This is the first of those topics.=

 

Currently we have a concept of a Task Configuration whe= re task parameters can be configured. The same Task Configuration can then = be referenced multiple times from  number of different Schedules.

 

It was pointed out that this can be very inefficient if= we want to run basically the same task with just one parameter changing ea= ch time such as the test target. E.g. if we are running against 10 different targets then we largely have to reprod= uce and transmit to the MA 10 very similar Task Configurations.<= /span>

 

The options as I understand them are:=

-        Specify all parameters = in Task Configurations is fine. Conceptually simple is more important than = efficiency

-        Allow a hierarchical in= heritance of Task Configurations. I.e. define a general Task Configuration = and the specialise for 10 different targets. May be very confusing for peop= le not familiar with such concepts especially at the data model level.

-        Allow task parameters t= o be specified either by using/referencing a Task Configuration or by suppl= ying them within a Schedule. E.g. this would allow a general Task Configura= tion to be used but the target could be supplied within the Schedule. Conceptually clean, flexible and allows t= he optimum balance.

 

All options are as powerful as each other so it comes d= own to which is easier to understand and which is more efficient.

 

Before someone asks, the current model is not quite as = clean as the first option on this list since we have Channel selection with= in the Schedule. I think the agreement was that this shouldn’t be treated as a special case so this will change= regardless of the decision above.

 

Trevor

--_000_D14B7E40AEBFD54EA3AD964902DD7CB78581556Aexmb1corpadtran_-- From nobody Wed Oct 15 10:32: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 1254B1A1B7C for ; Wed, 15 Oct 2014 10:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 8lh9kljaEDE0 for ; Wed, 15 Oct 2014 10:32:33 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCC21A0469 for ; Wed, 15 Oct 2014 10:32:33 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9CC17A27A7; Wed, 15 Oct 2014 13:32:31 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 5CB1FA27A5; Wed, 15 Oct 2014 13:32:31 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.143]) by SPQCCAS01.exfo.com ([10.28.36.8]) with mapi id 14.03.0174.001; Wed, 15 Oct 2014 13:32:30 -0400 From: Sharam Hakimi To: "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Information Model: Task Configuration Thread-Index: Ac/oeoC97VTH0qryQHqyqrB5AyP6JAABbRkwAAcPEEA= Date: Wed, 15 Oct 2014 17:32:30 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FEB164E@SPQCMBX02.exfo.com> References: 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_89294A6F3C6C91459E52E4128C4B02B70FEB164ESPQCMBX02exfoco_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-21026.001 X-TM-AS-Result: No--24.314-5.0-31-10 X-imss-scan-details: No--24.314-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-21026.001 X-TMASE-Result: 10--24.313700-5.000000 X-TMASE-MatchedRID: H0/uSqZo4D7WKlsMlVwfQ+v8QGaI25e3UAjrAJWsTe/qFlTg1wFn3AzZ v1Is3rTi9t03FccVflYvEMUzYj/5iFwiNkCSQ5LIo4Ef+Wmk9x1wryoe90UcsIBmm9OromHhxdz shg2VBUJ1h0VOhvUGwtqUTgVWzxv3q0qr+Q1qzEpIOSHptb5txx852jgffnmI2hV8jMmGLDRloJ 3lDbA6n8OzdsKZ2bnLOda5Aan0vG7vnOSC+jk4DmTJXSYk53OhviRliDV2nyz5rdsLa10IzGNok eyvFnLMmCs+V844sSrUKKPhEvXgxhlC83iczcIZfh/0N74LJAIpWss5kPUFdBjQD3m2MCf7BwC6 udV1r8I22uoEm245fkFWCvm86w840sXpjQvtH9Abrq24GKfh0CGUAoFdIEUeHqY6lAJju12oaIr P68De9cHprnC72UTHQHm5YLO+mCJI5aNiVPKgsZhyXgGCpXKTcbVmJQ7kUKWPaLJ/Ca3ST2ji04 EzOjY4vjLQU8lImJzh2LQAC7KGgadwsJe6fN2LEgwM8US/pTGp0vJxmLIwiDg2jfgv3Zp9UdfEK c10rU54nNRC+UXW5z7V1OrezJhfWfg4pIIFh8e4E8q66ZPDHNVYleRFiu07myiLZetSf8mVHVxP 1hp9BcaUO+wtQNbaJYJomegfbwcHpbPbImW23P1aRTeczq4J80KBE6dG9mdQCzcov9Zzpg== Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Jh5PH0VWlzazxTwswifiJbqFn6g Subject: Re: [lmap] Information Model: Task Configuration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Oct 2014 17:32:36 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B70FEB164ESPQCMBX02exfoco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would agree that the last option would be best. The task list and the ta= rgets should not be tied together. One would have a list of tasks (could be= one also) and a list of targets that would specify which task is required = to be used for that target. This way if all targets use only one task, then= that task would only be sent to the MA once. Sharam From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of KEN KO Sent: Wednesday, October 15, 2014 10:02 AM To: trevor.burbridge@bt.com; lmap@ietf.org Subject: Re: [lmap] Information Model: Task Configuration You probably want to hear views from a wider community, but I'll repeat my = preference from Dublin. I think the last option listed is preferable. Speci= fically, all parameters should be specifiable at the Task Configuration lev= el but over-rideable at the Schedule level where they are instantiated. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.= com Sent: Wednesday, October 15, 2014 7:18 AM To: lmap@ietf.org Subject: [lmap] Information Model: Task Configuration During Dublin we debated (but didn't come to a strong conclusion on) two ke= y topics. This is the first of those topics. Currently we have a concept of a Task Configuration where task parameters c= an be configured. The same Task Configuration can then be referenced multip= le times from number of different Schedules. It was pointed out that this can be very inefficient if we want to run basi= cally the same task with just one parameter changing each time such as the = test target. E.g. if we are running against 10 different targets then we la= rgely have to reproduce and transmit to the MA 10 very similar Task Configu= rations. The options as I understand them are: - Specify all parameters in Task Configurations is fine. Conceptuall= y simple is more important than efficiency - Allow a hierarchical inheritance of Task Configurations. I.e. defi= ne a general Task Configuration and the specialise for 10 different targets= . May be very confusing for people not familiar with such concepts especial= ly at the data model level. - Allow task parameters to be specified either by using/referencing = a Task Configuration or by supplying them within a Schedule. E.g. this woul= d allow a general Task Configuration to be used but the target could be sup= plied within the Schedule. Conceptually clean, flexible and allows the opti= mum balance. All options are as powerful as each other so it comes down to which is easi= er to understand and which is more efficient. Before someone asks, the current model is not quite as clean as the first o= ption on this list since we have Channel selection within the Schedule. I t= hink the agreement was that this shouldn't be treated as a special case so = this will change regardless of the decision above. Trevor --_000_89294A6F3C6C91459E52E4128C4B02B70FEB164ESPQCMBX02exfoco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 I would agree th= at the last option would be best. The task list and the targets should not = be tied together. One would have a list of tasks (could be one also) and a = list of targets that would specify which task is required to be used for that target. This way if all targets use o= nly one task, then that task would only be sent to the MA once.<= /span>

 

Sharam

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of KEN KO
Sent: Wednesday, October 15, 2014 10:02 AM
To: trevor.burbridge@bt.com; lmap@ietf.org
Subject: Re: [lmap] Information Model: Task Configuration=

 

You probably want to h= ear views from a wider community, but I’ll repeat my preference from = Dublin. I think the last option listed is preferable. Specifically, all par= ameters should be specifiable at the Task Configuration level but over-rideable at the Schedule level where they are= instantiated.

 

From: lmap [mailto:lmap-b= ounces@ietf.org] On Behalf Of trevor.burbridge@bt.com
Sent: Wednesday, October 15, 2014 7:18 AM
To: lmap@ietf.org
Subject: [lmap] Information Model: Task Configuration

 

During Dublin we debated (but didn’t come to a st= rong conclusion on) two key topics. This is the first of those topics.=

 

Currently we have a concept of a Task Configuration whe= re task parameters can be configured. The same Task Configuration can then = be referenced multiple times from  number of different Schedules.

 

It was pointed out that this can be very inefficient if= we want to run basically the same task with just one parameter changing ea= ch time such as the test target. E.g. if we are running against 10 different targets then we largely have to reprod= uce and transmit to the MA 10 very similar Task Configurations.<= /span>

 

The options as I understand them are:=

-        Specify all parameters = in Task Configurations is fine. Conceptually simple is more important than = efficiency

-        Allow a hierarchical in= heritance of Task Configurations. I.e. define a general Task Configuration = and the specialise for 10 different targets. May be very confusing for peop= le not familiar with such concepts especially at the data model level.

-        Allow task parameters t= o be specified either by using/referencing a Task Configuration or by suppl= ying them within a Schedule. E.g. this would allow a general Task Configura= tion to be used but the target could be supplied within the Schedule. Conceptually clean, flexible and allows t= he optimum balance.

 

All options are as powerful as each other so it comes d= own to which is easier to understand and which is more efficient.

 

Before someone asks, the current model is not quite as = clean as the first option on this list since we have Channel selection with= in the Schedule. I think the agreement was that this shouldn’t be treated as a special case so this will change= regardless of the decision above.

 

Trevor

--_000_89294A6F3C6C91459E52E4128C4B02B70FEB164ESPQCMBX02exfoco_-- From nobody Wed Oct 15 10:44: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 BCCF41AC423 for ; Wed, 15 Oct 2014 10:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX8jErA3GFhr for ; Wed, 15 Oct 2014 10:44:48 -0700 (PDT) Received: from p02c12o142.mxlogic.net (p02c12o142.mxlogic.net [208.65.145.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDF91A1B7C for ; Wed, 15 Oct 2014 10:44:47 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o142.mxlogic.net(mxl_mta-8.2.0-0) with ESMTP id f82be345.2abbebe12940.79289.00-576.227087.p02c12o142.mxlogic.net (envelope-from ); Wed, 15 Oct 2014 11:44:47 -0600 (MDT) X-MXL-Hash: 543eb28f4967301c-3a1ab95aad2269084d90799bdc990551ca5d0c19 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o142.mxlogic.net(mxl_mta-8.2.0-0) over TLS secured channel with ESMTP id d72be345.0.79094.00-315.226557.p02c12o142.mxlogic.net (envelope-from ); Wed, 15 Oct 2014 11:44:31 -0600 (MDT) X-MXL-Hash: 543eb27f71f8c2a2-45f2360a162cc8f1134ee304f5bfd1ed45e8bf43 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.0210.002; Wed, 15 Oct 2014 12:44:28 -0500 From: KEN KO To: Sharam Hakimi , "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Information Model: Task Configuration Thread-Index: Ac/oeoC97VTH0qryQHqyqrB5AyP6JAABbRkwAAcPEEAAALckUA== Date: Wed, 15 Oct 2014 17:44:28 +0000 Message-ID: References: <89294A6F3C6C91459E52E4128C4B02B70FEB164E@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70FEB164E@SPQCMBX02.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.179.199] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB785815802exmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=Jb2orC6V c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=qZHQZMT3apYA:10 a=Lil] X-AnalysisOut: [mCj0MqxoA:10 a=BLceEmwcHowA:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8] X-AnalysisOut: [ a=68w6W6546bKtfwxSOlMA:9 a=InkjsxoUTH7lfNjU:21 a=zr5tTJ-Y] X-AnalysisOut: [4SO-lAN5:21 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=W1qU_X6G] X-AnalysisOut: [3J8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=H9fw-ALdBJyNIr] X-AnalysisOut: [xIQ1cA:9 a=asgajqw3-UWi_Wvz:21 a=41EtMAqhli9Y3BmW:21 a=DID] X-AnalysisOut: [VkrkYGxcw6OV0:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZ] X-AnalysisOut: [eC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014101511); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FdkbJAb_XYECr_3tHG_dGipg2pQ Subject: Re: [lmap] Information Model: Task Configuration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Oct 2014 17:44:51 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB785815802exmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My view is a little more expansive than what I read Sharam saying. Since th= e Information Model can't anticipate what value there might be in overridin= g which parameters for a given Measurement Method, we shouldn't limit the o= verrides to a specific type of parameter (e.g., target). Allow the schedule= to override any parameter. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi Sent: Wednesday, October 15, 2014 11:33 AM To: trevor.burbridge@bt.com; lmap@ietf.org Subject: Re: [lmap] Information Model: Task Configuration I would agree that the last option would be best. The task list and the ta= rgets should not be tied together. One would have a list of tasks (could be= one also) and a list of targets that would specify which task is required = to be used for that target. This way if all targets use only one task, then= that task would only be sent to the MA once. Sharam From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of KEN KO Sent: Wednesday, October 15, 2014 10:02 AM To: trevor.burbridge@bt.com; lmap@ietf.org<= mailto:lmap@ietf.org> Subject: Re: [lmap] Information Model: Task Configuration You probably want to hear views from a wider community, but I'll repeat my = preference from Dublin. I think the last option listed is preferable. Speci= fically, all parameters should be specifiable at the Task Configuration lev= el but over-rideable at the Schedule level where they are instantiated. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.= com Sent: Wednesday, October 15, 2014 7:18 AM To: lmap@ietf.org Subject: [lmap] Information Model: Task Configuration During Dublin we debated (but didn't come to a strong conclusion on) two ke= y topics. This is the first of those topics. Currently we have a concept of a Task Configuration where task parameters c= an be configured. The same Task Configuration can then be referenced multip= le times from number of different Schedules. It was pointed out that this can be very inefficient if we want to run basi= cally the same task with just one parameter changing each time such as the = test target. E.g. if we are running against 10 different targets then we la= rgely have to reproduce and transmit to the MA 10 very similar Task Configu= rations. The options as I understand them are: - Specify all parameters in Task Configurations is fine. Conceptuall= y simple is more important than efficiency - Allow a hierarchical inheritance of Task Configurations. I.e. defi= ne a general Task Configuration and the specialise for 10 different targets= . May be very confusing for people not familiar with such concepts especial= ly at the data model level. - Allow task parameters to be specified either by using/referencing = a Task Configuration or by supplying them within a Schedule. E.g. this woul= d allow a general Task Configuration to be used but the target could be sup= plied within the Schedule. Conceptually clean, flexible and allows the opti= mum balance. All options are as powerful as each other so it comes down to which is easi= er to understand and which is more efficient. Before someone asks, the current model is not quite as clean as the first o= ption on this list since we have Channel selection within the Schedule. I t= hink the agreement was that this shouldn't be treated as a special case so = this will change regardless of the decision above. Trevor --_000_D14B7E40AEBFD54EA3AD964902DD7CB785815802exmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My view is a little mo= re expansive than what I read Sharam saying. Since the Information Model ca= n’t anticipate what value there might be in overriding which paramete= rs for a given Measurement Method, we shouldn’t limit the overrides to a specific type of parameter (e.g., target). Allow = the schedule to override any parameter.

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi
Sent: Wednesday, October 15, 2014 11:33 AM
To: trevor.burbridge@bt.com; lmap@ietf.org
Subject: Re: [lmap] Information Model: Task Configuration=

 

 I would agree that the last option would be best. The task list = and the targets should not be tied together. One would have a list of tasks= (could be one also) and a list of targets that would specify which task is required to be used for that target. This= way if all targets use only one task, then that task would only be sent to= the MA once.

 

Sharam

 

From: lmap [mailto:lm= ap-bounces@ietf.org] On Behalf Of KEN KO
Sent: Wednesday, October 15, 2014 10:02 AM
To: trevor.burbridge@bt.c= om; lmap@ietf.org
Subject: Re: [lmap] Information Model: Task Configuration=

 

You probably want to hear views from a wider community, but I’ll= repeat my preference from Dublin. I think the last option listed is prefer= able. Specifically, all parameters should be specifiable at the Task Configuration level but over-rideable at the Sched= ule level where they are instantiated.

 

From: lmap [mailto:l= map-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Wednesday, October 15, 2014 7:18 AM
To: lmap@ietf.org
Subject: [lmap] Information Model: Task Configuration

 

During Dublin we debated (but didn’t come to a s= trong conclusion on) two key topics. This is the first of those topics.

 

Currently we have a concept of a Task Configuration wh= ere task parameters can be configured. The same Task Configuration can then= be referenced multiple times from  number of different Schedules.

 

It was pointed out that this can be very inefficient i= f we want to run basically the same task with just one parameter changing e= ach time such as the test target. E.g. if we are running against 10 different targets then we largely have to reprod= uce and transmit to the MA 10 very similar Task Configurations.<= /span>

 

The options as I understand them are:

-        Specify all parameters = in Task Configurations is fine. Conceptually simple is more important than = efficiency

-        Allow a hierarchical in= heritance of Task Configurations. I.e. define a general Task Configuration = and the specialise for 10 different targets. May be very confusing for peop= le not familiar with such concepts especially at the data model level.

-        Allow task parameters t= o be specified either by using/referencing a Task Configuration or by suppl= ying them within a Schedule. E.g. this would allow a general Task Configura= tion to be used but the target could be supplied within the Schedule. Conceptually clean, flexible and allows t= he optimum balance.

 

All options are as powerful as each other so it comes = down to which is easier to understand and which is more efficient.

 

Before someone asks, the current model is not quite as= clean as the first option on this list since we have Channel selection wit= hin the Schedule. I think the agreement was that this shouldn’t be treated as a special case so this will ch= ange regardless of the decision above.

 

Trevor

--_000_D14B7E40AEBFD54EA3AD964902DD7CB785815802exmb1corpadtran_-- From nobody Wed Oct 15 10:56:36 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF631A1AB5 for ; Wed, 15 Oct 2014 10:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 CWcUPoGbqu2t for ; Wed, 15 Oct 2014 10:56:27 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id E7A381A9005 for ; Wed, 15 Oct 2014 10:56:20 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7764EA279E; Wed, 15 Oct 2014 13:56:20 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 2A192A2794; Wed, 15 Oct 2014 13:56:20 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.143]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Wed, 15 Oct 2014 13:56:19 -0400 From: Sharam Hakimi To: "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Information Model: Task Configuration Thread-Index: Ac/oeoC97VTH0qryQHqyqrB5AyP6JAABbRkwAAcPEEAAALckUAAASvCQ Date: Wed, 15 Oct 2014 17:56:19 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FEB167B@SPQCMBX02.exfo.com> References: <89294A6F3C6C91459E52E4128C4B02B70FEB164E@SPQCMBX02.exfo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: multipart/alternative; boundary="_000_89294A6F3C6C91459E52E4128C4B02B70FEB167BSPQCMBX02exfoco_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-21026.001 X-TM-AS-Result: No--26.625-5.0-31-10 X-imss-scan-details: No--26.625-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-21026.001 X-TMASE-Result: 10--26.624800-5.000000 X-TMASE-MatchedRID: u6ojmU07PKzMy6K24fisq3PkIViiTNODaBTWjXFXXd/4JyR+b5tvoE90 0KYgJiJVXMEoxMSQEvWBdy2U0bKmbRGRuqAmkM32E0Q83A2vD+tezmeoa8MJ84Bmm9OromHh8iA RW0/sh1dCTLqzHE/JIC8QxTNiP/mIXCI2QJJDksijgR/5aaT3HXCvKh73RRyw/k12Sb2MaHmA1y 0tmGNVYqEtAKz8ADwNcjXKuyuuhFu2jsN8aguKvL50lYduDghOF0R6C/1uGOptdJqoKEspy2eQS y4YrSM/EpisnA4A6t2WIB6+4pPraxtEDpEjEWsFmcJBz15Y+/VD3kXYiJVSRMIlDxqwsDYXQW9f AKJG7FN10vM1jY23YoSan56wJzMqh0zWQXCZZ8gwiJTf3kjwfd9WrDP4LKdpx7QfsswIVxXBGri 2x+GkHFehZ8JDMoGXa+5MR1psyWgee4l+GBnC9merpxpZwg4L+Gz435tISEH5N0o2THGRZFvr9J ucnAavzkH/0tV77RAZttB2H+RMvwkbnmLrKdccY4guKfvwCBYzH3zWWApNw7i7yMDZhOacAkZtb 7fl6Fqh/9Db0raJ+12/J3quhJk9wMbcjWDEkC96a7qHolmGuZkShYcLpGH9BL+V9lD389E/uAMu IS3/V/Cm8Bq5g9qRKGI9r3kB/qg3JCnr3+beTQ6w00GeWBFafS0Ip2eEHnyvXSmSdlcYmn2PYbD NMTe9eSC65CityAwzu8Cfb9W5d+2NBfnF+lO2Nedq+fKnY1KSO6/VkAYd7X7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Mg3OxQ5_BDsBzJPOVRUjr4nR7nI Subject: Re: [lmap] Information Model: Task Configuration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Oct 2014 17:56:34 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B70FEB167BSPQCMBX02exfoco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Whether one specifies multiple task lists or supplies a task list with an o= verride list for every target is not going to differ from the execution poi= nt of view in my opinion. I think it would be cleaner to specify multiple t= ask lists that are used by different targets. The assumption would be that = most targets will use the same task list with a few minor variations. Sharam From: KEN KO [mailto:KEN.KO@adtran.com] Sent: Wednesday, October 15, 2014 1:44 PM To: Sharam Hakimi; trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: Information Model: Task Configuration My view is a little more expansive than what I read Sharam saying. Since th= e Information Model can't anticipate what value there might be in overridin= g which parameters for a given Measurement Method, we shouldn't limit the o= verrides to a specific type of parameter (e.g., target). Allow the schedule= to override any parameter. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Sharam Hakimi Sent: Wednesday, October 15, 2014 11:33 AM To: trevor.burbridge@bt.com; lmap@ietf.org Subject: Re: [lmap] Information Model: Task Configuration I would agree that the last option would be best. The task list and the ta= rgets should not be tied together. One would have a list of tasks (could be= one also) and a list of targets that would specify which task is required = to be used for that target. This way if all targets use only one task, then= that task would only be sent to the MA once. Sharam From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of KEN KO Sent: Wednesday, October 15, 2014 10:02 AM To: trevor.burbridge@bt.com; lmap@ietf.org<= mailto:lmap@ietf.org> Subject: Re: [lmap] Information Model: Task Configuration You probably want to hear views from a wider community, but I'll repeat my = preference from Dublin. I think the last option listed is preferable. Speci= fically, all parameters should be specifiable at the Task Configuration lev= el but over-rideable at the Schedule level where they are instantiated. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.= com Sent: Wednesday, October 15, 2014 7:18 AM To: lmap@ietf.org Subject: [lmap] Information Model: Task Configuration During Dublin we debated (but didn't come to a strong conclusion on) two ke= y topics. This is the first of those topics. Currently we have a concept of a Task Configuration where task parameters c= an be configured. The same Task Configuration can then be referenced multip= le times from number of different Schedules. It was pointed out that this can be very inefficient if we want to run basi= cally the same task with just one parameter changing each time such as the = test target. E.g. if we are running against 10 different targets then we la= rgely have to reproduce and transmit to the MA 10 very similar Task Configu= rations. The options as I understand them are: - Specify all parameters in Task Configurations is fine. Conceptuall= y simple is more important than efficiency - Allow a hierarchical inheritance of Task Configurations. I.e. defi= ne a general Task Configuration and the specialise for 10 different targets= . May be very confusing for people not familiar with such concepts especial= ly at the data model level. - Allow task parameters to be specified either by using/referencing = a Task Configuration or by supplying them within a Schedule. E.g. this woul= d allow a general Task Configuration to be used but the target could be sup= plied within the Schedule. Conceptually clean, flexible and allows the opti= mum balance. All options are as powerful as each other so it comes down to which is easi= er to understand and which is more efficient. Before someone asks, the current model is not quite as clean as the first o= ption on this list since we have Channel selection within the Schedule. I t= hink the agreement was that this shouldn't be treated as a special case so = this will change regardless of the decision above. Trevor --_000_89294A6F3C6C91459E52E4128C4B02B70FEB167BSPQCMBX02exfoco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Whether one specifies = multiple task lists or supplies a task list with an override list for every= target is not going to differ from the execution point of view in my opini= on. I think it would be cleaner to specify multiple task lists that are used by different targets. The assumption wou= ld be that most targets will use the same task list with a few minor variat= ions.

 

Sharam   

 

From: KEN KO [= mailto:KEN.KO@adtran.com]
Sent: Wednesday, October 15, 2014 1:44 PM
To: Sharam Hakimi; trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: Information Model: Task Configuration=

 

My view is a little mo= re expansive than what I read Sharam saying. Since the Information Model ca= n’t anticipate what value there might be in overriding which paramete= rs for a given Measurement Method, we shouldn’t limit the overrides to a specific type of parameter (e.g., target). Allow = the schedule to override any parameter.

 

From: lmap [mailto:lmap-b= ounces@ietf.org] On Behalf Of Sharam Hakimi
Sent: Wednesday, October 15, 2014 11:33 AM
To: trevor.burbridge@bt.com; lmap@ietf.org
Subject: Re: [lmap] Information Model: Task Configuration=

 

 I would agree that the last option would be best. The task list = and the targets should not be tied together. One would have a list of tasks= (could be one also) and a list of targets that would specify which task is required to be used for that target. This= way if all targets use only one task, then that task would only be sent to= the MA once.

 

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of KEN KO
Sent: Wednesday, October 15, 2014 10:02 AM
To: trevor.burbridge@bt.c= om; lmap@ietf.org
Subject: Re: [lmap] Information Model: Task Configuration=

 

You probably want to hear views from a wider community, but I’ll= repeat my preference from Dublin. I think the last option listed is prefer= able. Specifically, all parameters should be specifiable at the Task Configuration level but over-rideable at the Sched= ule level where they are instantiated.

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbr= idge@bt.com
Sent: Wednesday, October 15, 2014 7:18 AM
To: lmap@ietf.org
Subject: [lmap] Information Model: Task Configuration

 

During Dublin we debated (but didn’t come to a strong conclu= sion on) two key topics. This is the first of those topics.

 

Currently we have a concept of a Task Configuration where task par= ameters can be configured. The same Task Configuration can then be referenc= ed multiple times from  number of different Schedules.

 

It was pointed out that this can be very inefficient if we want to= run basically the same task with just one parameter changing each time suc= h as the test target. E.g. if we are running against 10 different targets then we largely have to rep= roduce and transmit to the MA 10 very similar Task Configurations.

 

The options as I understand them are:

-        Specify all parameters = in Task Configurations is fine. Conceptually simple is more important than = efficiency

-        Allow a hierarchical in= heritance of Task Configurations. I.e. define a general Task Configuration = and the specialise for 10 different targets. May be very confusing for peop= le not familiar with such concepts especially at the data model level.

-        Allow task parameters t= o be specified either by using/referencing a Task Configuration or by suppl= ying them within a Schedule. E.g. this would allow a general Task Configura= tion to be used but the target could be supplied within the Schedule. Conceptually clean, flexible and allows t= he optimum balance.

 

All options are as powerful as each other so it comes down to whic= h is easier to understand and which is more efficient.

 

Before someone asks, the current model is not quite as clean as th= e first option on this list since we have Channel selection within the Sche= dule. I think the agreement was that this shouldn’t be treated as a special case so this will ch= ange regardless of the decision above.

 

Trevor

--_000_89294A6F3C6C91459E52E4128C4B02B70FEB167BSPQCMBX02exfoco_-- From nobody Wed Oct 15 14:48: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 E7D011ACDDA for ; Wed, 15 Oct 2014 14:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 VYboZygLR5qx for ; Wed, 15 Oct 2014 14:48:12 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 188DE1ACDD8 for ; Wed, 15 Oct 2014 14:48:12 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id A10EB8447CED7; Wed, 15 Oct 2014 21:48:06 +0000 (GMT) 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 s9FLm82I030821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 17:48:09 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 17:48:08 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] Information Model: Connecting Tasks Thread-Index: AQHP6IC4e54LYC3BTk2yq03a9beAt5wxsZXQ Date: Wed, 15 Oct 2014 21:48:07 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7734FC0C6BUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/qv4QzPYNCWMrpIDuIRiz_LNOlts Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 21:48:15 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7734FC0C6BUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, Again - I believe you were seeking a wider audience viewpoint but.. In Dublin - I believe I expressed that I didn't think queues were necessary= . It seems abit over-engineered. I know from a TR-069 data model standpoint I have been able to model the Sc= heduled task that is simply directed to another task as you suggested. BR, Tim From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Wednesday, October 15, 2014 8:33 AM To: lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks During Dublin we debated (but didn't come to a strong conclusion on) two ke= y topics. This is the second of those topics. We currently allow Task outputs to be directed to other Tasks. There is a m= istake in the current draft but conceptually the way it should have been ex= pressed was that the output of a Scheduled Task can be directed to another = Scheduled Task. This is achieved by specifying the destination Scheduled Ta= sk as part of the origin Scheduled Task. We've gone through a few tweaks ar= ound this theme and people still find it hard to understand. Therefore an option was put on the table to make the concept of queues betw= een Scheduled Tasks explicit. A Scheduled Task would output to a queue. Ano= ther Scheduled Task would input from a queue. The advantage was debated to be: - Guides implementation - Queue object now or in future can have parameters defining its b= ehaviour (e.g. maximum size, drop oldest or latest data when full etc.). Ev= en if such parameters were not desired today the queue object would enable = such parameters to be added in future It would be good to repeat the debate and get comments from others who were= n't in Dublin. Trevor. --_000_9966516C6EB5FC4381E05BF80AA55F7734FC0C6BUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

Again – I believe you were seek= ing a wider audience viewpoint but..

In Dublin – I believe I express= ed that I didn’t think queues were necessary. It seems abit over-engi= neered.

I know from a TR-069 data model stand= point I have been able to model the Scheduled task that is simply directed = to another task as you suggested.

 

BR,

Tim

 

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Wednesday, October 15, 2014 8:33 AM
To: lmap@ietf.org
Subject: Re: [lmap] Information Model: Connecting Tasks

 

During = Dublin we debated (but didn’t come to a strong conclusion on) two key= topics. This is the second of those topics.

&n= bsp;

We curr= ently allow Task outputs to be directed to other Tasks. There is a mistake = in the current draft but conceptually the way it should have been expressed= was that the output of a Scheduled Task can be directed to another Scheduled Task. This is achieved by specifying = the destination Scheduled Task as part of the origin Scheduled Task. WeR= 17;ve gone through a few tweaks around this theme and people still find it = hard to understand.

&n= bsp;

Therefo= re an option was put on the table to make the concept of queues between Sch= eduled Tasks explicit. A Scheduled Task would output to a queue. Another Sc= heduled Task would input from a queue.

&n= bsp;

The adv= antage was debated to be:

<= span style=3D"mso-list:Ignore">-          Guides implementation

<= span style=3D"mso-list:Ignore">-          Queue object now or in future can have parameters defining its behaviour (= e.g. maximum size, drop oldest or latest data when full etc.). Even if such= parameters were not desired today the queue object would enable such parameters to be added in future=

&n= bsp;

It woul= d be good to repeat the debate and get comments from others who weren’= ;t in Dublin.

&n= bsp;

Trevor.=

&n= bsp;

--_000_9966516C6EB5FC4381E05BF80AA55F7734FC0C6BUS70UWXCHMBA05z_-- From nobody Thu Oct 16 03:20: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 64B3A1ACDFB for ; Wed, 15 Oct 2014 15:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 D5RFsQzHz1Mw for ; Wed, 15 Oct 2014 15:54:53 -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 490511ACDFA for ; Wed, 15 Oct 2014 15:54:53 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id C45A5122441; Wed, 15 Oct 2014 19:04:03 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id E31BEF03A6; Wed, 15 Oct 2014 18:54:49 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Wed, 15 Oct 2014 18:54:49 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Timothy)" , "trevor.burbridge@bt.com" , "lmap@ietf.org" Date: Wed, 15 Oct 2014 18:54:48 -0400 Thread-Topic: [lmap] Information Model: Connecting Tasks Thread-Index: AQHP6IC4e54LYC3BTk2yq03a9beAt5wxsZXQgAARGn4= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D7BBF89F2@NJFPSRVEXG0.research.att.com> References: , <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@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: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/pw4M0i0NrMtRbEJC8nssJvIxGU8 X-Mailman-Approved-At: Thu, 16 Oct 2014 03:20:44 -0700 Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 22:54:55 -0000 One case to consider, a measurement task completes but for some reason the reporting task has not been received yet. Queuing the measurement resul= t would potentially save it for later, when the reporting task appears. I also agree with Trevor's point that it guides implementation, but I'm not married to an explicit queue. There has to be storage when the reporting task takes place sometime after measurement. Regards, Al ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy) [t= imothy.carey@alcatel-lucent.com] Sent: Wednesday, October 15, 2014 5:48 PM To: trevor.burbridge@bt.com; lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks Trevor, Again =96 I believe you were seeking a wider audience viewpoint but.. In Dublin =96 I believe I expressed that I didn=92t think queues were neces= sary. It seems abit over-engineered. I know from a TR-069 data model standpoint I have been able to model the Sc= heduled task that is simply directed to another task as you suggested. BR, Tim From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Wednesday, October 15, 2014 8:33 AM To: lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks During Dublin we debated (but didn=92t come to a strong conclusion on) two = key topics. This is the second of those topics. We currently allow Task outputs to be directed to other Tasks. There is a m= istake in the current draft but conceptually the way it should have been ex= pressed was that the output of a Scheduled Task can be directed to another = Scheduled Task. This is achieved by specifying the destination Scheduled Ta= sk as part of the origin Scheduled Task. We=92ve gone through a few tweaks = around this theme and people still find it hard to understand. Therefore an option was put on the table to make the concept of queues betw= een Scheduled Tasks explicit. A Scheduled Task would output to a queue. Ano= ther Scheduled Task would input from a queue. The advantage was debated to be: - Guides implementation - Queue object now or in future can have parameters defining its b= ehaviour (e.g. maximum size, drop oldest or latest data when full etc.). Ev= en if such parameters were not desired today the queue object would enable = such parameters to be added in future It would be good to repeat the debate and get comments from others who were= n=92t in Dublin. Trevor. From nobody Fri Oct 17 01:44: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 EF9DE1A9134 for ; Fri, 17 Oct 2014 01:44:46 -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 pPty0HY8dHct for ; Fri, 17 Oct 2014 01:44:45 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BE71A9135 for ; Fri, 17 Oct 2014 01:44:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 317876DC; Fri, 17 Oct 2014 10:44:43 +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 V9PYUnvwSJGx; Fri, 17 Oct 2014 10:44:41 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Oct 2014 10:44:42 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DF5720036; Fri, 17 Oct 2014 10:44:42 +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 Ns7ua8IpCyC4; Fri, 17 Oct 2014 10:44:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BA6A20035; Fri, 17 Oct 2014 10:44:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1AFDA2EFECF0; Fri, 17 Oct 2014 10:44:40 +0200 (CEST) Date: Fri, 17 Oct 2014 10:44:39 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20141017084439.GC80274@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "trevor.burbridge@bt.com" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/fbyR6OzHpetA3KK_Ah359xZonW4 Cc: "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 08:44:47 -0000 On Wed, Oct 15, 2014 at 09:48:07PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, > > Again - I believe you were seeking a wider audience viewpoint but.. > In Dublin - I believe I expressed that I didn't think queues were > necessary. It seems abit over-engineered. I know from a TR-069 data > model standpoint I have been able to model the Scheduled task that > is simply directed to another task as you suggested. Timothy, while you can hide the queues in the information model, they will exist in implementations and they will have impact on how an implementation behaves. If a measurement task produces data faster than say a reporting task picks it up, then at some time something happens, e.g., the measurement task gets blocked or data is getting dropped (either new incoming data, or old data purged, or something random). Even if we decide that we do not want to go into defining different queues and their behaviour today (which may be reasonable in order to get a first version finished and implementation experience), we may want implementations to report queue specific statistics (e.g. a drop rate) and we may want future version of LMAP to provide more details for configuring the behavior of the queues. By making queues first class citizens now, we are open to such future LMAP extensions and we allow implementations to provide proprietary extensions for example to report queue statistics even now. The only technical concern I have heard is that the current information model does by design now allow to have multiple consumers of data. If this restriction is desirable, I am sure we can also have it with explicit queues. /js (sorry for repeating my proposal once more ;-) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Oct 17 14:56: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 202801A870B for ; Fri, 17 Oct 2014 14:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Q4kOWqWSZLZc for ; Fri, 17 Oct 2014 14:56:45 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A2A1A8701 for ; Fri, 17 Oct 2014 14:56:45 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id B6CA0BAFB65A1; Fri, 17 Oct 2014 21:56:40 +0000 (GMT) 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 s9HLuiHR015716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 17:56:44 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 17:56:44 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model: Connecting Tasks Thread-Index: AQHP6IC4e54LYC3BTk2yq03a9beAt5wxsZXQgAKNpICAAN1MkA== Date: Fri, 17 Oct 2014 21:56:42 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> In-Reply-To: <20141017084439.GC80274@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Lh1vLQAZPkOH-KSyx4DPCbOkRy0 Cc: "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 21:56:48 -0000 Juergen, If you make queues part of the information model then we will require that = the scheduling be done via a queue interface as the information element is = part of the specification. I just wanted to avoid over engineering at this = point. As to the technical concern: The only technical concern I have heard is tha= t the current information model does by design now allow to have multiple c= onsumers of data. I guess if you provide abit more explanation as to what y= ou are asking for here.=20 As I understand the model, A scheduled task has a list of Downstream tasks.= An instance of a Downstream task has a filter based on the Output selectio= ns - multiple Downstream tasks can have the same output selection as far as= I understand it. A downstream task is also associated with one or more oth= er Tasks that is the object of the downstream tasks.=20 So multiple consumers (tasks that objects of a downstream task) of data (ou= tput selection of the scheduled task) is possible. Did I misunderstand some= thing? Thanks, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, October 17, 2014 3:45 AM To: Carey, Timothy (Timothy) Cc: trevor.burbridge@bt.com; lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks On Wed, Oct 15, 2014 at 09:48:07PM +0000, Carey, Timothy (Timothy) wrote: > Trevor, >=20 > Again - I believe you were seeking a wider audience viewpoint but.. > In Dublin - I believe I expressed that I didn't think queues were=20 > necessary. It seems abit over-engineered. I know from a TR-069 data=20 > model standpoint I have been able to model the Scheduled task that is=20 > simply directed to another task as you suggested. Timothy, while you can hide the queues in the information model, they will exist in = implementations and they will have impact on how an implementation behaves.= If a measurement task produces data faster than say a reporting task picks= it up, then at some time something happens, e.g., the measurement task get= s blocked or data is getting dropped (either new incoming data, or old data= purged, or something random). Even if we decide that we do not want to go = into defining different queues and their behaviour today (which may be reas= onable in order to get a first version finished and implementation experien= ce), we may want implementations to report queue specific statistics (e.g. = a drop rate) and we may want future version of LMAP to provide more details= for configuring the behavior of the queues. By making queues first class c= itizens now, we are open to such future LMAP extensions and we allow implem= entations to provide proprietary extensions for example to report queue sta= tistics even now. The only technical concern I have heard is that the current information mod= el does by design now allow to have multiple consumers of data. If this res= triction is desirable, I am sure we can also have it with explicit queues. /js (sorry for repeating my proposal once more ;-) --=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 Sun Oct 19 23:36:22 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837891A6FBC for ; Sun, 19 Oct 2014 23:36:17 -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 8MZYifTMxBMn for ; Sun, 19 Oct 2014 23:36:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1531A0378 for ; Sun, 19 Oct 2014 23:36: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 341E98E4; Mon, 20 Oct 2014 08:36:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TvVdFGPkAKGj; Mon, 20 Oct 2014 08:36:14 +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, 20 Oct 2014 08:36:14 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B602E2003F; Mon, 20 Oct 2014 08:36:14 +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 yY2rTJSqj6Vn; Mon, 20 Oct 2014 08:36:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5F452003A; Mon, 20 Oct 2014 08:36:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B6EB32F03C2A; Mon, 20 Oct 2014 08:36:13 +0200 (CEST) Date: Mon, 20 Oct 2014 08:36:13 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20141020063613.GD86545@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "trevor.burbridge@bt.com" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/wZKsvJRlzm4Cj5EKL3kFIyYLCGI Cc: "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 06:36:19 -0000 On Fri, Oct 17, 2014 at 09:56:42PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > If you make queues part of the information model then we will require that the scheduling be done via a queue interface as the information element is part of the specification. I just wanted to avoid over engineering at this point. I do not understand this. > As to the technical concern: The only technical concern I have heard is that the current information model does by design now allow to have multiple consumers of data. I guess if you provide abit more explanation as to what you are asking for here. Please read my previous post. My motivation is now what you claim. /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 Oct 20 00:03:36 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397A61A6FC7 for ; Mon, 20 Oct 2014 00:03:34 -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 Eh2tKaI8UN0G for ; Mon, 20 Oct 2014 00:03:30 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF83A1A6FC4 for ; Mon, 20 Oct 2014 00:03:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5B59C8E4; Mon, 20 Oct 2014 09:03:23 +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 Z05eDqexALlt; Mon, 20 Oct 2014 09:03:21 +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, 20 Oct 2014 09:03:21 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5000E20038; Mon, 20 Oct 2014 09:03:21 +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 P5IGkRVz335J; Mon, 20 Oct 2014 09:03:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D18E620035; Mon, 20 Oct 2014 09:03:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A5A302F03D01; Mon, 20 Oct 2014 09:03:19 +0200 (CEST) Date: Mon, 20 Oct 2014 09:03:19 +0200 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20141020070319.GA86721@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, lmap@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ytEzr3mFUmrHqe2WrDNnOxhMQXI Cc: lmap@ietf.org Subject: Re: [lmap] Information Model: Task Configuration 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, 20 Oct 2014 07:03:34 -0000 On Wed, Oct 15, 2014 at 02:18:26PM +0100, trevor.burbridge@bt.com wrote: > During Dublin we debated (but didn't come to a strong conclusion on) two key topics. This is the first of those topics. > > Currently we have a concept of a Task Configuration where task parameters can be configured. The same Task Configuration can then be referenced multiple times from number of different Schedules. > > It was pointed out that this can be very inefficient if we want to run basically the same task with just one parameter changing each time such as the test target. E.g. if we are running against 10 different targets then we largely have to reproduce and transmit to the MA 10 very similar Task Configurations. > > The options as I understand them are: > > - Specify all parameters in Task Configurations is fine. Conceptually simple is more important than efficiency > > - Allow a hierarchical inheritance of Task Configurations. I.e. define a general Task Configuration and the specialise for 10 different targets. May be very confusing for people not familiar with such concepts especially at the data model level. > > - Allow task parameters to be specified either by using/referencing a Task Configuration or by supplying them within a Schedule. E.g. this would allow a general Task Configuration to be used but the target could be supplied within the Schedule. Conceptually clean, flexible and allows the optimum balance. > > All options are as powerful as each other so it comes down to which is easier to understand and which is more efficient. > Let me expand on the third option: The Task Configuration is a name/value pair list. A bSchedule has another name/value pair list that is conceptually appended (or prepended - to be decided) to the Task Configuration list. The measurement task will have to decide based on the semantics of the parameters involved whether a repeated name/value pair is an overwrite or an addition. (This is nothing new since the Task Configuration even today allows repeated name/value pairs and this does make sense.) I believe this is conceptually simple. More 'static' task configuration parameters can be shared between schedules while more 'dynamic' task configuration parameters can go into the schedules. Example: For a ping6 ping, you may want to configure relatively static parameters such as the flow label to use, the interval between each packet, whether it is using IMCPv6 Echo requests or Node Information Queries, the DSCP value to use, the packet size, etc. in a Task Configuration and in the Schedule you configure the target(s) to be probed with these Task Configuration parameters. /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 Oct 20 11:20: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 2F3281A8AFB for ; Mon, 20 Oct 2014 11:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 4oA_sgeZ7gcn for ; Mon, 20 Oct 2014 11:20:30 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:1:8::180:100]) by ietfa.amsl.com (Postfix) with ESMTP id 53DF81A8AF6 for ; Mon, 20 Oct 2014 11:20:30 -0700 (PDT) Received: from [10.0.0.43] (89.80-202-16.nextgentel.com [80.202.16.89]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by epost.uninett.no (Postfix) with ESMTPSA id 8247E336548 for ; Mon, 20 Oct 2014 20:20:28 +0200 (CEST) Message-ID: <5445526C.8050409@uninett.no> Date: Mon, 20 Oct 2014 20:20:28 +0200 From: Arne Oslebo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: lmap@ietf.org References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> In-Reply-To: <20141020063613.GD86545@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FPyssnksjsfVfufbOoaDhiZXUTM Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:20:33 -0000 I agree with Timothy and would prefer not to include anything about queues in the information model. If we need to define queuing behavior then I think it is better done as part of the task definition. Queuing requirements for logging and reporting might be different. This will also make it easier for people who do not agree with the standardized queuing behavior to come up with their own solutions. Arne On 20. okt. 2014 08:36, Juergen Schoenwaelder wrote: > On Fri, Oct 17, 2014 at 09:56:42PM +0000, Carey, Timothy (Timothy) wrote: >> Juergen, >> >> If you make queues part of the information model then we will require that the scheduling be done via a queue interface as the information element is part of the specification. I just wanted to avoid over engineering at this point. > I do not understand this. > >> As to the technical concern: The only technical concern I have heard is that the current information model does by design now allow to have multiple consumers of data. I guess if you provide abit more explanation as to what you are asking for here. > Please read my previous post. My motivation is now what you claim. > > /js > From nobody Mon Oct 20 13:16: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 B27A41ACD8F for ; Mon, 20 Oct 2014 13:16:50 -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 TfrF5CFYXS_T for ; Mon, 20 Oct 2014 13:16:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1914F1ACDC3 for ; Mon, 20 Oct 2014 13:16:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 804B19CF; Mon, 20 Oct 2014 22:16:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 574wseFNf_VM; Mon, 20 Oct 2014 22:16:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 20 Oct 2014 22:16:43 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B542F20037; Mon, 20 Oct 2014 22:16:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id M5bRRtRcSbFL; Mon, 20 Oct 2014 22:16:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 633C020035; Mon, 20 Oct 2014 22:16:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 571BB2F058F6; Mon, 20 Oct 2014 22:16:42 +0200 (CEST) Date: Mon, 20 Oct 2014 22:16:42 +0200 From: Juergen Schoenwaelder To: Arne Oslebo Message-ID: <20141020201642.GA89064@elstar.local> Mail-Followup-To: Arne Oslebo , lmap@ietf.org References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <5445526C.8050409@uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5445526C.8050409@uninett.no> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/zpc0jOOGYQnhJ-dUXxYdkLHZxso Cc: lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:16:50 -0000 On Mon, Oct 20, 2014 at 08:20:28PM +0200, Arne Oslebo wrote: > I agree with Timothy and would prefer not to include anything about > queues in the information model. If we need to define queuing behavior > then I think it is better done as part of the task definition. Queuing > requirements for logging and reporting might be different. This will > also make it easier for people who do not agree with the standardized > queuing behavior to come up with their own solutions. Are you saying that every output channel of every task should have an independent queue but we better don't say so because being silent about queues allows everybody to implement what they like? I fail to see how we will get robust interoperable behaviour by leaving this completely open to interpretation and implementation choice. By robust I mean implementations that still behave in a predictable way in case of resource shortage (e.g. memory) or malfunctioning tasks in a chain of tasks (which may eventually lead to resource shortage). /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 Oct 21 00: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 94AAC1AD094 for ; Tue, 21 Oct 2014 00:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 ydHjBxzHNQua for ; Tue, 21 Oct 2014 00:14:42 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:1:8::180:100]) by ietfa.amsl.com (Postfix) with ESMTP id 042F91AD080 for ; Tue, 21 Oct 2014 00:14:41 -0700 (PDT) Received: from [IPv6:2001:700:1:0:3e97:eff:fe72:2ef7] (unknown [IPv6:2001:700:1:0:3e97:eff:fe72:2ef7]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by epost.uninett.no (Postfix) with ESMTPSA id C1465336655 for ; Tue, 21 Oct 2014 09:14:39 +0200 (CEST) Message-ID: <544607DF.3050802@uninett.no> Date: Tue, 21 Oct 2014 09:14:39 +0200 From: Arne Oslebo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: lmap@ietf.org References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <5445526C.8050409@uninett.no> <20141020201642.GA89064@elstar.local> In-Reply-To: <20141020201642.GA89064@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FJtGlXPqDDldSJhtZ5sw9_SF1Ag Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 07:14:45 -0000 On 20. okt. 2014 22:16, Juergen Schoenwaelder wrote: > On Mon, Oct 20, 2014 at 08:20:28PM +0200, Arne Oslebo wrote: >> I agree with Timothy and would prefer not to include anything about >> queues in the information model. If we need to define queuing behavior >> then I think it is better done as part of the task definition. Queuing >> requirements for logging and reporting might be different. This will >> also make it easier for people who do not agree with the standardized >> queuing behavior to come up with their own solutions. > Are you saying that every output channel of every task should have an > independent queue No, I'm saying that tasks that need it can have an input queue. > but we better don't say so because being silent > about queues allows everybody to implement what they like? I fail to > see how we will get robust interoperable behaviour by leaving this > completely open to interpretation and implementation choice. By robust > I mean implementations that still behave in a predictable way in case > of resource shortage (e.g. memory) or malfunctioning tasks in a chain > of tasks (which may eventually lead to resource shortage). I don't disagree that it can be good to standardize the queuing behavior, but I do not think it belongs in the information model. It has already been mentioned that we need a repository of common tasks like logging and reporting, and I think it's better to define the queuing behavior when we define these tasks. Arne From nobody Tue Oct 21 00:17: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 5F41F1A6FBE for ; Tue, 21 Oct 2014 00:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 NQslU2c6QuMa for ; Tue, 21 Oct 2014 00:17:24 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:1:8::180:100]) by ietfa.amsl.com (Postfix) with ESMTP id BE18A1AD069 for ; Tue, 21 Oct 2014 00:17:23 -0700 (PDT) Received: from [IPv6:2001:700:1:0:3e97:eff:fe72:2ef7] (unknown [IPv6:2001:700:1:0:3e97:eff:fe72:2ef7]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by epost.uninett.no (Postfix) with ESMTPSA id E0A3D336655; Tue, 21 Oct 2014 09:17:22 +0200 (CEST) Message-ID: <54460882.90402@uninett.no> Date: Tue, 21 Oct 2014 09:17:22 +0200 From: Arne Oslebo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <5445526C.8050409@uninett.no>, <20141020201642.GA89064@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/gW6xw8KYw4yndbqmtfTTc9-GU8w Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 07:17:27 -0000 On 20. okt. 2014 23:22, MORTON, ALFRED C (AL) wrote: > ________________________________________ > From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 20, 2014 4:16 PM > To: Arne Oslebo > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model: Connecting Tasks > > On Mon, Oct 20, 2014 at 08:20:28PM +0200, Arne Oslebo wrote: >> I agree with Timothy and would prefer not to include anything about >> queues in the information model. If we need to define queuing behavior >> then I think it is better done as part of the task definition. Queuing >> requirements for logging and reporting might be different. This will >> also make it easier for people who do not agree with the standardized >> queuing behavior to come up with their own solutions. > Are you saying that every output channel of every task should have an > independent queue but we better don't say so because being silent > about queues allows everybody to implement what they like? I fail to > see how we will get robust interoperable behaviour by leaving this > completely open to interpretation and implementation choice. By robust > I mean implementations that still behave in a predictable way in case > of resource shortage (e.g. memory) or malfunctioning tasks in a chain > of tasks (which may eventually lead to resource shortage). > > /js > > ACM: > > +1, the need for queuing output between schedule events seems rather obvious. > Clarity and consistency can be achieved if we embrace the concept, we can > still stop short of requirements for the size of the queue, etc. allowing > vendors to provide their size of choice. It might be obvious that we need queuing, but I do not think it is obvious what kind of queuing mechanism we need. I think it is a bad idea to introduce a common queuing element in the information model that forces us to implement a specific queuing mechanism for all types of tasks. For logging it might be good to have some kind of priority based queue so that errors have a higher priority than warning or informational messages, but for reporting a normal FIFO might be best. That is why I would prefer to standardize queuing behavior as part of the task definition and not in the information model. Arne From nobody Tue Oct 21 06:00: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 2D5881A1B4E for ; Tue, 21 Oct 2014 06:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 aXC6m-7UTR1v for ; Tue, 21 Oct 2014 06:00:23 -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 BC1DD1A1B67 for ; Tue, 21 Oct 2014 06:00:19 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 08AE5121F28; Tue, 21 Oct 2014 09:09:47 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id 7586FF03FF; Tue, 21 Oct 2014 09:00:19 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Tue, 21 Oct 2014 09:00:19 -0400 From: "MORTON, ALFRED C (AL)" To: Arne Oslebo , Juergen Schoenwaelder Date: Tue, 21 Oct 2014 09:00:19 -0400 Thread-Topic: [lmap] Information Model: Connecting Tasks Thread-Index: Ac/s/xI+9iq7Jmr2R+yUX0uFmYXfhwALbfOY Message-ID: <4AF73AA205019A4C8A1DDD32C034631D7BBF8A08@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <5445526C.8050409@uninett.no>,<20141020201642.GA89064@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com>, <54460882.90402@uninett.no> In-Reply-To: <54460882.90402@uninett.no> 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/J3WcrnsyxFmZ3KkWAsSD4dpKaBE Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:00:27 -0000 Hi Arne, There's a misunderstanding somewhere between: Al wrote: > Clarity and consistency can be achieved if we embrace the concept, we can > still stop short of requirements for the size of the queue, etc. ... Arne wrote: ...I think it is a bad idea to introduce a common queuing element in the information model that forces us to implement a specific queuing mechanism for all types of tasks. ---- I agree that queue design and feature specifics could be part of the task d= efinition. The queue in the Information Model is abstract, the same way tasks are abst= ract. Implementors will have freedom until they choose a task to build. Can you live with the abstract notion of a queue in the Info Model? Al PS: Arne replied to a my message from yesterday which mailman discarded du= e to out-going address issues, see below. ________________________________________ From: Arne Oslebo [arne.oslebo@uninett.no] Sent: Tuesday, October 21, 2014 3:17 AM To: MORTON, ALFRED C (AL); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks On 20. okt. 2014 23:22, MORTON, ALFRED C (AL) wrote: > ________________________________________ > From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder [j.= schoenwaelder@jacobs-university.de] > Sent: Monday, October 20, 2014 4:16 PM > To: Arne Oslebo > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Model: Connecting Tasks > > On Mon, Oct 20, 2014 at 08:20:28PM +0200, Arne Oslebo wrote: >> I agree with Timothy and would prefer not to include anything about >> queues in the information model. If we need to define queuing behavior >> then I think it is better done as part of the task definition. Queuing >> requirements for logging and reporting might be different. This will >> also make it easier for people who do not agree with the standardized >> queuing behavior to come up with their own solutions. > Are you saying that every output channel of every task should have an > independent queue but we better don't say so because being silent > about queues allows everybody to implement what they like? I fail to > see how we will get robust interoperable behaviour by leaving this > completely open to interpretation and implementation choice. By robust > I mean implementations that still behave in a predictable way in case > of resource shortage (e.g. memory) or malfunctioning tasks in a chain > of tasks (which may eventually lead to resource shortage). > > /js > > ACM: > > +1, the need for queuing output between schedule events seems rather obvi= ous. > Clarity and consistency can be achieved if we embrace the concept, we can > still stop short of requirements for the size of the queue, etc. allowing > vendors to provide their size of choice. It might be obvious that we need queuing, but I do not think it is obvious what kind of queuing mechanism we need. I think it is a bad idea to introduce a common queuing element in the information model that forces us to implement a specific queuing mechanism for all types of tasks. For logging it might be good to have some kind of priority based queue so that errors have a higher priority than warning or informational messages, but for reporting a normal FIFO might be best. That is why I would prefer to standardize queuing behavior as part of the task definition and not in the information model. Arne From nobody Tue Oct 21 06:06:55 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EF31A1B7F for ; Tue, 21 Oct 2014 06:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p1rNr1mRxKt0 for ; Tue, 21 Oct 2014 06:06:40 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA651A1B67 for ; Tue, 21 Oct 2014 06:06:38 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 9BE4EC82309CF; Tue, 21 Oct 2014 13:06:35 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9LD6acF027097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 09:06:37 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 09:06:37 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model: Connecting Tasks Thread-Index: AQHP6IC4e54LYC3BTk2yq03a9beAt5wxsZXQgAKNpICAAN1MkIADtdCAgAH/ZuA= Date: Tue, 21 Oct 2014 13:06:35 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734FC4476@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> In-Reply-To: <20141020063613.GD86545@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/TozAfzzUqoxu0n_2q5ZtPtORo44 Cc: "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:06:46 -0000 Juergen, My comment on making the queue a formal part of the information model would= be that there would be an expectation to make these first class objects in= the data models and associated protocols. Also testing and certification would also assume queue behavior. I am not against using queues to implement this solution. I just didn't nee= d to model the queues to implement the behavior of the existing information= model when I developed the TR-069 data model and protocol. As to the technical concern - Sorry I misread you post "does NOW allow" as = "does NOT allow". No I have no concerns that the information model "does al= low" multiple consumers of an output through modeling of multiple Tasks. Thanks, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 20, 2014 1:36 AM To: Carey, Timothy (Timothy) Cc: trevor.burbridge@bt.com; lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks On Fri, Oct 17, 2014 at 09:56:42PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > If you make queues part of the information model then we will require tha= t the scheduling be done via a queue interface as the information element i= s part of the specification. I just wanted to avoid over engineering at thi= s point. I do not understand this. =20 > As to the technical concern: The only technical concern I have heard is t= hat the current information model does by design now allow to have multiple= consumers of data. I guess if you provide abit more explanation as to what= you are asking for here.=20 Please read my previous post. My motivation is now what you claim. /js=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Oct 22 08:40: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 5EA631ACD7D for ; Wed, 22 Oct 2014 08:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 5wkQ2EC-jDJZ for ; Wed, 22 Oct 2014 08:40:26 -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 183C81ACD79 for ; Wed, 22 Oct 2014 08:40:26 -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 AC8D5122379 for ; Wed, 22 Oct 2014 11:45:16 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-green.research.att.com (Postfix) with ESMTP id 8EF40E0355 for ; Wed, 22 Oct 2014 11:33:14 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Wed, 22 Oct 2014 11:35:42 -0400 From: "MORTON, ALFRED C (AL)" To: "lmap@ietf.org" Date: Wed, 22 Oct 2014 11:34:29 -0400 Thread-Topic: [lmap] Information Model: Connecting Tasks Thread-Index: Ac/sotJLOa1y0ypcTcuSqYhHp0iAIgACHKHIAFiZngw= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D7BBF8A11@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <5445526C.8050409@uninett.no>, <20141020201642.GA89064@elstar.local>, <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_LIjnnGURBLmN98IeUymV3YBmDM Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:40:27 -0000 Re-sending the discarded message as a test, as instructed by ietf-action. ________________________________________ From: MORTON, ALFRED C (AL) Sent: Monday, October 20, 2014 5:22 PM To: Juergen Schoenwaelder; Arne Oslebo Cc: lmap@ietf.org Subject: RE: [lmap] Information Model: Connecting Tasks ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder [j.sc= hoenwaelder@jacobs-university.de] Sent: Monday, October 20, 2014 4:16 PM To: Arne Oslebo Cc: lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks On Mon, Oct 20, 2014 at 08:20:28PM +0200, Arne Oslebo wrote: > I agree with Timothy and would prefer not to include anything about > queues in the information model. If we need to define queuing behavior > then I think it is better done as part of the task definition. Queuing > requirements for logging and reporting might be different. This will > also make it easier for people who do not agree with the standardized > queuing behavior to come up with their own solutions. Are you saying that every output channel of every task should have an independent queue but we better don't say so because being silent about queues allows everybody to implement what they like? I fail to see how we will get robust interoperable behaviour by leaving this completely open to interpretation and implementation choice. By robust I mean implementations that still behave in a predictable way in case of resource shortage (e.g. memory) or malfunctioning tasks in a chain of tasks (which may eventually lead to resource shortage). /js ACM: +1, the need for queuing output between schedule events seems rather obviou= s. Clarity and consistency can be achieved if we embrace the concept, we can still stop short of requirements for the size of the queue, etc. allowing vendors to provide their size of choice. I don't understand the damage we cause if we recognize the queue, but willing to listen... Al From nobody Wed Oct 22 09:22: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 03F8B1ACDDA for ; Wed, 22 Oct 2014 09:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 c0QR6zwP7ULx for ; Wed, 22 Oct 2014 09:22:35 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF1A1ACDDC for ; Wed, 22 Oct 2014 09:22:35 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3F0BBA2851; Wed, 22 Oct 2014 12:22:34 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id F3CE2A284B; Wed, 22 Oct 2014 12:22:33 -0400 (EDT) Received: from SPQCMBX01.exfo.com ([169.254.1.252]) by SPQCCAS01.exfo.com ([10.28.36.8]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 12:22:34 -0400 From: Sharam Hakimi To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" Thread-Topic: [lmap] Information Model: Connecting Tasks Thread-Index: Ac/ofHtSaYdiY6Y/R4mNbjroR+i0BgACHKHIAFiZngwBCuiJYA== Date: Wed, 22 Oct 2014 16:22:32 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FED28A5@SPQCMBX01.exfo.com> References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <5445526C.8050409@uninett.no>, <20141020201642.GA89064@elstar.local>, <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A11@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D7BBF8A11@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-21042.006 X-TM-AS-Result: No--20.228-5.0-31-10 X-imss-scan-details: No--20.228-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-21042.006 X-TMASE-Result: 10--20.228400-5.000000 X-TMASE-MatchedRID: vEvJ7Rh1lGi0/JWJqIoqpmlHv4vQHqYToprEeoZHCQJZps+y1VXzqZpM kX9JMkJeGtEezVCnuxYezahljRyv3bzh4ZQI6lGcFYJUGv4DL3xR3sGN+j7mNOoWVODXAWfc0u5 faGP8ztSsoSOPLfWSWyH4SCJczjYbmGTohEsziMfMuewaQUInJLj0igGiOeKhDXHJBD8X89gFTP ZD7GmMeBt44KRVTewWWFjIDAh8gUa6de0YULw0FpCYtcHXhxbabveZreOw8zZtOgtW77/SphOuo XXlTr98CBG3yFdIPKTb0gjdp/sQ9UsimGEcVY8yDB+ErBr0bAMXZ6k61HUJz4FN4EqoFGbyDJWq LmHeBUlo99KIRMCHOMkFfAV3rlkw717yJ8IcCttCvapcIkxJX3WT6A/Vdqa0myiLZetSf8l9j2G wzTE3vSq2rl3dzGQ1A/3R8k/14e0= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/NRNIrfYZOTY7EHphY1QrMGioB6U Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 16:22:38 -0000 What I think needs to be specified is that an MA must have enough capabilit= y(CPU power, memory, etc.) to execute a single defined task( run task, log,= transfer results). Beyond that really should be up to the implementation. = If one can design an inexpensive device with multiple core CPUs and Gigs of= memory that allows for multiple concurrent tasks then that is up to the im= plementer.=20 I do not think we should manage implementations, rather specify the resourc= e requirement for every defined task. Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Wednesday, October 22, 2014 11:34 AM To: lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks Re-sending the discarded message as a test, as instructed by ietf-action. ________________________________________ From: MORTON, ALFRED C (AL) Sent: Monday, October 20, 2014 5:22 PM To: Juergen Schoenwaelder; Arne Oslebo Cc: lmap@ietf.org Subject: RE: [lmap] Information Model: Connecting Tasks ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder [j.sc= hoenwaelder@jacobs-university.de] Sent: Monday, October 20, 2014 4:16 PM To: Arne Oslebo Cc: lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks On Mon, Oct 20, 2014 at 08:20:28PM +0200, Arne Oslebo wrote: > I agree with Timothy and would prefer not to include anything about > queues in the information model. If we need to define queuing behavior > then I think it is better done as part of the task definition. Queuing > requirements for logging and reporting might be different. This will > also make it easier for people who do not agree with the standardized > queuing behavior to come up with their own solutions. Are you saying that every output channel of every task should have an independent queue but we better don't say so because being silent about queues allows everybody to implement what they like? I fail to see how we will get robust interoperable behaviour by leaving this completely open to interpretation and implementation choice. By robust I mean implementations that still behave in a predictable way in case of resource shortage (e.g. memory) or malfunctioning tasks in a chain of tasks (which may eventually lead to resource shortage). /js ACM: +1, the need for queuing output between schedule events seems rather obviou= s. Clarity and consistency can be achieved if we embrace the concept, we can still stop short of requirements for the size of the queue, etc. allowing vendors to provide their size of choice. I don't understand the damage we cause if we recognize the queue, but willing to listen... Al _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Oct 22 11:43: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 06C4B1A8721 for ; Wed, 22 Oct 2014 11:43:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 3Yzg_BH45GhV for ; Wed, 22 Oct 2014 11:43:35 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA9D1ACF8C for ; Wed, 22 Oct 2014 11:43:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1EB926FD; Wed, 22 Oct 2014 20:43:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id W9VTF2EyCNl9; Wed, 22 Oct 2014 20:43:30 +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, 22 Oct 2014 20:43:32 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3FBEB20037; Wed, 22 Oct 2014 20:43:32 +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 7ZkufVOZH7DA; Wed, 22 Oct 2014 20:43:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6087A20035; Wed, 22 Oct 2014 20:43:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5664D2F0A249; Wed, 22 Oct 2014 20:43:28 +0200 (CEST) Date: Wed, 22 Oct 2014 20:43:28 +0200 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20141022184328.GA94731@elstar.local> Mail-Followup-To: Sharam Hakimi , "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A11@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED28A5@SPQCMBX01.exfo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70FED28A5@SPQCMBX01.exfo.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/q0jvJAUCmkpNjfpY3k3iD3ND3M0 Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:43:37 -0000 On Wed, Oct 22, 2014 at 04:22:32PM +0000, Sharam Hakimi wrote: > What I think needs to be specified is that an MA must have enough capability(CPU power, memory, etc.) to execute a single defined task( run task, log, transfer results). Beyond that really should be up to the implementation. If one can design an inexpensive device with multiple core CPUs and Gigs of memory that allows for multiple concurrent tasks then that is up to the implementer. > > I do not think we should manage implementations, rather specify the resource requirement for every defined task. > Using LMAP, I can configure (a) how frequently a measurement test is executed (and hence how much data it produces) and (b) how frequently a reporting task is executed. In other words, the amount of buffer space I need depends on the schedule(s) and hence it is out of the control of the implementation. Even if an implementation tries to reject schedules that may potentially overrun resources, once you loose connectivity it surely can run out of resources again. Assuming an implementation has always sufficient resources is unrealistic and definitely not something that can be specified. Note: We are not talking about the execution of a single task but instead about how data is passed between tasks. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Oct 23 08:16: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 E74211AC39F for ; Thu, 23 Oct 2014 08:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EAEanJsoO2vK for ; Thu, 23 Oct 2014 08:16:44 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id 2938E1AC3CA for ; Thu, 23 Oct 2014 08:16:44 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 86CE6A28C6; Thu, 23 Oct 2014 11:16:40 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 48161A2872; Thu, 23 Oct 2014 11:16:40 -0400 (EDT) Received: from SPQCMBX01.exfo.com ([169.254.1.252]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 11:16:40 -0400 From: Sharam Hakimi To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model: Connecting Tasks Thread-Index: Ac/ofHtSaYdiY6Y/R4mNbjroR+i0BgACHKHIAFiZngwBCuiJYAANqJQAACHLIUA= Date: Thu, 23 Oct 2014 15:16:39 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FED2B21@SPQCMBX01.exfo.com> References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A11@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED28A5@SPQCMBX01.exfo.com> <20141022184328.GA94731@elstar.local> In-Reply-To: <20141022184328.GA94731@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.1018-21046.000 X-TM-AS-Result: No--14.601-5.0-31-10 X-imss-scan-details: No--14.601-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-21046.000 X-TMASE-Result: 10--14.601300-5.000000 X-TMASE-MatchedRID: 8+bhjh9TQnFzgDEqoQager50lYduDghOHfhlf9G5qF0oG/4CHNlRARtj JIHngtExqRXt5xlhTnwZqhQbVgkeSjlyVH8jNStNzMU0F3CreX5eNk/Yw6yJPRSzGeAOjJwLj7V ue0RgT/XWYeAcryogDf7DffVOwda7gvd6NMLGYikmtTGirqG/DwvxMaV6x4s8CVuEXtlNqcv8DC Z883e7OEM1quPvEyyrqj6QXerRcQNrHPrHzGoF4vVKwtcycSUsCt59Uh3p/NVzwVmY5TMrNvWRt l2G9fzDojLvHeRevkRHvkPFdlT8FRgQ2oZCJdupox5cBdU3pAdW/TWdUAkcwpPOTcYj4US40TD6 UetkoeWWUaXKwoXzYbh8wiI4NasiQ6tklRJO9igLbigRnpKlKSPzRlrdFGDwE50u/0H0Uz5JD9+ pqcVlgTbhvw+l1mPER/7pOGW/CQFDRzj+ozxLJw== Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/QWfzorNslK7qfYiUEoD1tkph58w Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 15:16:46 -0000 As an example, when a car is designed each part in the car defines the powe= r requirement for it to run. The Battery/Alternator system is designed base= d on as many parts that can run concurrently and that is up to implementati= on. Not all MAs will be created equal and I do not believe that we need to = specify an implementation. The user will dictate what their requirement is = and the implementation would need to match that. How many queues to handle = is up to the implementation. Today One server can handle 100 TWAMP connection and perform the test and a= nother can handle 1000. TWAMP does not specify the implementation, just wha= t is required to schedule, run, capture results and report results for one = instance. Sharam=20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, October 22, 2014 2:43 PM To: Sharam Hakimi Cc: MORTON, ALFRED C (AL); lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks On Wed, Oct 22, 2014 at 04:22:32PM +0000, Sharam Hakimi wrote: > What I think needs to be specified is that an MA must have enough capabil= ity(CPU power, memory, etc.) to execute a single defined task( run task, lo= g, transfer results). Beyond that really should be up to the implementation= . If one can design an inexpensive device with multiple core CPUs and Gigs = of memory that allows for multiple concurrent tasks then that is up to the = implementer.=20 >=20 > I do not think we should manage implementations, rather specify the resou= rce requirement for every defined task. >=20 Using LMAP, I can configure (a) how frequently a measurement test is executed (and hence how much data it produces) and (b) how frequently a reporting task is executed. In other words, the amount of buffer space I need depends on the schedule(s) and hence it is out of the control of the implementation. Even if an implementation tries to reject schedules that may potentially overrun resources, once you loose connectivity it surely can run out of resources again. Assuming an implementation has always sufficient resources is unrealistic and definitely not something that can be specified. Note: We are not talking about the execution of a single task but instead about how data is passed between tasks. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Oct 23 10:52:15 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B331ACE5D for ; Thu, 23 Oct 2014 10:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 2aEMVbZBuvzB for ; Thu, 23 Oct 2014 10:52:05 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D228B1A90FF for ; Thu, 23 Oct 2014 10:51:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApILAJY/SVSHCzIm/2dsb2JhbABcgkgjIyA0WQO5EwYFkzsbAQmHTQKBEhYBAXELhAQBAQMSG14BDAkVViYBBBsBGYgfAQykRYRtnzMghiWKAoJuD0QkgR4FkgWNCYNJgxuKF4QBg3iCNIEDAQEB X-IronPort-AV: E=Sophos; i="5.04,776,1406606400"; d="scan'208,217"; a="77900349" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Oct 2014 13:50:52 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 23 Oct 2014 13:50:51 -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, 23 Oct 2014 19:50:49 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: IETF-91 preliminary agenda Thread-Index: Ac/u6eCV/dwmVAQBQze8losyUOzOLQ== Date: Thu, 23 Oct 2014 17:50:48 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@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_9904FB1B0159DA42B0B887B7FA8119CA5C8DA22BAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/AArco3XVR_rGktuIwNUX_XZjyuY Subject: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Oct 2014 17:52:07 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DA22BAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DA22BAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have loaded a preliminary agenda for the meeting a= t IETF-91. You can find it at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still need to fi= ll in a number of TBD – who will lead the Information Model discussio= n? What protocol submissions will be proposed and who will lead the discussions? Please send your requests to Jason and = me, and do not forget that I-D submissions cut-off is Monday 10/27.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DA22BAZFFEXMB04globa_-- From nobody Thu Oct 23 11:07: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 BAA8A1A90FC for ; Thu, 23 Oct 2014 11:07:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Qk-4H56_ialf for ; Thu, 23 Oct 2014 11:07:44 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63671A9028 for ; Thu, 23 Oct 2014 11:07:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 14EF38FF; Thu, 23 Oct 2014 20:07:42 +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 jvvZU2jPdHSn; Thu, 23 Oct 2014 20:07:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 23 Oct 2014 20:07:40 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFA2E20037; Thu, 23 Oct 2014 20:07:40 +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 9NMLp0x2c9in; Thu, 23 Oct 2014 20:07:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D761C20035; Thu, 23 Oct 2014 20:07:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A6C292F0C3CB; Thu, 23 Oct 2014 20:07:37 +0200 (CEST) Date: Thu, 23 Oct 2014 20:07:36 +0200 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20141023180734.GA97528@elstar.local> Mail-Followup-To: Sharam Hakimi , "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A11@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED28A5@SPQCMBX01.exfo.com> <20141022184328.GA94731@elstar.local> <89294A6F3C6C91459E52E4128C4B02B70FED2B21@SPQCMBX01.exfo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70FED2B21@SPQCMBX01.exfo.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/GBGvAerekndaMNwueBTSsAT_Ses Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 18:07:47 -0000 Making queues explicit in the information model != specify the implementation. Without some form of queues, you can't pass information between tasks that run on different schedules. Following you analogy, I am saying we should say that the car has an engine instead of pretending all it has is a gas pedal. Once your car stops, it will become important to know whether you need to look for electicity or some other type of fuel. I guess analogies do not help much... /js On Thu, Oct 23, 2014 at 03:16:39PM +0000, Sharam Hakimi wrote: > As an example, when a car is designed each part in the car defines the power requirement for it to run. The Battery/Alternator system is designed based on as many parts that can run concurrently and that is up to implementation. Not all MAs will be created equal and I do not believe that we need to specify an implementation. The user will dictate what their requirement is and the implementation would need to match that. How many queues to handle is up to the implementation. > > Today One server can handle 100 TWAMP connection and perform the test and another can handle 1000. TWAMP does not specify the implementation, just what is required to schedule, run, capture results and report results for one instance. > > > Sharam > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, October 22, 2014 2:43 PM > To: Sharam Hakimi > Cc: MORTON, ALFRED C (AL); lmap@ietf.org > Subject: Re: [lmap] Information Model: Connecting Tasks > > On Wed, Oct 22, 2014 at 04:22:32PM +0000, Sharam Hakimi wrote: > > What I think needs to be specified is that an MA must have enough capability(CPU power, memory, etc.) to execute a single defined task( run task, log, transfer results). Beyond that really should be up to the implementation. If one can design an inexpensive device with multiple core CPUs and Gigs of memory that allows for multiple concurrent tasks then that is up to the implementer. > > > > I do not think we should manage implementations, rather specify the resource requirement for every defined task. > > > > Using LMAP, I can configure (a) how frequently a measurement test is > executed (and hence how much data it produces) and (b) how frequently > a reporting task is executed. In other words, the amount of buffer > space I need depends on the schedule(s) and hence it is out of the > control of the implementation. Even if an implementation tries to > reject schedules that may potentially overrun resources, once you > loose connectivity it surely can run out of resources again. > > Assuming an implementation has always sufficient resources is > unrealistic and definitely not something that can be specified. > > Note: We are not talking about the execution of a single task but > instead about how data is passed between tasks. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Oct 23 11:21:13 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7CE1A9138 for ; Thu, 23 Oct 2014 11:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 sxSBHmjXhEOr for ; Thu, 23 Oct 2014 11:21:10 -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 1977E1A90FC for ; Thu, 23 Oct 2014 11:21:10 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 4DFBA122D3E; Thu, 23 Oct 2014 14:29:03 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id 1BF02F041C; Thu, 23 Oct 2014 14:19:26 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Thu, 23 Oct 2014 14:19:25 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , Sharam Hakimi Date: Thu, 23 Oct 2014 14:19:24 -0400 Thread-Topic: [lmap] Information Model: Connecting Tasks Thread-Index: Ac/u7D8CMuBhT37ZS0qwUGiULVU//wAAIjf0 Message-ID: <4AF73AA205019A4C8A1DDD32C034631D7BBF8A23@NJFPSRVEXG0.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A11@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED28A5@SPQCMBX01.exfo.com> <20141022184328.GA94731@elstar.local> <89294A6F3C6C91459E52E4128C4B02B70FED2B21@SPQCMBX01.exfo.com>, <20141023180734.GA97528@elstar.local> In-Reply-To: <20141023180734.GA97528@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/ndcY7cuWqTfmfx5oqLkAYjPrhrc Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 18:21:12 -0000 I agree with Juergen's comment below. We are debating concepts in the Information Model (it's not even a data mo= del yet). Perhaps it is the uncertainty of what will be agreed that causes problems h= ere. Trevor, I hope we will have a more concrete proposal (with the queue concep= t) to review before IETF-91, then this issue can be put to bed. Al ________________________________________ From: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de] Sent: Thursday, October 23, 2014 2:07 PM To: Sharam Hakimi Cc: MORTON, ALFRED C (AL); lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks Making queues explicit in the information model !=3D specify the implementation. Without some form of queues, you can't pass information between tasks that run on different schedules. Following you analogy, I am saying we should say that the car has an engine instead of pretending all it has is a gas pedal. Once your car stops, it will become important to know whether you need to look for electicity or some other type of fuel. I guess analogies do not help much... /js On Thu, Oct 23, 2014 at 03:16:39PM +0000, Sharam Hakimi wrote: > As an example, when a car is designed each part in the car defines the po= wer requirement for it to run. The Battery/Alternator system is designed ba= sed on as many parts that can run concurrently and that is up to implementa= tion. Not all MAs will be created equal and I do not believe that we need t= o specify an implementation. The user will dictate what their requirement i= s and the implementation would need to match that. How many queues to handl= e is up to the implementation. > > Today One server can handle 100 TWAMP connection and perform the test and= another can handle 1000. TWAMP does not specify the implementation, just w= hat is required to schedule, run, capture results and report results for on= e instance. > > > Sharam > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, October 22, 2014 2:43 PM > To: Sharam Hakimi > Cc: MORTON, ALFRED C (AL); lmap@ietf.org > Subject: Re: [lmap] Information Model: Connecting Tasks > > On Wed, Oct 22, 2014 at 04:22:32PM +0000, Sharam Hakimi wrote: > > What I think needs to be specified is that an MA must have enough capab= ility(CPU power, memory, etc.) to execute a single defined task( run task, = log, transfer results). Beyond that really should be up to the implementati= on. If one can design an inexpensive device with multiple core CPUs and Gig= s of memory that allows for multiple concurrent tasks then that is up to th= e implementer. > > > > I do not think we should manage implementations, rather specify the res= ource requirement for every defined task. > > > > Using LMAP, I can configure (a) how frequently a measurement test is > executed (and hence how much data it produces) and (b) how frequently > a reporting task is executed. In other words, the amount of buffer > space I need depends on the schedule(s) and hence it is out of the > control of the implementation. Even if an implementation tries to > reject schedules that may potentially overrun resources, once you > loose connectivity it surely can run out of resources again. > > Assuming an implementation has always sufficient resources is > unrealistic and definitely not something that can be specified. > > Note: We are not talking about the execution of a single task but > instead about how data is passed between tasks. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Oct 23 14:11: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 6CCCA1A1B0A for ; Thu, 23 Oct 2014 14:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 e1cJaRXkWXia for ; Thu, 23 Oct 2014 14:11:37 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:1:8::180:100]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA21A1A22 for ; Thu, 23 Oct 2014 14:11:37 -0700 (PDT) Received: from [10.0.0.43] (unknown [80.202.16.89]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by epost.uninett.no (Postfix) with ESMTPSA id 7FE40336840 for ; Thu, 23 Oct 2014 23:11:35 +0200 (CEST) Message-ID: <54496F07.6030003@uninett.no> Date: Thu, 23 Oct 2014 23:11:35 +0200 From: Arne Oslebo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: lmap@ietf.org References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A11@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED28A5@SPQCMBX01.exfo.com> <20141022184328.GA94731@elstar.local> <89294A6F3C6C91459E52E4128C4B02B70FED2B21@SPQCMBX01.exfo.com>, <20141023180734.GA97528@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A23@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D7BBF8A23@NJFPSRVEXG0.research.att.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/cg1kjouv1IJmhCRRxCcZdAMhqhc Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 21:11:44 -0000 On 23. okt. 2014 20:19, MORTON, ALFRED C (AL) wrote: > I agree with Juergen's comment below. > > We are debating concepts in the Information Model (it's not even a data model yet). > Perhaps it is the uncertainty of what will be agreed that causes problems here. Even if implementation details have been brought into the discussion I think the key issue is whether we should include the concept of queues as a formal entity in the information model. This was discussed at the interim meeting as well and there people seemed to prefer not defining queues as a formal entity. Trevor said he would informally mention queues in the description so hopefully he will have a new version ready soon. Arne > > Trevor, I hope we will have a more concrete proposal (with the queue concept) > to review before IETF-91, then this issue can be put to bed. > > Al > ________________________________________ > From: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de] > Sent: Thursday, October 23, 2014 2:07 PM > To: Sharam Hakimi > Cc: MORTON, ALFRED C (AL); lmap@ietf.org > Subject: Re: [lmap] Information Model: Connecting Tasks > > Making queues explicit in the information model != specify the > implementation. Without some form of queues, you can't pass > information between tasks that run on different schedules. > > Following you analogy, I am saying we should say that the car has an > engine instead of pretending all it has is a gas pedal. Once your car > stops, it will become important to know whether you need to look for > electicity or some other type of fuel. > > I guess analogies do not help much... > > /js > > On Thu, Oct 23, 2014 at 03:16:39PM +0000, Sharam Hakimi wrote: >> As an example, when a car is designed each part in the car defines the power requirement for it to run. The Battery/Alternator system is designed based on as many parts that can run concurrently and that is up to implementation. Not all MAs will be created equal and I do not believe that we need to specify an implementation. The user will dictate what their requirement is and the implementation would need to match that. How many queues to handle is up to the implementation. >> >> Today One server can handle 100 TWAMP connection and perform the test and another can handle 1000. TWAMP does not specify the implementation, just what is required to schedule, run, capture results and report results for one instance. >> >> >> Sharam >> >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Wednesday, October 22, 2014 2:43 PM >> To: Sharam Hakimi >> Cc: MORTON, ALFRED C (AL); lmap@ietf.org >> Subject: Re: [lmap] Information Model: Connecting Tasks >> >> On Wed, Oct 22, 2014 at 04:22:32PM +0000, Sharam Hakimi wrote: >>> What I think needs to be specified is that an MA must have enough capability(CPU power, memory, etc.) to execute a single defined task( run task, log, transfer results). Beyond that really should be up to the implementation. If one can design an inexpensive device with multiple core CPUs and Gigs of memory that allows for multiple concurrent tasks then that is up to the implementer. >>> >>> I do not think we should manage implementations, rather specify the resource requirement for every defined task. >>> >> Using LMAP, I can configure (a) how frequently a measurement test is >> executed (and hence how much data it produces) and (b) how frequently >> a reporting task is executed. In other words, the amount of buffer >> space I need depends on the schedule(s) and hence it is out of the >> control of the implementation. Even if an implementation tries to >> reject schedules that may potentially overrun resources, once you >> loose connectivity it surely can run out of resources again. >> >> Assuming an implementation has always sufficient resources is >> unrealistic and definitely not something that can be specified. >> >> Note: We are not talking about the execution of a single task but >> instead about how data is passed between tasks. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > From nobody Fri Oct 24 01:23: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 8D0C41A872F for ; Fri, 24 Oct 2014 01:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 ml5h6oakoSHw for ; Fri, 24 Oct 2014 01:23:20 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3991F1A6EFB for ; Fri, 24 Oct 2014 01:23:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwLALgLSlSHCzIm/2dsb2JhbABcgkgjI1ROCgS5IQEBAQEBAQaTZodNAoEMFgEBfIQCAQEBAQMSG1wCAQgNBAQBAQsdBzIUCQgBAQQBEggBGYgfAQypcp9HAQEBAQEBAQMBAQEBAQEBAQEBAReGJYoCNwGDLYEeBZIFjQmDSYMbiheEAIN4bIFIgQMBAQE X-IronPort-AV: E=Sophos; i="5.04,779,1406606400"; d="scan'208,217"; a="91559490" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Oct 2014 04:23:18 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 24 Oct 2014 04:23:18 -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; Fri, 24 Oct 2014 04:23:17 -0400 From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: [lmap] IETF-91 preliminary agenda Thread-Index: Ac/u6eCV/dwmVAQBQze8losyUOzOLQAeZE1g Date: Fri, 24 Oct 2014 08:23:17 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@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_9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/oYYR21uxl5-mZHJ5Wl-65pmYnbQ Subject: Re: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 08:23:22 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Who of the LMAP contributors - especially authors of the documents and prot= ocol proposals will attend the meeting at IETF-91? Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, October 23, 2014 8:51 PM To: lmap@ietf.org Subject: [lmap] IETF-91 preliminary agenda Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Who of the LMAP contri= butors – especially authors of the documents and protocol proposals w= ill attend the meeting at IETF-91?

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, October 23, 2014 8:51 PM
To: lmap@ietf.org
Subject: [lmap] IETF-91 preliminary agenda

 

Hi,

 

I have loaded a preliminary agenda for the meeting a= t IETF-91. You can find it at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still need to fi= ll in a number of TBD – who will lead the Information Model discussio= n? What protocol submissions will be proposed and who will lead the discussions? Please send your requests to Jason and = me, and do not forget that I-D submissions cut-off is Monday 10/27.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99AZFFEXMB04globa_-- From nobody Fri Oct 24 06: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 728D61A00B0 for ; Fri, 24 Oct 2014 06:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 3WDRwuy2NPGA for ; Fri, 24 Oct 2014 06:36:25 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0D71A00BB for ; Fri, 24 Oct 2014 06:36: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.2-0) with ESMTP id 8d55a445.2ae77ac1d940.912600.00-2483.2567237.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 24 Oct 2014 13:36:24 +0000 (UTC) X-MXL-Hash: 544a55d85e5a54c0-cda71f928d5b1acbfc23739982bdc2eb2a98a360 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 1d55a445.0.912521.00-2351.2567009.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 24 Oct 2014 13:36:17 +0000 (UTC) X-MXL-Hash: 544a55d1696e1040-27945cb61d2a6af6a2d3c23623246f25b4ff841c 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 s9ODaGi9002703; Fri, 24 Oct 2014 09:36:16 -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 s9ODaBxu002649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Oct 2014 09:36:11 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 24 Oct 2014 13:36:00 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.152]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 09:36:00 -0400 From: "STARK, BARBARA H" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: [lmap] IETF-91 preliminary agenda Thread-Index: Ac/u6eCV/dwmVAQBQze8losyUOzOLQAeZE1gAArVmlA= Date: Fri, 24 Oct 2014 13:35:59 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EA6E1B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@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.70.107.87] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130EA6E1BGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=eZqKic4H c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=5isQNm-ud3IA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=48vgC7mUAAAA:8 a=qYtlewi-dx7xqXXzFk4A:9 a=Cju] X-AnalysisOut: [IK1q_8ugA:10 a=V7DYuYY8-8YyN2Af:21 a=NhAmwUUfo-wLPYUa:21 a] X-AnalysisOut: [=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7] X-AnalysisOut: [L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=KHjQoq97H] X-AnalysisOut: [gq1nRDq:21 a=jHS-15ikkWv4imkh:21 a=dYo-P1ZJ2gSBX0qV:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/xg2jwFalOFfmJmL6DqY8qVFuimA Subject: Re: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 13:36:27 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130EA6E1BGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will be there. But I'm not an author or proponent of anything in LMAP. I've seen it done in another WG where an author has participated remotely t= hrough an online meeting. I'd be happy to provide use of my online meeting = account (AT&T Connect -- not Webex or GoToMeeting, etc., but it works prett= y much the same) if we wanted to try this. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 4:23 AM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Hi, Who of the LMAP contributors - especially authors of the documents and prot= ocol proposals will attend the meeting at IETF-91? Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, October 23, 2014 8:51 PM To: lmap@ietf.org Subject: [lmap] IETF-91 preliminary agenda Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_2D09D61DDFA73D4C884805CC7865E61130EA6E1BGAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I will be there. But I= ’m not an author or proponent of anything in LMAP.<= /p>

I’ve seen it don= e in another WG where an author has participated remotely through an online= meeting. I’d be happy to provide use of my online meeting account (A= T&T Connect -- not Webex or GoToMeeting, etc., but it works pretty much the same) if we wanted to try this.=

Barbara

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 4:23 AM
To: Romascanu, Dan (Dan); lmap@ietf.org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Hi,<= /p>

 

Who of the LMAP contri= butors – especially authors of the documents and protocol proposals w= ill attend the meeting at IETF-91?

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, October 23, 2014 8:51 PM
To: lmap@ietf.org
Subject: [lmap] IETF-91 preliminary agenda

 

Hi,

 

I have loaded a preliminary agenda for the meeting a= t IETF-91. You can find it at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still need to fi= ll in a number of TBD – who will lead the Information Model discussio= n? What protocol submissions will be proposed and who will lead the discussions? Please send your requests to Jason and = me, and do not forget that I-D submissions cut-off is Monday 10/27.

 

Thanks and Regards,

 

Dan

 

--_000_2D09D61DDFA73D4C884805CC7865E61130EA6E1BGAALPA1MSGUSRBF_-- From nobody Fri Oct 24 08:04: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 CAA091A1A23 for ; Fri, 24 Oct 2014 08:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 7UeoxN0SLAIM for ; Fri, 24 Oct 2014 08:04:00 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04F71A006F for ; Fri, 24 Oct 2014 08:04:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiILALhpSlTGmAcV/2dsb2JhbABcgkgjI1RYBLkrDAEBAQECBpNmh00CgQcWAQF8hAIBAQEBAxIbXAIBCA0EBAEBCwsSBzIUCQgBAQQBEggBGYgfAQyqCJ9OAQEBAQEBAQMBAQEBAQEBAQEBAReGJYoCNwEKgyOBHgWSBY0Jg0mDG4oXhACDeGyBSIEDAQEB X-IronPort-AV: E=Sophos; i="5.04,780,1406606400"; d="scan'208,217"; a="91608449" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Oct 2014 11:03:58 -0400 X-OutboundMail_SMTP: 1 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; 24 Oct 2014 11:03:58 -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; Fri, 24 Oct 2014 11:03:56 -0400 From: "Romascanu, Dan (Dan)" To: "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: [lmap] IETF-91 preliminary agenda Thread-Index: Ac/u6eCV/dwmVAQBQze8losyUOzOLQAeZE1gAArVmlAAAyEBUA== Date: Fri, 24 Oct 2014 15:03:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130EA6E1B@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130EA6E1B@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ly29oGUGzW69hSZDMxHSnlHgdKI Subject: Re: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 15:04:04 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let me then broaden the scope of the question. Who plans to attend the meet= ing remotely? The schedule is 0900 - 1130 Hawaii time on Thursday November = 13. Regards, Dan From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Friday, October 24, 2014 4:36 PM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: RE: [lmap] IETF-91 preliminary agenda I will be there. But I'm not an author or proponent of anything in LMAP. I've seen it done in another WG where an author has participated remotely t= hrough an online meeting. I'd be happy to provide use of my online meeting = account (AT&T Connect -- not Webex or GoToMeeting, etc., but it works prett= y much the same) if we wanted to try this. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 4:23 AM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Hi, Who of the LMAP contributors - especially authors of the documents and prot= ocol proposals will attend the meeting at IETF-91? Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, October 23, 2014 8:51 PM To: lmap@ietf.org Subject: [lmap] IETF-91 preliminary agenda Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let me then broaden th= e scope of the question. Who plans to attend the meeting remotely? The sche= dule is 0900 – 1130 Hawaii time on Thursday November 13.

 

Regards,


Dan

 

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: Friday, October 24, 2014 4:36 PM
To: Romascanu, Dan (Dan); lmap@ietf.org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

I will be there. But I= ’m not an author or proponent of anything in LMAP.<= /p>

I’ve seen it don= e in another WG where an author has participated remotely through an online= meeting. I’d be happy to provide use of my online meeting account (A= T&T Connect -- not Webex or GoToMeeting, etc., but it works pretty much the same) if we wanted to try this.=

Barbara

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 4:23 AM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Hi,<= /p>

 

Who of the LMAP contri= butors – especially authors of the documents and protocol proposals w= ill attend the meeting at IETF-91?

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, October 23, 2014 8:51 PM
To: lmap@ietf.org
Subject: [lmap] IETF-91 preliminary agenda

 

Hi,

 

I have loaded a preliminary agenda for the meeting a= t IETF-91. You can find it at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still need to fi= ll in a number of TBD – who will lead the Information Model discussio= n? What protocol submissions will be proposed and who will lead the discussions? Please send your requests to Jason and = me, and do not forget that I-D submissions cut-off is Monday 10/27.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8AZFFEXMB04globa_-- From nobody Fri Oct 24 08:14: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 86A121A1A01 for ; Fri, 24 Oct 2014 08:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 TxW2n7ckXv4p for ; Fri, 24 Oct 2014 08:14:50 -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 70B161A1A46 for ; Fri, 24 Oct 2014 08:14:50 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id EB666123AD2; Fri, 24 Oct 2014 11:24:26 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-azure.research.att.com (Postfix) with ESMTP id 289A0E004D; Fri, 24 Oct 2014 11:14:47 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Fri, 24 Oct 2014 11:14:46 -0400 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , "STARK, BARBARA H" , "lmap@ietf.org" Date: Fri, 24 Oct 2014 11:14:45 -0400 Thread-Topic: [lmap] IETF-91 preliminary agenda Thread-Index: Ac/u6eCV/dwmVAQBQze8losyUOzOLQAeZE1gAArVmlAAAyEBUAAAbZjQ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D7BBDA075@NJFPSRVEXG0.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130EA6E1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D7BBDA075NJFPSRVEXG0rese_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/8jDtKkzj2-kla5rleOdWBetBcSA Subject: Re: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 15:14:53 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D7BBDA075NJFPSRVEXG0rese_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable to save others looking it up, HAST is (UTC-10:00), with no DST From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 11:04 AM To: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Let me then broaden the scope of the question. Who plans to attend the meet= ing remotely? The schedule is 0900 - 1130 Hawaii time on Thursday November = 13. Regards, Dan From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Friday, October 24, 2014 4:36 PM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: RE: [lmap] IETF-91 preliminary agenda I will be there. But I'm not an author or proponent of anything in LMAP. I've seen it done in another WG where an author has participated remotely t= hrough an online meeting. I'd be happy to provide use of my online meeting = account (AT&T Connect -- not Webex or GoToMeeting, etc., but it works prett= y much the same) if we wanted to try this. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 4:23 AM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Hi, Who of the LMAP contributors - especially authors of the documents and prot= ocol proposals will attend the meeting at IETF-91? Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, October 23, 2014 8:51 PM To: lmap@ietf.org Subject: [lmap] IETF-91 preliminary agenda Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_4AF73AA205019A4C8A1DDD32C034631D7BBDA075NJFPSRVEXG0rese_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

to save others looking it up, HA= ST is (UTC-10:00), with no DST

 

From: lmap [mailto:lmap-bounces@i= etf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, O= ctober 24, 2014 11:04 AM
To: STARK, BARBARA H; lmap@ietf.org
<= b>Subject: Re: [lmap] IETF-91 preliminary agenda

<= /div>

 

<= span style=3D'color:#1F497D'>Let me then broaden the scope of the question.= Who plans to attend the meeting remotely? The schedule is 0900 – 113= 0 Hawaii time on Thursday November 13.

 

Regards,


Dan<= /p>

 

 =

From: STARK, BARBARA H [= mailto:bs7652@att.com]
Sent: Friday, October 24, 2014 4:36 PM
To: Romascanu, Dan (Dan); lmap@ietf.org
Subject: RE: [lma= p] IETF-91 preliminary agenda

 

I will be there. But I’m not an author or proponent of anything= in LMAP.

I’ve seen it done in another WG where an author has participat= ed remotely through an online meeting. I’d be happy to provide use of= my online meeting account (AT&T Connect -- not Webex or GoToMeeting, e= tc., but it works pretty much the same) if we wanted to try this.

Barbara=

&n= bsp;

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, = 2014 4:23 AM
To: Romascanu, Dan (Dan); lmap@ietf.org
Subject: Re: [lmap] IETF-91 preliminary = agenda

 

Hi,

 

Who of the L= MAP contributors – especially authors of the documents and protocol p= roposals will attend the meeting at IETF-91?

 

Thanks and Regards,

 =

Dan

&= nbsp;

 

= --_000_4AF73AA205019A4C8A1DDD32C034631D7BBDA075NJFPSRVEXG0rese_-- From nobody Fri Oct 24 08:20:15 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7838D1A1A1C for ; Fri, 24 Oct 2014 08:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uX9JYBMTPbAc for ; Fri, 24 Oct 2014 08:20:10 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id E6AD01A0368 for ; Fri, 24 Oct 2014 08:20:09 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 63503A28F6; Fri, 24 Oct 2014 11:20:09 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 252BCA28F3; Fri, 24 Oct 2014 11:20:09 -0400 (EDT) Received: from SPQCMBX01.exfo.com ([169.254.1.252]) by SPQCCAS01.exfo.com ([10.28.36.8]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 11:20:08 -0400 From: Sharam Hakimi To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] Information Model: Connecting Tasks Thread-Index: Ac/ofHtSaYdiY6Y/R4mNbjroR+i0BgACHKHIAFiZngwBCuiJYAANqJQAACHLIUAADz7NAAAAaYAAACMf7JA= Date: Fri, 24 Oct 2014 15:20:08 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FED2D19@SPQCMBX01.exfo.com> References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A11@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED28A5@SPQCMBX01.exfo.com> <20141022184328.GA94731@elstar.local> <89294A6F3C6C91459E52E4128C4B02B70FED2B21@SPQCMBX01.exfo.com>, <20141023180734.GA97528@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A23@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D7BBF8A23@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-21048.000 X-TM-AS-Result: No--30.774-5.0-31-10 X-imss-scan-details: No--30.774-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-21048.000 X-TMASE-Result: 10--30.774400-5.000000 X-TMASE-MatchedRID: cxtZ8fwm3r9fW3i85vanos+ayFtEW0uY6Jj6zYvfFASAZpvTq6Jh4WFO iexrr+Z/Wdz6JMB6uZEFYH9Vyti0BrT8lYmoiiqmzNY33yIEF4a2awxxVfk3BxyMMoyfhsxIl1T ppRopjE52S+Sh796HkSghS3irceRtpUxzcSQ8HaTYd2+/8wYTdZK5aaUH9kQVu/jTz8Y/kepHp3 uRC0sBr0rb2v56pf1SWqwP0VH5X5ScmtrRK7tMe2a9ngFEgh47TJDl9FKHbrnvHbNVSAW5oMkUh KWc+gwPPwci7cdl7YdAWiPDhQ7r+VQCbNy9pFH3fuyIS1Zjfrt4XLNBjM9D5GHtZs6e3ZMHgiZx W8zUgARuwPey9fmTYwndjWFHf36YfalnNvZDQnwuLk8NfSpYennL427v8Q46ow/V8X6BDY7FEX6 adidGMt6t27BJ+B7G9cn2kV2xUSBTYCtOQB6Jrsuk6uE8mx6PlFphfRKYquogTu9XTnBqm3KQwT N31YBdd6Z641tFNXlSdL5bUkaqlwwIsQZbtzZwQr2qXCJMSV9y4VFP6muDhsnaL1ri/ilXU9a6z fLFA1a36h2hK5rvdn8mA3sDDq0AVkVZa47CjvDdB/CxWTRRuyUIayx+Skid Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/c9wgVX5efF2Im9aGXn2jC9I_MsA Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:20:12 -0000 Now that I think we agree not to specify processing power or resource requi= rements for passing parameters between tasks, it is back to just trying to = specify a queue mechanism to try to pass some parameters between tasks. Som= e parameters can be part of the schedule, for example: Run Task A If Task A completes with success Run Task B =20 Else goto Task C=20 Task B Task C One would not need to pass any parameter between A and B even though the re= sult of Task A is used to make a decision on the execution of the schedule = by the MA.=20 I am not sure how easy it would be to get consensus on the Queue structure = if we do not know what needs to be passed between what tasks or what the co= nsequence of that would be.=20 Sharam -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acm@research.att.com]=20 Sent: Thursday, October 23, 2014 2:19 PM To: Juergen Schoenwaelder; Sharam Hakimi Cc: lmap@ietf.org Subject: RE: [lmap] Information Model: Connecting Tasks I agree with Juergen's comment below. We are debating concepts in the Information Model (it's not even a data mo= del yet). Perhaps it is the uncertainty of what will be agreed that causes problems h= ere. Trevor, I hope we will have a more concrete proposal (with the queue concep= t) to review before IETF-91, then this issue can be put to bed. Al ________________________________________ From: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de] Sent: Thursday, October 23, 2014 2:07 PM To: Sharam Hakimi Cc: MORTON, ALFRED C (AL); lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks Making queues explicit in the information model !=3D specify the implementation. Without some form of queues, you can't pass information between tasks that run on different schedules. Following you analogy, I am saying we should say that the car has an engine instead of pretending all it has is a gas pedal. Once your car stops, it will become important to know whether you need to look for electicity or some other type of fuel. I guess analogies do not help much... /js On Thu, Oct 23, 2014 at 03:16:39PM +0000, Sharam Hakimi wrote: > As an example, when a car is designed each part in the car defines the po= wer requirement for it to run. The Battery/Alternator system is designed ba= sed on as many parts that can run concurrently and that is up to implementa= tion. Not all MAs will be created equal and I do not believe that we need t= o specify an implementation. The user will dictate what their requirement i= s and the implementation would need to match that. How many queues to handl= e is up to the implementation. > > Today One server can handle 100 TWAMP connection and perform the test and= another can handle 1000. TWAMP does not specify the implementation, just w= hat is required to schedule, run, capture results and report results for on= e instance. > > > Sharam > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, October 22, 2014 2:43 PM > To: Sharam Hakimi > Cc: MORTON, ALFRED C (AL); lmap@ietf.org > Subject: Re: [lmap] Information Model: Connecting Tasks > > On Wed, Oct 22, 2014 at 04:22:32PM +0000, Sharam Hakimi wrote: > > What I think needs to be specified is that an MA must have enough capab= ility(CPU power, memory, etc.) to execute a single defined task( run task, = log, transfer results). Beyond that really should be up to the implementati= on. If one can design an inexpensive device with multiple core CPUs and Gig= s of memory that allows for multiple concurrent tasks then that is up to th= e implementer. > > > > I do not think we should manage implementations, rather specify the res= ource requirement for every defined task. > > > > Using LMAP, I can configure (a) how frequently a measurement test is > executed (and hence how much data it produces) and (b) how frequently > a reporting task is executed. In other words, the amount of buffer > space I need depends on the schedule(s) and hence it is out of the > control of the implementation. Even if an implementation tries to > reject schedules that may potentially overrun resources, once you > loose connectivity it surely can run out of resources again. > > Assuming an implementation has always sufficient resources is > unrealistic and definitely not something that can be specified. > > Note: We are not talking about the execution of a single task but > instead about how data is passed between tasks. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Oct 24 08:27: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 74D8D1A0461 for ; Fri, 24 Oct 2014 08:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 RuzLCiuWXX9c for ; Fri, 24 Oct 2014 08:27:46 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id 223CC1A0115 for ; Fri, 24 Oct 2014 08:27:46 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B0DA6A28F6; Fri, 24 Oct 2014 11:27:45 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 6EA24A28F3; Fri, 24 Oct 2014 11:27:45 -0400 (EDT) Received: from SPQCMBX01.exfo.com ([169.254.1.252]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 11:27:45 -0400 From: Sharam Hakimi To: "MORTON, ALFRED C (AL)" , "Romascanu, Dan (Dan)" , "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: [lmap] IETF-91 preliminary agenda Thread-Index: Ac/u6eCV/dwmVAQBQze8losyUOzOLQAeZE1gAArVmlAAAyEBUAAAbZjQAABo0bA= Date: Fri, 24 Oct 2014 15:27:44 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FED2D3A@SPQCMBX01.exfo.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130EA6E1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D7BBDA075@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D7BBDA075@NJFPSRVEXG0.research.att.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_89294A6F3C6C91459E52E4128C4B02B70FED2D3ASPQCMBX01exfoco_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-21048.000 X-TM-AS-Result: No--32.251-5.0-31-10 X-imss-scan-details: No--32.251-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-21048.000 X-TMASE-Result: 10--32.251000-5.000000 X-TMASE-MatchedRID: Kx0w2sAofbvao4CRCsO6Y5V8a/0picnDbzxxC6bH7Odv0qcu7SRm5e3U B8FXOsM1KDqaG7dOyaJcUPFIoZERd6oDZpNjSrDVzMU0F3CreX53gvNDlwkK81pbYq2f4jz+AmL /YMh+r1EG3ko1352HKvkpASgo3DAgDL2trK/H+w5mVHNo7XGknSTbbsi+pqSFoL8SXnpbP76cls fP5iXpadnjPBPcJroFB9oA8H7Fp6ngwb2MnLCcFe9VsdrlGzy3QZXZg2I8JaYihbPFvhIWEM1S0 HxcirqLaSfZFvAzgW2QnT2Pup6fMNq72IXmYAV7StpI+4+KLgD9sV9Tla1qi0rRZP/NcCCSizrF pWHTBvcNat/xqna6p2rEBfVjKK6u1lfDCm9+EZWKC6Im4I1RFzK1/qdbjc7QFLXUWU5hGiFdqWv miTG8mp/Xz1rC/1g0tF3RbBlJV000nIDKoCZxv3YaZ/XR5khWwx0jRRxcQfPFB60vroeLbScNAd gd0gV52X0MdweWjLiSU848M/hs6K4QAeQvIGeqNNHZMWDTEbfeR5dcF7n1ecO/l0Ny5PZ5mrQ5u ocR4x9mmc5bUXub8tVIxRq5LXM2lwV2iaAfSWcURSScn+QSXtivpTdmVCR2I/NGWt0UYPD6kjSp m7q0C2X+dpDsnAiPNwrMJhNRlMMK3sBmfKBU9+AKN/2i80uz Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Zzvye_-baub5e4B6WwED-9ZUVSc Subject: Re: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 15:27:49 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B70FED2D3ASPQCMBX01exfoco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Currently it is + 6 hours for US-EST and + 3 hours US-PST . However next week DST will go into effect so it will be +5 hours US-EST a= nd +2 hours US-PST during the meeting. If it helps. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Friday, October 24, 2014 11:15 AM To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda to save others looking it up, HAST is (UTC-10:00), with no DST From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 11:04 AM To: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Let me then broaden the scope of the question. Who plans to attend the meet= ing remotely? The schedule is 0900 - 1130 Hawaii time on Thursday November = 13. Regards, Dan From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Friday, October 24, 2014 4:36 PM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: RE: [lmap] IETF-91 preliminary agenda I will be there. But I'm not an author or proponent of anything in LMAP. I've seen it done in another WG where an author has participated remotely t= hrough an online meeting. I'd be happy to provide use of my online meeting = account (AT&T Connect -- not Webex or GoToMeeting, etc., but it works prett= y much the same) if we wanted to try this. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 4:23 AM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Hi, Who of the LMAP contributors - especially authors of the documents and prot= ocol proposals will attend the meeting at IETF-91? Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, October 23, 2014 8:51 PM To: lmap@ietf.org Subject: [lmap] IETF-91 preliminary agenda Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_89294A6F3C6C91459E52E4128C4B02B70FED2D3ASPQCMBX01exfoco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Currently   = it is   + 6 hours for US-EST and  + 3 hours US-PST .=

 

However next week DST = will go into effect  so it will be +5 hours US-EST  and += 2 hours US-PST  during the meeting.

 

If it helps.

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL)
Sent: Friday, October 24, 2014 11:15 AM
To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

to save others looking it up, HAST is (UTC-10:00), with no DST

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 11:04 AM
To: STARK, BARBARA H; lmap@ietf.org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Let me then broaden th= e scope of the question. Who plans to attend the meeting remotely? The sche= dule is 0900 – 1130 Hawaii time on Thursday November 13.

 

Regards,


Dan

 

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: Friday, October 24, 2014 4:36 PM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

I will be there. But I= ’m not an author or proponent of anything in LMAP.<= /p>

I’ve seen it don= e in another WG where an author has participated remotely through an online= meeting. I’d be happy to provide use of my online meeting account (A= T&T Connect -- not Webex or GoToMeeting, etc., but it works pretty much the same) if we wanted to try this.=

Barbara

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 4:23 AM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Hi,<= /p>

 

Who of the LMAP contri= butors – especially authors of the documents and protocol proposals w= ill attend the meeting at IETF-91?

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, October 23, 2014 8:51 PM
To: lmap@ietf.org
Subject: [lmap] IETF-91 preliminary agenda

 

Hi,

 

I have loaded a preliminary agenda for the meeting a= t IETF-91. You can find it at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still need to fi= ll in a number of TBD – who will lead the Information Model discussio= n? What protocol submissions will be proposed and who will lead the discussions? Please send your requests to Jason and = me, and do not forget that I-D submissions cut-off is Monday 10/27.

 

Thanks and Regards,

 

Dan

 

--_000_89294A6F3C6C91459E52E4128C4B02B70FED2D3ASPQCMBX01exfoco_-- From nobody Fri Oct 24 08:36:08 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4A91A1A7B for ; Fri, 24 Oct 2014 08:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 aJDArtFPNAzE for ; Fri, 24 Oct 2014 08:36:02 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0EB81A1A76 for ; Fri, 24 Oct 2014 08:36:01 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 1e17a445.2b0ea9e42940.988523.00-2491.2784143.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 24 Oct 2014 15:36:01 +0000 (UTC) X-MXL-Hash: 544a71e1141f02a2-7708360e3a3c616330b43b7b0fa882b043a9d4b5 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 9d17a445.0.988436.00-2277.2783903.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 24 Oct 2014 15:35:56 +0000 (UTC) X-MXL-Hash: 544a71dc7b299829-4f7594061453ed33de9e9487c766828ced5edef0 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 s9OFZqho021241; Fri, 24 Oct 2014 11:35:53 -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 s9OFZjio021143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Oct 2014 11:35:46 -0400 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 24 Oct 2014 15:35:38 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.152]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 11:35:38 -0400 From: "STARK, BARBARA H" To: Sharam Hakimi , "MORTON, ALFRED C (AL)" , "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: [lmap] IETF-91 preliminary agenda Thread-Index: Ac/u6eCV/dwmVAQBQze8losyUOzOLQAeZE1gAArVmlAAAyEBUAAAbZjQAABo0bAAADA0sA== Date: Fri, 24 Oct 2014 15:35:38 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EA6F89@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130EA6E1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D7BBDA075@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED2D3A@SPQCMBX01.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70FED2D3A@SPQCMBX01.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.107.87] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130EA6F89GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=be/cppzB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=5isQNm-ud3IA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=pTHmISxBAAAA:8 a=48vgC7mUAAAA:8 a=_DqVdqSvZe9] X-AnalysisOut: [iBesEB0sA:9 a=CjuIK1q_8ugA:10 a=N-ozWoxKi1A8k37V:21 a=d1TM] X-AnalysisOut: [VyOfqB9KbpfO:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq] X-AnalysisOut: [4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-h] X-AnalysisOut: [UA:10 a=GcwwP3k8FZGs2KRJ:21 a=KXV4dVH4FN2u7z8E:21 a=oSsx6Z] X-AnalysisOut: [QMYmpGbi9m:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/TPGNVc00BKmPd7RhHaP6Gr5tghs Subject: Re: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 15:36:05 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130EA6F89GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually -- next week Europe goes *off* DST (and west coast US is still on = PDT). The week after next, the parts of US currently on DST go off DST. So = when IETF is in Hawaii, everyone will be on standard time. Barbara From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] Sent: Friday, October 24, 2014 11:28 AM To: MORTON, ALFRED C (AL); Romascanu, Dan (Dan); STARK, BARBARA H; lmap@iet= f.org Subject: RE: [lmap] IETF-91 preliminary agenda Currently it is + 6 hours for US-EST and + 3 hours US-PST . However next week DST will go into effect so it will be +5 hours US-EST a= nd +2 hours US-PST during the meeting. If it helps. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Friday, October 24, 2014 11:15 AM To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda to save others looking it up, HAST is (UTC-10:00), with no DST From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 11:04 AM To: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Let me then broaden the scope of the question. Who plans to attend the meet= ing remotely? The schedule is 0900 - 1130 Hawaii time on Thursday November = 13. Regards, Dan From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Friday, October 24, 2014 4:36 PM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: RE: [lmap] IETF-91 preliminary agenda I will be there. But I'm not an author or proponent of anything in LMAP. I've seen it done in another WG where an author has participated remotely t= hrough an online meeting. I'd be happy to provide use of my online meeting = account (AT&T Connect -- not Webex or GoToMeeting, etc., but it works prett= y much the same) if we wanted to try this. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 4:23 AM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Hi, Who of the LMAP contributors - especially authors of the documents and prot= ocol proposals will attend the meeting at IETF-91? Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, October 23, 2014 8:51 PM To: lmap@ietf.org Subject: [lmap] IETF-91 preliminary agenda Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_2D09D61DDFA73D4C884805CC7865E61130EA6F89GAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually -- next week = Europe goes *off* DST (and west coast US is still on PDT). The week = after next, the parts of US currently on DST go off DST. So when IETF is in= Hawaii, everyone will be on standard time.

Barbara

 

From: Sharam H= akimi [mailto:sharam.hakimi@exfo.com]
Sent: Friday, October 24, 2014 11:28 AM
To: MORTON, ALFRED C (AL); Romascanu, Dan (Dan); STARK, BARBARA H; l= map@ietf.org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

Currently   = it is   + 6 hours for US-EST and  + 3 hours US-PST .=

 

However next week DST = will go into effect  so it will be +5 hours US-EST  and += 2 hours US-PST  during the meeting.

 

If it helps.

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL)
Sent: Friday, October 24, 2014 11:15 AM
To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

to save others looking it up, HAST is (UTC-10:00), with no DST

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 11:04 AM
To: STARK, BARBARA H; lmap@ietf.org=
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Let me then broaden th= e scope of the question. Who plans to attend the meeting remotely? The sche= dule is 0900 – 1130 Hawaii time on Thursday November 13.

 

Regards,


Dan

 

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: Friday, October 24, 2014 4:36 PM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

I will be there. But I= ’m not an author or proponent of anything in LMAP.<= /p>

I’ve seen it don= e in another WG where an author has participated remotely through an online= meeting. I’d be happy to provide use of my online meeting account (A= T&T Connect -- not Webex or GoToMeeting, etc., but it works pretty much the same) if we wanted to try this.=

Barbara

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 4:23 AM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Hi,<= /p>

 

Who of the LMAP contri= butors – especially authors of the documents and protocol proposals w= ill attend the meeting at IETF-91?

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, October 23, 2014 8:51 PM
To: lmap@ietf.org
Subject: [lmap] IETF-91 preliminary agenda

 

Hi,

 

I have loaded a preliminary agenda for the meeting a= t IETF-91. You can find it at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still need to fi= ll in a number of TBD – who will lead the Information Model discussio= n? What protocol submissions will be proposed and who will lead the discussions? Please send your requests to Jason and = me, and do not forget that I-D submissions cut-off is Monday 10/27.

 

Thanks and Regards,

 

Dan

 

--_000_2D09D61DDFA73D4C884805CC7865E61130EA6F89GAALPA1MSGUSRBF_-- From nobody Fri Oct 24 08:40: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 20DDA1A1A87 for ; Fri, 24 Oct 2014 08:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 IQ5rhh_14XZu for ; Fri, 24 Oct 2014 08:40:33 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4380A1A1A88 for ; Fri, 24 Oct 2014 08:40:33 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 88F43C8E5B99; Fri, 24 Oct 2014 15:40:29 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s9OFeWTA028932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 11:40:32 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.185]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 11:40:32 -0400 From: "Carey, Timothy (Timothy)" To: "MORTON, ALFRED C (AL)" , "Romascanu, Dan (Dan)" , "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: [lmap] IETF-91 preliminary agenda Thread-Index: AQHP758lK6oLW2thB0eUWYHPhXKbdpw/YhjQ Date: Fri, 24 Oct 2014 15:40:30 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734FC87CB@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130EA6E1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D7BBDA075@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D7BBDA075@NJFPSRVEXG0.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.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F7734FC87CBUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/tZGD9ME6kZeLwlnaOmRUf6gMpOU Subject: Re: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 15:40:36 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7734FC87CBUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I plan to attend in person but I am not an author of any of the LMAP IETF d= rafts. BR, Tim From: MORTON, ALFRED C (AL) [mailto:acm@research.att.com] Sent: Friday, October 24, 2014 10:15 AM To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda to save others looking it up, HAST is (UTC-10:00), with no DST From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 11:04 AM To: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Let me then broaden the scope of the question. Who plans to attend the meet= ing remotely? The schedule is 0900 - 1130 Hawaii time on Thursday November = 13. Regards, Dan From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Friday, October 24, 2014 4:36 PM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: RE: [lmap] IETF-91 preliminary agenda I will be there. But I'm not an author or proponent of anything in LMAP. I've seen it done in another WG where an author has participated remotely t= hrough an online meeting. I'd be happy to provide use of my online meeting = account (AT&T Connect -- not Webex or GoToMeeting, etc., but it works prett= y much the same) if we wanted to try this. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 4:23 AM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Hi, Who of the LMAP contributors - especially authors of the documents and prot= ocol proposals will attend the meeting at IETF-91? Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, October 23, 2014 8:51 PM To: lmap@ietf.org Subject: [lmap] IETF-91 preliminary agenda Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_9966516C6EB5FC4381E05BF80AA55F7734FC87CBUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I plan to attend in person but I am n= ot an author of any of the LMAP IETF drafts.

 

BR,

Tim

 

From: MORTON, = ALFRED C (AL) [mailto:acm@research.att.com]
Sent: Friday, October 24, 2014 10:15 AM
To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

to save others looking it up, HAST is (UTC-10:00), with no DST

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 11:04 AM
To: STARK, BARBARA H; lmap@ietf.org=
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Let me then broaden th= e scope of the question. Who plans to attend the meeting remotely? The sche= dule is 0900 – 1130 Hawaii time on Thursday November 13.

 

Regards,


Dan

 

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: Friday, October 24, 2014 4:36 PM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

I will be there. But I= ’m not an author or proponent of anything in LMAP.<= /p>

I’ve seen it don= e in another WG where an author has participated remotely through an online= meeting. I’d be happy to provide use of my online meeting account (A= T&T Connect -- not Webex or GoToMeeting, etc., but it works pretty much the same) if we wanted to try this.=

Barbara

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 4:23 AM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Hi,<= /p>

 

Who of the LMAP contri= butors – especially authors of the documents and protocol proposals w= ill attend the meeting at IETF-91?

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, October 23, 2014 8:51 PM
To: lmap@ietf.org
Subject: [lmap] IETF-91 preliminary agenda

 

Hi,

 

I have loaded a preliminary agenda for the meeting a= t IETF-91. You can find it at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still need to fi= ll in a number of TBD – who will lead the Information Model discussio= n? What protocol submissions will be proposed and who will lead the discussions? Please send your requests to Jason and = me, and do not forget that I-D submissions cut-off is Monday 10/27.

 

Thanks and Regards,

 

Dan

 

--_000_9966516C6EB5FC4381E05BF80AA55F7734FC87CBUS70UWXCHMBA05z_-- From nobody Fri Oct 24 08:43:21 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B04D1A1AE7 for ; Fri, 24 Oct 2014 08:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 39n-mt6M8gD6 for ; Fri, 24 Oct 2014 08:43:17 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8745F1A1AA3 for ; Fri, 24 Oct 2014 08:42:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwLAJRxSlSHCzIm/2dsb2JhbABcgkgjI1ROCgS5NwEBAQECBpNmh00CgQcWAQF8hAIBAQEBAxIbXAIBCA0EBAEBCwsSBzIUCQgBAQQBEggBGYgfAQyqC59NAQEBAQEBAQMBAQEBAQEBAQEBAReGJYoCNwEKgyOBHgWSBY0Jg0mDG4oXhACDeGyBSIEDAQEB X-IronPort-AV: E=Sophos; i="5.04,780,1406606400"; d="scan'208,217"; a="91615410" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Oct 2014 11:42:32 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 24 Oct 2014 11:42:32 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 17:42:31 +0200 From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: [lmap] IETF-91 preliminary agenda Thread-Index: Ac/u6eCV/dwmVAQBQze8losyUOzOLQAeZE1gAArVmlAAAyEBUAABbPQA Date: Fri, 24 Oct 2014 15:42:30 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8DB319@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130EA6E1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8@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_9904FB1B0159DA42B0B887B7FA8119CA5C8DB319AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/DTGXhDzxq3hRxi907KUZkgWIlJc Subject: Re: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 15:43:20 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DB319AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I loaded an updated - but still preliminary - agenda based on input and req= uests received in the last 24 hours. http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 6:04 PM To: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Let me then broaden the scope of the question. Who plans to attend the meet= ing remotely? The schedule is 0900 - 1130 Hawaii time on Thursday November = 13. Regards, Dan From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Friday, October 24, 2014 4:36 PM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: RE: [lmap] IETF-91 preliminary agenda I will be there. But I'm not an author or proponent of anything in LMAP. I've seen it done in another WG where an author has participated remotely t= hrough an online meeting. I'd be happy to provide use of my online meeting = account (AT&T Connect -- not Webex or GoToMeeting, etc., but it works prett= y much the same) if we wanted to try this. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 4:23 AM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Hi, Who of the LMAP contributors - especially authors of the documents and prot= ocol proposals will attend the meeting at IETF-91? Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, October 23, 2014 8:51 PM To: lmap@ietf.org Subject: [lmap] IETF-91 preliminary agenda Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DB319AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I loaded an updated &#= 8211; but still preliminary – agenda based on input and requests rece= ived in the last 24 hours.

 

http://www.ietf.org/proceedi= ngs/91/agenda/agenda-91-lmap

 

Regards,

 

Dan<= /p>

 

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 6:04 PM
To: STARK, BARBARA H; lmap@ietf.org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Let me then broaden th= e scope of the question. Who plans to attend the meeting remotely? The sche= dule is 0900 – 1130 Hawaii time on Thursday November 13.

 

Regards,


Dan

 

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: Friday, October 24, 2014 4:36 PM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

I will be there. But I= ’m not an author or proponent of anything in LMAP.<= /p>

I’ve seen it don= e in another WG where an author has participated remotely through an online= meeting. I’d be happy to provide use of my online meeting account (A= T&T Connect -- not Webex or GoToMeeting, etc., but it works pretty much the same) if we wanted to try this.=

Barbara

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 4:23 AM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Hi,<= /p>

 

Who of the LMAP contri= butors – especially authors of the documents and protocol proposals w= ill attend the meeting at IETF-91?

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, October 23, 2014 8:51 PM
To: lmap@ietf.org
Subject: [lmap] IETF-91 preliminary agenda

 

Hi,

 

I have loaded a preliminary agenda for the meeting a= t IETF-91. You can find it at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still need to fi= ll in a number of TBD – who will lead the Information Model discussio= n? What protocol submissions will be proposed and who will lead the discussions? Please send your requests to Jason and = me, and do not forget that I-D submissions cut-off is Monday 10/27.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DB319AZFFEXMB04globa_-- From nobody Fri Oct 24 08:44: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 957EC1A1AEB for ; Fri, 24 Oct 2014 08:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 evpdKuBHAwva for ; Fri, 24 Oct 2014 08:44:04 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id E561F1A1ACA for ; Fri, 24 Oct 2014 08:43:05 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6D3C9A28FC; Fri, 24 Oct 2014 11:43:05 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 2268FA28F8; Fri, 24 Oct 2014 11:43:05 -0400 (EDT) Received: from SPQCMBX01.exfo.com ([169.254.1.252]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 11:43:04 -0400 From: Sharam Hakimi To: "STARK, BARBARA H" , "MORTON, ALFRED C (AL)" , "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: [lmap] IETF-91 preliminary agenda Thread-Index: Ac/u6eCV/dwmVAQBQze8losyUOzOLQAeZE1gAArVmlAAAyEBUAAAbZjQAABo0bAAADA0sAAAT8pA Date: Fri, 24 Oct 2014 15:43:04 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FED2D72@SPQCMBX01.exfo.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130EA6E1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D7BBDA075@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED2D3A@SPQCMBX01.exfo.com> <2D09D61DDFA73D4C884805CC7865E61130EA6F89@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130EA6F89@GAALPA1MSGUSRBF.ITServices.sbc.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_89294A6F3C6C91459E52E4128C4B02B70FED2D72SPQCMBX01exfoco_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-21048.000 X-TM-AS-Result: No--35.638-5.0-31-10 X-imss-scan-details: No--35.638-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-21048.000 X-TMASE-Result: 10--35.638100-5.000000 X-TMASE-MatchedRID: Rp71wniPtoMDJrf2+hNOhcyRWt/R6ep8HTzSJQBZgdG3kA4NCeVb2BQx TjG1ZjcpIWzmoUykPQghMIMFzZSkN/Wzx4I556JgQpxiLlDD9FUFyyHXLpCyVu2u9WxDRZ0zN1/ ckxs1XmZWBxS0yOrYGyjR5b9QOX5TW+syeqqgE5FIRA38P/dwbkKzuF0egUUDmmzaGKIwUHYDdb qf2nbl9CH6jxfQvhjoZOjDZ7O+51lNlZ1zEcyAY6CS5FukbuII9mnDjfUPq56MCACDStb7tYzRE xx/TfU2ck/JTXMJp5B546GCZUbPi44a2rhHAtuZ9CCGBIPoccml9VzHf0qr7mrhyhOS2sZfOZVt RhVbf3MlpVclvjJJDMgC3MmtYeSlxcE4/N0crPzBtFDYGmaWKhrL4FDGAJ+F7Z/Wg/tvXkeECu5 7IZXqYqduVYQZj4GSxKymVSQrRs648STHBWWrBQwfhKwa9GwDWq9ln3+CkiGlF7MF/8ayEjnuQW M5MjklgExzV+J9XRgLOQeGPRNJMrSYnj+K473ZEgwM8US/pTGp0vJxmLIwiDg2jfgv3Zp9UdfEK c10rU54nNRC+UXW5wufIB114UNpe4t+BIGa1PR7k1ZHmKLF7SXdp9l6EkRZeoj5lf28MILfJn8Y mbDwRih8Zk4WjkhkFABeLgZr0ZEfE8yM4pjsD/7E6GNqs6ceOwBXM346/+wwvuQp8J/GD0NNJUP uHDKUxC3nckAPbFBfYk3Td6FQtwI8Cm0vm7jn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/gfrb3PJPZCXSUjV2kygfQo0-FQE Subject: Re: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 15:44:13 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B70FED2D72SPQCMBX01exfoco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry Barbara. You are correct we go off of DST. It is on Nov 2nd . The times would still be correct. From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Friday, October 24, 2014 11:36 AM To: Sharam Hakimi; MORTON, ALFRED C (AL); Romascanu, Dan (Dan); lmap@ietf.o= rg Subject: RE: [lmap] IETF-91 preliminary agenda Actually -- next week Europe goes *off* DST (and west coast US is still on = PDT). The week after next, the parts of US currently on DST go off DST. So = when IETF is in Hawaii, everyone will be on standard time. Barbara From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] Sent: Friday, October 24, 2014 11:28 AM To: MORTON, ALFRED C (AL); Romascanu, Dan (Dan); STARK, BARBARA H; lmap@iet= f.org Subject: RE: [lmap] IETF-91 preliminary agenda Currently it is + 6 hours for US-EST and + 3 hours US-PST . However next week DST will go into effect so it will be +5 hours US-EST a= nd +2 hours US-PST during the meeting. If it helps. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Friday, October 24, 2014 11:15 AM To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda to save others looking it up, HAST is (UTC-10:00), with no DST From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 11:04 AM To: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Let me then broaden the scope of the question. Who plans to attend the meet= ing remotely? The schedule is 0900 - 1130 Hawaii time on Thursday November = 13. Regards, Dan From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Friday, October 24, 2014 4:36 PM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: RE: [lmap] IETF-91 preliminary agenda I will be there. But I'm not an author or proponent of anything in LMAP. I've seen it done in another WG where an author has participated remotely t= hrough an online meeting. I'd be happy to provide use of my online meeting = account (AT&T Connect -- not Webex or GoToMeeting, etc., but it works prett= y much the same) if we wanted to try this. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 4:23 AM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Hi, Who of the LMAP contributors - especially authors of the documents and prot= ocol proposals will attend the meeting at IETF-91? Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, October 23, 2014 8:51 PM To: lmap@ietf.org Subject: [lmap] IETF-91 preliminary agenda Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_89294A6F3C6C91459E52E4128C4B02B70FED2D72SPQCMBX01exfoco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry Barbara. You are= correct we go off of DST. It is on Nov 2nd .<= /p>

 

The times would still = be correct.

 

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: Friday, October 24, 2014 11:36 AM
To: Sharam Hakimi; MORTON, ALFRED C (AL); Romascanu, Dan (Dan); lmap= @ietf.org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

Actually -- next week = Europe goes *off* DST (and west coast US is still on PDT). The week = after next, the parts of US currently on DST go off DST. So when IETF is in= Hawaii, everyone will be on standard time.

Barbara

 

From: Sharam H= akimi [mailto:sharam.hakimi@exfo.com]
Sent: Friday, October 24, 2014 11:28 AM
To: MORTON, ALFRED C (AL); Romascanu, Dan (Dan); STARK, BARBARA H; l= map@ietf.org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

Currently   = it is   + 6 hours for US-EST and  + 3 hours US-PST .=

 

However next week DST = will go into effect  so it will be +5 hours US-EST  and += 2 hours US-PST  during the meeting.

 

If it helps.

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL)
Sent: Friday, October 24, 2014 11:15 AM
To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

to save others looking it up, HAST is (UTC-10:00), with no DST

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 11:04 AM
To: STARK, BARBARA H; lmap@ietf.org=
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Let me then broaden th= e scope of the question. Who plans to attend the meeting remotely? The sche= dule is 0900 – 1130 Hawaii time on Thursday November 13.

 

Regards,


Dan

 

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: Friday, October 24, 2014 4:36 PM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

I will be there. But I= ’m not an author or proponent of anything in LMAP.<= /p>

I’ve seen it don= e in another WG where an author has participated remotely through an online= meeting. I’d be happy to provide use of my online meeting account (A= T&T Connect -- not Webex or GoToMeeting, etc., but it works pretty much the same) if we wanted to try this.=

Barbara

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 4:23 AM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Hi,<= /p>

 

Who of the LMAP contri= butors – especially authors of the documents and protocol proposals w= ill attend the meeting at IETF-91?

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, October 23, 2014 8:51 PM
To: lmap@ietf.org
Subject: [lmap] IETF-91 preliminary agenda

 

Hi,

 

I have loaded a preliminary agenda for the meeting a= t IETF-91. You can find it at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still need to fi= ll in a number of TBD – who will lead the Information Model discussio= n? What protocol submissions will be proposed and who will lead the discussions? Please send your requests to Jason and = me, and do not forget that I-D submissions cut-off is Monday 10/27.

 

Thanks and Regards,

 

Dan

 

--_000_89294A6F3C6C91459E52E4128C4B02B70FED2D72SPQCMBX01exfoco_-- From nobody Fri Oct 24 10:07: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 09EFD1A8704 for ; Fri, 24 Oct 2014 10:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 nP2lRx1E4i5Z for ; Fri, 24 Oct 2014 10:07:14 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [199.166.16.238]) by ietfa.amsl.com (Postfix) with ESMTP id 64AE91A8878 for ; Fri, 24 Oct 2014 10:01:03 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0B143A28F8; Fri, 24 Oct 2014 13:01:01 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id B7BE0A28F6; Fri, 24 Oct 2014 13:01:00 -0400 (EDT) Received: from SPQCMBX01.exfo.com ([169.254.1.252]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 13:01:00 -0400 From: Sharam Hakimi To: "Romascanu, Dan (Dan)" , "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: [lmap] IETF-91 preliminary agenda Thread-Index: Ac/u6eCV/dwmVAQBQze8losyUOzOLQAeZE1gAArVmlAAAyEBUAABbPQAAAKx6YA= Date: Fri, 24 Oct 2014 17:00:59 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70FED2E05@SPQCMBX01.exfo.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130EA6E1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DB319@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8DB319@AZ-FFEXMB04.global.avaya.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_89294A6F3C6C91459E52E4128C4B02B70FED2E05SPQCMBX01exfoco_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-21048.000 X-TM-AS-Result: No--32.817-5.0-31-10 X-imss-scan-details: No--32.817-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-21048.000 X-TMASE-Result: 10--32.816700-5.000000 X-TMASE-MatchedRID: Rp71wniPtoPD66A+AisN3bU+IyHhkXf1ebXaFXrQhJEkJm4xb2+/2aJC UdXVSnDZWN064PgS/Y4+f/KYh6Q26IPa1O+f7WdNStpI+4+KLgDh0NtY/EbaZWEORtrscnjUbF8 vAfCsEi3croi3CFtkcdW+58ZicXMH06P6nK44odCdtRmRhPNchvqtWPv3hAK2V9eB8vnmKe/21I T7+uo2GI9LEBgA6XLbUGCP1JhbFvCqwFDk0fZEpVaOpp/sV5nVVQHOr6CvF1aynk7TnYzMusxJR grKV1uXo1a2NAE+qSJ5zZhMIeLPzuyBTqRThUr4KWuiyZLRI4DrKzHqnonLwgzvg1/q1MH2Gu6b 1xkNe4dYVA2Tj4cKiOeJm6LClLmHwisXXd5ilGsJytP0oDv7v3Yv8liC4zR7Ooj9DXM40dL8H5l sMnSxSeI+Ja+Fp+EYrBBSnn/GVMan+dP7GcjVHbqQyAveNtg60zEP/d7xPF1G2qlFbyxbItKOgl +DNKODEdMdV1DG+alaTYT7jtOnD5J+pRMlvKpCIj0zFI5DoJItUSMDHceMrqTsE8Z/jrr+XpkMM ah9hY2No4yU4Zjt4Vc3B1k53+Rh0nbjHOkZyPnf8GJjBXCUiA3mvPKZj/z+sstO9qYbwEmjxYyR Ba/qJeBPbNdhr3+duPItwmogb14fLjSGr0iRsRRYZQhKG+2teSC65CityAyJGpV7BSbVhyVSy8q nN5DfL1ydOLTtAfW4BqfGs+mO1X7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/dzGkqOMCk0kGpXVuBDsW_E_JOv0 Subject: Re: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 17:07:18 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B70FED2E05SPQCMBX01exfoco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, On the reading list: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ https://datatracker.ietf.org/doc/draft-bagnulo-lmap-http/ https://datatracker.ietf.org/doc/draft-deng-lmap-collaboration/ https://datatracker.ietf.org/doc/draft-liu-lmap-rest/ https://datatracker.ietf.org/doc/draft-ooki-lmap-internet-measurement The last link is missing the system at the end. It should be: https://datatracker.ietf.org/doc/draft-ooki-lmap-internet-measurement-syste= m Regards, Sharam From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 11:43 AM To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda I loaded an updated - but still preliminary - agenda based on input and req= uests received in the last 24 hours. http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 6:04 PM To: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Let me then broaden the scope of the question. Who plans to attend the meet= ing remotely? The schedule is 0900 - 1130 Hawaii time on Thursday November = 13. Regards, Dan From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Friday, October 24, 2014 4:36 PM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: RE: [lmap] IETF-91 preliminary agenda I will be there. But I'm not an author or proponent of anything in LMAP. I've seen it done in another WG where an author has participated remotely t= hrough an online meeting. I'd be happy to provide use of my online meeting = account (AT&T Connect -- not Webex or GoToMeeting, etc., but it works prett= y much the same) if we wanted to try this. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 4:23 AM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Hi, Who of the LMAP contributors - especially authors of the documents and prot= ocol proposals will attend the meeting at IETF-91? Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, October 23, 2014 8:51 PM To: lmap@ietf.org Subject: [lmap] IETF-91 preliminary agenda Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_89294A6F3C6C91459E52E4128C4B02B70FED2E05SPQCMBX01exfoco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan,

 

On the reading list:

 

https://datatracker.ietf.org/doc/draft-ietf-lmap-informati= on-model/

https://datatracker.ietf.org/doc/draft-bagnulo-lmap-http/<= o:p>

https://datatracker.ietf.org/doc/draft-deng-lmap-collabora= tion/

https://datatracker.ietf.org/doc/draft-liu-lmap-rest/=

https://datatracker.ietf.org/doc/draft-ooki-lmap-internet-= measurement

 

The last link is missi= ng the system at the end. It should be:

 

https://datatracker.ietf.org/doc/draft-ooki-= lmap-internet-measurement-system

 

Regards,

Sharam

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 11:43 AM
To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

I loaded an updated &#= 8211; but still preliminary – agenda based on input and requests rece= ived in the last 24 hours.

 

http://www.ietf.org/proceedi= ngs/91/agenda/agenda-91-lmap

 

Regards,

 

Dan<= /p>

 

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 6:04 PM
To: STARK, BARBARA H; lmap@ietf.org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Let me then broaden th= e scope of the question. Who plans to attend the meeting remotely? The sche= dule is 0900 – 1130 Hawaii time on Thursday November 13.

 

Regards,


Dan

 

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: Friday, October 24, 2014 4:36 PM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

I will be there. But I= ’m not an author or proponent of anything in LMAP.<= /p>

I’ve seen it don= e in another WG where an author has participated remotely through an online= meeting. I’d be happy to provide use of my online meeting account (A= T&T Connect -- not Webex or GoToMeeting, etc., but it works pretty much the same) if we wanted to try this.=

Barbara

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 4:23 AM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Hi,<= /p>

 

Who of the LMAP contri= butors – especially authors of the documents and protocol proposals w= ill attend the meeting at IETF-91?

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, October 23, 2014 8:51 PM
To: lmap@ietf.org
Subject: [lmap] IETF-91 preliminary agenda

 

Hi,

 

I have loaded a preliminary agenda for the meeting a= t IETF-91. You can find it at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still need to fi= ll in a number of TBD – who will lead the Information Model discussio= n? What protocol submissions will be proposed and who will lead the discussions? Please send your requests to Jason and = me, and do not forget that I-D submissions cut-off is Monday 10/27.

 

Thanks and Regards,

 

Dan

 

--_000_89294A6F3C6C91459E52E4128C4B02B70FED2E05SPQCMBX01exfoco_-- From nobody Fri Oct 24 10:11:33 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0785D1A6FFB for ; Fri, 24 Oct 2014 10:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 KuCsjh_n3FO6 for ; Fri, 24 Oct 2014 10:11:24 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29181A875B for ; Fri, 24 Oct 2014 10:08:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiELAAmHSlTGmAcV/2dsb2JhbABcgkgjI1RYBLksDAEBAQECBpNoh0sCgQgWAQF8hAIBAQEBAxIbXAIBCA0EBAEBCwsSBzIUCQgCBAESCAEZiB8BDKsen08BAQEBAQEBAQEBAQEBAQEBAQEBAQEXhiWKAi0KAQqDI4EeBY9ngh6ERohDg0mDG4oXhACDeGyBSIEDAQEB X-IronPort-AV: E=Sophos; i="5.04,781,1406606400"; d="scan'208,217"; a="91633033" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Oct 2014 13:08:38 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 24 Oct 2014 13:08:38 -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; Fri, 24 Oct 2014 19:08:37 +0200 From: "Romascanu, Dan (Dan)" To: Sharam Hakimi , "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: [lmap] IETF-91 preliminary agenda Thread-Index: Ac/u6eCV/dwmVAQBQze8losyUOzOLQAeZE1gAArVmlAAAyEBUAABbPQAAAKx6YAAAFP/UA== Date: Fri, 24 Oct 2014 17:08:36 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8DBB20@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C8DA22B@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DAD99@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130EA6E1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DB1F8@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8DB319@AZ-FFEXMB04.global.avaya.com> <89294A6F3C6C91459E52E4128C4B02B70FED2E05@SPQCMBX01.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70FED2E05@SPQCMBX01.exfo.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_9904FB1B0159DA42B0B887B7FA8119CA5C8DBB20AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/EujkIzR_KY9XkfV1H-UeqCzH_6M Subject: Re: [lmap] IETF-91 preliminary agenda X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 17:11:28 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DBB20AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fixed. Thanks and Regards, Dan From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] Sent: Friday, October 24, 2014 8:01 PM To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] IETF-91 preliminary agenda Hi Dan, On the reading list: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ https://datatracker.ietf.org/doc/draft-bagnulo-lmap-http/ https://datatracker.ietf.org/doc/draft-deng-lmap-collaboration/ https://datatracker.ietf.org/doc/draft-liu-lmap-rest/ https://datatracker.ietf.org/doc/draft-ooki-lmap-internet-measurement The last link is missing the system at the end. It should be: https://datatracker.ietf.org/doc/draft-ooki-lmap-internet-measurement-syste= m Regards, Sharam From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 11:43 AM To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda I loaded an updated - but still preliminary - agenda based on input and req= uests received in the last 24 hours. http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 6:04 PM To: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Let me then broaden the scope of the question. Who plans to attend the meet= ing remotely? The schedule is 0900 - 1130 Hawaii time on Thursday November = 13. Regards, Dan From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Friday, October 24, 2014 4:36 PM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: RE: [lmap] IETF-91 preliminary agenda I will be there. But I'm not an author or proponent of anything in LMAP. I've seen it done in another WG where an author has participated remotely t= hrough an online meeting. I'd be happy to provide use of my online meeting = account (AT&T Connect -- not Webex or GoToMeeting, etc., but it works prett= y much the same) if we wanted to try this. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Friday, October 24, 2014 4:23 AM To: Romascanu, Dan (Dan); lmap@ietf.org Subject: Re: [lmap] IETF-91 preliminary agenda Hi, Who of the LMAP contributors - especially authors of the documents and prot= ocol proposals will attend the meeting at IETF-91? Thanks and Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, October 23, 2014 8:51 PM To: lmap@ietf.org Subject: [lmap] IETF-91 preliminary agenda Hi, I have loaded a preliminary agenda for the meeting at IETF-91. You can find= it at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still n= eed to fill in a number of TBD - who will lead the Information Model discus= sion? What protocol submissions will be proposed and who will lead the disc= ussions? Please send your requests to Jason and me, and do not forget that = I-D submissions cut-off is Monday 10/27. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DBB20AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fixed.

 

Thanks and Regards,

 

Dan<= /p>

 

From: Sharam H= akimi [mailto:sharam.hakimi@exfo.com]
Sent: Friday, October 24, 2014 8:01 PM
To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

Hi Dan,

 

On the reading list:

 

https://datatracker.ietf.org/doc/draft-ietf-lmap-info= rmation-model/

https://datatracker.ietf.org/doc/draft-bagnulo-lmap-http/

https://datatracker.ietf.org/doc/draft-deng-lmap-collabor= ation/

https://datatracker.ietf.org/doc/draft-liu-lmap-rest/

https://datatracker.ietf.org/doc/draft-ooki-lmap-in= ternet-measurement

 

The last link is missi= ng the system at the end. It should be:

 

https://datatracker.ietf.org/doc/draft-ooki-= lmap-internet-measurement-system

 

Regards,

Sharam

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 11:43 AM
To: Romascanu, Dan (Dan); STARK, BARBARA H; lmap@ietf.org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

I loaded an updated &#= 8211; but still preliminary – agenda based on input and requests rece= ived in the last 24 hours.

 

http://www.ietf.org/proceedi= ngs/91/agenda/agenda-91-lmap

 

Regards,

 

Dan<= /p>

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 6:04 PM
To: STARK, BARBARA H; lmap@ietf.org=
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Let me then broaden th= e scope of the question. Who plans to attend the meeting remotely? The sche= dule is 0900 – 1130 Hawaii time on Thursday November 13.

 

Regards,


Dan

 

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: Friday, October 24, 2014 4:36 PM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: RE: [lmap] IETF-91 preliminary agenda

 

I will be there. But I= ’m not an author or proponent of anything in LMAP.<= /p>

I’ve seen it don= e in another WG where an author has participated remotely through an online= meeting. I’d be happy to provide use of my online meeting account (A= T&T Connect -- not Webex or GoToMeeting, etc., but it works pretty much the same) if we wanted to try this.=

Barbara

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, October 24, 2014 4:23 AM
To: Romascanu, Dan (Dan); lmap@ietf= .org
Subject: Re: [lmap] IETF-91 preliminary agenda

 

Hi,<= /p>

 

Who of the LMAP contri= butors – especially authors of the documents and protocol proposals w= ill attend the meeting at IETF-91?

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, October 23, 2014 8:51 PM
To: lmap@ietf.org
Subject: [lmap] IETF-91 preliminary agenda

 

Hi,

 

I have loaded a preliminary agenda for the meeting a= t IETF-91. You can find it at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. We still need to fi= ll in a number of TBD – who will lead the Information Model discussio= n? What protocol submissions will be proposed and who will lead the discussions? Please send your requests to Jason and = me, and do not forget that I-D submissions cut-off is Monday 10/27.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8DBB20AZFFEXMB04globa_-- From nobody Fri Oct 24 14:11: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 ACBD21A916C for ; Fri, 24 Oct 2014 14:11:33 -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 Xw7iZ5AkQb0R for ; Fri, 24 Oct 2014 14:11:30 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75711A9174 for ; Fri, 24 Oct 2014 14:10:58 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id la4so712679vcb.41 for ; Fri, 24 Oct 2014 14:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Pt1WhWR6/PmD+tGc6w//WduR/19m2sk774w8tyZ5jRw=; b=vwFtDEzRqLr6czhJbdU+f/eqwMFt4kUXGbxk0uQ3Z7Ichmsc3EmDOsbqcjLLxBCI/m ZKxAeWf5urluJgCApZ9fO3Ub95voy0+JcAz456NjOqfL5igyKMD4bigftkQ0L9ufc0RR M+ArbcoCwD571V2LhhNyOzzoNkS1FhvnotjqvEdtoWok33d0c1zlSHOiEsGpIroDAgc2 fudYDNWDc7vmo1mp2oHP4VWz5w/x6Slw83xbzyEe7zmKVo2mwqL7DE2F0qCmDPJTsmy+ rFvry5Qw29FXZc+eEzcwE8n1ibWItLvuvpYf7aCY+pgzfokOrUvNiI0csGWHW1ZmFVcg HYrQ== MIME-Version: 1.0 X-Received: by 10.220.116.193 with SMTP id n1mr9266vcq.48.1414185057739; Fri, 24 Oct 2014 14:10:57 -0700 (PDT) Received: by 10.221.65.71 with HTTP; Fri, 24 Oct 2014 14:10:57 -0700 (PDT) In-Reply-To: <20141020070319.GA86721@elstar.local> References: <20141020070319.GA86721@elstar.local> Date: Fri, 24 Oct 2014 14:10:57 -0700 Message-ID: From: Greg Mirsky To: Juergen Schoenwaelder , trevor.burbridge@bt.com, "lmap@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3437a20367430506319e63 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ZPgLbWP9TB61Ton1qj-aOqhg0qg Subject: Re: [lmap] Information Model: Task Configuration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Oct 2014 21:11:34 -0000 --047d7b3437a20367430506319e63 Content-Type: text/plain; charset=UTF-8 Hi Juergen, et. al, what I think Ken is saying, and I agree with that approach, is that, using your example, Schedule may overwrite *any *parameter configured in a Task Configuration not just fill in missing parameters. Regards, Greg On Mon, Oct 20, 2014 at 12:03 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Oct 15, 2014 at 02:18:26PM +0100, trevor.burbridge@bt.com wrote: > > During Dublin we debated (but didn't come to a strong conclusion on) two > key topics. This is the first of those topics. > > > > Currently we have a concept of a Task Configuration where task > parameters can be configured. The same Task Configuration can then be > referenced multiple times from number of different Schedules. > > > > It was pointed out that this can be very inefficient if we want to run > basically the same task with just one parameter changing each time such as > the test target. E.g. if we are running against 10 different targets then > we largely have to reproduce and transmit to the MA 10 very similar Task > Configurations. > > > > The options as I understand them are: > > > > - Specify all parameters in Task Configurations is fine. > Conceptually simple is more important than efficiency > > > > - Allow a hierarchical inheritance of Task Configurations. I.e. > define a general Task Configuration and the specialise for 10 different > targets. May be very confusing for people not familiar with such concepts > especially at the data model level. > > > > - Allow task parameters to be specified either by > using/referencing a Task Configuration or by supplying them within a > Schedule. E.g. this would allow a general Task Configuration to be used but > the target could be supplied within the Schedule. Conceptually clean, > flexible and allows the optimum balance. > > > > All options are as powerful as each other so it comes down to which is > easier to understand and which is more efficient. > > > > Let me expand on the third option: > > The Task Configuration is a name/value pair list. A bSchedule has > another name/value pair list that is conceptually appended (or > prepended - to be decided) to the Task Configuration list. The > measurement task will have to decide based on the semantics of the > parameters involved whether a repeated name/value pair is an > overwrite or an addition. (This is nothing new since the Task > Configuration even today allows repeated name/value pairs and this > does make sense.) > > I believe this is conceptually simple. More 'static' task > configuration parameters can be shared between schedules while more > 'dynamic' task configuration parameters can go into the schedules. > > Example: > > For a ping6 ping, you may want to configure relatively static > parameters such as the flow label to use, the interval between > each packet, whether it is using IMCPv6 Echo requests or Node > Information Queries, the DSCP value to use, the packet size, > etc. in a Task Configuration and in the Schedule you configure the > target(s) to be probed with these Task Configuration parameters. > > /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 > --047d7b3437a20367430506319e63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juergen, et. al,
what I think K= en is saying, and I agree with that approach, is that, using your example, = Schedule may overwrite any parameter configured in a Task Configurat= ion not just fill in missing parameters.

Regards,
Gre= g

On Mon= , Oct 20, 2014 at 12:03 AM, Juergen Schoenwaelder <j.sc= hoenwaelder@jacobs-university.de> wrote:
On Wed, Oct 15, 2014 at 02:18:26PM +0100, trevor.burbridge@bt.com wrote:=
> During Dublin we debated (but didn't come to a strong conclusion o= n) two key topics. This is the first of those topics.
>
> Currently we have a concept of a Task Configuration where task paramet= ers can be configured. The same Task Configuration can then be referenced m= ultiple times from=C2=A0 number of different Schedules.
>
> It was pointed out that this can be very inefficient if we want to run= basically the same task with just one parameter changing each time such as= the test target. E.g. if we are running against 10 different targets then = we largely have to reproduce and transmit to the MA 10 very similar Task Co= nfigurations.
>
> The options as I understand them are:
>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Specify all parameters in Task Configurat= ions is fine. Conceptually simple is more important than efficiency
>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Allow a hierarchical inheritance of Task = Configurations. I.e. define a general Task Configuration and the specialise= for 10 different targets. May be very confusing for people not familiar wi= th such concepts especially at the data model level.
>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Allow task parameters to be specified eit= her by using/referencing a Task Configuration or by supplying them within a= Schedule. E.g. this would allow a general Task Configuration to be used bu= t the target could be supplied within the Schedule. Conceptually clean, fle= xible and allows the optimum balance.
>
> All options are as powerful as each other so it comes down to which is= easier to understand and which is more efficient.
>

Let me expand on the third option:

=C2=A0 =C2=A0 The Task Configuration is a name/value pair list. A bSchedule= has
=C2=A0 =C2=A0 another name/value pair list that is conceptually appended (o= r
=C2=A0 =C2=A0 prepended - to be decided) to the Task Configuration list. Th= e
=C2=A0 =C2=A0 measurement task will have to decide based on the semantics o= f the
=C2=A0 =C2=A0 parameters involved whether a repeated name/value pair is an<= br> =C2=A0 =C2=A0 overwrite or an addition. (This is nothing new since the Task=
=C2=A0 =C2=A0 Configuration even today allows repeated name/value pairs and= this
=C2=A0 =C2=A0 does make sense.)

I believe this is conceptually simple. More 'static' task
configuration parameters can be shared between schedules while more
'dynamic' task configuration parameters can go into the schedules.<= br>
Example:

=C2=A0 =C2=A0 For a ping6 ping, you may want to configure relatively static=
=C2=A0 =C2=A0 parameters such as the flow label to use, the interval betwee= n
=C2=A0 =C2=A0 each packet, whether it is using IMCPv6 Echo requests or Node=
=C2=A0 =C2=A0 Information Queries, the DSCP value to use, the packet size,<= br> =C2=A0 =C2=A0 etc. in a Task Configuration and in the Schedule you configur= e the
=C2=A0 =C2=A0 target(s) to be probed with these Task Configuration paramete= rs.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1, 28759 Bre= men, Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>

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

--047d7b3437a20367430506319e63-- From nobody Fri Oct 24 14:36: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 5B0DC1A6FC1 for ; Fri, 24 Oct 2014 14:36:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 pOHudknb4hdM for ; Fri, 24 Oct 2014 14:36:22 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17131A6FBA for ; Fri, 24 Oct 2014 14:36: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 74341A31; Fri, 24 Oct 2014 23:36:20 +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 aSRPv8V8DlRO; Fri, 24 Oct 2014 23:36:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 24 Oct 2014 23:36:19 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2223620037; Fri, 24 Oct 2014 23:36:19 +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 GGgg92Xq6pPb; Fri, 24 Oct 2014 23:36:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7968820035; Fri, 24 Oct 2014 23:36:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A60042F0EF2D; Fri, 24 Oct 2014 23:36:16 +0200 (CEST) Date: Fri, 24 Oct 2014 23:36:16 +0200 From: Juergen Schoenwaelder To: Greg Mirsky Message-ID: <20141024213616.GA1889@elstar.local> Mail-Followup-To: Greg Mirsky , trevor.burbridge@bt.com, "lmap@ietf.org" References: <20141020070319.GA86721@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/cG4Sq2pkETpGjCbuEzdnBWEs0Dw Cc: trevor.burbridge@bt.com, "lmap@ietf.org" Subject: Re: [lmap] Information Model: Task Configuration X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 21:36:24 -0000 Hi, I understand but I disagree since the semantics of the parameters need decide whether we overwrite or add another parameters. Hence, it is best to join the parameter lists and to let the task, based on the semantics of the parameters, decide what it should do. For me, the parameters are an ordered list and duplicates are allowed. The most meaningful operation for me is an append (or prepend). Here is an example: iperf -u -c localhost -t 10 -t 2 The option -t can only appear once, last option wins. Another example: ping www.ietf.org -c 8 -c 2 mtr -c 8 -c 2 www.ietf.org The option -c can only appear once, last option wins. And one more: happy -q 6 -q 1 www.ietf.org www.bing.com The option -q can only appear once, last option wins. The target can appear multiple times so both www.ietf.org and www.bing.com are probed. /js On Fri, Oct 24, 2014 at 02:10:57PM -0700, Greg Mirsky wrote: > Hi Juergen, et. al, > what I think Ken is saying, and I agree with that approach, is that, using > your example, Schedule may overwrite *any *parameter configured in a Task > Configuration not just fill in missing parameters. > > Regards, > Greg > > On Mon, Oct 20, 2014 at 12:03 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Wed, Oct 15, 2014 at 02:18:26PM +0100, trevor.burbridge@bt.com wrote: > > > During Dublin we debated (but didn't come to a strong conclusion on) two > > key topics. This is the first of those topics. > > > > > > Currently we have a concept of a Task Configuration where task > > parameters can be configured. The same Task Configuration can then be > > referenced multiple times from number of different Schedules. > > > > > > It was pointed out that this can be very inefficient if we want to run > > basically the same task with just one parameter changing each time such as > > the test target. E.g. if we are running against 10 different targets then > > we largely have to reproduce and transmit to the MA 10 very similar Task > > Configurations. > > > > > > The options as I understand them are: > > > > > > - Specify all parameters in Task Configurations is fine. > > Conceptually simple is more important than efficiency > > > > > > - Allow a hierarchical inheritance of Task Configurations. I.e. > > define a general Task Configuration and the specialise for 10 different > > targets. May be very confusing for people not familiar with such concepts > > especially at the data model level. > > > > > > - Allow task parameters to be specified either by > > using/referencing a Task Configuration or by supplying them within a > > Schedule. E.g. this would allow a general Task Configuration to be used but > > the target could be supplied within the Schedule. Conceptually clean, > > flexible and allows the optimum balance. > > > > > > All options are as powerful as each other so it comes down to which is > > easier to understand and which is more efficient. > > > > > > > Let me expand on the third option: > > > > The Task Configuration is a name/value pair list. A bSchedule has > > another name/value pair list that is conceptually appended (or > > prepended - to be decided) to the Task Configuration list. The > > measurement task will have to decide based on the semantics of the > > parameters involved whether a repeated name/value pair is an > > overwrite or an addition. (This is nothing new since the Task > > Configuration even today allows repeated name/value pairs and this > > does make sense.) > > > > I believe this is conceptually simple. More 'static' task > > configuration parameters can be shared between schedules while more > > 'dynamic' task configuration parameters can go into the schedules. > > > > Example: > > > > For a ping6 ping, you may want to configure relatively static > > parameters such as the flow label to use, the interval between > > each packet, whether it is using IMCPv6 Echo requests or Node > > Information Queries, the DSCP value to use, the packet size, > > etc. in a Task Configuration and in the Schedule you configure the > > target(s) to be probed with these Task Configuration parameters. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Oct 24 14:46: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 08DBC1A8A62 for ; Fri, 24 Oct 2014 14:46:17 -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 0jhIpZbxRWiy for ; Fri, 24 Oct 2014 14:46:14 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42ECD1A6FA8 for ; Fri, 24 Oct 2014 14:46:14 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hq12so753711vcb.19 for ; Fri, 24 Oct 2014 14:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=MLCmMWdheshsCZFkK1+CH6q2uVeDr7RL+X3zQrmvxR0=; b=tGU7pM+2HsZ8DipZw4gXE1RylbBNJ3LAR5f5jg90qFqE/gkvtbRkIs3lPlGfTyvOdV LXsFAO8/tsTpe//gCpzGZNrQHXw0p+h81fG4V5iH+kYNGVcAEYIRhfCtL4D9haIspS/a jN22qr1jAURDqmOSPVs/z3oGyYSemwdzj93FJoY+kak3sBgUhsIGWTJtZWu5qvjv7YPs nBkm8hRD7585pDd02Nbb5R0nCBiQEMb9E8T6nCEy3CcsfS/JYsfUT5SJedopsAzE1VSh g/WwYqpPX4MU7FL8g0LLrqSDSYsmdtnkErUnUgoz/XM7wTcSUJXwje8fblmWkHk5DEn3 J9DA== MIME-Version: 1.0 X-Received: by 10.52.101.225 with SMTP id fj1mr552346vdb.10.1414187173207; Fri, 24 Oct 2014 14:46:13 -0700 (PDT) Received: by 10.221.65.71 with HTTP; Fri, 24 Oct 2014 14:46:13 -0700 (PDT) In-Reply-To: <20141020201642.GA89064@elstar.local> References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <5445526C.8050409@uninett.no> <20141020201642.GA89064@elstar.local> Date: Fri, 24 Oct 2014 14:46:13 -0700 Message-ID: From: Greg Mirsky To: Juergen Schoenwaelder , Arne Oslebo , "lmap@ietf.org" Content-Type: multipart/alternative; boundary=bcaec54860341ae3470506321c94 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Kq17WT6-VT_OEUfFihTS8WWk6ww Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 21:46:17 -0000 --bcaec54860341ae3470506321c94 Content-Type: text/plain; charset=UTF-8 Hi Juergen, I agree that specifying behavior is important to arrive to interoperable implementations. I don't think that specifying particular mechanism, i.e. queue, is critical. I don't think that when considering queue we assume it as infinite resource. If that is the case, then I can present implementation without a queue as queue of zero depth. Thus the only difference between queued and un-queued output would be when it may get overrun. What I'd like to have is defined behavior of end-points of the output channel. Regards, Greg On Mon, Oct 20, 2014 at 1:16 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Oct 20, 2014 at 08:20:28PM +0200, Arne Oslebo wrote: > > I agree with Timothy and would prefer not to include anything about > > queues in the information model. If we need to define queuing behavior > > then I think it is better done as part of the task definition. Queuing > > requirements for logging and reporting might be different. This will > > also make it easier for people who do not agree with the standardized > > queuing behavior to come up with their own solutions. > > Are you saying that every output channel of every task should have an > independent queue but we better don't say so because being silent > about queues allows everybody to implement what they like? I fail to > see how we will get robust interoperable behaviour by leaving this > completely open to interpretation and implementation choice. By robust > I mean implementations that still behave in a predictable way in case > of resource shortage (e.g. memory) or malfunctioning tasks in a chain > of tasks (which may eventually lead to resource shortage). > > /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 > --bcaec54860341ae3470506321c94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juergen,
I agree that specifyin= g behavior is important to arrive to interoperable implementations. I don&#= 39;t think that specifying particular mechanism, i.e. queue, is critical. I= don't think that when considering queue we assume it as infinite resou= rce. If that is the case, then I can present implementation without a queue= as queue of zero depth. Thus the only difference between queued and un-que= ued output would be when it may get overrun. What I'd like to have is d= efined behavior of end-points of the output channel.

Regards,<= br>
Greg

On Mon, Oct 20, 2014 at 1:16 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Oct 20, 2014 at 08:20:28P= M +0200, Arne Oslebo wrote:
> I agree with Timothy and would prefer not to include anything about > queues in the information model. If we need to define queuing behavior=
> then I think it is better done as part of the task definition. Queuing=
> requirements for logging and reporting might be different. This will > also make it easier for people who do not agree with the standardized<= br> > queuing behavior to come up with their own solutions.

Are you saying that every output channel of every task should have a= n
independent queue but we better don't say so because being silent
about queues allows everybody to implement what they like? I fail to
see how we will get robust interoperable behaviour by leaving this
completely open to interpretation and implementation choice. By robust
I mean implementations that still behave in a predictable way in case
of resource shortage (e.g. memory) or malfunctioning tasks in a chain
of tasks (which may eventually lead to resource shortage).

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1, 28759 Bre= men, Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>

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

--bcaec54860341ae3470506321c94-- From nobody Mon Oct 27 10:56: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 C62B01A8892 for ; Mon, 27 Oct 2014 10:55:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 0qqBKDeBLLqh for ; Mon, 27 Oct 2014 10:55:49 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE951A883C for ; Mon, 27 Oct 2014 10:55:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 724F875A; Mon, 27 Oct 2014 18:55:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kOujWhPpzJ51; Mon, 27 Oct 2014 18:55:16 +0100 (CET) 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, 27 Oct 2014 18:55:20 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 153DA20037; Mon, 27 Oct 2014 18:55:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yauBPhTDzunD; Mon, 27 Oct 2014 18:55:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E75E820035; Mon, 27 Oct 2014 18:55:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2D2AF2F14932; Mon, 27 Oct 2014 18:55:18 +0100 (CET) Date: Mon, 27 Oct 2014 18:55:18 +0100 From: Juergen Schoenwaelder To: Greg Mirsky Message-ID: <20141027175518.GB9540@elstar.local> Mail-Followup-To: Greg Mirsky , Arne Oslebo , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F7734FC0C6B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <5445526C.8050409@uninett.no> <20141020201642.GA89064@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/d7GCbRqPO6BSOjj_1njmIvT-p6A Cc: Arne Oslebo , "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:55:52 -0000 Please tell me how you pass results from a measurement task to reporting task scheduled later without a queue. Thanks, /js On Fri, Oct 24, 2014 at 02:46:13PM -0700, Greg Mirsky wrote: > Hi Juergen, > I agree that specifying behavior is important to arrive to interoperable > implementations. I don't think that specifying particular mechanism, i.e. > queue, is critical. I don't think that when considering queue we assume it > as infinite resource. If that is the case, then I can present > implementation without a queue as queue of zero depth. Thus the only > difference between queued and un-queued output would be when it may get > overrun. What I'd like to have is defined behavior of end-points of the > output channel. > > Regards, > Greg > > On Mon, Oct 20, 2014 at 1:16 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Oct 20, 2014 at 08:20:28PM +0200, Arne Oslebo wrote: > > > I agree with Timothy and would prefer not to include anything about > > > queues in the information model. If we need to define queuing behavior > > > then I think it is better done as part of the task definition. Queuing > > > requirements for logging and reporting might be different. This will > > > also make it easier for people who do not agree with the standardized > > > queuing behavior to come up with their own solutions. > > > > Are you saying that every output channel of every task should have an > > independent queue but we better don't say so because being silent > > about queues allows everybody to implement what they like? I fail to > > see how we will get robust interoperable behaviour by leaving this > > completely open to interpretation and implementation choice. By robust > > I mean implementations that still behave in a predictable way in case > > of resource shortage (e.g. memory) or malfunctioning tasks in a chain > > of tasks (which may eventually lead to resource shortage). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Oct 27 11:03: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 811171A888A for ; Mon, 27 Oct 2014 10:57:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2nspG2Z5HP1C for ; Mon, 27 Oct 2014 10:57:33 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4ED21A8849 for ; Mon, 27 Oct 2014 10:57:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7956B765; Mon, 27 Oct 2014 18:57:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id C2GwKe6PVFyZ; Mon, 27 Oct 2014 18:57:25 +0100 (CET) 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, 27 Oct 2014 18:57:29 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3EEC20038; Mon, 27 Oct 2014 18:57:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pK4mk7VYxseb; Mon, 27 Oct 2014 18:57:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 147DC20035; Mon, 27 Oct 2014 18:57:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 89C442F14962; Mon, 27 Oct 2014 18:57:27 +0100 (CET) Date: Mon, 27 Oct 2014 18:57:27 +0100 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20141027175727.GC9540@elstar.local> Mail-Followup-To: Sharam Hakimi , "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A11@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED28A5@SPQCMBX01.exfo.com> <20141022184328.GA94731@elstar.local> <20141023180734.GA97528@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A23@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED2D19@SPQCMBX01.exfo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70FED2D19@SPQCMBX01.exfo.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/6x33eFc0d11s9rgJsVn5ocZNB5w Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:57:35 -0000 We are talking about passing measurement results to a reporting tasks. The word 'parameter' may confuse this little detail. And a specific corner case does not help us to resolve the general case, namely that measurement tasks and reporting tasks run according to independent schedules. /js On Fri, Oct 24, 2014 at 03:20:08PM +0000, Sharam Hakimi wrote: > Now that I think we agree not to specify processing power or resource requirements for passing parameters between tasks, it is back to just trying to specify a queue mechanism to try to pass some parameters between tasks. Some parameters can be part of the schedule, for example: > > Run Task A > If Task A completes with success Run Task B > Else goto Task C > > > Task B > Task C > > One would not need to pass any parameter between A and B even though the result of Task A is used to make a decision on the execution of the schedule by the MA. > > I am not sure how easy it would be to get consensus on the Queue structure if we do not know what needs to be passed between what tasks or what the consequence of that would be. > > Sharam > > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acm@research.att.com] > Sent: Thursday, October 23, 2014 2:19 PM > To: Juergen Schoenwaelder; Sharam Hakimi > Cc: lmap@ietf.org > Subject: RE: [lmap] Information Model: Connecting Tasks > > I agree with Juergen's comment below. > > We are debating concepts in the Information Model (it's not even a data model yet). > Perhaps it is the uncertainty of what will be agreed that causes problems here. > > Trevor, I hope we will have a more concrete proposal (with the queue concept) > to review before IETF-91, then this issue can be put to bed. > > Al > ________________________________________ > From: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de] > Sent: Thursday, October 23, 2014 2:07 PM > To: Sharam Hakimi > Cc: MORTON, ALFRED C (AL); lmap@ietf.org > Subject: Re: [lmap] Information Model: Connecting Tasks > > Making queues explicit in the information model != specify the > implementation. Without some form of queues, you can't pass > information between tasks that run on different schedules. > > Following you analogy, I am saying we should say that the car has an > engine instead of pretending all it has is a gas pedal. Once your car > stops, it will become important to know whether you need to look for > electicity or some other type of fuel. > > I guess analogies do not help much... > > /js > > On Thu, Oct 23, 2014 at 03:16:39PM +0000, Sharam Hakimi wrote: > > As an example, when a car is designed each part in the car defines the power requirement for it to run. The Battery/Alternator system is designed based on as many parts that can run concurrently and that is up to implementation. Not all MAs will be created equal and I do not believe that we need to specify an implementation. The user will dictate what their requirement is and the implementation would need to match that. How many queues to handle is up to the implementation. > > > > Today One server can handle 100 TWAMP connection and perform the test and another can handle 1000. TWAMP does not specify the implementation, just what is required to schedule, run, capture results and report results for one instance. > > > > > > Sharam > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, October 22, 2014 2:43 PM > > To: Sharam Hakimi > > Cc: MORTON, ALFRED C (AL); lmap@ietf.org > > Subject: Re: [lmap] Information Model: Connecting Tasks > > > > On Wed, Oct 22, 2014 at 04:22:32PM +0000, Sharam Hakimi wrote: > > > What I think needs to be specified is that an MA must have enough capability(CPU power, memory, etc.) to execute a single defined task( run task, log, transfer results). Beyond that really should be up to the implementation. If one can design an inexpensive device with multiple core CPUs and Gigs of memory that allows for multiple concurrent tasks then that is up to the implementer. > > > > > > I do not think we should manage implementations, rather specify the resource requirement for every defined task. > > > > > > > Using LMAP, I can configure (a) how frequently a measurement test is > > executed (and hence how much data it produces) and (b) how frequently > > a reporting task is executed. In other words, the amount of buffer > > space I need depends on the schedule(s) and hence it is out of the > > control of the implementation. Even if an implementation tries to > > reject schedules that may potentially overrun resources, once you > > loose connectivity it surely can run out of resources again. > > > > Assuming an implementation has always sufficient resources is > > unrealistic and definitely not something that can be specified. > > > > Note: We are not talking about the execution of a single task but > > instead about how data is passed between tasks. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > 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 Mon Oct 27 11:53: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 0F9B21A88EA for ; Mon, 27 Oct 2014 11:53:27 -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 D-wEcV45EA-g for ; Mon, 27 Oct 2014 11:53:24 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18191ACEFD for ; Mon, 27 Oct 2014 11:53:09 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s9RIr6sc011855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2014 13:53:06 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E50581E002C; Mon, 27 Oct 2014 13:53:00 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id D0D5A1E0073; Mon, 27 Oct 2014 13:53:00 -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 s9RIr0t2018464; Mon, 27 Oct 2014 13:53:00 -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 s9RIqxgD018428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 13:53:00 -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; Mon, 27 Oct 2014 13:52:59 -0500 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" , "'Sharam Hakimi'" Thread-Topic: [lmap] Information Model: Connecting Tasks Thread-Index: Ac/ofHtSaYdiY6Y/R4mNbjroR+i0BgACHKHIAFiZngwBCuiJYAANqJQAACHLIUAADz7NAAAAaYAAACMf7JAAp16vgAAImJXw Date: Mon, 27 Oct 2014 18:52:58 +0000 Message-ID: References: <20141017084439.GC80274@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734FC28C7@US70UWXCHMBA05.zam.alcatel-lucent.com> <20141020063613.GD86545@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF89FD@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A11@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED28A5@SPQCMBX01.exfo.com> <20141022184328.GA94731@elstar.local> <20141023180734.GA97528@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D7BBF8A23@NJFPSRVEXG0.research.att.com> <89294A6F3C6C91459E52E4128C4B02B70FED2D19@SPQCMBX01.exfo.com> <20141027175727.GC9540@elstar.local> In-Reply-To: <20141027175727.GC9540@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Xbngii3wcg3YTkJdukrmiDSo24A Cc: "'MORTON, ALFRED C \(AL\)'" , "'lmap@ietf.org'" Subject: Re: [lmap] Information Model: Connecting Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:53:27 -0000 I still believe that most tests are actually scripts vs. a task...=20 A task is a work item... that can contain a script ? Enjoy the meeting - I'm on vacation for a good part of this one so I dind't= bother trying to ask for travel. Best regards, Mike -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: Monday, October 27, 2014 12:57 PM To: Sharam Hakimi Cc: MORTON, ALFRED C (AL); lmap@ietf.org Subject: Re: [lmap] Information Model: Connecting Tasks We are talking about passing measurement results to a reporting tasks. The word 'parameter' may confuse this little detail. And a specific corner = case does not help us to resolve the general case, namely that measurement = tasks and reporting tasks run according to independent schedules. /js On Fri, Oct 24, 2014 at 03:20:08PM +0000, Sharam Hakimi wrote: > Now that I think we agree not to specify processing power or resource req= uirements for passing parameters between tasks, it is back to just trying t= o specify a queue mechanism to try to pass some parameters between tasks. S= ome parameters can be part of the schedule, for example: >=20 > Run Task A > If Task A completes with success Run Task B =20 > Else goto Task C >=20 >=20 > Task B > Task C >=20 > One would not need to pass any parameter between A and B even though the = result of Task A is used to make a decision on the execution of the schedul= e by the MA.=20 >=20 > I am not sure how easy it would be to get consensus on the Queue structur= e if we do not know what needs to be passed between what tasks or what the = consequence of that would be.=20 >=20 > Sharam >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acm@research.att.com] > Sent: Thursday, October 23, 2014 2:19 PM > To: Juergen Schoenwaelder; Sharam Hakimi > Cc: lmap@ietf.org > Subject: RE: [lmap] Information Model: Connecting Tasks >=20 > I agree with Juergen's comment below. >=20 > We are debating concepts in the Information Model (it's not even a data = model yet). > Perhaps it is the uncertainty of what will be agreed that causes problems= here. >=20 > Trevor, I hope we will have a more concrete proposal (with the queue=20 > concept) to review before IETF-91, then this issue can be put to bed. >=20 > Al > ________________________________________ > From: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de] > Sent: Thursday, October 23, 2014 2:07 PM > To: Sharam Hakimi > Cc: MORTON, ALFRED C (AL); lmap@ietf.org > Subject: Re: [lmap] Information Model: Connecting Tasks >=20 > Making queues explicit in the information model !=3D specify the=20 > implementation. Without some form of queues, you can't pass=20 > information between tasks that run on different schedules. >=20 > Following you analogy, I am saying we should say that the car has an=20 > engine instead of pretending all it has is a gas pedal. Once your car=20 > stops, it will become important to know whether you need to look for=20 > electicity or some other type of fuel. >=20 > I guess analogies do not help much... >=20 > /js >=20 > On Thu, Oct 23, 2014 at 03:16:39PM +0000, Sharam Hakimi wrote: > > As an example, when a car is designed each part in the car defines the = power requirement for it to run. The Battery/Alternator system is designed = based on as many parts that can run concurrently and that is up to implemen= tation. Not all MAs will be created equal and I do not believe that we need= to specify an implementation. The user will dictate what their requirement= is and the implementation would need to match that. How many queues to han= dle is up to the implementation. > > > > Today One server can handle 100 TWAMP connection and perform the test a= nd another can handle 1000. TWAMP does not specify the implementation, just= what is required to schedule, run, capture results and report results for = one instance. > > > > > > Sharam > > > > -----Original Message----- > > From: Juergen Schoenwaelder=20 > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, October 22, 2014 2:43 PM > > To: Sharam Hakimi > > Cc: MORTON, ALFRED C (AL); lmap@ietf.org > > Subject: Re: [lmap] Information Model: Connecting Tasks > > > > On Wed, Oct 22, 2014 at 04:22:32PM +0000, Sharam Hakimi wrote: > > > What I think needs to be specified is that an MA must have enough cap= ability(CPU power, memory, etc.) to execute a single defined task( run task= , log, transfer results). Beyond that really should be up to the implementa= tion. If one can design an inexpensive device with multiple core CPUs and G= igs of memory that allows for multiple concurrent tasks then that is up to = the implementer. > > > > > > I do not think we should manage implementations, rather specify the r= esource requirement for every defined task. > > > > > > > Using LMAP, I can configure (a) how frequently a measurement test is=20 > > executed (and hence how much data it produces) and (b) how=20 > > frequently a reporting task is executed. In other words, the amount=20 > > of buffer space I need depends on the schedule(s) and hence it is=20 > > out of the control of the implementation. Even if an implementation=20 > > tries to reject schedules that may potentially overrun resources,=20 > > once you loose connectivity it surely can run out of resources again. > > > > Assuming an implementation has always sufficient resources is=20 > > unrealistic and definitely not something that can be specified. > > > > Note: We are not talking about the execution of a single task but=20 > > instead about how data is passed between tasks. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=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 Tue Oct 28 06:39: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 1DB131A88B5 for ; Tue, 28 Oct 2014 06:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 BMnDYg7Widz7 for ; Tue, 28 Oct 2014 06:39:17 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B841A88A4 for ; Tue, 28 Oct 2014 06:39:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAMANebT1SHCzIm/2dsb2JhbABcgkgjI1RZA7pEAQEBAQEBBpNqh00CgRoWAQFxC4QEAQEDEhteAQwJFVYmAQQbARmIHwEMpQeEcaAfhjSKI4NlgR4FkgeTb44ZgVOCJYI0gQMBAQE X-IronPort-AV: E=Sophos; i="5.04,802,1406606400"; d="scan'208,217"; a="78419317" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Oct 2014 09:39:13 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 28 Oct 2014 09:38:57 -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, 28 Oct 2014 14:38:56 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: updated agenda for IETF-91 Thread-Index: Ac/ytIScQVHQR/sHS0u7m1sux4Q3hw== Date: Tue, 28 Oct 2014 13:38:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8E0535@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_9904FB1B0159DA42B0B887B7FA8119CA5C8E0535AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/LY4rRiv9iTt2TLN4HKuwGG2mz78 Subject: [lmap] updated agenda for IETF-91 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Oct 2014 13:39:19 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E0535AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have uploaded an updated agenda for the LMAP meeting at IETF-91 at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E0535AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have uploaded an updated agenda for the LMAP meeti= ng at IETF-91 at http:/= /www.ietf.org/proceedings/91/agenda/agenda-91-lmap.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E0535AZFFEXMB04globa_-- From nobody Tue Oct 28 10:05: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 147491A9009; Tue, 28 Oct 2014 10:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=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 Km8sVolHiM5d; Tue, 28 Oct 2014 10:05:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F152A1A901E; Tue, 28 Oct 2014 10:05:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141028170528.26988.56575.idtracker@ietfa.amsl.com> Date: Tue, 28 Oct 2014 10:05:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/JrzI55MQyGd_AWDGabdmpEX6a98 Cc: lmap@ietf.org Subject: [lmap] I-D ACTION:draft-ietf-lmap-router-buffer-sizes-ksubram-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 17:05:33 -0000 --NextPart 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 : Router Buffer Sizes In The WAN Author(s) : K. Subramaniam, et al Filename : draft-ietf-lmap-router-buffer-sizes-ksubram Pages : 9 Date : 2014-10-28 This draft identifies the set of data that needs to be collected, and analyzed to quantify router buffer sizes used in routers in the Wide Area Network (WAN). The scope of this draft is limited to WAN links that have link latencies of 40 to 150 milliseconds. Reducing router buffer sizes has many advantages, the most important being cost. However, there is not much data available today to effectively calculate this. This draft details use cases for the study, and lists data that needs to be taken into consideration to be able to quantify the size of router buffers. The details of the individual measurement metrics are beyond the scope of this document. Neither does the draft identify methods to gather the data. What it identifies is a need to be able to collect, and report this empirical data in a readable fashion thus providing the ability to study and compare data in a more standardized method. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-lmap-router-buffer-sizes-ksubram-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lmap-router-buffer-sizes-ksubram"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-10-28100528.I-D@ietf.org> --NextPart-- From nobody Wed Oct 29 11:01: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 5BF801A8745 for ; Wed, 29 Oct 2014 11:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 3nvmJTnblXkr for ; Wed, 29 Oct 2014 11:00:55 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4566D1A874D for ; Wed, 29 Oct 2014 11:00:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkLAHMqUVTGmAcV/2dsb2JhbABcgkgjI1RZA7oTDAEBAQEBAQaTdodNAoEdFgEBAQEBAXyEBAEBAxIbXgEMCRVWJgEEGwEZiB8BDKNYhHGff4Y2iimDZYEeBY9ugh+TdY4ogVOCJYI0gQMBAQE X-IronPort-AV: E=Sophos; i="5.07,278,1413259200"; d="scan'208,217"; a="92319002" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Oct 2014 14:00:53 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 29 Oct 2014 14:00:32 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 19:00:32 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: another updated agenda ... Thread-Index: Ac/zojn6HIJSSnM3QQOtaMEaiGS5zA== Date: Wed, 29 Oct 2014 18:00:31 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8E486E@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_9904FB1B0159DA42B0B887B7FA8119CA5C8E486EAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9UMwKSpREnZ_PXJhEGYcFmqxx1o Subject: [lmap] another updated agenda ... X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Oct 2014 18:00:59 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E486EAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ... for the LMAP meeting at IETF-91 was uploaded at http://www.ietf.org/pro= ceedings/91/agenda/agenda-91-lmap. We are still in bashing mode. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E486EAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

… for the LMAP meeting at IETF-91 was uploaded= at http://www.ietf.org/proceedings/91/agenda/agenda-91-lmap.

 

We are still in bashing mode.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E486EAZFFEXMB04globa_-- From nobody Fri Oct 31 14:31: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 033131A1BFF for ; Fri, 31 Oct 2014 14:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 vGZs_U6-8BMO for ; Fri, 31 Oct 2014 14:31:36 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1132F1A1C02 for ; Fri, 31 Oct 2014 14:31:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMLALf+U1TGmAcV/2dsb2JhbABcgkgjI1RcuWcGk0GHTQKBGRYBAQEBAQFxC4QEAQEDEhteAQwJFVYmAQQbGogfAQymboRxn0UBCgEBARoEhjeKKINlgR4FkhWETYhHg0qDHo4vg3iCNIEDAQEB X-IronPort-AV: E=Sophos; i="5.07,295,1413259200"; d="scan'208,217"; a="92695078" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 31 Oct 2014 17:31:34 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 31 Oct 2014 17:31:34 -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; Fri, 31 Oct 2014 22:31:33 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: final IETF-91 agenda due Monday 11/3! Thread-Index: Ac/1UgnOn1jyZe5hS5+LcChJWm6kKg== Date: Fri, 31 Oct 2014 21:31:32 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8E6D8F@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_9904FB1B0159DA42B0B887B7FA8119CA5C8E6D8FAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/aHKHodNB-PjPI9Ydf5CToeEhpPc Subject: [lmap] final IETF-91 agenda due Monday 11/3! X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Oct 2014 21:31:38 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E6D8FAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The preliminary agenda of the meeting at IETF-91 is available at https://da= tatracker.ietf.org/meeting/91/agenda/lmap/. The final agenda is due Monday = 11/3. Please let us know if there are any missing items or changes you want= to bring to the agenda. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E6D8FAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The preliminary agenda of the meeting at IETF-91 is = available at https://datatracker.ietf.org/meeting/91/agenda/lmap/. The fina= l agenda is due Monday 11/3. Please let us know if there are any missing it= ems or changes you want to bring to the agenda.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8E6D8FAZFFEXMB04globa_--