From acmorton@att.com Tue Oct 1 07:08:31 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466C411E82DE for ; Tue, 1 Oct 2013 07:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.677 X-Spam-Level: X-Spam-Status: No, score=-106.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5pPnDd8B3iv for ; Tue, 1 Oct 2013 07:08:26 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id A4E8611E8259 for ; Tue, 1 Oct 2013 07:05:57 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id E7D71120606 for ; Tue, 1 Oct 2013 10:05:53 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id 1ABD4E018A for ; Tue, 1 Oct 2013 10:05:54 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Tue, 1 Oct 2013 10:05:57 -0400 From: "MORTON, ALFRED C (AL)" To: "lmap@ietf.org" Date: Tue, 1 Oct 2013 10:05:56 -0400 Thread-Topic: [ippm] Fwd: draft-mornulo-ippm-registry-columns-00.txt Thread-Index: Ac6+rmFqRLaon/ebRxqBdvecoVgxTA== Message-ID: <2845723087023D4CB5114223779FA9C8AB040F16@njfpsrvexg8.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 Subject: [lmap] FW: [ippm] Fwd: draft-mornulo-ippm-registry-columns-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 14:08:31 -0000 Hi all, Folks who are interested in LMAP know how important it will be to=20 establish a registry for the metrics we intend to control and report about. Please take a look at the various registry drafts, especially the latest proposals below, and send your comments to the IPPM wg (where this work will be undertaken eventually, according to their charter).=20 It is fairly easy to imagine using a registry and evaluate its construction= =20 when you have application already in mind, and LMAP fills that bill. regards, Al > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > marcelo bagnulo braun > Sent: Monday, September 30, 2013 12:48 PM > To: ippm@ietf.org > Subject: [ippm] Fwd: New Version Notification for draft-mornulo-ippm- > registry-columns-00.txt >=20 > Hi, >=20 > After further discussion with several folks, we have produced yet two > other drafts, namely draft-mornulo-ippm-registry-columns and > draft-mornulo-ippm-registry. >=20 > - one draft (draft-mornulo-ippm-registry-00) uses the RFC6390 template > in a strict manner. >=20 > - the other draft (draft-mornulo-ippm-registry-columns-00) adapts the > RFC6390 into something that may be more appropriate for a registry > template (as opposed to a metric template) >=20 > In particular some concerns that were raised during the discussions were: >=20 > - Measurement Description is really the Measurement Definition > - Measurement Points are really Run-time parameters (column not needed) > - it's fine to have guidance on measurement timing and clock sync in > an RFC > (but not needed in the registry), so Measurement Timing column not > needed. >=20 >=20 > I personally fine with either of them and it think it is much more > important to agree and move forward than the differences between the two > drafts. >=20 > Comments? >=20 > Regards, marcelo >=20 >=20 > -------- Mensaje original -------- > Asunto: New Version Notification for > draft-mornulo-ippm-registry-columns-00.txt > Fecha: Mon, 30 Sep 2013 09:45:38 -0700 > De: internet-drafts@ietf.org > Para: Al Morton , Philip Eardley > , Marcelo Bagnulo , Al C. > Morton >=20 >=20 >=20 > A new version of I-D, draft-mornulo-ippm-registry-columns-00.txt > has been successfully submitted by Marcelo Bagnulo and posted to the > IETF repository. >=20 > Filename: draft-mornulo-ippm-registry-columns > Revision: 00 > Title: A(nother) Registry for Performance Metrics > Creation date: 2013-09-30 > Group: Individual Submission > Number of pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-mornulo-ippm- > registry-columns-00.txt > Status: http://datatracker.ietf.org/doc/draft-mornulo-ippm- > registry-columns > Htmlized: http://tools.ietf.org/html/draft-mornulo-ippm-registry- > columns-00 >=20 >=20 > Abstract: > This memo investigates a scheme to organize registry entries, > especially those defined in RFCs prepared in the IP Performance > Metrics (IPPM) Working Group of the IETF, and applicable to all IETF > metrics. Three aspects make IPPM metric registration difficult: (1) > Use of the Type-P notion to allow users to specify their own packet > types. (2) Use of flexible input variables, called Parameters in IPPM > definitions, some which determine the quantity measured and others > which should not be specified until execution of the measurement. (3) > Allowing flexibility in choice of statistics to summarize the results > on a stream of measurement packets. Specifically, this memo proposes > a way to organize registry entries into columns that are well- > defined, permiting consistent development of entries over time. > Also, this fosters development of registry entries based on existing > reference RFCs for performance metrics, and requires expert review > for every entry before IANA action. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From mlinsner@cisco.com Wed Oct 2 09:48:44 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E90021F93FB for ; Wed, 2 Oct 2013 09:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCKCg21Ob9Nj for ; Wed, 2 Oct 2013 09:48:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A515121F995B for ; Wed, 2 Oct 2013 09:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2186; q=dns/txt; s=iport; t=1380732494; x=1381942094; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=9Li5lK5enDWid0C3xV/0Z1A9r1WAtkpUmS2u2Z/rF0Q=; b=RALBmAmEyTXp2FSZujU3ZiwrUgw/gnkTnOQDpyWayq6ThJ0pPBJ8sUtB suYiOlfQ69J936nffSLvjr2ktS26tWI4NYD7ViKktN6A6FGkJuVVA4wEm rpxRQGTMv56rREOCc05ES4YyPfYCu/EYZ7gbIl4hH+yZ9IwlGA9KBQrZD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0FAAxOTFKtJXG+/2dsb2JhbABZgwc4TAbBFoEYFm0HgiUBAQEEOj0UAQgiFEIbAQYDAgQbAYd9BwWbTKE9jyA4gx+BBAOZMJBQgySCKg X-IronPort-AV: E=Sophos;i="4.90,1019,1371081600"; d="scan'208";a="267289299" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 02 Oct 2013 16:48:04 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r92Gm4Fo024543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Oct 2013 16:48:04 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.232]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 2 Oct 2013 11:48:04 -0500 From: "Marc Linsner (mlinsner)" To: "lmap@ietf.org" Thread-Topic: New Version Notification for draft-linsner-lmap-use-cases-04.txt Thread-Index: AQHOv4xHIZ2D7AIAG0CZrOmJYU9dKJnhr/sA Date: Wed, 2 Oct 2013 16:48:03 +0000 Message-ID: <581E085DEB6A444093CDAEA4C4EE481815AD92BC@xmb-rcd-x08.cisco.com> In-Reply-To: <20131002162652.20697.1975.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.195.119] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] FW: New Version Notification for draft-linsner-lmap-use-cases-04.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:48:44 -0000 All, An updated version of our Use Case draft. This includes the compilation of the (3) use cases drafts presented at the Berlin meeting, as agreed by the various authors. Still to be done is further input from regulators as that use case needs more work. Unfortunately, the timing of the US Gov't shutdown doesn't bode well for hearing from our friends at the FCC. I'll reach out to other regulators that showed interest at the Berlin meeting. Please provide comments to the list so we can determine needed changes and turn this around prior to Vancouver. Thanks, Marc, Phil, Trevor > >A new version of I-D, draft-linsner-lmap-use-cases-04.txt >has been successfully submitted by Marc Linsner and posted to the >IETF repository. > >Filename: draft-linsner-lmap-use-cases >Revision: 04 >Title: Large-Scale Broadband Measurement Use Cases >Creation date: 2013-10-02 >Group: Individual Submission >Number of pages: 16 >URL: =20 >http://www.ietf.org/internet-drafts/draft-linsner-lmap-use-cases-04.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-linsner-lmap-use-cases >Htmlized: =20 >http://tools.ietf.org/html/draft-linsner-lmap-use-cases-04 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-linsner-lmap-use-cases-04 > >Abstract: > Measuring broadband performance on a large scale is important for > network diagnostics by providers and users, as well for as public > policy. To conduct such measurements, user networks gather data, > either on their own initiative or instructed by a measurement > controller, and then upload the measurement results to a designated > measurement server. Understanding the various scenarios and users of > measuring broadband performance is essential to development of the > system requirements. The details of the measurement metrics > themselves are beyond the scope of this document. > > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From dromasca@avaya.com Wed Oct 2 10:06:37 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A1B21F9D1B for ; Wed, 2 Oct 2013 10:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ctfdnD7NJMf for ; Wed, 2 Oct 2013 10:06:24 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE3521F9950 for ; Wed, 2 Oct 2013 10:01:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFACBRTFLGmAcV/2dsb2JhbABZgmYhOFLBFoEYFm0HgiUBAQEBAwEBAQ8oNBcEAgEIDQQEAQELFAkHJwsUCQgBAQQTCBqHZAELoCGcXhMEjyA4BoMZgQQDnl2LI4FmgT6CKg X-IronPort-AV: E=Sophos;i="4.90,1019,1371096000"; d="scan'208";a="30867804" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 02 Oct 2013 13:01:17 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Oct 2013 12:57:45 -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.0146.000; Wed, 2 Oct 2013 19:01:13 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] adopt draft-linsner-lmap-use-cases-03 as initial WG I-D for the LMAP Use Cases Thread-Index: Ac65IXbW3VC3lH2rT9STOkhiBxylfQGbqh0g Date: Wed, 2 Oct 2013 17:01:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128EF8F9@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128E759F@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128E759F@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] adopt draft-linsner-lmap-use-cases-03 as initial WG I-D for the LMAP Use Cases X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:06:37 -0000 No concerns were expressed so we seem to have consensus on this issue.=20 Authors, please submit the next version as draft-ietf-lmap-use-cases-00.=20 Thanks and Regards, Dan > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Tuesday, September 24, 2013 3:31 PM > To: lmap@ietf.org > Subject: [lmap] adopt draft-linsner-lmap-use-cases-03 as initial WG I-D > for the LMAP Use Cases >=20 > Hi, >=20 > I propose to adopt draft-linsner-lmap-use-cases-03 as initial WG I-D for > the LMAP Use Cases. >=20 > If you have any questions or concerns please send them to the WG list > before Tuesday 10/1 COB. >=20 > Thanks and Regards, >=20 > Dan > (as chair) >=20 >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From dromasca@avaya.com Wed Oct 2 10:07:43 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C707C21F9E1A for ; Wed, 2 Oct 2013 10:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY0NgtNKtDr0 for ; Wed, 2 Oct 2013 10:07:29 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id DC44021F9E91 for ; Wed, 2 Oct 2013 10:02:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAG5QTFKHCzI1/2dsb2JhbABZgmYhOFLBFoEYFm0HgiUBAQEBAwEBAQ8oNBcEAgEIDQQEAQELFAkHJwsUCQgBAQQTCBqHZAELoB+cXhMEjyA4BoMZgQQDnl2LI4FmgT6CKg X-IronPort-AV: E=Sophos;i="4.90,1019,1371096000"; d="scan'208";a="26278314" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Oct 2013 13:02:02 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Oct 2013 12:53:13 -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.0146.000; Wed, 2 Oct 2013 13:01:56 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [lmap] adopt draft-folks-lmap-framework-00 as initial WG I-D for the LMAP Framework Thread-Index: Ac65IXbW3VC3lH2rT9STOkhiBxylfQGb48Hg Date: Wed, 2 Oct 2013 17:01:55 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128EF906@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128E763B@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128E763B@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] adopt draft-folks-lmap-framework-00 as initial WG I-D for the LMAP Framework X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:07:43 -0000 No concerns were expressed so we seem to have consensus on this issue.=20 Authors, please submit the next version as draft-ietf-lmap-framework-00.=20 Thanks and Regards, Dan > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Tuesday, September 24, 2013 3:53 PM > To: lmap@ietf.org > Subject: [lmap] adopt draft-folks-lmap-framework-00 as initial WG I-D > for the LMAP Framework >=20 > Hi, >=20 > (please disregard the previous message about the LMAP Framework > document) >=20 > I propose to adopt draft-folks-lmap-framework-00 as initial WG I-D for > the LMAP Framework. >=20 > If you have any questions or concerns please send them to the WG list > before Tuesday 10/1 COB. >=20 > Thanks and Regards, >=20 > Dan > (as chair) >=20 >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From internet-drafts@ietf.org Thu Oct 3 04:39:27 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532C921E808D; Thu, 3 Oct 2013 04:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBnJ9VNV78tU; Thu, 3 Oct 2013 04:39:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 583A721E808C; Thu, 3 Oct 2013 04:35:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131003113511.13078.63939.idtracker@ietfa.amsl.com> Date: Thu, 03 Oct 2013 04:35:11 -0700 Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 11:39:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Large-Scale Measurement of Broadband Perf= ormance Working Group of the IETF. Title : A framework for large-scale measurement platforms (LMAP) Author(s) : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-00.txt Pages : 37 Date : 2013-10-03 Abstract: Measuring broadband service on a large scale requires standardisation of the logical architecture and a description of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (large-scale measurement platforms). The document is a contribution towards the LMAP working group's milestone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-framework-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dromasca@avaya.com Thu Oct 3 06:00:04 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C507021E8082 for ; Thu, 3 Oct 2013 06:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.368 X-Spam-Level: X-Spam-Status: No, score=-103.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZtYlmO4WxfK for ; Thu, 3 Oct 2013 05:59:51 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1782A21F9C6C for ; Thu, 3 Oct 2013 05:57:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAHdoTVLGmAcV/2dsb2JhbABZgmYhgQrBPYEgFm0HgicBAQMSKFEBFRUUQiYBBBsah2QBmyyER5xzjyCDV4EEA55diyODJIIq X-IronPort-AV: E=Sophos;i="4.90,1026,1371096000"; d="scan'208";a="30471088" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Oct 2013 08:57:41 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Oct 2013 08:54:02 -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.0146.000; Thu, 3 Oct 2013 14:57:33 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: IETF 88 - agenda and schedules Thread-Index: Ac7AOB/qnUV9+A0sQLiGwWPW8hzmiA== Date: Thu, 3 Oct 2013 12:57:32 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128F169A@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] IETF 88 - agenda and schedules X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 13:00:05 -0000 Hi, IETF 88 is just one month away.=20 Please send your requests and proposals for agenda items.=20 Also please note that the 'Important Dates' file includes the following:=20 *2013-10-07 (Monday): Working Group Chair approval for initial document (Ve= rsion -00) submissions appreciated by UTC 24:00. ... *2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, in= cluding -00) by UTC 24:00, upload using IETF ID Submission Tool.=20 There is only one submission cu-off date for all I-Ds, but in case you plan= to submit a -00 draft (initial document) you need to let Jason and/or me b= efore Monday 10/7, so that we can pre-approve it.=20 Thanks and Regards, Dan From bclaise@cisco.com Fri Oct 4 07:52:13 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4688C21F9C89 for ; Fri, 4 Oct 2013 07:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HCGh8G2LwS4 for ; Fri, 4 Oct 2013 07:52:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9198621F9B21 for ; Fri, 4 Oct 2013 07:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4362; q=dns/txt; s=iport; t=1380898146; x=1382107746; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=PhwOaM9G7jiHYqw00MyofQgrfJacJFL7YI9bmdjnk4o=; b=PC3yeiG210JVOzmc30r+lQ+id0SP8S2GzfjBAJksQyYZLjjwp5acILAb Ie1UZgqkXl+0Vi+/QsTk7gzevy68FVWVxvxv4qp8Sw38RqTuQ3FKSkSWa 2SRsa0LneNugPYycwy8msygiMOxZaoFILY1n9ji3DFfVFy+nIPB0RnB88 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAHfUTlKQ/khR/2dsb2JhbABZgweKD7hDgRoWbQeCJQEBAQRuCg0EDw0DAQIKFg8JAwIBAgE7AggGDQYCAQGIArt+j0AYBoQdA5gBhjWLSoMmOg X-IronPort-AV: E=Sophos;i="4.90,1033,1371081600"; d="scan'208,217";a="160345181" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 04 Oct 2013 14:49:05 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r94En2AI011427 for ; Fri, 4 Oct 2013 14:49:03 GMT Message-ID: <524ED55D.1000400@cisco.com> Date: Fri, 04 Oct 2013 16:49:01 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "lmap@ietf.org" References: <524ED467.4090704@cisco.com> In-Reply-To: <524ED467.4090704@cisco.com> X-Forwarded-Message-Id: <524ED467.4090704@cisco.com> Content-Type: multipart/alternative; boundary="------------020209040807050602050702" Subject: [lmap] Fwd: New version of the Performance Metrics Registry draft X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Oct 2013 14:52:13 -0000 This is a multi-part message in MIME format. --------------020209040807050602050702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Forwarded here: FYI. Please comment in the IPPM mailing list. Regards, Benoit -------- Original Message -------- Subject: New version of the Performance Metrics Registry draft Date: Fri, 04 Oct 2013 16:44:55 +0200 From: Benoit Claise To: IETF IPPM WG Dear all, I posted a new version of the Performance Metrics Registry draft. Performance Metrics Registry draft-claise-ippm-perf-metric-registry-01.txt Abstract This document specifies an IANA registry for Performance Metrics, for both active monitoring and passive monitoring, along with the initial content. This document also gives a set of guidelines for Performance Metrics requesters and reviewers. What we need is a new performance metrics registry. There are actually 3 different tasks: Task 1: IANA registry setup Task 2: Performance metric guidelines for requester and reviewers Task 3: Initial content for the registry Task 3.1 perf metrics that are already compliant with the RFC 6390 template Task 3.2 selection of operationally relevant IPPM performance metrics 3.2 is out of scope of this document, for now. This draft provides an experiment on how to map IPDV into the RFC 6390 template (this is a first attempt). Please provide your feedback. Regards, Benoit --------------020209040807050602050702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Forwarded here: FYI.
Please comment in the IPPM mailing list.

Regards, Benoit


-------- Original Message --------
Subject: New version of the Performance Metrics Registry draft
Date: Fri, 04 Oct 2013 16:44:55 +0200
From: Benoit Claise <bclaise@cisco.com>
To: IETF IPPM WG <ippm@ietf.org> 


Dear all,

I posted a new version of the Performance Metrics Registry draft.

                      Performance Metrics Registry
             draft-claise-ippm-perf-metric-registry-01.txt

Abstract

   This document specifies an IANA registry for Performance Metrics, for
   both active monitoring and passive monitoring, along with the initial
   content.  This document also gives a set of guidelines for
   Performance Metrics requesters and reviewers.


What we need is a new performance metrics registry. There are actually 3 
different tasks:
    Task 1:  IANA registry setup
    Task 2: Performance metric guidelines for requester and reviewers
    Task 3: Initial content for the registry
        Task 3.1 perf metrics that are already compliant with the RFC 
6390 template
        Task 3.2 selection of operationally relevant IPPM performance 
metrics

3.2 is out of scope of this document, for now.

This draft provides an experiment on how to map IPDV into the RFC 6390 
template (this is a first attempt).

Please provide your feedback.

Regards, Benoit


--------------020209040807050602050702-- From internet-drafts@ietf.org Sun Oct 6 01:32:46 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E1121F9901; Sun, 6 Oct 2013 01:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASJSELQO4BuN; Sun, 6 Oct 2013 01:32:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BF021F9E95; Sun, 6 Oct 2013 01:32:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131006083245.2583.38185.idtracker@ietfa.amsl.com> Date: Sun, 06 Oct 2013 01:32:45 -0700 Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-use-cases-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 08:32:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Large-Scale Measurement of Broadband Perf= ormance Working Group of the IETF. Title : Large-Scale Broadband Measurement Use Cases Author(s) : Marc Linsner Philip Eardley Trevor Burbridge Filename : draft-ietf-lmap-use-cases-00.txt Pages : 16 Date : 2013-10-03 Abstract: Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well for as public policy. To conduct such measurements, user networks gather data, either on their own initiative or instructed by a measurement controller, and then upload the measurement results to a designated measurement server. Understanding the various scenarios and users of measuring broadband performance is essential to development of the system requirements. The details of the measurement metrics themselves are beyond the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-use-cases-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dromasca@avaya.com Sun Oct 6 01:35:05 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BCB21F9E9C for ; Sun, 6 Oct 2013 01:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.411 X-Spam-Level: X-Spam-Status: No, score=-103.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lpWdiiXhslN for ; Sun, 6 Oct 2013 01:34:59 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4680421F9DE1 for ; Sun, 6 Oct 2013 01:34:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMNAEcgUVLGmAcV/2dsb2JhbABZgmYhOFKDKKkjlE0XfhZtB4IlAQEBAQMSCwYRNxoGAQgNBAQBAQMCBgsSAwIEMBQBBgEBBQUEEwgMDodkAQuaJYRIij6RYReBKYxfgRg+BIJgNYEEA5QkhQyFLosjgySBcTk X-IronPort-AV: E=Sophos;i="4.90,1043,1371096000"; d="scan'208";a="30807996" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Oct 2013 04:34:55 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Oct 2013 04:31:04 -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.0146.000; Sun, 6 Oct 2013 10:34:45 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: NOMCOM 2013 - Second Call for Nominations - two weeks left Thread-Index: AQHOwSewhpu8VeF/l0OSNTEvDOPwD5nnWxUQ Date: Sun, 6 Oct 2013 08:34:45 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128FE3BB@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [lmap] FW: NOMCOM 2013 - Second Call for Nominations - two weeks left X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 08:35:05 -0000 UGxlYXNlIHN1Ym1pdCB0byBOT01DT00gMjAxMyB5b3VyIHByb3Bvc2FscyBmb3Igbm9taW5hdGlv bnMgZm9yIHRoZSBiZXN0IHBlb3BsZSB3aG8gY2FuIGZpbGwgaW4gdGhlIG9wZW4gcG9zaXRpb25z LiBUaGlzIGlzIGFuIGltcG9ydGFudCBjb250cmlidXRpb24gdG8gdGhlIElFVEYuIA0KDQpUaGFu a3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogaWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aWV0Zi1hbm5v dW5jZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTm9tQ29tIENoYWlyIDIwMTMNClNl bnQ6IEZyaWRheSwgT2N0b2JlciAwNCwgMjAxMyA4OjMyIFBNDQpUbzogSUVURiBBbm5vdW5jZW1l bnQgTGlzdA0KQ2M6IElFVEYgRGlzY3VzcyBMaXN0DQpTdWJqZWN0OiBOT01DT00gMjAxMyAtIFNl Y29uZCBDYWxsIGZvciBOb21pbmF0aW9ucyAtIHR3byB3ZWVrcyBsZWZ0DQoNCk5vbWluYXRpb25z IGZvciB0aGUgSUVTRywgSUFCLCBhbmQgSUFPQyBhcmUgZHVlIHRvIHRoZSBOb21jb20gYnkgRnJp ZGF5LCAxOCBPY3RvYmVyLCAyMDEzLg0KDQpJcyB0aGVyZSBzb21lb25lIHlvdSB3b3JrIHdpdGgg YXQgSUVURiB3aG8gaGFzIGxlYWRlcnNoaXAgcG90ZW50aWFsIGFuZCBhIGdyb3dpbmcgdHJhY2sg cmVjb3JkPyBQbGVhc2UgcmVhZCB0aGUgTm9tY29tIGNhbGwgZm9yIG5vbWluYXRpb25zIGFuZCBj b25zaWRlciBub21pbmF0aW5nIGhlciBvciBoaW0uIE9yIHNldmVyYWwgZm9sa3MhIERlYWRsaW5l IGZvciBub21pbmF0aW9ucyBpcyBPY3RvYmVyIDE4LiAgTm9taW5hdGUgc29vbiB0byBnaXZlIHlv dXIgbm9taW5lZShzKSBwbGVudHkgdGltZSB0byBmaWxsIGluIHRoZSBxdWVzdGlvbm5haXJlLiBJ bmZvcm1hdGlvbiBhYm91dCB0aGUgZGVzaXJlZCBleHBlcnRpc2UgZm9yIHBvc2l0aW9ucyBpcyBo ZXJlOiANCiAgICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAx My9leHBlcnRpc2UNCg0KTG90cyBtb3JlLCBpbmNsdWRpbmcgd2hpY2ggcG9zaXRpb25zIGFyZSBv cGVuLCBob3cgdG8gbWFrZSBhIG5vbWluYXRpb24sIGFuZCBob3cgdG8gc2VuZCB1cyB5b3VyIGZl ZWRiYWNrIG9uIHRoZSBkZXNpcmVkIGV4cGVydGlzZSwgZm9sbG93cy4NCg0KSUVURmVycywgbGV0 J3MgaGVhciBmcm9tIHlvdSEgIE1ha2Ugbm9taW5hdGlvbnMsIGFjY2VwdCBub21pbmF0aW9ucyEN Cg0KSWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucyBhYm91dCB0aGUgcHJvY2VzcywgZmVlbCBmcmVl IHRvIGdldCBpbiB0b3VjaCB3aXRoIG1lLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkFsbGlzb24gZm9y IHRoZSBOb21jb20NCg0KQWxsaXNvbiBNYW5raW4NCk5vbWNvbSBDaGFpciAyMDEzLTE0DQoNCi0t LS0tIFRoZSBJbmZvIFlvdSBOZWVkIGZvciBOb21pbmF0aW5nIC0tLS0tDQoNClRoZSAyMDEzLTE0 IE5vbWluYXRpbmcgQ29tbWl0dGVlIChOb21jb20pIGlzIHNlZWtpbmcgbm9taW5hdGlvbnMgZnJv bSBub3cgdW50aWwgT2N0b2JlciAxOCwgMjAxMy4gVGhlIG9wZW4gcG9zaXRpb25zIGJlaW5nIGNv bnNpZGVyZWQgYnkgdGhpcyB5ZWFyJ3MgTm9tY29tIGNhbiBiZSBmb3VuZCBsYXRlciBpbiB0aGlz IHNlY3Rpb24sIGFuZCBhbHNvIG9uIHRoaXMgeWVhcidzIE5vbWNvbSB3ZWJzaXRlOiANCg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAxMy8NCg0KTm9taW5hdGlvbnMgbWF5 IGJlIG1hZGUgYnkgc2VsZWN0aW5nIHRoZSBOb21pbmF0ZSBsaW5rIGF0IHRoZSB0b3Agb2YgdGhl IE5vbWNvbSAyMDEzIGhvbWUgcGFnZSwgb3IgYnkgdmlzaXRpbmcgdGhlIGZvbGxvd2luZyBVUkw6 IA0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDEzL25vbWluYXRlLw0K DQpOb3RlIHRoYXQgbm9taW5hdGlvbnMgbWFkZSB1c2luZyB0aGUgd2ViIHRvb2wgcmVxdWlyZSBh biBpZXRmLm9yZyBkYXRhdHJhY2tlciBhY2NvdW50LiBZb3UgY2FuIGNyZWF0ZSBhIGRhdGF0cmFj a2VyIGlldGYub3JnIGFjY291bnQgaWYgeW91IGRvbid0IGhhdmUgb25lIGFscmVhZHkgYnkgdmlz aXRpbmcgdGhlIGZvbGxvd2luZyBVUkw6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv YWNjb3VudHMvY3JlYXRlLw0KDQpOb21pbmF0aW9ucyBtYXkgYWxzbyBiZSBtYWRlIGJ5IGVtYWls IHRvIG5vbWNvbTEzIGF0IGlldGYub3JnLg0KSWYgeW91IG5vbWluYXRlIGJ5IGVtYWlsLCBwbGVh c2UgaW5jbHVkZSB0aGUgd29yZCAiTm9taW5hdGUiIGluIHRoZSBTdWJqZWN0IGFuZCBpbmRpY2F0 ZSBpbiB0aGUgZW1haWwgd2hvIGlzIGJlaW5nIG5vbWluYXRlZCwgdGhlaXIgZW1haWwgYWRkcmVz cyAodG8gY29uZmlybSBhY2NlcHRhbmNlIG9mIHRoZSBub21pbmF0aW9uKSwgYW5kIHRoZSBwb3Np dGlvbiBmb3Igd2hpY2ggeW91IGFyZSBtYWtpbmcgdGhlIG5vbWluYXRpb24uIElmIHlvdSB1c2Ug ZW1haWwsIHBsZWFzZSB1c2UgYSBzZXBhcmF0ZSBlbWFpbCBmb3IgZWFjaCBwZXJzb24geW91IG5v bWluYXRlLCBhbmQgZm9yIGVhY2ggcG9zaXRpb24gKGlmIHlvdSBhcmUgbm9taW5hdGluZyBvbmUg cGVyc29uIGZvciBtdWx0aXBsZSBwb3NpdGlvbnMpLg0KDQpTZWxmLW5vbWluYXRpb24gaXMgd2Vs Y29tZSEgIE5vIG5lZWQgdG8gYmUgc2h5Lg0KDQpOb21jb20gMjAxMy0xNCB3aWxsIGZvbGxvdyB0 aGUgcG9saWN5IGZvciAiT3BlbiBEaXNjbG9zdXJlIG9mIFdpbGxpbmcgTm9taW5lZXMiIGRlc2Ny aWJlZCBpbiBSRkMgNTY4MC4gIEFzIHN0YXRlZCBpbiBSRkMgNTY4MDogIlRoZSBsaXN0IG9mIG5v bWluZWVzIHdpbGxpbmcgdG8gYmUgY29uc2lkZXJlZCBmb3IgcG9zaXRpb25zIHVuZGVyIHJldmll dyBpbiB0aGUgY3VycmVudCBOb21jb20gY3ljbGUgaXMgbm90IGNvbmZpZGVudGlhbCIuIFdpbGxp bmcgbm9taW5lZXMgZm9yIGVhY2ggcG9zaXRpb24gd2lsbCBiZSBsaXN0ZWQgaW4gYSBwdWJsaWNs eSBhY2Nlc3NpYmxlIHdheSAtIGFueW9uZSB3aXRoIGEgZGF0YXRyYWNrZXIgYWNjb3VudCBtYXkg YWNjZXNzIHRoZSBsaXN0cy4gIEluIGFsbCBvdGhlciB3YXlzLCB0aGUgY29uZmlkZW50aWFsaXR5 IHJlcXVpcmVtZW50cyBvZiBSRkMgMzc3Ny9CQ1AxMCByZW1haW4gaW4gZWZmZWN0LiAgQWxsIGZl ZWRiYWNrIGFuZCBhbGwgTm9tY29tIGRlbGliZXJhdGlvbnMgd2lsbCByZW1haW4gY29uZmlkZW50 aWFsIGFuZCB3aWxsIG5vdCBiZSBkaXNjbG9zZWQuICANCg0KSW4gb3JkZXIgdG8gZW5zdXJlIHRp bWUgdG8gY29sbGVjdCBzdWZmaWNpZW50IGNvbW11bml0eSBmZWVkYmFjayBhYm91dCBlYWNoIG9m IHRoZSB3aWxsaW5nIG5vbWluZWVzLCBub21pbmF0aW9ucyBtdXN0IGJlIHJlY2VpdmVkIGJ5IHRo ZSBOb21jb20gb24gb3IgYmVmb3JlIE9jdG9iZXIgMTgsIDIwMTMuICBQbGVhc2Ugc3VibWl0IHlv dXIgbm9taW5hdGlvbnMgYXMgZWFybHkgYXMgcG9zc2libGUgZm9yIHRoZSBzYWtlIG9mIHlvdXIg bm9taW5lZXMsIGFzIHdlJ3ZlIHNldCB0aGUgcXVlc3Rpb25uYWlyZSBzdWJtaXNzaW9uIGRlYWRs aW5lIGZvciBPY3RvYmVyIDI1LCAyMDEzLg0KDQpUaGUgbGlzdCBvZiBwZW9wbGUgYW5kIHBvc3Rz IHdob3NlIHRlcm1zIGVuZCB3aXRoIHRoZSBNYXJjaCAyMDE0IElFVEYgbWVldGluZywgYW5kIHRo dXMgdGhlIHBvc2l0aW9ucyBmb3Igd2hpY2ggd2UgYXJlIGFjY2VwdGluZyBub21pbmF0aW9uczog IA0KDQpJQU9DDQpDaHJpcyBHcmlmZml0aHMNCg0KSUFCDQpCZXJuYXJkIEFib2JhDQpNYXJjIEJs YW5jaGV0DQpSb3NzIENhbGxvbg0KRWxpb3QgTGVhcg0KSGFubmVzIFRzY2hvZmVuaWcNCg0KSUVT Rw0KQmFycnkgTGVpYmEgKEFwcGxpY2F0aW9ucykNCkJyaWFuIEhhYmVybWFuIChJbnRlcm5ldCkN CkJlbm9pdCBDbGFpc2UgKE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQpIEdvbnphbG8gQ2FtYXJp bGxvIChSQUkpIFN0ZXdhcnQgQnJ5YW50IChSb3V0aW5nKSBTZWFuIFR1cm5lciAoU2VjdXJpdHkp IE1hcnRpbiBTdGllbWVybGluZyAoVHJhbnNwb3J0KQ0KDQpQbGVhc2UgYmUgcmVzb3VyY2VmdWwg aW4gaWRlbnRpZnlpbmcgcG9zc2libGUgY2FuZGlkYXRlcyBmb3IgdGhlc2UgcG9zaXRpb25zLCBh cyBkZXZlbG9waW5nIG91ciB0YWxlbnQgaXMgYSB2ZXJ5IGNydWNpYWwgcmVxdWlyZW1lbnQgZm9y IHRoZSBJRVRGLiAgQWxzbywgcGxlYXNlIGdpdmUgc2VyaW91cyBjb25zaWRlcmF0aW9uIHRvIGFj Y2VwdGluZyBub21pbmF0aW9ucyB5b3UgcmVjZWl2ZS4gIA0KIA0KVGhlIHN1bW1hcmllcyBvZiB0 aGUgZGVzaXJlZCBleHBlcnRpc2UgZm9yIHRoZSBwb3NpdGlvbnMsIGRldmVsb3BlZCBieSB0aGUg cmVzcGVjdGl2ZSBib2RpZXMsIGFyZSBmb3VuZCBhdDoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9ub21jb20vMjAxMy9leHBlcnRpc2UvDQoNCkluIGFkZGl0aW9uIHRvIG5vbWluYXRp b25zLCB0aGUgTm9tY29tIHNlZWtzIGNvbW11bml0eSBpbnB1dCBvbiB0aGUgcG9zaXRpb25zIHRo ZW1zZWx2ZXMuICBXZSBuZWVkIGFuZCB3ZWxjb21lIHRoZSBjb21tdW5pdHkncyB2aWV3cyBhbmQg aW5wdXQgb24gdGhlIGpvYnMgd2l0aGluIGVhY2ggb3JnYW5pemF0aW9uLiBJZiB5b3UgaGF2ZSBp ZGVhcyBvbiB0aGUgcG9zaXRpb25zJyByZXNwb25zaWJpbGl0aWVzIChtb3JlLCBsZXNzLCBkaWZm ZXJlbnQpLCBwbGVhc2UgbGV0IHVzIGtub3cuICBZb3UgY2FuIHNlbmQgdXMgZW1haWwgYWJvdXQg dGhpcyB0bw0Kbm9tY29tMTMgYXQgaWV0Zi5vcmcsIGFuZCB3ZSB3aWxsIHVzZSB0aGlzIGZlZWRi YWNrIGFjdGl2ZWx5Lg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgaGVscCBpbiBub21pbmF0aW5nIGEg Z3JlYXQgcG9vbCBvZiBzdHJvbmcgYW5kIGludGVyZXN0aW5nIG5vbWluZWVzIQ0KDQoNCg0K From Michael.K.Bugenhagen@centurylink.com Mon Oct 7 06:47:03 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A248421E81EC for ; Mon, 7 Oct 2013 06:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsywPfI-JFPt for ; Mon, 7 Oct 2013 06:46:58 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8533E21E81E8 for ; Mon, 7 Oct 2013 06:46:57 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r97DktLn016405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Oct 2013 08:46:55 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id D7C351E0055; Mon, 7 Oct 2013 07:46:49 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id B0C281E0049; Mon, 7 Oct 2013 07:46:49 -0600 (MDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r97Dkn3u006644; Mon, 7 Oct 2013 08:46:49 -0500 (CDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r97Dkmff006641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Oct 2013 08:46:48 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.02.0318.001; Mon, 7 Oct 2013 08:46:48 -0500 From: "Bugenhagen, Michael K" To: "'MORTON, ALFRED C (AL)'" , marcelo bagnulo braun , "lmap@ietf.org" Thread-Topic: thoughts on test Descriptor - RE: [ippm] Fwd: draft-mornulo-ippm-registry-columns-00.txt Thread-Index: Ac6+rmFqRLaon/ebRxqBdvecoVgxTAEstPyQ Date: Mon, 7 Oct 2013 13:46:47 +0000 Message-ID: References: <2845723087023D4CB5114223779FA9C8AB040F16@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8AB040F16@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [lmap] thoughts on test Descriptor - RE: [ippm] Fwd: draft-mornulo-ippm-registry-columns-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Oct 2013 13:47:03 -0000 Marcelo, Al, Knowing the first question out of any Op's guys mouth when you ask him = to do a test ... I came up with this.. I suggest that the "test name" label be expanded so that it may accommoda= te at least 3 levels of hierarchy in describing what type of test it is. I'm meaning a highest order test descriptor that would allow universal unde= rstanding of the type of test, and more importantly its impact. The attributes of the test would be placed behind this field... Example - Test Name composite view of the hierarchy I'm suggesting The Fields should be industry / customer recognizable so they correlate the= ir results=20 1) Test Class (purpose) Capacity Site specific testing (Webpage load) Performance (=20 Monitoring (SLA type / OAM type) Availability =09 2) Assumed service life cycle (turn-up, live, out-of-service) 2) Test type (Protocol) 3) Code origin (test engine source in case of duplicates types that perform= differently) 4) Impact (how much capacity does it eat) - low, med, ..., all 5) Network context (Segmented or end to end)=20 6) One way / Two way=20 =09 Example -=20 -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of MOR= TON, ALFRED C (AL) Sent: Tuesday, October 01, 2013 9:06 AM To: lmap@ietf.org Subject: [lmap] FW: [ippm] Fwd: draft-mornulo-ippm-registry-columns-00.txt Hi all, Folks who are interested in LMAP know how important it will be to establish= a registry for the metrics we intend to control and report about. Please take a look at the various registry drafts, especially the latest pr= oposals below, and send your comments to the IPPM wg (where this work will = be undertaken eventually, according to their charter).=20 It is fairly easy to imagine using a registry and evaluate its construction= when you have application already in mind, and LMAP fills that bill. regards, Al > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf=20 > Of marcelo bagnulo braun > Sent: Monday, September 30, 2013 12:48 PM > To: ippm@ietf.org > Subject: [ippm] Fwd: New Version Notification for draft-mornulo-ippm-=20 > registry-columns-00.txt >=20 > Hi, >=20 > After further discussion with several folks, we have produced yet two=20 > other drafts, namely draft-mornulo-ippm-registry-columns and=20 > draft-mornulo-ippm-registry. >=20 > - one draft (draft-mornulo-ippm-registry-00) uses the RFC6390 template=20 > in a strict manner. >=20 > - the other draft (draft-mornulo-ippm-registry-columns-00) adapts the > RFC6390 into something that may be more appropriate for a registry=20 > template (as opposed to a metric template) >=20 > In particular some concerns that were raised during the discussions were: >=20 > - Measurement Description is really the Measurement Definition > - Measurement Points are really Run-time parameters (column not needed) > - it's fine to have guidance on measurement timing and clock sync in=20 > an RFC > (but not needed in the registry), so Measurement Timing column not=20 > needed. >=20 >=20 > I personally fine with either of them and it think it is much more=20 > important to agree and move forward than the differences between the=20 > two drafts. >=20 > Comments? >=20 > Regards, marcelo >=20 >=20 > -------- Mensaje original -------- > Asunto: New Version Notification for > draft-mornulo-ippm-registry-columns-00.txt > Fecha: Mon, 30 Sep 2013 09:45:38 -0700 > De: internet-drafts@ietf.org > Para: Al Morton , Philip Eardley > , Marcelo Bagnulo , Al C. > Morton >=20 >=20 >=20 > A new version of I-D, draft-mornulo-ippm-registry-columns-00.txt > has been successfully submitted by Marcelo Bagnulo and posted to the=20 > IETF repository. >=20 > Filename: draft-mornulo-ippm-registry-columns > Revision: 00 > Title: A(nother) Registry for Performance Metrics > Creation date: 2013-09-30 > Group: Individual Submission > Number of pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-mornulo-ippm- > registry-columns-00.txt > Status: http://datatracker.ietf.org/doc/draft-mornulo-ippm- > registry-columns > Htmlized: http://tools.ietf.org/html/draft-mornulo-ippm-registry- > columns-00 >=20 >=20 > Abstract: > This memo investigates a scheme to organize registry entries, > especially those defined in RFCs prepared in the IP Performance > Metrics (IPPM) Working Group of the IETF, and applicable to all IETF > metrics. Three aspects make IPPM metric registration difficult: (1) > Use of the Type-P notion to allow users to specify their own packet > types. (2) Use of flexible input variables, called Parameters in IPPM > definitions, some which determine the quantity measured and others > which should not be specified until execution of the measurement. (3) > Allowing flexibility in choice of statistics to summarize the results > on a stream of measurement packets. Specifically, this memo proposes > a way to organize registry entries into columns that are well- > defined, permiting consistent development of entries over time. > Also, this fosters development of registry entries based on existing > reference RFCs for performance metrics, and requires expert review > for every entry before IANA action. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From Michael.K.Bugenhagen@centurylink.com Mon Oct 7 06:54:43 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B0D11E80D9 for ; Mon, 7 Oct 2013 06:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wceqeBu2ac4o for ; Mon, 7 Oct 2013 06:54:38 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id EB0FC21E8099 for ; Mon, 7 Oct 2013 06:54:35 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r97DsWbG004409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Oct 2013 07:54:32 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2FF751E0053; Mon, 7 Oct 2013 08:54:27 -0500 (CDT) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 10F221E004D; Mon, 7 Oct 2013 08:54:27 -0500 (CDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r97DsQWg019505; Mon, 7 Oct 2013 08:54:26 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r97DsQ1F019497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Oct 2013 08:54:26 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.02.0318.001; Mon, 7 Oct 2013 08:54:26 -0500 From: "Bugenhagen, Michael K" To: "Bugenhagen, Michael K" , "'MORTON, ALFRED C (AL)'" , "'marcelo bagnulo braun'" , "'lmap@ietf.org'" Thread-Topic: thoughts on test Descriptor - RE: [ippm] Fwd: draft-mornulo-ippm-registry-columns-00.txt Thread-Index: Ac6+rmFqRLaon/ebRxqBdvecoVgxTAEstPyQAAChgPA= Date: Mon, 7 Oct 2013 13:54:24 +0000 Message-ID: References: <2845723087023D4CB5114223779FA9C8AB040F16@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] thoughts on test Descriptor - RE: [ippm] Fwd: draft-mornulo-ippm-registry-columns-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Oct 2013 13:54:43 -0000 Oops -- pulled the trigger too fast..(clicked send by mistake... ) BTW-- I just don't see this in the current stream of fields, I don't have a= preference where they go but I think they are important. Best regards, Mike=20 Here's a fuller set.=20 1) Test Class (purpose) Capacity (throughput) Site specific testing (Webpage load) Performance (stress testing) Monitoring (SLA type / OAM type) Availability (CC oriented - may include multipath) =09 2) Assumed service life cycle (turn-up, live, out-of-service) Forced OOS (out of service) required - speaks to the urgency of the test Live yet Polite test (may stop if customer traffic impacts results) Live low impact Passive no impact 3) Test type (Protocol) TCP UDP .... 4) Code origin (test engine source in case of duplicates types that perform= differently) Special test engines should be called out so results match if they exist (Vendor ID / Engine Code) type field would work here 5) Impact (how much capacity does it eat) - low, med, ..., all For OAM tests =3D X megs CPU clicks required for code (recommend reserving / helps CAC to be unders= tood) Memory required (same same) 6) Network context (Segmented or end to end)=20 End to end is =3D QoE Segment tests generally mean two tests run at once, one end-to-end, the ot= her from one end to a segment. i.e. - segmented means you need two test results to read the tea leaves. 7) One way / Two way=20 No-symmetrical comes into play here.. =09 Example -=20 -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of MOR= TON, ALFRED C (AL) Sent: Tuesday, October 01, 2013 9:06 AM To: lmap@ietf.org Subject: [lmap] FW: [ippm] Fwd: draft-mornulo-ippm-registry-columns-00.txt Hi all, Folks who are interested in LMAP know how important it will be to establish= a registry for the metrics we intend to control and report about. Please take a look at the various registry drafts, especially the latest pr= oposals below, and send your comments to the IPPM wg (where this work will = be undertaken eventually, according to their charter).=20 It is fairly easy to imagine using a registry and evaluate its construction= when you have application already in mind, and LMAP fills that bill. regards, Al > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf=20 > Of marcelo bagnulo braun > Sent: Monday, September 30, 2013 12:48 PM > To: ippm@ietf.org > Subject: [ippm] Fwd: New Version Notification for draft-mornulo-ippm-=20 > registry-columns-00.txt >=20 > Hi, >=20 > After further discussion with several folks, we have produced yet two=20 > other drafts, namely draft-mornulo-ippm-registry-columns and=20 > draft-mornulo-ippm-registry. >=20 > - one draft (draft-mornulo-ippm-registry-00) uses the RFC6390 template=20 > in a strict manner. >=20 > - the other draft (draft-mornulo-ippm-registry-columns-00) adapts the > RFC6390 into something that may be more appropriate for a registry=20 > template (as opposed to a metric template) >=20 > In particular some concerns that were raised during the discussions were: >=20 > - Measurement Description is really the Measurement Definition > - Measurement Points are really Run-time parameters (column not needed) > - it's fine to have guidance on measurement timing and clock sync in=20 > an RFC > (but not needed in the registry), so Measurement Timing column not=20 > needed. >=20 >=20 > I personally fine with either of them and it think it is much more=20 > important to agree and move forward than the differences between the=20 > two drafts. >=20 > Comments? >=20 > Regards, marcelo >=20 >=20 > -------- Mensaje original -------- > Asunto: New Version Notification for > draft-mornulo-ippm-registry-columns-00.txt > Fecha: Mon, 30 Sep 2013 09:45:38 -0700 > De: internet-drafts@ietf.org > Para: Al Morton , Philip Eardley > , Marcelo Bagnulo , Al C. > Morton >=20 >=20 >=20 > A new version of I-D, draft-mornulo-ippm-registry-columns-00.txt > has been successfully submitted by Marcelo Bagnulo and posted to the=20 > IETF repository. >=20 > Filename: draft-mornulo-ippm-registry-columns > Revision: 00 > Title: A(nother) Registry for Performance Metrics > Creation date: 2013-09-30 > Group: Individual Submission > Number of pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-mornulo-ippm- > registry-columns-00.txt > Status: http://datatracker.ietf.org/doc/draft-mornulo-ippm- > registry-columns > Htmlized: http://tools.ietf.org/html/draft-mornulo-ippm-registry- > columns-00 >=20 >=20 > Abstract: > This memo investigates a scheme to organize registry entries, > especially those defined in RFCs prepared in the IP Performance > Metrics (IPPM) Working Group of the IETF, and applicable to all IETF > metrics. Three aspects make IPPM metric registration difficult: (1) > Use of the Type-P notion to allow users to specify their own packet > types. (2) Use of flexible input variables, called Parameters in IPPM > definitions, some which determine the quantity measured and others > which should not be specified until execution of the measurement. (3) > Allowing flexibility in choice of statistics to summarize the results > on a stream of measurement packets. Specifically, this memo proposes > a way to organize registry entries into columns that are well- > defined, permiting consistent development of entries over time. > Also, this fosters development of registry entries based on existing > reference RFCs for performance metrics, and requires expert review > for every entry before IANA action. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From timothy.carey@alcatel-lucent.com Tue Oct 8 15:23:39 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279A211E810F for ; Tue, 8 Oct 2013 15:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfmVctZtKRbO for ; Tue, 8 Oct 2013 15:23:26 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0316011E810E for ; Tue, 8 Oct 2013 15:23:10 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r98MN9Ne017631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Oct 2013 17:23:09 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r98MN9VF016662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Oct 2013 18:23:09 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 8 Oct 2013 18:23:09 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: Information Model Attributes - MA Identifier Thread-Index: Ac7EdPa2AuhUUygZR8KfHgiaY8JHCQ== Date: Tue, 8 Oct 2013 22:23:08 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771F296C@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771F296CUS70UWXCHMBA05zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [lmap] Information Model Attributes - MA Identifier X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Oct 2013 22:23:40 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771F296CUS70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the July draft of the Information Model the Measurement Agent has an att= ribute for the Identifier that is referencing a MAC address. In the past we have seen issues with MAC addresses as identifiers for devic= es (e.g, which address to use when a device has multiple MACs, devices with= out MAC Addresses). One suggestion is to make this identifier a UUID based on RFC 4122 UUID string(36:36) Universally Unique Identifier. See [RFC4122]. Thoughts regarding this would be appreciated BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771F296CUS70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the July draft of the Information Model the Measu= rement Agent has an attribute for the Identifier that is referencing a MAC = address.

In the past we have seen issues with MAC addresses a= s identifiers for devices (e.g, which address to use when a device has mult= iple MACs, devices without MAC Addresses).

 

One suggestion is to make this identifier a UUID bas= ed on RFC 4122

UUID

string(36:36)

Universally Unique Identifier. See [RFC4122].

 

Thoughts regarding this would be appreciated

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F771F296CUS70UWXCHMBA05zam_-- From jason.weil@twcable.com Tue Oct 8 16:48:29 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1608A21E80C3 for ; Tue, 8 Oct 2013 16:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHFzjJbF8TDQ for ; Tue, 8 Oct 2013 16:48:25 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id C185421E80C4 for ; Tue, 8 Oct 2013 16:48:19 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,1059,1371096000"; d="scan'208,217";a="49685938" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 08 Oct 2013 19:47:52 -0400 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.96]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 8 Oct 2013 19:47:53 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Date: Tue, 8 Oct 2013 19:47:51 -0400 Thread-Topic: Feedback Requested on -00 drafts Thread-Index: Ac7EgM2QYjFyImSNSdOPzD3A0iLzAw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE7A11E71F941jasonweiltwcablecom_" MIME-Version: 1.0 Subject: [lmap] Feedback Requested on -00 drafts X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Oct 2013 23:48:29 -0000 --_000_CE7A11E71F941jasonweiltwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LMAP WG, I would like to request the WG take some time to review and provide feedba= ck on two newly posted -00 versions of proposed WG drafts. The drafts are r= elated to our first two milestones (Use Case and Framework) and both includ= e a number of proposals that have been merged over the last few months. If = there are any concerns or additional points that you feel need to be addres= sed now is the time to post those comments to the list. 1. A framework for large-scale measurement platforms (Posted Oct 6, 2013) = - https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ 2. Large-Scale Broadband Measurement Use Cases (Posted Oct 3, 2013) - http= s://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ 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_CE7A11E71F941jasonweiltwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
LMAP WG,=

I would = like to request the WG take some time to  review and provide feedback = on two newly posted -00 versions of proposed WG drafts. The drafts are rela= ted to our first two milestones (Use Case and Framework) and both include a number of proposals that have been merge= d over the last few months. If there are any concerns or additional points = that you feel need to be addressed now is the time to post those comments t= o the list. 

1.  = ;A framework for large-scale= measurement platforms (Posted Oct 6, 2013) -  https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/



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_CE7A11E71F941jasonweiltwcablecom_-- From trevor.burbridge@bt.com Wed Oct 9 00:21:50 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CAC21E80E3 for ; Wed, 9 Oct 2013 00:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UJxnAn1Bd2D for ; Wed, 9 Oct 2013 00:21:45 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 16C0121E80D3 for ; Wed, 9 Oct 2013 00:21:44 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 9 Oct 2013 08:21:42 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.69]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 9 Oct 2013 08:21:42 +0100 From: To: , Date: Wed, 9 Oct 2013 08:21:40 +0100 Thread-Topic: Information Model Attributes - MA Identifier Thread-Index: Ac7EdPa2AuhUUygZR8KfHgiaY8JHCQASuGeA Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771F296C@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771F296C@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72C2F78040DEMV64UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] Information Model Attributes - MA Identifier X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Oct 2013 07:21:50 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72C2F78040DEMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The MA ID (Measurement Agent Identifier) is currently just expressed as a S= tring in the Information Model. The MAC Address is a separate and different= parameter in the model. I think we were always imagining it might be a UUID. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Car= ey, Timothy (Timothy) Sent: 08 October 2013 23:23 To: lmap@ietf.org Subject: [lmap] Information Model Attributes - MA Identifier In the July draft of the Information Model the Measurement Agent has an att= ribute for the Identifier that is referencing a MAC address. In the past we have seen issues with MAC addresses as identifiers for devic= es (e.g, which address to use when a device has multiple MACs, devices with= out MAC Addresses). One suggestion is to make this identifier a UUID based on RFC 4122 UUID string(36:36) Universally Unique Identifier. See [RFC4122]. Thoughts regarding this would be appreciated BR, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72C2F78040DEMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The MA ID (Measurement Agent Identifier) is currently just ex= pressed as a String in the Information Model. The MAC Address is a separate= and different parameter in the model.

 

I think we were always imagining it= might be a UUID.

 

Trevor.

 

Trevor Burbridge
Network Infrastructure & Innovation | BT= Innovate & Design
Tel: 01473 645115
Fax: 01473 640929
=
This email contains BT inf= ormation, which may be privileged or confidential. It's meant only for the = individual(s) or entity named above. If you're not the intended recipient, = note that disclosing, copying, distributing or using this information is pr= ohibited. If you've received this email in error, please let me know immedi= ately on the email address above. Thank you.
We monitor our email system= , and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Stre= et London EC1A 7AJ
Registered in England no: 1800000

 

<= p class=3DMsoNormal>From: lmap-bounces@ietf.org [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)Sent: 08 October 2013 23:23
To: lmap@ietf.org
Subje= ct: [lmap] Information Model Attributes - MA Identifier

 

In the July draft of the Information Model the Mea= surement Agent has an attribute for the Identifier that is referencing a MA= C address.

In = the past we have seen issues with MAC addresses as identifiers for devices = (e.g, which address to use when a device has multiple MACs, devices without= MAC Addresses).

 

One= suggestion is to make this identifier a UUID based on RFC 4122<= /span>

UUID

string(36:3= 6)

Universally Unique Identifier. See [RFC4122].

 

Thoughts regarding this would be appreciated<= /o:p>

 

BR,

<= p class=3DMsoNormal>Tim

= --_000_ED51D9282D1D3942B9438CA8F3372EB72C2F78040DEMV64UKRDdoma_-- From marcelo@it.uc3m.es Wed Oct 9 00:27:47 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FE021E80E4 for ; Wed, 9 Oct 2013 00:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFur6k-eM1UY for ; Wed, 9 Oct 2013 00:27:43 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id F2F5B21E80C7 for ; Wed, 9 Oct 2013 00:27:42 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A0DF1FA939F for ; Wed, 9 Oct 2013 09:27:40 +0200 (CEST) X-uc3m-safe: yes Received: from [163.117.203.129] (unknown [163.117.203.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 71DA69D2837 for ; Wed, 9 Oct 2013 09:27:40 +0200 (CEST) Message-ID: <52550572.2010901@it.uc3m.es> Date: Wed, 09 Oct 2013 09:27:46 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: lmap@ietf.org References: <9966516C6EB5FC4381E05BF80AA55F771F296C@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771F296C@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Wed, 09 Oct 2013 09:27:40 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20206.005 X-TM-AS-Result: No--12.750-7.0-31-1 X-imss-scan-details: No--12.750-7.0-31-1 Subject: Re: [lmap] Information Model Attributes - MA Identifier X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Oct 2013 07:27:47 -0000 Hi Tim, I agree with you. I think our idea was to use UUID (moreover, in http://tools.ietf.org/html/draft-bagnulo-lmap-http-00 we already reflect that) Regards, marcelo El 09/10/13 00:23, Carey, Timothy (Timothy) escribió: > > In the July draft of the Information Model the Measurement Agent has > an attribute for the Identifier that is referencing a MAC address. > > In the past we have seen issues with MAC addresses as identifiers for > devices (e.g, which address to use when a device has multiple MACs, > devices without MAC Addresses). > > One suggestion is to make this identifier a UUID based on RFC 4122 > > UUID > > > > string(36:36) > > > > Universally Unique Identifier. See [RFC4122 <#R.RFC4122>]. > > Thoughts regarding this would be appreciated > > BR, > > Tim > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From trammell@tik.ee.ethz.ch Wed Oct 9 00:29:19 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9B921E80C7 for ; Wed, 9 Oct 2013 00:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFisdO7NHfpI for ; Wed, 9 Oct 2013 00:29:14 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id AA23421E80E2 for ; Wed, 9 Oct 2013 00:29:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D9C85D9386; Wed, 9 Oct 2013 09:29:12 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dDhjKPTjm2Dn; Wed, 9 Oct 2013 09:29:12 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 82A20D9374; Wed, 9 Oct 2013 09:29:12 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_1A4C35AD-B6B6-46BB-AE1C-3C0A9B92141E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Trammell In-Reply-To: <52550572.2010901@it.uc3m.es> Date: Wed, 9 Oct 2013 09:29:11 +0200 Message-Id: References: <9966516C6EB5FC4381E05BF80AA55F771F296C@US70UWXCHMBA05.zam.alcatel-lucent.com> <52550572.2010901@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1510) Cc: lmap@ietf.org Subject: Re: [lmap] Information Model Attributes - MA Identifier X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Oct 2013 07:29:19 -0000 --Apple-Mail=_1A4C35AD-B6B6-46BB-AE1C-3C0A9B92141E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 hi Marcelo, Tim, all, Ah, good.=20 Note also that using UUIDs for MAs may have benefits for privacy as = well, at least with respect to accidentally leaked identifiers: they = cannot be correlated to SLAAC addresses or to device manufacturers as = MAC addresses can. Cheers, Brian On Oct 9, 2013, at 9:27 AM, marcelo bagnulo braun = wrote: > Hi Tim, >=20 > I agree with you. I think our idea was to use UUID (moreover, in = http://tools.ietf.org/html/draft-bagnulo-lmap-http-00 we already reflect = that) >=20 > Regards, marcelo >=20 >=20 > El 09/10/13 00:23, Carey, Timothy (Timothy) escribi=F3: >>=20 >> In the July draft of the Information Model the Measurement Agent has = an attribute for the Identifier that is referencing a MAC address. >>=20 >> In the past we have seen issues with MAC addresses as identifiers for = devices (e.g, which address to use when a device has multiple MACs, = devices without MAC Addresses). >>=20 >> One suggestion is to make this identifier a UUID based on RFC 4122 >>=20 >> UUID >>=20 >> =09 >>=20 >> string(36:36) >>=20 >> =09 >>=20 >> Universally Unique Identifier. See [RFC4122 <#R.RFC4122>]. >>=20 >> Thoughts regarding this would be appreciated >>=20 >> BR, >>=20 >> Tim >>=20 >>=20 >>=20 >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --Apple-Mail=_1A4C35AD-B6B6-46BB-AE1C-3C0A9B92141E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSVQXHAAoJENt3nsOmbNJciM4H/0AJzSjGkjaESJDzhRV6AL4o EHbs6QWOvG0wuq2TvwbfG3g5VUjAk90x4Yj/IBpLfCVsBc5HYB7WITqGERwMhN+f YT/Fvr7lR5xroEyyv7b+M7PqOPXb0tAGDP/QQYMCvh/vehQ10To9PZT2KSIRRfzc GPPHb5FgPuNzYXj9xGXRSOODRqD7MIJ9Sloy7zJ/qzs4nwGBi5EJCJgMKQscLtzl kUX9HezV8Fa6N8rPl1v1asYBsPVA+1sQeIdh2dsCDvkD2t0peHXqd3DTu7K9sqpE RIRiMvsZJsy1aMHudZX4lA/Bf3ES+mJWDxn1LCt04SIbAZ/P7/AIUV9FJF3lE1k= =TkDL -----END PGP SIGNATURE----- --Apple-Mail=_1A4C35AD-B6B6-46BB-AE1C-3C0A9B92141E-- From acmorton@att.com Wed Oct 9 05:15:05 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C60811E817F for ; Wed, 9 Oct 2013 05:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4lv3Bt+3vNG for ; Wed, 9 Oct 2013 05:14:59 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD3411E8177 for ; Wed, 9 Oct 2013 05:14:53 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 06E40120B1C; Wed, 9 Oct 2013 08:14:53 -0400 (EDT) Received: from njfpsrvexg1.research.att.com (njfpsrvexg1.research.att.com [135.207.177.20]) by mail-green.research.att.com (Postfix) with ESMTP id 1369DE0122; Wed, 9 Oct 2013 08:14:34 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg1.research.att.com ([fe80::58ce:ca01:5d18:db01%13]) with mapi; Wed, 9 Oct 2013 08:14:52 -0400 From: "MORTON, ALFRED C (AL)" To: Brian Trammell , marcelo bagnulo braun Date: Wed, 9 Oct 2013 08:14:51 -0400 Thread-Topic: [lmap] Information Model Attributes - MA Identifier Thread-Index: Ac7EwVF+tAunnZoLSx2IkyMxSSHKlgAJ5bDg Message-ID: <2845723087023D4CB5114223779FA9C8AB1BDB58@njfpsrvexg8.research.att.com> References: <9966516C6EB5FC4381E05BF80AA55F771F296C@US70UWXCHMBA05.zam.alcatel-lucent.com> <52550572.2010901@it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Model Attributes - MA Identifier X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Oct 2013 12:15:05 -0000 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Brian Trammell ... > Note also that using UUIDs for MAs may have benefits for privacy as well, > at least with respect to accidentally leaked identifiers: they cannot be > correlated to SLAAC addresses or to device manufacturers as MAC addresses > can. >=20 We can take the above as a comment/additional consideration to mention in the framework privacy section, so thanks for that! Al From timothy.carey@alcatel-lucent.com Wed Oct 9 08:09:54 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E17F21E808A for ; Wed, 9 Oct 2013 08:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tRF1Q3xfXfX for ; Wed, 9 Oct 2013 08:09:47 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2BB21F9D4C for ; Wed, 9 Oct 2013 08:09:17 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r99F9BD0015372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Oct 2013 10:09:12 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r99F9BFQ000865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 11:09:11 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 9 Oct 2013 11:09:11 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Information Model Attributes - MA Identifier Thread-Index: Ac7EdPa2AuhUUygZR8KfHgiaY8JHCQASuGeAABBfC2A= Date: Wed, 9 Oct 2013 15:09:10 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771F3BCA@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771F296C@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771F3BCAUS70UWXCHMBA05zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [lmap] Information Model Attributes - MA Identifier X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Oct 2013 15:09:54 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771F3BCAUS70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, Thanks for the information - then I must have missed that it was separate. What is the MAC Address used for? BR, Tim From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Wednesday, October 09, 2013 2:22 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: Information Model Attributes - MA Identifier The MA ID (Measurement Agent Identifier) is currently just expressed as a S= tring in the Information Model. The MAC Address is a separate and different= parameter in the model. I think we were always imagining it might be a UUID. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Car= ey, Timothy (Timothy) Sent: 08 October 2013 23:23 To: lmap@ietf.org Subject: [lmap] Information Model Attributes - MA Identifier In the July draft of the Information Model the Measurement Agent has an att= ribute for the Identifier that is referencing a MAC address. In the past we have seen issues with MAC addresses as identifiers for devic= es (e.g, which address to use when a device has multiple MACs, devices with= out MAC Addresses). One suggestion is to make this identifier a UUID based on RFC 4122 UUID string(36:36) Universally Unique Identifier. See [RFC4122]. Thoughts regarding this would be appreciated BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771F3BCAUS70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

Thanks for the informa= tion – then I must have missed that it was separate.

What is the MAC Addres= s used for?

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Wednesday, October 09, 2013 2:22 AM
To: Carey, Timothy (Timothy); lmap@ietf.org
Subject: RE: Information Model Attributes - MA Identifier=

 

The MA = ID (Measurement Agent Identifier) is currently just expressed as a String i= n the Information Model. The MAC Address is a separate and different parame= ter in the model.

&n= bsp;

I think= we were always imagining it might be a UUID.

&n= bsp;

Trevor.=

&n= bsp;

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

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this infor= mation is prohibited. If you've received this email in error, please let me= know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 08 October 2013 23:23
To: lmap@ietf.org
Subject: [lmap] Information Model Attributes - MA Identifier

 

In the July draft of the Information Model the Measu= rement Agent has an attribute for the Identifier that is referencing a MAC = address.

In the past we have seen issues with MAC addresses a= s identifiers for devices (e.g, which address to use when a device has mult= iple MACs, devices without MAC Addresses).

 

One suggestion is to make this identifier a UUID bas= ed on RFC 4122

UUID

string(36:36)

Universally Unique Identifier. See [RFC4122].

 

Thoughts regarding this would be appreciated

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F771F3BCAUS70UWXCHMBA05zam_-- From trevor.burbridge@bt.com Wed Oct 9 08:12:43 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8833821E8056 for ; Wed, 9 Oct 2013 08:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ4V5i4NIDbU for ; Wed, 9 Oct 2013 08:12:38 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0740121E809B for ; Wed, 9 Oct 2013 08:12:33 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 9 Oct 2013 16:12:32 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.69]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Wed, 9 Oct 2013 16:12:32 +0100 From: To: , Date: Wed, 9 Oct 2013 16:12:31 +0100 Thread-Topic: Information Model Attributes - MA Identifier Thread-Index: Ac7EdPa2AuhUUygZR8KfHgiaY8JHCQASuGeAABBfC2AAABQ5gA== Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771F296C@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F3BCA@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771F3BCA@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72C2F780813EMV64UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] Information Model Attributes - MA Identifier X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Oct 2013 15:12:43 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72C2F780813EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It should be optional - basically a way in some deployment scenarios for th= e Controller to be able to identify the physical device (and thereby things= like address it was shipped to and who to contact about it etc.). Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 09 October 2013 16:09 To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: Information Model Attributes - MA Identifier Trevor, Thanks for the information - then I must have missed that it was separate. What is the MAC Address used for? BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Wednesday, October 09, 2013 2:22 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: Information Model Attributes - MA Identifier The MA ID (Measurement Agent Identifier) is currently just expressed as a S= tring in the Information Model. The MAC Address is a separate and different= parameter in the model. I think we were always imagining it might be a UUID. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 08 October 2013 23:23 To: lmap@ietf.org Subject: [lmap] Information Model Attributes - MA Identifier In the July draft of the Information Model the Measurement Agent has an att= ribute for the Identifier that is referencing a MAC address. In the past we have seen issues with MAC addresses as identifiers for devic= es (e.g, which address to use when a device has multiple MACs, devices with= out MAC Addresses). One suggestion is to make this identifier a UUID based on RFC 4122 UUID string(36:36) Universally Unique Identifier. See [RFC4122]. Thoughts regarding this would be appreciated BR, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72C2F780813EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It should be optional – basically a way in some deploym= ent scenarios for the Controller to be able to identify the physical device= (and thereby things like address it was shipped to and who to contact abou= t it etc.).

 

Trevor.

 

Trevor Burbridge
Network Infrastructure & Innovation | BT Inno= vate & Design
Tel: 01473 645115
Fax: 01473 640929
<= span style=3D'color:#1F497D'>
This email contains BT informat= ion, which may be privileged or confidential. It's meant only for the indiv= idual(s) or entity named above. If you're not the intended recipient, note = that disclosing, copying, distributing or using this information is prohibi= ted. If you've received this email in error, please let me know immediately= on the email address above. Thank you.
We monitor our email system, and= may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street Lo= ndon EC1A 7AJ
Registered in England no: 1800000

 

From: Carey, Timothy (Timothy) [mailt= o:timothy.carey@alcatel-lucent.com]
Sent: 09 October 2013 16:09<= br>To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org
Subject: R= E: Information Model Attributes - MA Identifier

=

 

Trevor,

 

Th= anks for the information – then I must have missed that it was separa= te.

What is the MAC Address used for?

 =

= BR,

Tim

 

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Wednesday, = October 09, 2013 2:22 AM
To: Carey, Timothy (Timothy); lmap@ietf.org
Subject: RE: Information= Model Attributes - MA Identifier

 

The MA ID (Measurement Agent Identifier= ) is currently just expressed as a String in the Information Model. The MAC= Address is a separate and different parameter in the model.

 =

I think we we= re always imagining it might be a UUID.

 

Trevor.

 

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

Th= is email contains BT information, which may be privileged or confidential. = It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or usin= g this information is prohibited. If you've received this email in error, p= lease let me know immediately on the email address above. Thank you.
We = monitor our email system, and may record your emails.
British Telecommunications plc
Registered= office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 180= 0000

 

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

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behal= f Of Carey, Timothy (Timothy)
Sent: 08 October 2013 23:23
= To: lmap@ietf.org
Subject= : [lmap] Information Model Attributes - MA Identifier=

 

In the July draft of the Information Model the Measu= rement Agent has an attribute for the Identifier that is referencing a MAC = address.

In th= e past we have seen issues with MAC addresses as identifiers for devices (e= .g, which address to use when a device has multiple MACs, devices without M= AC Addresses).

 

One s= uggestion is to make this identifier a UUID based on RFC 4122

UUID

string(36:36)<= o:p>

Universally Unique Identifier. See [RFC4122].

 

Thoughts regarding this would be appreciated=

 =

BR,

Tim

= --_000_ED51D9282D1D3942B9438CA8F3372EB72C2F780813EMV64UKRDdoma_-- From timothy.carey@alcatel-lucent.com Wed Oct 9 08:46:24 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA29711E81B3 for ; Wed, 9 Oct 2013 08:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.848 X-Spam-Level: X-Spam-Status: No, score=-9.848 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u34t8ssLbFe8 for ; Wed, 9 Oct 2013 08:46:12 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 756B311E8192 for ; Wed, 9 Oct 2013 08:46:12 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r99Fk5hv028006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Oct 2013 10:46:05 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r99Fk1Jl027882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 11:46:01 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 9 Oct 2013 11:46:01 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Information Model Attributes - MA Identifier Thread-Index: Ac7EdPa2AuhUUygZR8KfHgiaY8JHCQASuGeAABBfC2AAABQ5gAAA2+mg Date: Wed, 9 Oct 2013 15:46:00 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771F3C0D@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771F296C@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F3BCA@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771F3C0DUS70UWXCHMBA05zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [lmap] Information Model Attributes - MA Identifier X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Oct 2013 15:46:24 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771F3C0DUS70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So in the information model it is MA MAC; does the name make sense or shoul= d it be MADeviceID? If it is truly a device identifier do we want to type i= t as a MAC Address or just allow it to be a URN? BR, Tim From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Wednesday, October 09, 2013 10:13 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: Information Model Attributes - MA Identifier It should be optional - basically a way in some deployment scenarios for th= e Controller to be able to identify the physical device (and thereby things= like address it was shipped to and who to contact about it etc.). Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 09 October 2013 16:09 To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: Information Model Attributes - MA Identifier Trevor, Thanks for the information - then I must have missed that it was separate. What is the MAC Address used for? BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Wednesday, October 09, 2013 2:22 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: Information Model Attributes - MA Identifier The MA ID (Measurement Agent Identifier) is currently just expressed as a S= tring in the Information Model. The MAC Address is a separate and different= parameter in the model. I think we were always imagining it might be a UUID. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 08 October 2013 23:23 To: lmap@ietf.org Subject: [lmap] Information Model Attributes - MA Identifier In the July draft of the Information Model the Measurement Agent has an att= ribute for the Identifier that is referencing a MAC address. In the past we have seen issues with MAC addresses as identifiers for devic= es (e.g, which address to use when a device has multiple MACs, devices with= out MAC Addresses). One suggestion is to make this identifier a UUID based on RFC 4122 UUID string(36:36) Universally Unique Identifier. See [RFC4122]. Thoughts regarding this would be appreciated BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771F3C0DUS70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So in the information = model it is MA MAC; does the name make sense or should it be MADeviceID? If= it is truly a device identifier do we want to type it as a MAC Address or = just allow it to be a URN?

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Wednesday, October 09, 2013 10:13 AM
To: Carey, Timothy (Timothy); lmap@ietf.org
Subject: RE: Information Model Attributes - MA Identifier=

 

It shou= ld be optional – basically a way in some deployment scenarios for the= Controller to be able to identify the physical device (and thereby things = like address it was shipped to and who to contact about it etc.).

&n= bsp;

Trevor.=

&n= bsp;

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

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this infor= mation is prohibited. If you've received this email in error, please let me= know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: Carey, T= imothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: 09 October 2013 16:09
To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org
Subject: RE: Information Model Attributes - MA Identifier=

 

Trevor,

 

Thanks for the informa= tion – then I must have missed that it was separate.

What is the MAC Addres= s used for?

 

BR,<= /p>

Tim<= /p>

 

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Wednesday, October 09, 2013 2:22 AM
To: Carey, Timothy (Timothy); lmap@= ietf.org
Subject: RE: Information Model Attributes - MA Identifier=

 

The MA = ID (Measurement Agent Identifier) is currently just expressed as a String i= n the Information Model. The MAC Address is a separate and different parame= ter in the model.

&n= bsp;

I think= we were always imagining it might be a UUID.

&n= bsp;

Trevor.=

&n= bsp;

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

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this infor= mation is prohibited. If you've received this email in error, please let me= know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 08 October 2013 23:23
To: lmap@ietf.org
Subject: [lmap] Information Model Attributes - MA Identifier

 

In the July draft of the Information Model the Measu= rement Agent has an attribute for the Identifier that is referencing a MAC = address.

In the past we have seen issues with MAC addresses a= s identifiers for devices (e.g, which address to use when a device has mult= iple MACs, devices without MAC Addresses).

 

One suggestion is to make this identifier a UUID bas= ed on RFC 4122

UUID

string(36:36)

Universally Unique Identifier. See [RFC4122].

 

Thoughts regarding this would be appreciated

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F771F3C0DUS70UWXCHMBA05zam_-- From timothy.carey@alcatel-lucent.com Wed Oct 9 12:58:09 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CDA21F9D46 for ; Wed, 9 Oct 2013 12:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj6Z7oBmUMrj for ; Wed, 9 Oct 2013 12:57:58 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5E40021E81B3 for ; Wed, 9 Oct 2013 12:57:35 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r99JvCs1029026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 9 Oct 2013 14:57:13 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r99Jv0Ws013568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 9 Oct 2013 15:57:12 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 9 Oct 2013 15:57:03 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbw== Date: Wed, 9 Oct 2013 19:57:02 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771F3EFEUS70UWXCHMBA05zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Oct 2013 19:58:13 -0000 X-List-Received-Date: Wed, 09 Oct 2013 19:58:13 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771F3EFEUS70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771F3EFEUS70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

During the 3Q2013 BBF meeting, the BBHome group had = an opportunity to review the LMAP information model.

I have tried to incorporate the comments and questio= ns here:

 

1)      It was unclear what the definition was for the Cros= sTraffic attribute.

Upon further discussion in the group we thought that= the CrossTraffic parameter was an indication that the Result of a measurem= ent might be suspect because there was other traffic detected by the measur= ement agent that might cause an invalid measurement.

 

If this is true – should we rename this attrib= ute to something like SuspectResult and type it as a Boolean?

 

I also suggest this description:

This parameter indicates if the measurement agent has determined th= at the result may be suspect. Events that cause a result to be suspect is specific to the implementation of the measurement agent b= ut may include events such as indications of other traffic or an unusual CP= U load that may interfere with test.

 

2)   = ;  In the Measurement Ag= ent there is an attribute supported measurements that is a list of entries = to the Registry

This seems fine; the group di= d ask for a clarification if a device could support more than one Measureme= nt Agent.

 

3)   = ;  When we reviewed the = Options for a Task we were not sure if this was something where each option= was a Name/Value pair that could be individually maintained or if they options should be maintained as a bulk list of Name/Value pairs= . What this would mean is if you wanted to add, edit or delete on option yo= u have to resend entire option list.

 

 

Thoughts?

 

Thanks,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F771F3EFEUS70UWXCHMBA05zam_-- From j.schoenwaelder@jacobs-university.de Thu Oct 10 02:42:51 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED83021F9AE7 for ; Thu, 10 Oct 2013 02:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dUp2HHGgGF1 for ; Thu, 10 Oct 2013 02:42:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 70EDD21F9A8D for ; Thu, 10 Oct 2013 02:42:08 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 189E920066; Thu, 10 Oct 2013 11:42:08 +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 sa7ZdVlWM6Yg; Thu, 10 Oct 2013 11:42:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CFC72005C; Thu, 10 Oct 2013 11:42:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C88CE28C38D2; Thu, 10 Oct 2013 11:42:01 +0200 (CEST) Date: Thu, 10 Oct 2013 11:42:01 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20131010094159.GA66526@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "trevor.burbridge@bt.com" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F771F296C@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F3BCA@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F3C0D@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771F3C0D@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model Attributes - MA Identifier X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 09:42:52 -0000 On Wed, Oct 09, 2013 at 03:46:00PM +0000, Carey, Timothy (Timothy) wrote: > So in the information model it is MA MAC; does the name make sense > or should it be MADeviceID? If it is truly a device identifier do we > want to type it as a MAC Address or just allow it to be a URN? I think this makes sense since in the use cases I have seen this MAC address seems to be used primarily as a device ID. And this device ID may be one of the MAC addresses of a device - this is what you often find printed on the back of home router like devices. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Oct 10 06:38:33 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B300821E8120 for ; Thu, 10 Oct 2013 06:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.872 X-Spam-Level: X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeKyNrpbOSIv for ; Thu, 10 Oct 2013 06:38:28 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id DC52221E808D for ; Thu, 10 Oct 2013 06:38:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFACutVlLGmAcV/2dsb2JhbABTBoJDIyE4UsEdgSIWdIIlAQEBAQMSG1wCAQgNBAQBAQsdBzIUCQgBAQQBEggah2QBC5w9nFoTBI4ODHwtCgGDH4EEA55kg2+HNIMkgXE5 X-IronPort-AV: E=Sophos;i="4.90,1072,1371096000"; d="scan'208,217";a="31958378" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Oct 2013 09:38:25 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Oct 2013 09:34:27 -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.0146.000; Thu, 10 Oct 2013 15:38:24 +0200 From: "Romascanu, Dan (Dan)" To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwAlBVMQ Date: Thu, 10 Oct 2013 13:38:23 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129043E4@AZ-FFEXMB04.global.avaya.com> References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA129043E4AZFFEXMB04globa_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Oct 2013 13:38:34 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA129043E4AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thank you for you input. Just to make sure that we understand your comments= in the right context - you are referring in your mail to https://datatrack= er.ietf.org/doc/draft-burbridge-lmap-information-model/, right? Please conf= irm. Thanks and Regards, Dan (LMAP co-chair) From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Car= ey, Timothy (Timothy) Sent: Wednesday, October 09, 2013 10:57 PM To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_9904FB1B0159DA42B0B887B7FA8119CA129043E4AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

 

Thank you for you inpu= t. Just to make sure that we understand your comments in the right context = – you are referring in your mail to https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/, right? Please confirm.

 

Thanks and Regards,

 

Dan<= /p>

(LMAP co-chair)

 

 

 

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: Wednesday, October 09, 2013 10:57 PM
To: lmap@ietf.org
Subject: [lmap] LMAP Information Model - BBF Questions and Comments<= o:p>

 

Hello,

 

During the 3Q2013 BBF meeting, the BBHome group had = an opportunity to review the LMAP information model.

I have tried to incorporate the comments and questio= ns here:

 

1)      It was unclear what the de= finition was for the CrossTraffic attribute.

Upon further discussion in the group we thought that= the CrossTraffic parameter was an indication that the Result of a measurem= ent might be suspect because there was other traffic detected by the measur= ement agent that might cause an invalid measurement.

 

If this is true – should we rename this attrib= ute to something like SuspectResult and type it as a Boolean?

 

I also suggest this description:

This parameter indicates if the measurement agent has determined th= at the result may be suspect. Events that cause a result to be suspect is specific to the implementation of the measurement agent b= ut may include events such as indications of other traffic or an unusual CP= U load that may interfere with test.

 

2)   = ;  In the Measurement Agent there is an attribute supported measurements t= hat is a list of entries to the Registry

This seems fine; the group di= d ask for a clarification if a device could support more than one Measureme= nt Agent.

 

3)   = ;  When we reviewed the Options for a Task we were not sure if this was so= mething where each option was a Name/Value pair that could be individually maintained or if they options should be maintained as a bu= lk list of Name/Value pairs. What this would mean is if you wanted to add, = edit or delete on option you have to resend entire option list.<= /span>

 

 

Thoughts?

 

Thanks,

Tim

--_000_9904FB1B0159DA42B0B887B7FA8119CA129043E4AZFFEXMB04globa_-- From timothy.carey@alcatel-lucent.com Thu Oct 10 06:40:12 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C2421E8103 for ; Thu, 10 Oct 2013 06:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aerkqYvKz6W5 for ; Thu, 10 Oct 2013 06:40:05 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE7F21E8116 for ; Thu, 10 Oct 2013 06:40:05 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9ADe3nQ025419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Oct 2013 08:40:03 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9ADe2Mf016746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 09:40:02 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 10 Oct 2013 09:40:02 -0400 From: "Carey, Timothy (Timothy)" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwAlBVMQAAAX6sA= Date: Thu, 10 Oct 2013 13:40:02 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771F4340@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> <9904FB1B0159DA42B0B887B7FA8119CA129043E4@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129043E4@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.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771F4340US70UWXCHMBA05zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Oct 2013 13:40:12 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771F4340US70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes these questions are on the information model. From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Thursday, October 10, 2013 8:38 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Hi, Thank you for you input. Just to make sure that we understand your comments= in the right context - you are referring in your mail to https://datatrack= er.ietf.org/doc/draft-burbridge-lmap-information-model/, right? Please conf= irm. Thanks and Regards, Dan (LMAP co-chair) From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Car= ey, Timothy (Timothy) Sent: Wednesday, October 09, 2013 10:57 PM To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771F4340US70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes these questions ar= e on the information model.

 

From: Romascan= u, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Thursday, October 10, 2013 8:38 AM
To: Carey, Timothy (Timothy); lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

Hi, =

 

Thank you for you inpu= t. Just to make sure that we understand your comments in the right context = – you are referring in your mail to https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model/, right? Please confirm.

 

Thanks and Regards,

 

Dan<= /p>

(LMAP co-chair)

 

 

 

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: Wednesday, October 09, 2013 10:57 PM
To: lmap@ietf.org
Subject: [lmap] LMAP Information Model - BBF Questions and Comments<= o:p>

 

Hello,

 

During the 3Q2013 BBF meeting, the BBHome group had = an opportunity to review the LMAP information model.

I have tried to incorporate the comments and questio= ns here:

 

1)      It was unclear what the definition was for the Cros= sTraffic attribute.

Upon further discussion in the group we thought that= the CrossTraffic parameter was an indication that the Result of a measurem= ent might be suspect because there was other traffic detected by the measur= ement agent that might cause an invalid measurement.

 

If this is true – should we rename this attrib= ute to something like SuspectResult and type it as a Boolean?

 

I also suggest this description:

This parameter indicates if the measurement agent has determined th= at the result may be suspect. Events that cause a result to be suspect is specific to the implementation of the measurement agent b= ut may include events such as indications of other traffic or an unusual CP= U load that may interfere with test.

 

2)   = ;  In the Measurement Ag= ent there is an attribute supported measurements that is a list of entries = to the Registry

This seems fine; the group di= d ask for a clarification if a device could support more than one Measureme= nt Agent.

 

3)   = ;  When we reviewed the = Options for a Task we were not sure if this was something where each option= was a Name/Value pair that could be individually maintained or if they options should be maintained as a bulk list of Name/Value pairs= . What this would mean is if you wanted to add, edit or delete on option yo= u have to resend entire option list.

 

 

Thoughts?

 

Thanks,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F771F4340US70UWXCHMBA05zam_-- From j.schoenwaelder@jacobs-university.de Thu Oct 10 07:03:37 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3132721F9C87 for ; Thu, 10 Oct 2013 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIT+LKDfpm8S for ; Thu, 10 Oct 2013 07:03:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CB6FD21F9A37 for ; Thu, 10 Oct 2013 07:03:28 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DECD920045; Thu, 10 Oct 2013 16:03:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jek9NFw-F3ym; Thu, 10 Oct 2013 16:03:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E1FF20061; Thu, 10 Oct 2013 16:03:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D3B4928C4AD8; Thu, 10 Oct 2013 16:03:20 +0200 (CEST) Date: Thu, 10 Oct 2013 16:03:19 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20131010140319.GA66883@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 14:03:37 -0000 On Wed, Oct 09, 2013 at 07:57:02PM +0000, Carey, Timothy (Timothy) wrote: > 2) In the Measurement Agent there is an attribute supported measurements that is a list of entries to the Registry > This seems fine; the group did ask for a clarification if a device could support more than one Measurement Agent. > This is somewhat difficult to answer since we do not have a strict definition of what is a 'device'. In many use cases today, you likely have only one MA per device but I can also envision 'devices' that have multiple embedded MAs. I think the framework and information model should allow this as long as this does not add significant complexity to LMAP solutions. > 3) When we reviewed the Options for a Task we were not sure if this was something where each option was a Name/Value pair that could be individually maintained or if they options should be maintained as a bulk list of Name/Value pairs. What this would mean is if you wanted to add, edit or delete on option you have to resend entire option list. I think this is a protocol issue, not really an information model issue. Some protocols may only allow to modify the set as a complete unit while others may provide the flexibility to modify arbitrary subsets of the options. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Oct 10 09:22:58 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650ED21E80DE for ; Thu, 10 Oct 2013 09:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.364 X-Spam-Level: X-Spam-Status: No, score=-103.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+AAjgkXaaYQ for ; Thu, 10 Oct 2013 09:22:53 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 09D5811E816B for ; Thu, 10 Oct 2013 09:22:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgLAIzTVlLGmAcV/2dsb2JhbABZgmYhOFKsSpRegSMWbQeCJwEBAxIoUQEVFRRCJgEEGwEZh2QBC5huhEiccI8Wg1eBBAOeZIsjgySCKg X-IronPort-AV: E=Sophos;i="4.90,1073,1371096000"; d="scan'208";a="31466056" 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 2013 12:22:52 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Oct 2013 12:18:54 -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.0146.000; Thu, 10 Oct 2013 18:22:50 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: Draft Agenda for the LMAP WG meeting at IETF-88 Thread-Index: Ac7F1PYisVIBBY4mTV2SxQ5xG9sSQA== Date: Thu, 10 Oct 2013 16:22:50 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12904793@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] Draft Agenda for the LMAP WG meeting at IETF-88 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Oct 2013 16:22:58 -0000 Hi, We uploaded the following draft agenda for IETF-88 at http://www.ietf.org/p= roceedings/88/agenda/agenda-88-lmap.=20 At this point in time the meeting agenda is not final, so the meeting day a= nd time is not final either. Note that we have only two hours allocated thi= s time, which is 30 min less than in Berlin.=20 The agenda focuses on the first priority items in the WG charter - especial= ly on the use cases and framework WG documents. Time allocations are prelim= inary, and we expect also to fill in the owners for each one of the time sl= ots letting based on your volunteering.=20 Please comment on the agenda and let us know if:=20 - there is anything we missed or new work you need meeting time for - are the time allocations right - who is volunteering to own the items on the agenda?=20 Thanks and Regards, Jason and Dan From timothy.carey@alcatel-lucent.com Thu Oct 10 11:18:54 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1F721E809D for ; Thu, 10 Oct 2013 11:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.418 X-Spam-Level: X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WbzIyQ+-XzU for ; Thu, 10 Oct 2013 11:18:49 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CC23511E81B3 for ; Thu, 10 Oct 2013 11:16:28 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9AIGPnD023276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Oct 2013 13:16:26 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r9AIGPxn002510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 14:16:25 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 10 Oct 2013 14:16:25 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwAuUfOAAAApO4A= Date: Thu, 10 Oct 2013 18:16:24 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771F4A86@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20131010140319.GA66883@elstar.local> In-Reply-To: <20131010140319.GA66883@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Oct 2013 18:18:55 -0000 Juergen thanks for the response - my comments inline -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, October 10, 2013 9:03 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments On Wed, Oct 09, 2013 at 07:57:02PM +0000, Carey, Timothy (Timothy) wrote: =20 > 2) In the Measurement Agent there is an attribute supported measureme= nts that is a list of entries to the Registry > This seems fine; the group did ask for a clarification if a device could = support more than one Measurement Agent. >=20 This is somewhat difficult to answer since we do not have a strict definition of what is a 'device'. In many use cases today, you likely have only one MA per device but I can also envision 'devices' that have multiple embedded MAs. I think the framework and information model should allow this as long as this does not add significant complexity to LMAP solutions. Thanks - I would agree that a device may support multiple agents; I h= aven't see it become a complex problem; the issue was directly related to h= ow to retrieve the measurements supported - was it the device or agent; we = will place it on the agent. =20 > 3) When we reviewed the Options for a Task we were not sure if this w= as something where each option was a Name/Value pair that could be individu= ally maintained or if they options should be maintained as a bulk list of N= ame/Value pairs. What this would mean is if you wanted to add, edit or dele= te on option you have to resend entire option list. I think this is a protocol issue, not really an information model issue. Some protocols may only allow to modify the set as a complete unit while others may provide the flexibility to modify arbitrary subsets of the options. I certainly am fine with this approach although that is not what in d= raft-bagnulo-lmap-http-00 which doesn't address the management of the infor= mation model in any great detail; since I didn't see the rules there I thou= ght I would ask. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Oct 10 11:37:08 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF6521F8DA3 for ; Thu, 10 Oct 2013 11:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L+9HMvmZUxm for ; Thu, 10 Oct 2013 11:37:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ECDBB11E81A5 for ; Thu, 10 Oct 2013 11:35:31 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C7362005B; Thu, 10 Oct 2013 20:35:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UrKVNJRIpLX3; Thu, 10 Oct 2013 20:35: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 BCBFF20054; Thu, 10 Oct 2013 20:35:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0B17428C5BB8; Thu, 10 Oct 2013 20:35:24 +0200 (CEST) Date: Thu, 10 Oct 2013 20:35:24 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20131010183524.GA68041@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20131010140319.GA66883@elstar.local> <9966516C6EB5FC4381E05BF80AA55F771F4A86@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771F4A86@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 18:37:08 -0000 On Thu, Oct 10, 2013 at 06:16:24PM +0000, Carey, Timothy (Timothy) wrote: > > This is somewhat difficult to answer since we do not have a strict > definition of what is a 'device'. In many use cases today, you likely > have only one MA per device but I can also envision 'devices' that > have multiple embedded MAs. I think the framework and information > model should allow this as long as this does not add significant > complexity to LMAP solutions. > > Thanks - I would agree that a device may support multiple agents; I haven't see it become a complex problem; the issue was directly related to how to retrieve the measurements supported - was it the device or agent; we will place it on the agent. Yes, I would also place it on the agent. > > 3) When we reviewed the Options for a Task we were not sure if this was something where each option was a Name/Value pair that could be individually maintained or if they options should be maintained as a bulk list of Name/Value pairs. What this would mean is if you wanted to add, edit or delete on option you have to resend entire option list. > > I think this is a protocol issue, not really an information model > issue. Some protocols may only allow to modify the set as a complete > unit while others may provide the flexibility to modify arbitrary > subsets of the options. > > I certainly am fine with this approach although that is not what in draft-bagnulo-lmap-http-00 which doesn't address the management of the information model in any great detail; since I didn't see the rules there I thought I would ask. > This is a -00 draft and there are many things not fully worked out. The next revision hopefully is more complete. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From trevor.burbridge@bt.com Fri Oct 11 02:08:43 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E71E11E8198 for ; Fri, 11 Oct 2013 02:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm3F21DGU-qd for ; Fri, 11 Oct 2013 02:08:23 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD1621F9DB4 for ; Fri, 11 Oct 2013 02:08:00 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 11 Oct 2013 10:07:59 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.69]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 11 Oct 2013 10:07:59 +0100 From: To: , Date: Fri, 11 Oct 2013 10:07:57 +0100 Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwBNwgFQ Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72C2F8149D2EMV64UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 09:08:43 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72C2F8149D2EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that cross-traffic should not be a simple Boolean, nor subsumed int= o a general 'suspect' parameter. It needs to be a counter such as bytes of traffic sent/received over the WA= N interface. The reason for this is that the level of traffic needs to be c= aptured to determine the impact on different tests and different results. T= he threshold will be varied depending on both the test that was running and= the analysis being performed. Furthermore it can also be used to determine the effectiveness of test back= -off procedures in the presence of user traffic and to analyse the impact t= he tests are having on user experience. Trevor. From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Car= ey, Timothy (Timothy) Sent: 09 October 2013 20:57 To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72C2F8149D2EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think that cross-traffic should not be a simple Boolean, no= r subsumed into a general ‘suspect’ parameter.

 

It needs to be = a counter such as bytes of traffic sent/received over the WAN interface. Th= e reason for this is that the level of traffic needs to be captured to dete= rmine the impact on different tests and different results. The threshold wi= ll be varied depending on both the test that was running and the analysis b= eing performed.

 

Furthermore it can also be used to determine the effecti= veness of test back-off procedures in the presence of user traffic and to a= nalyse the impact the tests are having on user experience.

 

Trevor.

 = ;

&= nbsp;

Fro= m: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] = On Behalf Of Carey, Timothy (Timothy)
Sent: 09 October 2013 2= 0:57
To: lmap@ietf.org
Subject: [lmap] LMAP Information= Model - BBF Questions and Comments

 

Hello,

&= nbsp;

During the 3Q= 2013 BBF meeting, the BBHome group had an opportunity to review the LMAP in= formation model.

I have tried to incorporate the comments and questions here:<= /span>

 <= /p>

1)&n= bsp;     It was unclear what the definition was for the CrossTraffic attribute.<= o:p>

Upon further d= iscussion in the group we thought that the CrossTraffic parameter was an in= dication that the Result of a measurement might be suspect because there wa= s other traffic detected by the measurement agent that might cause an inval= id measurement.

 

If th= is is true – should we rename this attribute to something like Suspec= tResult and type it as a Boolean?

 

I also suggest this description:

This para= meter indicates if the measurement agent has determined that the result may= be suspect. Events that cause a result to be suspect is specific to the im= plementation of the measurement agent but may include events such as indica= tions of other traffic or an unusual CPU load that may interfere with test.=

 

2)     In the Measurement Agent there is an attribute supp= orted measurements that is a list of entries to the Registry

This seems fine; the group did = ask for a clarification if a device could support more than one Measurement= Agent.

&nb= sp;

3)     When we reviewed the Options for a Task we were not sure if this w= as something where each option was a Name/Value pair that could be individu= ally maintained or if they options should be maintained as a bulk list of N= ame/Value pairs. What this would mean is if you wanted to add, edit or dele= te on option you have to resend entire option list.

 

 

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif= ";color:black'>Thoughts?

 

Th= anks,

Tim<= span lang=3DEN-US>

= --_000_ED51D9282D1D3942B9438CA8F3372EB72C2F8149D2EMV64UKRDdoma_-- From timothy.carey@alcatel-lucent.com Fri Oct 11 09:44:48 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2933011E80DC for ; Fri, 11 Oct 2013 09:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwNXZGZdBtVG for ; Fri, 11 Oct 2013 09:44:41 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2B411E815E for ; Fri, 11 Oct 2013 09:44:39 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9BFxvFb020009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Oct 2013 11:44:36 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9BEggVk029497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 10:42:42 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Fri, 11 Oct 2013 10:42:42 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwBNwgFQAAu9HOA= Date: Fri, 11 Oct 2013 14:42:42 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771F56FA@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771F56FAUS70UWXCHMBA05zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 16:44:48 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771F56FAUS70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, But isn't what you are describing elements of what would be considered the = "context" of the test result; which changes based on the test I would imagi= ne. Maybe that is all that is necessary is to flush out all the elements yo= u want to place in the context? BR, Tim From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Friday, October 11, 2013 4:08 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I think that cross-traffic should not be a simple Boolean, nor subsumed int= o a general 'suspect' parameter. It needs to be a counter such as bytes of traffic sent/received over the WA= N interface. The reason for this is that the level of traffic needs to be c= aptured to determine the impact on different tests and different results. T= he threshold will be varied depending on both the test that was running and= the analysis being performed. Furthermore it can also be used to determine the effectiveness of test back= -off procedures in the presence of user traffic and to analyse the impact t= he tests are having on user experience. Trevor. From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Car= ey, Timothy (Timothy) Sent: 09 October 2013 20:57 To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771F56FAUS70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

But isn’t what y= ou are describing elements of what would be considered the “context&#= 8221; of the test result; which changes based on the test I would imagine. = Maybe that is all that is necessary is to flush out all the elements you want to place in the context?

 

BR,<= /p>

Tim<= /p>

 

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Friday, October 11, 2013 4:08 AM
To: Carey, Timothy (Timothy); lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

I think= that cross-traffic should not be a simple Boolean, nor subsumed into a gen= eral ‘suspect’ parameter.

&n= bsp;

It need= s to be a counter such as bytes of traffic sent/received over the WAN inter= face. The reason for this is that the level of traffic needs to be captured= to determine the impact on different tests and different results. The threshold will be varied depending on bot= h the test that was running and the analysis being performed.

&n= bsp;

Further= more it can also be used to determine the effectiveness of test back-off pr= ocedures in the presence of user traffic and to analyse the impact the test= s are having on user experience.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 09 October 2013 20:57
To: lmap@ietf.org
Subject: [lmap] LMAP Information Model - BBF Questions and Comments<= o:p>

 

Hello,

 

During the 3Q2013 BBF meeting, the BBHome group had = an opportunity to review the LMAP information model.

I have tried to incorporate the comments and questio= ns here:

 

1)      It was unclear what the definition was for the Cros= sTraffic attribute.

Upon further discussion in the group we thought that= the CrossTraffic parameter was an indication that the Result of a measurem= ent might be suspect because there was other traffic detected by the measur= ement agent that might cause an invalid measurement.

 

If this is true – should we rename this attrib= ute to something like SuspectResult and type it as a Boolean?

 

I also suggest this description:

This parameter indicates if the measurement agent has determined th= at the result may be suspect. Events that cause a result to be suspect is specific to the implementation of the measurement agent b= ut may include events such as indications of other traffic or an unusual CP= U load that may interfere with test.

 

2)   = ;  In the Measurement Ag= ent there is an attribute supported measurements that is a list of entries = to the Registry

This seems fine; the group di= d ask for a clarification if a device could support more than one Measureme= nt Agent.

 

3)   = ;  When we reviewed the = Options for a Task we were not sure if this was something where each option= was a Name/Value pair that could be individually maintained or if they options should be maintained as a bulk list of Name/Value pairs= . What this would mean is if you wanted to add, edit or delete on option yo= u have to resend entire option list.

 

 

Thoughts?

 

Thanks,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F771F56FAUS70UWXCHMBA05zam_-- From dromasca@avaya.com Sun Oct 13 23:56:32 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F398811E815B for ; Sun, 13 Oct 2013 23:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.363 X-Spam-Level: X-Spam-Status: No, score=-103.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdGbAsClAT93 for ; Sun, 13 Oct 2013 23:56:26 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAFE11E812A for ; Sun, 13 Oct 2013 23:56:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmILADOUW1LGmAcV/2dsb2JhbABZgmYhOFKtDpRZgRoWbQeCJQEBAQEDAQEBDygxAxcGAQgNBAQBAQsLCQkuCxQHAQEFBQQTCAwBDYdkAQucBoRInD4XjgmBGD4EgxWBBAOUKIUMhTCLI4MkgXA5 X-IronPort-AV: E=Sophos;i="4.93,490,1378872000"; d="scan'208";a="31840537" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Oct 2013 02:56:21 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Oct 2013 02:52:11 -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.0146.000; Mon, 14 Oct 2013 08:56:20 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [OPS-AREA] NOMCOM 2013 - Need OPS Candidates Thread-Index: AQHOyG3MVRwTY/3WvUS5NTaCqVZnI5nzw7cg Date: Mon, 14 Oct 2013 06:56:19 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12906F4C@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] FW: [OPS-AREA] NOMCOM 2013 - Need OPS Candidates X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 06:56:32 -0000 A message from the NOMCOM chair. Please consider nominating candidates or v= olunteering.=20 Regards, Dan -----Original Message----- From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On Behal= f Of Allison Mankin Sent: Monday, October 14, 2013 2:42 AM To: Ops Area Subject: [OPS-AREA] NOMCOM 2013 - Need OPS Candidates Hi, OPS-area folks, We are very low on candidates for the OPS AD position. Even if you support= the present incumbent, there's a lot to be said for accepting a nomination= - you'll have learned about your company's willingness to support; you'll = have filled out the questionnaire, which I've always found to be a good opp= ortunity to think about one's area and about the IETF; and you'll have expe= rienced and contributed to the nomcom process overall, a key part of the IE= TF's culture. This process only works because many IETFers take part; pleas= e join in. Nominate yourself, or nominate someone whom you've observed working, someon= e who you think is showing leadership potential, someone who could be a gre= at AD. If there's someone who you think should be an AD in future, ask her= or him to consider accepting a nomination now. Deadline for nominations is October 18. Nominate soon to give your nominee(s) enough time to fill in the questionnaire, which is due October 2= 5. Lots more, including which positions are open, how to make a nomination (in= cluding nomination of yourself), and how to send us your feedback on the de= sired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with= me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now u= ntil October 18, 2013. The open positions being considered by this year's N= omcom can be found later in this section, and also on this year's Nomcom we= bsite: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the No= mcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatrack= er account. You can create a datatracker ietf.org account if you don't have= one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject= and indicate in the email who is being nominated, their email address (to = confirm acceptance of the nomination), and the position for which you are m= aking the nomination. If you use email, please use a separate email for eac= h person you nominate, and for each position (if you are nominating one per= son for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nomin= ees" described in RFC 5680. As stated in RFC 5680: "The list of nominees w= illing to be considered for positions under review in the current Nomcom cy= cle is not confidential". Willing nominees for each position will be listed= in a publicly accessible way - anyone with a datatracker account may acces= s the lists. In all other ways, the confidentiality requirements of RFC 37= 77/BCP10 remain in effect. All feedback and all Nomcom deliberations will = remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each= of the willing nominees, nominations must be received by the Nomcom on or = before October 18, 2013. Please submit your nominations as early as possib= le for the sake of your nominees, as we've set the questionnaire submission= deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeti= ng, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart B= ryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these position= s, as developing our talent is a very crucial requirement for the IETF. Al= so, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the = respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positio= ns themselves. We need and welcome the community's views and input on the = jobs within each organization. If you have ideas on the positions' responsi= bilities (more, less, different), please let us know. You can send us emai= l about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interestin= g nominees! _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From dromasca@avaya.com Wed Oct 16 02:46:05 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E73911E8123 for ; Wed, 16 Oct 2013 02:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.874 X-Spam-Level: X-Spam-Status: No, score=-102.874 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoFwkONcarrg for ; Wed, 16 Oct 2013 02:45:59 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 60B8511E811A for ; Wed, 16 Oct 2013 02:45:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYNAK1fXlKHCzI1/2dsb2JhbABagmYhOFKDKaoClGIYgQkWbQeCJQEBAQEDEhERMwcFEgYBCA0EAQIBAQEDAgYdAwIEMBQBAgQBAQUFBAoJCBqHZAELnGmESIo+kkEXgSmMVAsKgQ4GECQCAoJkNYEGA5kzhTCLI4FmgT6BZwkXIg X-IronPort-AV: E=Sophos;i="4.93,506,1378872000"; d="scan'208";a="32710204" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 16 Oct 2013 05:45:57 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Oct 2013 05:36:44 -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.0146.000; Wed, 16 Oct 2013 11:45:56 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: New Liaison Statement, "Performance Measurement Liaison Response to Broadband Forum" Thread-Index: AQHOyehHLW3zJXn6JUyKgGSwYhfxrpn3FRRA Date: Wed, 16 Oct 2013 09:45:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1290A5C3@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [lmap] FW: New Liaison Statement, "Performance Measurement Liaison Response to Broadband Forum" X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:46:05 -0000 DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGlhaXNvbiBTdGF0ZW1l bnQgTWFuYWdlbWVudCBUb29sIFttYWlsdG86bHNtdEBpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5 LCBPY3RvYmVyIDE1LCAyMDEzIDExOjUwIFBNDQpUbzogQ2hyaXN0b3BoZSBBbHRlcg0KQ2M6IEph c29uIFdlaWw7IEJyaWFuIFRyYW1tZWxsOyBCaWxsIENlcnZlbnk7IFJheSBCZWxsaXM7IE1hcmsg VG93bnNsZXk7IFNhcmFoIEJhbmtzOyBBbCBNb3J0b247IEdvbnphbG8gQ2FtYXJpbGxvOyBSb21h c2NhbnUsIERhbiAoRGFuKTsgQ2hyaXN0b3BoZSBBbHRlciBUZWNobmljYWwgQ29tbWl0dGVlIENo YWlyIEJyb2FkYmFuZCBGb3J1bTsgQmVub2l0IENsYWlzZTsgSm9lbCBKYWVnZ2xpOyBEYXZpZCBT aW5pY3JvcGUgSUVURi9Ccm9hZGJhbmQgRm9ydW0gTGlhaXNvbiBNYW5hZ2VyOyBSb3NzIENhbGxv bjsgSmFyaSBBcmtrbyBJRVRGIENoYWlyOyBSb2JpbiBNZXJzaCBCcm9hZGJhbmQgRm9ydW0gQ0VP OyBHYWJyaWVsbGUgQmluZ2hhbSBCcm9hZGJhbmQgRm9ydW0gU2VjcmV0YXJpYXQ7IEphc29uIFdh bGxzIEJyb2FkYmFuZCBIb21lIFdvcmtpbmcgR3JvdXAgQ28tQ2hhaXI7IEpvaG4gQmxhY2tmb3Jk IEJyb2FkYmFuZCBIb21lIFdvcmtpbmcgR3JvdXAgQ28tQ2hhaXI7IERhdmUgVGhvcm5lIEJyb2Fk YmFuZCBGb3J1bSBFMkUgQXJjaGl0ZWN0dXJlIFdHIENoYWlyOyBEYXZlIEFsbGFuIEJyb2FkYmFu ZCBGb3J1bSBFMkUgQXJjaGl0ZWN0dXJlIFdHIENoYWlyOyBTdmVuIE9vZ2hlIEJyb2FkYmFuZCBG b3J1bSBFMkUgQXJjaGl0ZWN0dXJlIFdHIFZpY2UgQ2hhaXI7IFBldGVyIEFkYW1zIEJyb2FkYmFu ZCBGb3J1bSBPcGVyYXRpb25zIGFuZCBOZXR3b3JrIE1hbmFnZW1lbnQgV0cgQ2hhaXI7IEphc29u IFdlaWw7IERhdmlkIFNpbmljcm9wZQ0KU3ViamVjdDogTmV3IExpYWlzb24gU3RhdGVtZW50LCAi UGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgTGlhaXNvbiBSZXNwb25zZSB0byBCcm9hZGJhbmQgRm9y dW0iDQoNClRpdGxlOiBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBMaWFpc29uIFJlc3BvbnNlIHRv IEJyb2FkYmFuZCBGb3J1bSBTdWJtaXNzaW9uIERhdGU6IDIwMTMtMTAtMTUgVVJMIG9mIHRoZSBJ RVRGIFdlYiBwYWdlOiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjg2Lw0K DQpGcm9tOiBUaGUgSUVURiAoSmFyaSBBcmtrbyA8RGF2aWQgU2luaWNyb3BlIDxkYXZpZC5zaW5p Y3JvcGVAZXJpY3Nzb24uY29tPj4pDQpUbzogQnJvYWRiYW5kIEZvcnVtIChDaHJpc3RvcGhlIEFs dGVyIDxjaHJpc3RvcGhlLmFsdGVyQG9yYW5nZS5jb20+KQ0KQ2M6IEphc29uIFdlaWwgPGphc29u LndlaWxAdHdjYWJsZS5jb20+LEJyaWFuIFRyYW1tZWxsICA8dHJhbW1lbGxAdGlrLmVlLmV0aHou Y2g+LEJpbGwgQ2VydmVueSA8YmlsbEB3amNlcnZlbnkuY29tPixSYXkgQmVsbGlzIDxtYXJrQHRv d25zbGV5Lm5ldD4sTWFyayBUb3duc2xleSA8cmF5LmJlbGxpc0Bub21pbmV0Lm9yZy51az4sU2Fy YWggQmFua3MgPHNiYW5rc0BhZXJvaGl2ZS5jb20+LEFsIE1vcnRvbiA8YWNtb3J0b25AYXR0LmNv bT4sR29uemFsbyBDYW1hcmlsbG8gPGdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNvbT4sRGFu IFJvbWFzY2FudSA8ZHJvbWFzY2FAYXZheWEuY29tPixDaHJpc3RvcGhlIEFsdGVyIFRlY2huaWNh bCBDb21taXR0ZWUgQ2hhaXIgQnJvYWRiYW5kIEZvcnVtIDxjaHJpc3RvcGhlLmFsdGVyQG9yYW5n ZS5jb20+LEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPixKb2VsIEphZWdnbGkgPGpv ZWxqYUBib2d1cy5jb20+LERhdmlkIFNpbmljcm9wZSBJRVRGL0Jyb2FkYmFuZCBGb3J1bSBMaWFp c29uIE1hbmFnZXIgPGRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb20+LFJvc3MgQ2FsbG9uIDxy Y2FsbG9uQGp1bmlwZXIubmV0PixKYXJpIEFya2tvIElFVEYgQ2hhaXIgPGphcmkuYXJra29AcGl1 aGEubmV0PixSb2JpbiBNZXJzaCBCcm9hZGJhbmQgRm9ydW0gQ0VPIDxybWVyc2hAYnJvYWRiYW5k LWZvcnVtLm9yZz4sR2FicmllbGxlIEJpbmdoYW0gQnJvYWRiYW5kIEZvcnVtIFNlY3JldGFyaWF0 IDxnYmluZ2hhbUBicm9hZGJhbmQtZm9ydW0ub3JnPixKYXNvbiBXYWxscyBCcm9hZGJhbmQgSG9t ZSBXb3JraW5nIEdyb3VwIENvLUNoYWlyIDxqYXNvbkBxYWNhZmUuY29tPixKb2huIEJsYWNrZm9y ZCBCcm9hZGJhbmQgSG9tZSBXb3JraW5nIEdyb3VwIENvLUNoYWlyIDxqb2huLmJsYWNrZm9yZEBw YWNlLmNvbT4sRGF2ZSBUaG9ybmUgQnJvYWRiYW5kIEZvcnVtIEUyRSBBcmNoaXRlY3R1cmUgV0cg Q2hhaXIgPGRhdmlkLmoudGhvcm5lQGJ0LmNvbT4sRGF2ZSBBbGxhbiBCcm9hZGJhbmQgRm9ydW0g RTJFIEFyY2hpdGVjdHVyZSBXRyBDaGFpciA8ZGF2aWQuaS5hbGxhbkBlcmljc3Nvbi5jb20+LFN2 ZW4gT29naGUgQnJvYWRiYW5kIEZvcnVtIEUyRSBBcmNoaXRlY3R1cmUgV0cgVmljZSBDaGFpciA8 c3Zlbi5vb2doZUBhbGNhdGVsLWx1Y2VudC5jb20+LFBldGVyIEFkYW1zIEJyb2FkYmFuZCBGb3J1 bSBPcGVyYXRpb25zIGFuZCBOZXR3b3JrIE1hbmFnZW1lbnQgV0cgQ2hhaXIgPHBldGVyLmFkYW1z QGFkdHJhbi5jb20+IFJlcG9uc2UgQ29udGFjdDogRGF2aWQgU2luaWNyb3BlIDxkYXZpZC5zaW5p Y3JvcGVAZXJpY3Nzb24uY29tPiBUZWNobmljYWwgQ29udGFjdDogSmFzb24gV2VpbCA8amFzb24u d2VpbEB0d2NhYmxlLmNvbT4NClB1cnBvc2U6IEluIHJlc3BvbnNlDQoNCkJvZHk6IERhdGU6IE9j dG9iZXIgMTUsIDIwMTMNCg0KVG86IA0KQ2hyaXN0b3BoZSBBbHRlciwgVGVjaG5pY2FsIENvbW1p dHRlZSBDaGFpciwgQnJvYWRiYW5kIEZvcnVtIChjaHJpc3RvcGhlLmFsdGVyQG9yYW5nZS5jb20p DQogDQpGcm9tOiANCkRhbiBSb21hc2NhbnUsIElFVEYgTGFyZ2UtU2NhbGUgTWVhc3VyZW1lbnQg b2YgQnJvYWRiYW5kIFBlcmZvcm1hbmNlIFdHIENoYWlyIChkcm9tYXNjYUBhdmF5YS5jb20pIEph c29uIFdlaWwsIElFVEYgTGFyZ2UtU2NhbGUgTWVhc3VyZW1lbnQgb2YgQnJvYWRiYW5kIFBlcmZv cm1hbmNlIFdHIENoYWlyIChqYXNvbi53ZWlsQHR3Y2FibGUuY29tKSBCcmlhbiBUcmFtbWVsbCwg SUVURiBJUCBQZXJmb3JtYW5jZSBNZXRyaWNzIFdHIENoYWlyICh0cmFtbWVsbEB0aWsuZWUuZXRo ei5jaCkgQmlsbCBDZXJ2ZW55LCBJRVRGIElQIFBlcmZvcm1hbmNlIE1ldHJpY3MgV0cgQ2hhaXIg KGJpbGxAd2pjZXJ2ZW55LmNvbSkgUmF5IEJlbGxpcywgSUVURiBIb21lIE5ldHdvcmtpbmcgV0cg Q2hhaXIgKHJheS5iZWxsaXNAbm9taW5ldC5vcmcudWspIE1hcmsgVG93bnNsZXksIElFVEYgSG9t ZSBOZXR3b3JraW5nIFdHIENoYWlyIChtYXJrQHRvd25zbGV5Lm5ldCkgU2FyYWggQmFua3MsIElF VEYgQmVuY2htYXJraW5nIE1ldGhvZG9sb2d5IFdHIENoYWlyIChzYmFua3NAYWVyb2hpdmUuY29t KSBBbCBNb3J0b24sIElFVEYgQmVuY2htYXJraW5nIE1ldGhvZG9sb2d5IFdHIENoYWlyIChhY21v cnRvbkBhdHQuY29tKQ0KDQpDQzoNCkRhdmlkIFNpbmljcm9wZSwgSUVURi9Ccm9hZGJhbmQgRm9y dW0gTGlhaXNvbiBNYW5hZ2VyIChkYXZpZC5zaW5pY3JvcGVAZXJpY3Nzb24uY29tKSBSb3NzIENh bGxvbiwgSUVURiBJbnRlcm5ldCBBcmNoaXRlY3R1cmUgQm9hcmQgKHJjYWxsb25AanVuaXBlci5u ZXQpIEphcmkgQXJra28sIElFVEYgQ2hhaXIgKGphcmkuYXJra29AcGl1aGEubmV0KSBSb2JpbiBN ZXJzaCwgQnJvYWRiYW5kIEZvcnVtIENFTyAocm1lcnNoQGJyb2FkYmFuZC1mb3J1bS5vcmcpIEdh YnJpZWxsZSBCaW5naGFtLCBCcm9hZGJhbmQgRm9ydW0gU2VjcmV0YXJpYXQgKGdiaW5naGFtQGJy b2FkYmFuZC1mb3J1bS5vcmcpIEphc29uIFdhbGxzLCBCcm9hZGJhbmQgSG9tZSBXb3JraW5nIEdy b3VwIENvLUNoYWlyIChqYXNvbkBxYWNhZmUuY29tKSBKb2huIEJsYWNrZm9yZCwgQnJvYWRiYW5k IEhvbWUgV29ya2luZyBHcm91cCBDby1DaGFpciAoam9obi5ibGFja2ZvcmRAcGFjZS5jb20pIERh dmUgVGhvcm5lLCBCcm9hZGJhbmQgRm9ydW0gRTJFIEFyY2hpdGVjdHVyZSBXRyBDaGFpciAoZGF2 aWQuai50aG9ybmVAYnQuY29tKSBEYXZlIEFsbGFuLCBCcm9hZGJhbmQgRm9ydW0gRTJFIEFyY2hp dGVjdHVyZSBXRyBDaGFpciAoZGF2aWQuaS5hbGxhbkBlcmljc3Nvbi5jb20pIFN2ZW4gT29naGUs IEJyb2FkYmFuZCBGb3J1bSBFMkUgQXJjaGl0ZWN0dXJlIFdHIFZpY2UgQ2hhaXIgKHN2ZW4ub29n aGVAYWxjYXRlbC1sdWNlbnQuY29tKSBQZXRlciBBZGFtcywgQnJvYWRiYW5kIEZvcnVtIE9wZXJh dGlvbnMgYW5kIE5ldHdvcmsgTWFuYWdlbWVudCBXRyBDaGFpciAocGV0ZXIuYWRhbXNAYWR0cmFu LmNvbSkgDQoNCg0KDQpUaGFuay15b3UgZm9yIHlvdXIgbGlhaXNvbnMgbGlzdGVkIGJlbG93IGFu ZCBrZWVwaW5nIHRoZSBJRVRGIGluIG1pbmQgd2hpbGUgZGV2ZWxvcGluZyB3b3JrIHdvcmsgb24g QnJvYWRiYW5kIEZvcnVtdihCQkYpIFdULTMwNCBCcm9hZGJhbmQgQWNjZXNzIFNlcnZpY2UgQXR0 cmlidXRlcyBhbmQgUGVyZm9ybWFuY2UgTWV0cmljcy4gIA0KIA0KQkJGIExpYWlzb25zIHRvIGRh dGU6DQpNYXIgMjAxMyAtIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjQz LyAgdG8gSUVURiBDaGFpciBhbmQgSUVTRyBEZWMgMjAxMiAtIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbGlhaXNvbi8xMjIxLyAgdG8gSVBQTSBjaGFpcnMgYW5kIFRyYW5zcG9ydCBhbmQg T3BzIEFEcyBTZXAgMjAxMiAtIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8x MTg1LyAgdG8gSUVURiBDaGFpciBhbmQgSUVTRyBBdWcgMjAxMiAtIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMTc5LyAgdG8gT3BzIEFyZWEgRGlyZWN0b3JzDQogDQogDQpU aGFuayB5b3UgYWxzbyBmb3IgeW91ciBwYXRpZW5jZS4gIFdoaWxlIHRoZXJlIGhhcyBiZWVuIHNp Z25pZmljYW50IGludGVyZXN0IGluIGxhcmdlLXNjYWxlIG1lYXN1cmVtZW50IG9mIEJyb2FkYmFu ZCBwZXJmb3JtYW5jZSwgZm9ybWFsIElFVEYgd29ya2luZyBncm91cHMgdG8gYWRkcmVzcyBtYWpv ciBjb21wb25lbnRzIG9mIHRoaXMgdG9waWMgaGFkIG5vdCBiZWVuIGNoYXJ0ZXJlZCB1bnRpbCB0 aGlzIHN1bW1lci4gIE5vdyB0aGF0IHRoZSBJUFBNIFdHIGhhcyBiZWVuIHJlLWNoYXJ0ZXJlZCAo dG8gY29uc2lkZXIgbWVhc3VyZW1lbnQgbWV0aG9kcyBhcHByb3ByaWF0ZSBmb3IgbGFyZ2Utc2Nh bGUgbWVhc3VyZW1lbnRzKSBhbmQgdGhlIExNQVAgV0cgZm9ybWVkICh0byBjb25zaWRlciB0aGUg YXJjaGl0ZWN0dXJhbCBmcmFtZXdvcmsgYW5kIG9wZXJhdGlvbmFsIGNvbXBvbmVudHMpLCBib3Ro IGdyb3VwcyBsb29rIGZvcndhcmQgdG8gY29tbXVuaWNhdGluZyB3aXRoIHRoZSBCQkYgb24gdGhp cyBzdWJqZWN0Lg0KIA0KSW4gYWRkaXRpb24gdG8gTE1BUCBhbmQgSVBQTSwgeW91IG1heSBhbHNv IHdhbnQgdG8gY29uc2lkZXIgQk1XRyBhbmQgSG9tZW5ldCBmb3Igc29tZSBvZiB5b3VyIFdULTMw NCBlZmZvcnRzLiAgUGxlYXNlIHNlZSB0aGUgbGlua3MgYmVsb3cgZm9yIGFsbCBvZiB0aGVzZSB3 b3JraW5nIGdyb3Vwc+KAmSBjaGFydGVycywgc2NvcGUgYW5kIHdvcmsgcGxhbnMuDQogDQpMTUFQ IChPcHMgYW5kIE1nbXQgQXJlYSkgLSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2xt YXAvY2hhcnRlci8NCklQUE0gKFRyYW5zcG9ydCBBcmVhKSAtIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvd2cvaXBwbS9jaGFydGVyLw0KQk1XRyAoT3BzIGFuZCBNZ210IEFyZWEpIC0gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9ibXdnL2NoYXJ0ZXIvDQpIb21lTmV0IChJbnRl cm5ldCBBcmVhKSAtIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvaG9tZW5ldC9jaGFy dGVyLyANCiANCldlIG5vdGUgdGhhdCB5b3Ugd291bGQgbGlrZSB0byByZWZlcmVuY2UgSUVURiBw cm90b2NvbHMgYW5kIHdvcmsgdG8gc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnRzIG9mIHlvdXIgYXJj aGl0ZWN0dXJlLiAgV2UgYmVsaWV2ZSB0aGlzIGlzIGEgZ29vZCBkaXZpc2lvbiBvZiB3b3JrIGFu ZCBzY29wZSBhbmQgd291bGQgYmUgaGFwcHkgdG8gY29vcGVyYXRlIGFsb25nIHRoZXNlIGxpbmVz LiAgV2UgZW5jb3VyYWdlIHNwZWNpZmljIGNvbW11bmljYXRpb24gd2l0aCBlYWNoIG9mIHRoZSBp bmRpdmlkdWFsIHdvcmtpbmcgZ3JvdXBzIHZpYSB0aGVpciBDaGFpcnMgYWxvbmcgdGhlIGxpbmVz IG9mIHRoZWlyIGNoYXJ0ZXJzLiAgRm9yIHRvcGljcyB0aGF0IGNyb3NzIG9uZSBvciBtb3JlIFdH cywgcGxlYXNlIGFkZHJlc3MgdGhlIGxpYWlzb24gdG8gdGhlIENoYWlycyBvZiBhbGwgb2YgdGhl IHJlbGV2YW50IHdvcmtpbmcgZ3JvdXBzIGFuZCB0aGUgbGlhaXNvbiBtYW5hZ2VyIGZyb20gdGhl IElFVEYgd2hvIHdpbGwgaGVscCBkaXJlY3QgdGhlIGxpYWlzb24gdG8gdGhlIGFwcHJvcHJpYXRl IFdHIG9yIElFVEYgYXV0aG9yaXR5Lg0KIA0KVGhlIExNQVAgV0cgaXMgcmV2aWV3aW5nIHlvdXIg TWFyY2ggMjAxMyBMaWFpc29uIGFuZCBub3RlcyB0aGUgZm9sbG93aW5nIHJlcXVlc3RzIGZvciBp bmZvcm1hdGlvbjoNCkZlZWRiYWNrIG9uIHRoZSB1c2Ugb2YgU0lQIHRvIHByb3ZpZGUgYW4gaW50 ZXIgYW5kIGludHJhIGRvbWFpbiBtZWNoYW5pc20gdG8gcHJvYmUgdGVzdCB0YXJnZXQgcmVzb3Vy Y2UgYXZhaWxhYmlsaXR5LiANCkNvbW1lbnRzIG9uIHRoZSB1c2Ugb2YgRE5TLVNEKFJGQzY3NjMp IGFuZCBtRE5TIChSRkM2NzYyKSB0byBzdXBwb3J0IEJCRidzIHNlcnZpY2UgYXR0cmlidXRlIGNv bW11bmljYXRpb24uICAgDQpJbmZvcm1hdGlvbiBtb2RlbCBkZXZlbG9wbWVudCBmb3IgdGVzdCBh bmQgcmVwb3J0IHBhcmFtZXRlcnMgDQoNCkxNQVAgV0cgUmVzcG9uc2U6DQogDQpUaGUgTE1BUCBX RyB3YXMgZm9ybWVkIGluIEp1bmUgYW5kIGhlbGQgaXRzIGZpcnN0IG1lZXRpbmcgaW4gSnVseSBv ZiB0aGlzIHllYXIuIEZvbGxvd2luZyB0aGUgZ29hbHMgYW5kIG1pbGVzdG9uZXMgYXMgb3V0bGlu ZWQgaW4gdGhlIFdHIENoYXJ0ZXIgdGhhdCBjYW4gYmUgZm91bmQgaW4gdGhlIGFib3ZlIGxpbmss IHRoZSBXRyB3aWxsIGJlIGZvY3Vzc2VkIG9uIGZpbmFsaXppbmcgVXNlIENhc2UgYW5kIEZyYW1l d29yayBkb2N1bWVudHMgYW5kIHRoZW4gYmVnaW5uaW5nIHdvcmsgb24gdGhlIEluZm9ybWF0aW9u IE1vZGVsIGRvY3VtZW50LiBUaGUgSW5mb3JtYXRpb24gTW9kZWwgd2FzIG1lbnRpb25lZCBhcyBh biBhcmVhIG9mIGludGVyZXN0IGJ5IHRoZSBCQkYgaW4gdGhlIE1hcmNoIExpYWlzb24uIFRoZSBM TUFQIFdHIHdvdWxkIHdlbGNvbWUgaW5wdXQgZnJvbSB0aGUgQkJGIGFzIGl0IGJlZ2lucyB3b3Jr IG9uIHRoZSBJbmZvcm1hdGlvbiBNb2RlbCBkb2N1bWVudC4gRm9yIHJlZmVyZW5jZSwgdGhlIElu Zm9ybWF0aW9uYWwgTW9kZWwgc2NvcGUgYXMgZGVzY3JpYmVkIGluIHRoZSBMTUFQIFdHIENoYXJ0 ZXIgaXMgaW5jbHVkZWQgZm9yIHJlZmVyZW5jZTogDQpJbmZvcm1hdGlvbiBNb2RlbCwgdGhlIGFi c3RyYWN0IGRlZmluaXRpb24gb2YgdGhlIGluZm9ybWF0aW9uIGNhcnJpZWQgZnJvbSB0aGUgQ29u dHJvbGxlciB0byB0aGUgTUEgYW5kIHRoZSBpbmZvcm1hdGlvbiBjYXJyaWVkIGZyb20gdGhlIE1B IHRvIHRoZSBDb2xsZWN0b3IuIEl0IGluY2x1ZGVzDQogICAqIFRoZSBtZXRyaWMocykgdGhhdCBj YW4gYmUgbWVhc3VyZWQgYW5kIHZhbHVlcyBmb3IgaXRzIHBhcmFtZXRlcnMgc3VjaCBhcyB0aGUg UGVlciBNQSBwYXJ0aWNpcGF0aW5nIGluIHRoZSBtZWFzdXJlbWVudCBhbmQgdGhlIGRlc2lyZWQg ZW52aXJvbm1lbnRhbCBjb25kaXRpb25zIChmb3IgZXhhbXBsZSwgb25seSBjb25kdWN0IHRoZSBt ZWFzdXJlbWVudCB3aGVuIHRoZXJlIGlzIG5vIHVzZXIgdHJhZmZpYyBvYnNlcnZlZCkNCiAgICog VGhlIHNjaGVkdWxlOiB3aGVuIHRoZSBtZWFzdXJlbWVudCBzaG91bGQgYmUgcnVuIGFuZCBob3cg dGhlIHJlc3VsdHMgc2hvdWxkIGJlIHJlcG9ydGVkICh3aGVuIGFuZCB0byB3aGljaCBDb2xsZWN0 b3IpDQogICAqIFRoZSByZXBvcnQ6IHRoZSBtZXRyaWMocykgbWVhc3VyZWQgYW5kIHdoZW4sIHRo ZSBhY3R1YWwgcmVzdWx0LCBhbmQgc3VwcG9ydGluZyBtZXRhZGF0YSBzdWNoIGFzIGxvY2F0aW9u LiBSZXN1bHQgcmVwb3J0cyBtYXkgYmUgb3JnYW5pemVkIGluIGJhdGNoZXMgb3IgbWF5IGJlIHJl cG9ydGVkIGltbWVkaWF0ZWx5LCBzdWNoIGFzIGZvciBhbiBvbi1kZW1hbmQgbWVhc3VyZW1lbnQu DQpJbiByZWdhcmRzIHRvIGludGVyZXN0IG9mIHVzaW5nIEROUy1TRCBhbmQgbUROUyBpbiBzdXBw b3J0IG9mIHNlcnZpY2UgYXR0cmlidXRlIGNvbW11bmljYXRpb24gYmV0d2VlbiBkZXZpY2VzIHdp dGhpbiB0aGUgaG9tZSBuZXR3b3JrLCB0aGUgTE1BUCBXRyB3b3VsZCBkZWZlciB0aGlzIHF1ZXN0 aW9uIGFuZCBwb3NzaWJsZSBmdXJ0aGVyIGFuYWx5c2lzIHRvIHdvcmsgdGhhdCBpcyB0YWtpbmcg cGxhY2UgaW4gdGhlIEhvbWVuZXQgV0cuIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGN1cnJlbnRs eSB0aGUgbUROUyBQcm90b2NvbCBpcyBjb25zdHJhaW5lZCB0byBhIHNpbmdsZSBsaW5rIGJhc2Vk IG9uIGl0cyB1c2Ugb2YgbGluay1sb2NhbCBtdWx0aWNhc3QuIElmIHRoZSBCQkYgd291bGQgYmUg aW50ZXJlc3RlZCBpbiB0aGUgdXNlIG9mIG1ETlMgYW5kIEROUy1TRCBpbiBhIG11bHRpLXNlZ21l bnRlZCBob21lIG5ldHdvcmssIHRoaXMgd291bGQgcmVxdWlyZSBuZXcgd29yayB0byB0aG9zZSBw cm90b2NvbHMgdGhhdCBpcyBiZWluZyBkaXNjdXNzZWQgYXMgcGFydCBvZiBhIG5ldyBXb3JraW5n IEdyb3VwLiBEaXNjdXNzaW9uIG9mIHRoYXQgV0cgY2hhcnRlciBsYW5ndWFnZSBpcyBjdXJyZW50 bHkgdGFraW5nIHBsYWNlLg0KIA0KSW4gcmVnYXJkcyB0byB0aGUgdXNlIG9mIFNJUCBhcyBhIGlu dGVyLWRvbWFpbiBhbmQvb3IgaW50cmEtZG9tYWluIG1lY2hhbmlzbSBmb3IgdGhlIGRpc2NvdmVy eSBvZiB0ZXN0IHRhcmdldCAoTWVhc3VyZW1lbnQgUGVlciBpbiBMTUFQIHRlcm1pbm9sb2d5KSBh dmFpbGFiaWxpdHksIHRoaXMgcG9pbnQgcmVwcmVzZW50cyBjb21tdW5pY2F0aW9uIHRoYXQgd291 bGQgdGFrZSBwbGFjZSBiZXR3ZWVuIGEgTWVhc3VyZW1lbnQgQWdlbnQgYW5kIGEgTWVhc3VyZW1l bnQgUGVlci4gQ29tbXVuaWNhdGlvbiByZXF1aXJlbWVudHMgYXMgcGFydCBvZiBhIHRlc3QgYmV0 d2VlbiBhIE1BIGFuZCBpdHMgbWVhc3VyZW1lbnQgdGFyZ2V0IChNZWFzdXJlbWVudCBQZWVyKSBp cyBjdXJyZW50bHkgbm90IGluY2x1ZGVkIGFzIG9uZSBvZiB0aGUgd29yayBpdGVtcyBwZXIgdGhl IExNQVAgY2hhcnRlciBidXQgbWF5IGJlIGEgdG9waWMgb2YgZGlzY3Vzc2lvbiBmb3IgZnV0dXJl IHdvcmsuDQogDQpJUFBNIFdHIFJlc3BvbnNlOiAgDQogDQpQbGVhc2UgYmUgYWR2aXNlZCB0aGF0 IHRoZSBJUFBNIFdHIGhhcyBjb25zaWRlcmVkIHVwZGF0ZXMgdG8gUkZDIDI2ODAgYW5kIDI2ODEg aW4gdGhlaXIgTWFyY2ggMjAxMyByZWNoYXJ0ZXJpbmcsIGJ1dCB0aGVzZSBoYXZlIGJlZW4gZGVm ZXJyZWQgdW50aWwgaXQgaXMgY2xlYXIgd2hhdCBpbXBhY3QgdGhlIGVmZm9ydCB0byB1cGRhdGUg dGhlIGZyYW1ld29yayAoMjMzMCkgYW5kIHRoZSBlZmZvcnQgdG8gZGVmaW5lIGEgcmVnaXN0cnkg b24gdGhlIE1hcmNoIDIwMTMgY2hhcnRlciB3aWxsIGhhdmUgb24gdGhlc2UgdXBkYXRlcy4gSVBQ TSBleHBlY3RzIHRoYXQgdGhlIHJlc3VsdCB3aWxsIGJlIGNvbXBhdGlibGUgd2l0aCAyNjgwIGFu ZCAyNjgxLCBhbmQgYXMgc3VjaCBkZXZlbG9wbWVudHMgYmFzZWQgb24gdGhlc2UgUkZDcyBtYXkg Y29udGludWUgYXMgdGhleSBhcmUuDQogDQpNYW55IG9mIHRoZSBpc3N1ZXMgd2l0aCAzMTQ4IHJh aXNlZCBpbiBRdWVzdGlvbiAxIG9mIHRoZSBEZWNlbWJlciAyMDEyIEJCRiBsaWFpc29uIG1heSBi ZSBhZGRyZXNzZWQgYnkgZHJhZnQtaWV0Zi1pcHBtLW1vZGVsLWJhc2VkLW1ldHJpY3MtMDAsIG9u IHdoaWNoIHdvcmsgaXMgcHJvZ3Jlc3NpbmcgdW5kZXIgdGhlaXIgY3VycmVudCBjaGFydGVyOyBk aXNjdXNzaW9uIG9mIGlzc3VlcyB3aXRoIGJ1bGsgY2FwYWNpdHkgbWVhc3VyZW1lbnQgbm90IGFk ZHJlc3NlZCB0aGVyZWluIGlzIHdlbGNvbWUgb24gdGhlIGlwcG1AaWV0Zi5vcmcgbWFpbGluZyBs aXN0Lg0KIA0KV2l0aCByZXNwZWN0IHRvIHRoZSByZW1haW5pbmcgb3V0c3RhbmRpbmcgcXVlc3Rp b25zLCB0aGUgSVBQTSBXRyB3aWxsIHRha2UgdGhlbSBhcyBpbmZvcm1hdGlvbiB0aGF0IEJCRiBp cyBjb25zaWRlcmluZyB0aGUgdXNlIG9mIDMzOTMgYW5kIDYzNDkgYXMgd2VsbDsgSVBQTSBpcyBu b3QgY29uc2lkZXJpbmcgdXBkYXRlcyB0byB0aGVzZSBhdCB0aGlzIHRpbWUsIHNvIHRoZXkgcmVt YWluIGEgc3RhYmxlIGJhc2lzIGZvciBmdXJ0aGVyIHdvcmssIG5vdGluZyBhZ2FpbiBpbiB0aGUg bGF0dGVyIGNhc2UgdGhhdCBkcmFmdC1pZXRmLWlwcG0tbW9kZWwtYmFzZWQtbWV0cmljcy0wMCBh aW1zIHRvIGFkZHJlc3MgaXNzdWVzIGluIHVzaW5nIFRDUCB0byBtZWFzdXJlIFRDUCBidWxrIHRy YW5zZmVyIGNhcGFjaXR5Lg0KIA0KSVBQTSB1bmRlcnN0YW5kcyBmcm9tIFF1ZXN0aW9uIDYgdGhh dCAnbW92aW5nIHVwIHRoZSBzdGFjaycsIGxvb2tpbmcgc3BlY2lmaWNhbGx5IGF0IFZvSVAsIHN0 cmVhbWluZyB2aWRlbywgYW5kIEROUyByZXNvbHV0aW9uIHRpbWUsIGFyZSBvZiBpbnRlcmVzdCB0 byBCQkYuIElQUE0gaXMgbm90IGN1cnJlbnRseSB3b3JraW5nIG9uIG1ldHJpY3MgaW4gdGhpcyBh cmVhLCBidXQgd291bGQgY2VydGFpbmx5IGNvbnNpZGVyIGNvbnRyaWJ1dGlvbnMgdGhlcmVvbiB1 bmRlciBpdHMgY3VycmVudCBjaGFydGVyLCBhbmQgaGF2ZSByZXZpZXdlZCBhdCBsZWFzdCBvbmUg aW5kaXZpZHVhbCBkcmFmdCBvbiBidWZmZXJlZCBzdHJlYW1pbmcgdmlkZW8gcGVyZm9ybWFuY2Ug ZHVyaW5nIHRoZSBjaGFydGVyaW5nIGRpc2N1c3Npb25zIGluIE1hcmNoIDIwMTMuDQogDQpBcyBm b3IgdGhlIGdlbmVyYWwgbGluZSBvZiB0aGVzZSBxdWVzdGlvbnMgKGVzcGVjaWFsbHkgNiksIHBs ZWFzZSBub3RlIHRoZSBvbmdvaW5nIHJlZ2lzdHJ5IGVmZm9ydCBvbiB0aGUgSVBQTSBjaGFydGVy LiBUaGVyZSBhcmUgdGhyZWUgaW5kaXZpZHVhbCBkcmFmdHM6IGRyYWZ0LWJhZ251bG8taXBwbS1u ZXctcmVnaXN0cnksIGRyYWZ0LWJhZ251bG8taXBwbS1uZXctcmVnaXN0cnktaW5kZXBlbmRlbnQs IGFuZCBkcmFmdC1jbGFpc2UtaXBwbS1wZXJmLW1ldHJpYy1yZWdpc3RyeS4gVGhlIGF1dGhvcnMg YXJlIGN1cnJlbnRseSB3b3JraW5nIG9uIGEgdW5pZmllZCBhcHByb2FjaCB0byBhIHBlcmZvcm1h bmNlIG1ldHJpY3MgcmVnaXN0cnksIHdpdGggdGhlIGludGVudGlvbiB0aGF0IHRoZSBvdXRjb21l IGJlIGFkb3B0ZWQgZm9yIGZ1cnRoZXIgZGV2ZWxvcG1lbnQgd2l0aGluIHRoZSBJUFBNIFdHLiBU aGlzIHJlZ2lzdHJ5IHdpbGwgYmUgcG9wdWxhdGVkIHdpdGggcmVjb21tZW5kZWQgbWV0cmljcyBm b3IgTE1BUCB1c2UgY2FzZXMsIHdoaWNoIHdvdWxkIHJlcHJlc2VudCBhIGNvbnNlbnN1cyBzdGF0 ZW1lbnQgZnJvbSBJUFBNIG9uIHRoZSBtZXRyaWNzIElQUE0gY29uc2lkZXIgdXNlZnVsIGluIHRo aXMgYXJlYS4gV29yayBpbiB0aGlzIGFyZWEgaXMgb25nb2luZywgYW5kIHdlIHdlbGNvbWUgY29t bWVudGFyeSBvbiB0aGUgaXBwbUBpZXRmLm9yZyBsaXN0IG9uY2UgdGhlIHVuaWZpZWQgcmVnaXN0 cnkgZG9jdW1lbnQgaXMgcHVibGlzaGVkLg0KIA0KV2Ugbm90ZWQgdGhhdCB0aGVyZSBtaWdodCBi ZSBpbnRlcmVzdCBpbiB0aGUgaWRlbnRpZmljYXRpb24gb2YgdGVzdCByZWZlcmVuY2UgcG9pbnRz LiAgVGhpcyBpcyBjdXJyZW50bHkgb24gdGhlIElQUE0gV0cgY2hhcnRlciBhbmQgd2Ugbm93IGhh dmUgYW4gaW5pdGlhbCB3b3JraW5nIGdyb3VwIGRvY3VtZW50IChodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXBwbS1sbWFwLXBhdGgpLiANCiANClRoZSBJRVRGIGVu Y291cmFnZXMgdGhvc2UgaW4gdGhlIEJCRiB3aG8gYXJlIGludGVyZXN0ZWQgaW4gdGhpcyBJRVRG IHdvcmssIHRvIHBhcnRpY2lwYXRlIGFuZCBoZWxwIGRyaXZlIHRoZSB3b3JrIHZpYSB0aGUgcmVs ZXZhbnQgSUVURiBXRyBlbWFpbCBsaXN0cyBub3RlZCBhYm92ZSBhbmQgdGhlIElFVEYgZGV2ZWxv cG1lbnQgcHJvY2Vzc2VzLiAgV2hpbGUgZm9ybWFsIGxpYWlzb24gY29tbXVuaWNhdGlvbiBpcyBu ZWNlc3NhcnkgYW5kIGJlbmVmaWNpYWwsIGRpcmVjdCwgYWN0aXZlIHBhcnRpY2lwYXRpb24gYnkg aW50ZXJlc3RlZCBwYXJ0aWVzIGlzIHZlcnkgaGVscGZ1bCBhbmQgY29tcGxlbWVudGFyeSB0byBk cml2ZSB0aGUgZGVsaXZlcmFibGVzIG5lZWRlZCBiZXR3ZWVuIHRoZSBvcmdhbml6YXRpb25zLiAg UGxlYXNlIG5vdGUgdGhhdCBhY2Nlc3MgdG8gYWxsIHJlbGV2YW50IElFVEYgd29ya2luZyBncm91 cHMsIGVtYWlsIGxpc3RzLCBkb2N1bWVudHMgYW5kIHByb2Nlc3MgaXMgb3BlbiBzbyB0aGFuIGFu eSBpbnRlcmVzdGVkIHBhcnR5IG1heSBwYXJ0aWNpcGF0ZSBhbmQgY29udHJpYnV0ZS4NCiANCkxp a2V3aXNlLCB0aGUgSUVURiB3b3VsZCBiZSBoYXBweSB0byBwcm92aWRlIGlucHV0IGFuZCBmZWVk YmFjayBvbiBCQkYgcmVsYXRlZCB3b3JrLiAgV2UgdW5kZXJzdGFuZCB0aGUgQkJGIGlzIGEgbWVt YmVyc2hpcCBvcmdhbml6YXRpb24gYW5kIG1heSByZXN0cmljdCBhY2Nlc3MgdG8gaXRzIHJlbGV2 YW50IHdvcmtzIGluIHByb2dyZXNzLiAgVG8gZmFjaWxpdGF0ZSBjb29wZXJhdGlvbiB3aXRoIHRo ZSBJRVRGLCBwbGVhc2UgbGlhaXNlIGFueSB3b3JrIGluIHByb2dyZXNzIHlvdSB3b3VsZCBsaWtl IHRoZSBJRVRGIHRvIGNvbnNpZGVyLCByZXZpZXcsIGNvbW1lbnQgb24sIGNvbGxhYm9yYXRlIG9u LCBldGMuLCB3aXRoIHRoZSB1bmRlcnN0YW5kaW5nIHRoYXQgYWNjZXNzIHRvIHRoZSBsaWFpc29u IGFuZCBpdHMgYXR0YWNobWVudHMgd2lsbCBiZSBvcGVuIGFuZCBub3QgYmUgcmVzdHJpY3RlZCBv ciBsaW1pdGVkIHRvIEJCRiBtZW1iZXJzaGlwLg0KIA0KU2luY2VyZWx5LA0KTE1BUCwgSVBQTSwg SG9tZW5ldCBhbmQgQk1XRyBDaGFpcnMNCkF0dGFjaG1lbnRzOg0KDQpObyBkb2N1bWVudCBoYXMg YmVlbiBhdHRhY2hlZA0KDQo= From philip.eardley@bt.com Thu Oct 17 02:56:13 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01E911E8258 for ; Thu, 17 Oct 2013 02:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.238 X-Spam-Level: X-Spam-Status: No, score=-103.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFUg5OT10soh for ; Thu, 17 Oct 2013 02:56:00 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id A304F11E8250 for ; Thu, 17 Oct 2013 02:55:56 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 17 Oct 2013 10:55:54 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.51]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Thu, 17 Oct 2013 10:55:54 +0100 From: To: , , Date: Thu, 17 Oct 2013 10:55:53 +0100 Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwBNwgFQAAu9HOABI66CwA== Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F56FA@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771F56FA@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9E3D83DEMV67UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Oct 2013 09:56:13 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9E3D83DEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wonder if both things are valid: - For all (?) tests, it would be interesting to report that the MA su= spects the results may be dodgy. - For specific tests it may be interesting to know the amount of cros= s-traffic. A lot of cross-traffic may or may not indicate that the result i= s dodgy phil From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Car= ey, Timothy (Timothy) Sent: 11 October 2013 15:43 To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments Trevor, But isn't what you are describing elements of what would be considered the = "context" of the test result; which changes based on the test I would imagi= ne. Maybe that is all that is necessary is to flush out all the elements yo= u want to place in the context? BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Friday, October 11, 2013 4:08 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I think that cross-traffic should not be a simple Boolean, nor subsumed int= o a general 'suspect' parameter. It needs to be a counter such as bytes of traffic sent/received over the WA= N interface. The reason for this is that the level of traffic needs to be c= aptured to determine the impact on different tests and different results. T= he threshold will be varied depending on both the test that was running and= the analysis being performed. Furthermore it can also be used to determine the effectiveness of test back= -off procedures in the presence of user traffic and to analyse the impact t= he tests are having on user experience. Trevor. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 09 October 2013 20:57 To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9E3D83DEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I wonder if bo= th things are valid:

-=        For a= ll (?) tests, it would be interesting to report that the MA suspects the re= sults may be dodgy.

-=        For s= pecific tests it may be interesting to know the amount of cross-traffic. A = lot of cross-traffic may or may not indicate that the result is dodgy<= /o:p>

 

phil

&nbs= p;

From:= lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On= Behalf Of Carey, Timothy (Timothy)
Sent: 11 October 2013 15:= 43
To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org
Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments=

 

Trevor,<= /span>

<= o:p> 

But isn’t what you are describing elements of what wo= uld be considered the “context” of the test result; which chang= es based on the test I would imagine. Maybe that is all that is necessary i= s to flush out all the elements you want to place in the context?

 

BR,

Tim

 

=

 =

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.c= om]
Sent: Friday, October 11, 2013 4:08 AM
To: Car= ey, Timothy (Timothy); lmap@ietf.orgSubject: RE: LMAP Information Model - BBF Questions and Comments

 

I think that cross-traffic should not be a simple Boolean, nor subsumed in= to a general ‘suspect’ parameter.

 

It needs to be a counter suc= h as bytes of traffic sent/received over the WAN interface. The reason for = this is that the level of traffic needs to be captured to determine the imp= act on different tests and different results. The threshold will be varied = depending on both the test that was running and the analysis being performe= d.

=  

Furthermore it can also be used to determine the effectiveness of test = back-off procedures in the presence of user traffic and to analyse the impa= ct the tests are having on user experience.

 

Trevor.

 

 

From:= lmap-bounces@ietf.org [<= a href=3D"mailto:lmap-bounces@ietf.org">mailto:lmap-bounces@ietf.org] <= b>On Behalf Of Carey, Timothy (Timothy)
Sent: 09 October 2013= 20:57
To: lmap@ietf.org
= Subject: [lmap] LMAP Information Model - BBF Questions and Comments<= o:p>

 

=

Hello,

 

During the 3Q2013 BBF meeting, the BBHome group h= ad an opportunity to review the LMAP information model.

I have tried to incorporate the c= omments and questions here:

 

1)      = It was unclear what the definiti= on was for the CrossTraffic attribute.

Upon further discussion in the group we thought th= at the CrossTraffic parameter was an indication that the Result of a measur= ement might be suspect because there was other traffic detected by the meas= urement agent that might cause an invalid measurement.

 

If this is true – should we rename = this attribute to something like SuspectResult and type it as a Boolean?

 

I also suggest this des= cription:

This parameter indicates if the measurement a= gent has determined that the result may be suspect. Events that cause a res= ult to be suspect is specific to the implementation of the measurement agen= t but may include events such as indications of other traffic or an unusual= CPU load that may interfere with test.

 

<= p class=3DMsoListParagraph style=3D'margin-left:18.0pt;text-indent:-18.0pt;= mso-list:l1 level1 lfo2'>2) &= nbsp;   In the M= easurement Agent there is an attribute supported measurements that is a lis= t of entries to the Registry

This seems fine; the group did ask for a clarification if a dev= ice could support more than one Measurement Agent.

 

3)   &nb= sp; When we reviewed the Opt= ions for a Task we were not sure if this was something where each option wa= s a Name/Value pair that could be individually maintained or if they option= s should be maintained as a bulk list of Name/Value pairs. What this would = mean is if you wanted to add, edit or delete on option you have to resend e= ntire option list.

 

&nb= sp;

Thoughts?

 <= /p>

Thanks,

Tim

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9E3D83DEMV67UKRDdoma_-- From timothy.carey@alcatel-lucent.com Thu Oct 17 04:26:53 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB3911E817C for ; Thu, 17 Oct 2013 04:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.17 X-Spam-Level: X-Spam-Status: No, score=-10.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvhXP5tQGX+6 for ; Thu, 17 Oct 2013 04:26:46 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id DCE9A11E8102 for ; Thu, 17 Oct 2013 04:26:45 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r9HBQgRc019878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Oct 2013 06:26:42 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r9HBQg4q022382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Oct 2013 07:26:42 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 17 Oct 2013 07:26:42 -0400 From: "Carey, Timothy (Timothy)" To: "philip.eardley@bt.com" , "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwBNwgFQAAu9HOABI66CwAADTIjg Date: Thu, 17 Oct 2013 11:26:41 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771F8721@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F56FA@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771F8721US70UWXCHMBA05zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Oct 2013 11:26:54 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771F8721US70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes that is the way I have seen the Suspect Boolean used. From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Thursday, October 17, 2013 11:56 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I wonder if both things are valid: - For all (?) tests, it would be interesting to report that the MA su= spects the results may be dodgy. - For specific tests it may be interesting to know the amount of cros= s-traffic. A lot of cross-traffic may or may not indicate that the result i= s dodgy phil From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Car= ey, Timothy (Timothy) Sent: 11 October 2013 15:43 To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments Trevor, But isn't what you are describing elements of what would be considered the = "context" of the test result; which changes based on the test I would imagi= ne. Maybe that is all that is necessary is to flush out all the elements yo= u want to place in the context? BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Friday, October 11, 2013 4:08 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I think that cross-traffic should not be a simple Boolean, nor subsumed int= o a general 'suspect' parameter. It needs to be a counter such as bytes of traffic sent/received over the WA= N interface. The reason for this is that the level of traffic needs to be c= aptured to determine the impact on different tests and different results. T= he threshold will be varied depending on both the test that was running and= the analysis being performed. Furthermore it can also be used to determine the effectiveness of test back= -off procedures in the presence of user traffic and to analyse the impact t= he tests are having on user experience. Trevor. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 09 October 2013 20:57 To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771F8721US70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes that is the way I = have seen the Suspect Boolean used.

 

From: philip.e= ardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, October 17, 2013 11:56 AM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org=
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

I wonder if bot= h things are valid:

-       For all= (?) tests, it would be interesting to report that the MA suspects the resu= lts may be dodgy.

-       For spe= cific tests it may be interesting to know the amount of cross-traffic. A lo= t of cross-traffic may or may not indicate that the result is dodgy

 

phil=

 

From: lmap-bou= nces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 11 October 2013 15:43
To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org
Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comme= nts

 

Trevor,

 

But isn’t what y= ou are describing elements of what would be considered the “context&#= 8221; of the test result; which changes based on the test I would imagine. = Maybe that is all that is necessary is to flush out all the elements you want to place in the context?

 

BR,<= /p>

Tim<= /p>

 

 

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Friday, October 11, 2013 4:08 AM
To: Carey, Timothy (Timothy); lmap@= ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

I think= that cross-traffic should not be a simple Boolean, nor subsumed into a gen= eral ‘suspect’ parameter.

&n= bsp;

It need= s to be a counter such as bytes of traffic sent/received over the WAN inter= face. The reason for this is that the level of traffic needs to be captured= to determine the impact on different tests and different results. The threshold will be varied depending on bot= h the test that was running and the analysis being performed.

&n= bsp;

Further= more it can also be used to determine the effectiveness of test back-off pr= ocedures in the presence of user traffic and to analyse the impact the test= s are having on user experience.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 09 October 2013 20:57
To: lmap@ietf.org
Subject: [lmap] LMAP Information Model - BBF Questions and Comments<= o:p>

 

Hello,

 

During the 3Q2013 BBF meeting, the BBHome group had = an opportunity to review the LMAP information model.

I have tried to incorporate the comments and questio= ns here:

 

1)      It was unclear what the definition was for the Cros= sTraffic attribute.

Upon further discussion in the group we thought that= the CrossTraffic parameter was an indication that the Result of a measurem= ent might be suspect because there was other traffic detected by the measur= ement agent that might cause an invalid measurement.

 

If this is true – should we rename this attrib= ute to something like SuspectResult and type it as a Boolean?

 

I also suggest this description:

This parameter indicates if the measurement agent has determined th= at the result may be suspect. Events that cause a result to be suspect is specific to the implementation of the measurement agent b= ut may include events such as indications of other traffic or an unusual CP= U load that may interfere with test.

 

2)   = ;  In the Measurement Ag= ent there is an attribute supported measurements that is a list of entries = to the Registry

This seems fine; the group di= d ask for a clarification if a device could support more than one Measureme= nt Agent.

 

3)   = ;  When we reviewed the = Options for a Task we were not sure if this was something where each option= was a Name/Value pair that could be individually maintained or if they options should be maintained as a bulk list of Name/Value pairs= . What this would mean is if you wanted to add, edit or delete on option yo= u have to resend entire option list.

 

 

Thoughts?

 

Thanks,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F771F8721US70UWXCHMBA05zam_-- From philip.eardley@bt.com Thu Oct 17 04:32:36 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8562C11E81B4 for ; Thu, 17 Oct 2013 04:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.898 X-Spam-Level: X-Spam-Status: No, score=-102.898 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GawYviDiElgP for ; Thu, 17 Oct 2013 04:32:31 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id B197311E811A for ; Thu, 17 Oct 2013 04:32:21 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 17 Oct 2013 12:32:19 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.51]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 17 Oct 2013 12:32:20 +0100 From: To: , , Date: Thu, 17 Oct 2013 12:32:18 +0100 Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwBNwgFQAAu9HOABI66CwAADTIjgAAAg/nA= Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F56FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F8721@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771F8721@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9E3D889EMV67UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Oct 2013 11:32:36 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9E3D889EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perhaps a 'suspect code' rather than a boolean [cross-traffic, CPU on MA, o= verload on Measurement Peer, etc] ? From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 17 October 2013 12:27 To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Yes that is the way I have seen the Suspect Boolean used. From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Thursday, October 17, 2013 11:56 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I wonder if both things are valid: - For all (?) tests, it would be interesting to report that the MA su= spects the results may be dodgy. - For specific tests it may be interesting to know the amount of cros= s-traffic. A lot of cross-traffic may or may not indicate that the result i= s dodgy phil From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 11 October 2013 15:43 To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments Trevor, But isn't what you are describing elements of what would be considered the = "context" of the test result; which changes based on the test I would imagi= ne. Maybe that is all that is necessary is to flush out all the elements yo= u want to place in the context? BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Friday, October 11, 2013 4:08 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I think that cross-traffic should not be a simple Boolean, nor subsumed int= o a general 'suspect' parameter. It needs to be a counter such as bytes of traffic sent/received over the WA= N interface. The reason for this is that the level of traffic needs to be c= aptured to determine the impact on different tests and different results. T= he threshold will be varied depending on both the test that was running and= the analysis being performed. Furthermore it can also be used to determine the effectiveness of test back= -off procedures in the presence of user traffic and to analyse the impact t= he tests are having on user experience. Trevor. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 09 October 2013 20:57 To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9E3D889EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Perhaps a R= 16;suspect code’ rather than a boolean [cross-traffic, CPU on MA, ove= rload on Measurement Peer= , etc]

?

 

= From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcate= l-lucent.com]
Sent: 17 October 2013 12:27
To: Eardley,= PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

Yes that is the way I have = seen the Suspect Boolean used.

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

=

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thurs= day, October 17, 2013 11:56 AM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: LMAP Inf= ormation Model - BBF Questions and Comments

 

I wonder if both things are valid:

<= p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1 = lfo2'>-       For all (?) tests, it would be interesting to = report that the MA suspects the results may be dodgy.

-       For specific tests it may be interesting to kn= ow the amount of cross-traffic. A lot of cross-traffic may or may not indic= ate that the result is dodgy

 

phil

=

 

<= p class=3DMsoNormal>From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timot= hy (Timothy)
Sent: 11 October 2013 15:43
To: Burbridge,= T,Trevor,TUB8 R; lmap@ietf.org
S= ubject: Re: [lmap] LMAP Information Model - BBF Questions and Comments<= o:p>

 

=

Trevor,

 

But isn’t what you are describing elements of= what would be considered the “context” of the test result; whi= ch changes based on the test I would imagine. Maybe that is all that is nec= essary is to flush out all the elements you want to place in the context?

 

BR,

Tim

 

 

From:= trevor.burbridg= e@bt.com [mailto:trevor.burb= ridge@bt.com]
Sent: Friday, October 11, 2013 4:08 AM
T= o: Carey, Timothy (Timothy); lmap@ietf= .org
Subject: RE: LMAP Information Model - BBF Questions and = Comments

 

I think that cross-traffic should not be a simple Boolean, nor= subsumed into a general ‘suspect’ parameter.=

 

It needs to be a= counter such as bytes of traffic sent/received over the WAN interface. The= reason for this is that the level of traffic needs to be captured to deter= mine the impact on different tests and different results. The threshold wil= l be varied depending on both the test that was running and the analysis be= ing performed.

 

Furthermore it can also be used to determine the effectiven= ess of test back-off procedures in the presence of user traffic and to anal= yse the impact the tests are having on user experience.

 

Trevor.=

 

&nbs= p;

From:= lmap-bounces@ietf= .org [mailto:lmap-bounces@ietf= .org] On Behalf Of Carey, Timothy (Timothy)
Sent: 09 O= ctober 2013 20:57
To: lmap@ietf.= org
Subject: [lmap] LMAP Information Model - BBF Questions an= d Comments

 = ;

Hello,=

 

During the 3Q2013 BBF meeting, the BBH= ome group had an opportunity to review the LMAP information model.

I have tried to incorp= orate the comments and questions here:

 

1)    &nb= sp; It was unclear what t= he definition was for the CrossTraffic attribute.

Upon further discussion in the group we= thought that the CrossTraffic parameter was an indication that the Result = of a measurement might be suspect because there was other traffic detected = by the measurement agent that might cause an invalid measurement.

 

If this is true – should= we rename this attribute to something like SuspectResult and type it as a = Boolean?

=  

I also sugge= st this description:

This parameter indicates if the = measurement agent has determined that the result may be suspect. Events tha= t cause a result to be suspect is specific to the implementation of the mea= surement agent but may include events such as indications of other traffic = or an unusual CPU load that may interfere with test.=

 

= 2)     In the Measurement Agent there is an attribute supported measurements that= is a list of entries to the Registry

This seems fine; the group did ask for a clarification= if a device could support more than one Measurement Agent.

 

3)  =    When we reviewe= d the Options for a Task we were not sure if this was something where each = option was a Name/Value pair that could be individually maintained or if th= ey options should be maintained as a bulk list of Name/Value pairs. What th= is would mean is if you wanted to add, edit or delete on option you have to= resend entire option list.

 

 

Thoughts= ?

 

Thanks,=

Tim=

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9E3D889EMV67UKRDdoma_-- From timothy.carey@alcatel-lucent.com Thu Oct 17 04:36:50 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A5221F960D for ; Thu, 17 Oct 2013 04:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.848 X-Spam-Level: X-Spam-Status: No, score=-9.848 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1kH8CO3PdmG for ; Thu, 17 Oct 2013 04:36:43 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D55F221F942D for ; Thu, 17 Oct 2013 04:36:40 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9HBac9k013666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Oct 2013 06:36:38 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9HBabY0022257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Oct 2013 07:36:37 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 17 Oct 2013 07:36:37 -0400 From: "Carey, Timothy (Timothy)" To: "philip.eardley@bt.com" , "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwBNwgFQAAu9HOABI66CwAADTIjgAAAg/nAAADVZEA== Date: Thu, 17 Oct 2013 11:36:36 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771F8757@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F56FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F8721@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771F8757US70UWXCHMBA05zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Oct 2013 11:36:50 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771F8757US70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You could but then you have to specify the domain of what is suspected. It = would be list because there could be multiple conditions. From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Thursday, October 17, 2013 1:32 PM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Perhaps a 'suspect code' rather than a boolean [cross-traffic, CPU on MA, o= verload on Measurement Peer, etc] ? From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 17 October 2013 12:27 To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Yes that is the way I have seen the Suspect Boolean used. From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Thursday, October 17, 2013 11:56 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I wonder if both things are valid: - For all (?) tests, it would be interesting to report that the MA su= spects the results may be dodgy. - For specific tests it may be interesting to know the amount of cros= s-traffic. A lot of cross-traffic may or may not indicate that the result i= s dodgy phil From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 11 October 2013 15:43 To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments Trevor, But isn't what you are describing elements of what would be considered the = "context" of the test result; which changes based on the test I would imagi= ne. Maybe that is all that is necessary is to flush out all the elements yo= u want to place in the context? BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Friday, October 11, 2013 4:08 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I think that cross-traffic should not be a simple Boolean, nor subsumed int= o a general 'suspect' parameter. It needs to be a counter such as bytes of traffic sent/received over the WA= N interface. The reason for this is that the level of traffic needs to be c= aptured to determine the impact on different tests and different results. T= he threshold will be varied depending on both the test that was running and= the analysis being performed. Furthermore it can also be used to determine the effectiveness of test back= -off procedures in the presence of user traffic and to analyse the impact t= he tests are having on user experience. Trevor. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 09 October 2013 20:57 To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771F8757US70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You could but then you= have to specify the domain of what is suspected. It would be list because = there could be multiple conditions.

 

From: philip.e= ardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, October 17, 2013 1:32 PM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org=
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

Perhaps a ̵= 6;suspect code’ rather than a boolean [cross-traffic, CPU on MA, over= load on Measurement Peer, etc]<= o:p>

?

 

From: Carey, T= imothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: 17 October 2013 12:27
To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.o= rg
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

Yes that is the way I = have seen the Suspect Boolean used.

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, October 17, 2013 11:56 AM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

I wonder if bot= h things are valid:

-       For all= (?) tests, it would be interesting to report that the MA suspects the resu= lts may be dodgy.

-       For spe= cific tests it may be interesting to know the amount of cross-traffic. A lo= t of cross-traffic may or may not indicate that the result is dodgy

 

phil=

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 11 October 2013 15:43
To: Burbridge,T,Trevor,TUB8 R; lmap= @ietf.org
Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comme= nts

 

Trevor,

 

But isn’t what y= ou are describing elements of what would be considered the “context&#= 8221; of the test result; which changes based on the test I would imagine. = Maybe that is all that is necessary is to flush out all the elements you want to place in the context?

 

BR,<= /p>

Tim<= /p>

 

 

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Friday, October 11, 2013 4:08 AM
To: Carey, Timothy (Timothy); lmap@= ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

I think= that cross-traffic should not be a simple Boolean, nor subsumed into a gen= eral ‘suspect’ parameter.

&n= bsp;

It need= s to be a counter such as bytes of traffic sent/received over the WAN inter= face. The reason for this is that the level of traffic needs to be captured= to determine the impact on different tests and different results. The threshold will be varied depending on bot= h the test that was running and the analysis being performed.

&n= bsp;

Further= more it can also be used to determine the effectiveness of test back-off pr= ocedures in the presence of user traffic and to analyse the impact the test= s are having on user experience.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 09 October 2013 20:57
To: lmap@ietf.org
Subject: [lmap] LMAP Information Model - BBF Questions and Comments<= o:p>

 

Hello,

 

During the 3Q2013 BBF meeting, the BBHome group had = an opportunity to review the LMAP information model.

I have tried to incorporate the comments and questio= ns here:

 

1)      It was unclear what the definition was for the Cros= sTraffic attribute.

Upon further discussion in the group we thought that= the CrossTraffic parameter was an indication that the Result of a measurem= ent might be suspect because there was other traffic detected by the measur= ement agent that might cause an invalid measurement.

 

If this is true – should we rename this attrib= ute to something like SuspectResult and type it as a Boolean?

 

I also suggest this description:

This parameter indicates if the measurement agent has determined th= at the result may be suspect. Events that cause a result to be suspect is specific to the implementation of the measurement agent b= ut may include events such as indications of other traffic or an unusual CP= U load that may interfere with test.

 

2)   = ;  In the Measurement Ag= ent there is an attribute supported measurements that is a list of entries = to the Registry

This seems fine; the group di= d ask for a clarification if a device could support more than one Measureme= nt Agent.

 

3)   = ;  When we reviewed the = Options for a Task we were not sure if this was something where each option= was a Name/Value pair that could be individually maintained or if they options should be maintained as a bulk list of Name/Value pairs= . What this would mean is if you wanted to add, edit or delete on option yo= u have to resend entire option list.

 

 

Thoughts?

 

Thanks,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F771F8757US70UWXCHMBA05zam_-- From dromasca@avaya.com Thu Oct 17 07:32:42 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E32421F9D12 for ; Thu, 17 Oct 2013 07:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URGBIZ=0.725, URG_BIZ=1.585, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCLFym6sBrmZ for ; Thu, 17 Oct 2013 07:32:36 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5135C11E80F9 for ; Thu, 17 Oct 2013 07:32:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYHAHn0X1LGmAcV/2dsb2JhbABVBYJmIThSgym6WRiBCxZtB4IlAQEBAQMSCwYRNxoGAQgNBAQBAQMCBh0DAgQwFAEGAQEFBQQTCBqHZAELnneESIo+kjETBIEpjH16PoJkNYEHA55liyWDJIIp X-IronPort-AV: E=Sophos;i="4.93,514,1378872000"; d="scan'208";a="32410091" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Oct 2013 10:31:59 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Oct 2013 10:27:37 -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.0146.000; Thu, 17 Oct 2013 16:31:58 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: NOMCOM - Time-Critical - Final Call for Nominations Thread-Index: AQHOy0K+cko6OZy9e0GkJAHVkQ0ZYpn49LGw Date: Thu, 17 Oct 2013 14:31:57 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1290CBFF@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [lmap] FW: NOMCOM - Time-Critical - Final Call for Nominations X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Oct 2013 14:32:42 -0000 DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWV0Zi1hbm5vdW5jZS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgTm9tQ29tIENoYWlyIDIwMTMNClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE3 LCAyMDEzIDU6MDkgUE0NClRvOiBJRVRGIEFubm91bmNlbWVudCBMaXN0DQpDYzogSUVURiBEaXNj dXNzDQpTdWJqZWN0OiBOT01DT00gLSBUaW1lLUNyaXRpY2FsIC0gRmluYWwgQ2FsbCBmb3IgTm9t aW5hdGlvbnMNCg0KQSBjcml0aWNhbGx5IGxvdyBudW1iZXIgb2YgcGVvcGxlIGhhdmUgYWNjZXB0 ZWQgbm9taW5hdGlvbnMgZm9yIHNvbWUgb2YgdGhlIElFU0cgb3BlbiBwb3NpdGlvbnMuICBUaGVy ZSBpcyBvbmx5IG9uZSBub21pbmVlIHBlciBzbG90IGluIEFQUCwgT1BTIGFuZCBUU1YsIG9ubHkg dHdvIGluIElOVCBhbmQgUkFJLiAgTWFueSBmb2xrcyBoYXZlIGRlY2xpbmVkIG5vbWluYXRpb25z LiAgDQoNCldoaWxlIHRoZSBOb21jb20gYXBwcmVjaWF0ZXMgdGhhdCBzdXBwb3J0IGZvciB0d28g eWVhcnMgb2YgaW50ZW5zZSBzZXJ2aWNlIGlzIGhhcmQgdG8gYXNzdXJlLCBhbmQgd2hpbGUgd2Ug YXJlIGF3YXJlIHRoYXQgdGhlcmUgaXMgbXVjaCBzdXBwb3J0IGZvciB0aGUgaW5jdW1iZW50cyB3 aG8gYXJlIHN0YW5kaW5nLCB0aGUgSUVURiBzaG91bGQgY29udGludWFsbHkgYmUgY29uc2lkZXJp bmcgd2hpY2ggbmV3IHRhbGVudCBpcyBhdmFpbGFibGUgZm9yIG91ciBsZWFkZXJzaGlwLCBhbmQg dGhlIE5vbWNvbSBwcm9jZXNzIG5lZWRzIGZvciB0aGVyZSB0byBiZSBzb21lIHJldmlldyBhbmQg ZGVsaWJlcmF0aW9uLiANCg0KVGhlcmVmb3JlLCB3ZSB1cmdlbnRseSByZXF1ZXN0IHRoYXQgbW9y ZSBub21pbmVlcyBjb21lIGZvcndhcmQuICANCg0KREVBRExJTkVTDQpOb21pbmF0aW9ucyAtIE9j dG9iZXIgMTgNClF1ZXN0aW9ubmFpcmVzIGZyb20gbm9taW5lZXMgLSBPY3RvYmVyIDI1DQoNCk5v dCBjb2luY2lkZW50YWxseSwgdGhpcyBpcyBhIGdvb2QgdGltZSB0byB0aGluayBvdmVyIGFuZCBz ZW5kIHlvdXIgY29tbWVudHMgYWJvdXQgdGhlIGN1cnJlbnQgc3RhdGVtZW50cyBvZiBkZXNpcmVk IGV4cGVydGlzZSBvZiBwb3NpdGlvbnMgLSB0aGlzIGlzIHBhcnQgb2YgdGhlIE5vbWNvbSdzIGFu bnVhbCByZXZpZXcgcHJvY2VzcyBhcyB3ZWxsLiAgU2VuZCB0aGVtIHRvIG5vbWNvbTEzQGlldGYu b3JnLg0KDQpEZWZpbml0aXZlIGxvY2F0aW9uIFsqXSBvZiB0aGUgY3VycmVudCBzdGF0ZW1lbnRz IG9uIGRlc2lyZWQgZXhwZXJ0aXNlOg0KICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9ub21jb20vMjAxMy9leHBlcnRpc2UvDQoNCkluc3RydWN0aW9ucyBhbmQgZGV0YWlscyBvbiBu b21pbmF0aW9uIFsqKl06DQogICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Fubi9u b21jb20vNjA2MDIvDQoNClRoYW5rcywgZXZlcnlvbmUsDQoNCkFsbGlzb24gZm9yIHRoZSBOb21j b20NCg0KWypdIFRoaXMgeWVhciB0aGUgTm9tY29tIHRvb2xzIHdlcmUgcmVjb2RlZCwgYW5kIGFs c28gdHJhbnNpdGlvbmVkIGludG8gdGhlIGRhdGF0cmFja2VyLiAgQXBvbG9naWVzIGZvciBhIG51 bWJlciBvZiBwbGFjZXMgd2hlcmUgd2UgZGlkbid0IGNhdGNoIHJlZmVyZW5jZSBlcnJvcnMuDQoN ClsqKl0gWWVzLCBhbGFzLCB0aGUgcHJldmlvdXMgY2FsbCBmb3Igbm9taW5hdGlvbnMgdXNlZCAi T0FNIiBpbnN0ZWFkIG9mICJPUFMsIiBidXQgd2UgaGF2ZSogY29ycmVjdGVkIHRoaXMgKGNoYWly J3MgcGlsb3QpIGVycm9yIHdoZXJlIGl0IG9jY3VycmVkIGluIHRoZSBOb21jb20gcGFnZXMuDQo= From dromasca@avaya.com Sun Oct 20 01:22:50 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9A911E8378 for ; Sun, 20 Oct 2013 01:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.295 X-Spam-Level: X-Spam-Status: No, score=-103.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bq39KBZ4Wo4H for ; Sun, 20 Oct 2013 01:22:39 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id BC93811E8376 for ; Sun, 20 Oct 2013 01:22:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMLAH6RY1KHCzI1/2dsb2JhbABXA4JmIThUqUyUZ4EgFm0HgiUBAQEBAwEBAQ8oNBcCBAEIDQMBBAEBCxQJIgwLFAcBAQUFBBMIARmHZAEMnyiESJwwFwSPJyESCwuDDoEKA55riyWBZoE+gio X-IronPort-AV: E=Sophos;i="4.93,532,1378872000"; d="scan'208";a="28380368" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Oct 2013 04:22:37 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 20 Oct 2013 04:13:15 -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.0146.000; Sun, 20 Oct 2013 10:22:35 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements Thread-Index: AQHOy/4OMHoNRWXrdkCdpYvEqB53/Zn9QwTQ Date: Sun, 20 Oct 2013 08:22:34 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1290F4A1@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] FW: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 08:22:50 -0000 -----Original Message----- From: nmrg-bounces@irtf.org [mailto:nmrg-bounces@irtf.org] On Behalf Of Jue= rgen Schoenwaelder Sent: Friday, October 18, 2013 3:32 PM To: nmrg@irtf.org Subject: Re: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale ne= twork measurements Hi, the slides presented on Monday have been uploaded to the IETF interim meeti= ngs tracker. You can find the material here: http://www.ietf.org/proceedings/interim/2013/10/14/nmrg/proceedings.html Thanks to everybody who participated in this meeting. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ nmrg mailing list nmrg@irtf.org https://www.irtf.org/mailman/listinfo/nmrg From trevor.burbridge@bt.com Mon Oct 21 01:35:16 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EAD11E8110 for ; Mon, 21 Oct 2013 01:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcxLhM1PJxir for ; Mon, 21 Oct 2013 01:35:10 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 09FD311E8337 for ; Mon, 21 Oct 2013 01:34:38 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 21 Oct 2013 09:34:37 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.44]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 21 Oct 2013 09:34:37 +0100 From: To: , , Date: Mon, 21 Oct 2013 09:34:35 +0100 Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwBNwgFQAAu9HOABI66CwAADTIjgAAAg/nAAADVZEADCwa6A Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F56FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F8721@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F8757@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771F8757@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72C30114B52EMV64UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 08:35:16 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72C30114B52EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry - I've been away. I still think the best way is to simply report the= bytes of cross-traffic. What I tried to get across in my first response is= that the level I want to filter at is not simply dependent on the test bei= ng operated. It will also depend on what I am trying to do with the data. I= t is a simple approach that covers all possible eventualities. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 17 October 2013 12:37 To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments You could but then you have to specify the domain of what is suspected. It = would be list because there could be multiple conditions. From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Thursday, October 17, 2013 1:32 PM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Perhaps a 'suspect code' rather than a boolean [cross-traffic, CPU on MA, o= verload on Measurement Peer, etc] ? From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 17 October 2013 12:27 To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Yes that is the way I have seen the Suspect Boolean used. From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Thursday, October 17, 2013 11:56 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I wonder if both things are valid: - For all (?) tests, it would be interesting to report that the MA s= uspects the results may be dodgy. - For specific tests it may be interesting to know the amount of cro= ss-traffic. A lot of cross-traffic may or may not indicate that the result = is dodgy phil From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 11 October 2013 15:43 To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments Trevor, But isn't what you are describing elements of what would be considered the = "context" of the test result; which changes based on the test I would imagi= ne. Maybe that is all that is necessary is to flush out all the elements yo= u want to place in the context? BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Friday, October 11, 2013 4:08 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I think that cross-traffic should not be a simple Boolean, nor subsumed int= o a general 'suspect' parameter. It needs to be a counter such as bytes of traffic sent/received over the WA= N interface. The reason for this is that the level of traffic needs to be c= aptured to determine the impact on different tests and different results. T= he threshold will be varied depending on both the test that was running and= the analysis being performed. Furthermore it can also be used to determine the effectiveness of test back= -off procedures in the presence of user traffic and to analyse the impact t= he tests are having on user experience. Trevor. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 09 October 2013 20:57 To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72C30114B52EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry  - I’ve been away. I still think the best wa= y is to simply report the bytes of cross-traffic. What I tried to get acros= s in my first response is that the level I want to filter at is not simply = dependent on the test being operated. It will also depend on what I am tryi= ng to do with the data. It is a simple approach that covers all possible ev= entualities.

 

Trevor.

 

Trevor Burbridge
Network Infrastructure & Innovation | BT Inno= vate & Design
Tel: 01473 645115
Fax: 01473 640929
<= span style=3D'color:#1F497D'>
This email contains BT informat= ion, which may be privileged or confidential. It's meant only for the indiv= idual(s) or entity named above. If you're not the intended recipient, note = that disclosing, copying, distributing or using this information is prohibi= ted. If you've received this email in error, please let me know immediately= on the email address above. Thank you.
We monitor our email system, and= may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street Lo= ndon EC1A 7AJ
Registered in England no: 1800000

 

From: Carey, Timothy (Timothy) [mailt= o:timothy.carey@alcatel-lucent.com]
Sent: 17 October 2013 12:37<= br>To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@iet= f.org
Subject: RE: LMAP Information Model - BBF Questions and Com= ments

 

You c= ould but then you have to specify the domain of what is suspected. It would= be list because there could be multiple conditions.

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

From:= philip.eardley@bt.com [<= a href=3D"mailto:philip.eardley@bt.com">mailto:philip.eardley@bt.com] <= br>Sent: Thursday, October 17, 2013 1:32 PM
To: Carey, Tim= othy (Timothy); trevor.burbridge= @bt.com; lmap@ietf.org
Subje= ct: RE: LMAP Information Model - BBF Questions and Comments<= /span>

 

Perhaps a ‘suspect code’ = rather than a boolean [cross-traffic, CPU on MA, overload on Measurement Peer, etc]

?

 

From: C= arey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: 17 October = 2013 12:27
To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 = R; lmap@ietf.org
Subject: RE= : LMAP Information Model - BBF Questions and Comments

=

 

= Yes that is the way I have seen = the Suspect Boolean used.

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday= , October 17, 2013 11:56 AM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: LMAP Inform= ation Model - BBF Questions and Comments

<= p class=3DMsoNormal> 

I wonder if both things are valid:

-        For all (?) tests, it would be interesting to= report that the MA suspects the results may be dodgy.

-      &nbs= p; For specific tests it may be interestin= g to know the amount of cross-traffic. A lot of cross-traffic may or may no= t indicate that the result is dodgy

 

phil

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey= , Timothy (Timothy)
Sent: 11 October 2013 15:43
To: Bur= bridge,T,Trevor,TUB8 R; lmap@ietf.org<= br>Subject: Re: [lmap] LMAP Information Model - BBF Questions and Co= mments

 

Trev= or,

 

But isn’t what you are describing el= ements of what would be considered the “context” of the test re= sult; which changes based on the test I would imagine. Maybe that is all th= at is necessary is to flush out all the elements you want to place in the c= ontext?

 

BR,

Tim

=

 =

 

From: trevor.b= urbridge@bt.com [mailto:trev= or.burbridge@bt.com]
Sent: Friday, October 11, 2013 4:08 AM<= br>To: Carey, Timothy (Timothy); lm= ap@ietf.org
Subject: RE: LMAP Information Model - BBF Questio= ns and Comments

 

I think that cross-traffic should not be a simple Boolea= n, nor subsumed into a general ‘suspect’ parameter.<= /span>

 

It needs t= o be a counter such as bytes of traffic sent/received over the WAN interfac= e. The reason for this is that the level of traffic needs to be captured to= determine the impact on different tests and different results. The thresho= ld will be varied depending on both the test that was running and the analy= sis being performed.

 

Furthermore it can also be used to determine the eff= ectiveness of test back-off procedures in the presence of user traffic and = to analyse the impact the tests are having on user experience.

 

Trevor.

&= nbsp;

 

From: lmap-bounce= s@ietf.org [mailto:lmap-bounce= s@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 09 October 2013 20:57
To: lmap= @ietf.org
Subject: [lmap] LMAP Information Model - BBF Questi= ons and Comments

 

Hello,<= /span>

 <= /p>

During the 3Q2013 BBF meeting, t= he BBHome group had an opportunity to review the LMAP information model.

I have tried to = incorporate the comments and questions here:

 

1)   &n= bsp;  It was unclear= what the definition was for the CrossTraffic attribute.<= /p>

Upon further discussion in the g= roup we thought that the CrossTraffic parameter was an indication that the = Result of a measurement might be suspect because there was other traffic de= tected by the measurement agent that might cause an invalid measurement.

 

If this is true –= should we rename this attribute to something like SuspectResult and type i= t as a Boolean?

 

I als= o suggest this description:

This parameter indicates if= the measurement agent has determined that the result may be suspect. Event= s that cause a result to be suspect is specific to the implementation of th= e measurement agent but may include events such as indications of other tra= ffic or an unusual CPU load that may interfere with test.

&nb= sp;

2)     In the Measurement Agent there is an attribute supported measureme= nts that is a list of entries to the Registry

This seems fine; the group did ask for a clari= fication if a device could support more than one Measurement Agent.

 =

3)&nbs= p;    When we= reviewed the Options for a Task we were not sure if this was something whe= re each option was a Name/Value pair that could be individually maintained = or if they options should be maintained as a bulk list of Name/Value pairs.= What this would mean is if you wanted to add, edit or delete on option you= have to resend entire option list.

 

 

T= houghts?

&nb= sp;

Thanks,=

Tim

= --_000_ED51D9282D1D3942B9438CA8F3372EB72C30114B52EMV64UKRDdoma_-- From marcelo@it.uc3m.es Mon Oct 21 02:17:46 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A57A11E8193 for ; Mon, 21 Oct 2013 02:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfyq538ZqxBn for ; Mon, 21 Oct 2013 02:17:35 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDAC11E8337 for ; Mon, 21 Oct 2013 02:17:32 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C17F811C4125 for ; Mon, 21 Oct 2013 11:17:30 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost13.it.uc3m.es (unknown [163.117.139.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 9331D11C4008 for ; Mon, 21 Oct 2013 11:17:30 +0200 (CEST) Message-ID: <5264F130.8040605@it.uc3m.es> Date: Mon, 21 Oct 2013 11:17:36 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "lmap@ietf.org" References: <20131021091555.8769.48897.idtracker@ietfa.amsl.com> In-Reply-To: <20131021091555.8769.48897.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131021091555.8769.48897.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Mon, 21 Oct 2013 11:17:30 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20232.005 X-TM-AS-Result: No--15.014-7.0-31-1 X-imss-scan-details: No--15.014-7.0-31-1 Subject: [lmap] Fwd: New Version Notification for draft-bagnulo-lmap-http-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 09:17:47 -0000 Hi, We have submitted an updated version of the http draft. This version includes a more complete example of how this would work, including both the capabilities and logging information exchange between the MA and the cotroller among other smaller changes. comments are as usual welcome. Thanks, marcelo -------- Mensaje original -------- Asunto: New Version Notification for draft-bagnulo-lmap-http-01.txt Fecha: Mon, 21 Oct 2013 02:15:55 -0700 De: internet-drafts@ietf.org Para: Trevor Burbridge , Sam Crawford , Vaibhav Bajpai , Juergen Schoenwaelder , Marcelo Bagnulo A new version of I-D, draft-bagnulo-lmap-http-01.txt has been successfully submitted by Marcelo Bagnulo and posted to the IETF repository. Filename: draft-bagnulo-lmap-http Revision: 01 Title: Large MeAsurement Platform Protocol Creation date: 2013-10-21 Group: Individual Submission Number of pages: 22 URL: http://www.ietf.org/internet-drafts/draft-bagnulo-lmap-http-01.txt Status: http://datatracker.ietf.org/doc/draft-bagnulo-lmap-http Htmlized: http://tools.ietf.org/html/draft-bagnulo-lmap-http-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-bagnulo-lmap-http-01 Abstract: This documents specifies the LMAP protocol based on HTTP for the Control and Report in Large Scale Measurement Platforms. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From timothy.carey@alcatel-lucent.com Mon Oct 21 03:32:42 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F32311E84F6 for ; Mon, 21 Oct 2013 03:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2SxLoOpGKta for ; Mon, 21 Oct 2013 03:32:32 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id E0BB911E84DC for ; Mon, 21 Oct 2013 03:30:59 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r9LAUuNp016857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Oct 2013 05:30:57 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r9LAUuss021893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 06:30:56 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 21 Oct 2013 06:30:56 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwBNwgFQAAu9HOABI66CwAADTIjgAAAg/nAAADVZEADCwa6AAAQH12A= Date: Mon, 21 Oct 2013 10:30:56 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771FA8BD@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F56FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F8721@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F8757@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771FA8BDUS70UWXCHMBA05zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 10:32:43 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771FA8BDUS70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, So then what do we do about measurements that are suspect for other conditi= ons than cross traffic? Could you provide a good, description that could be used in the Information= model for Cross Traffic that would cover all possible eventualities. The reason for the description is that we would want developers to implemen= t the element in such a way that 2 implementations would have the same resu= lt for the same test instance.... BR, Tim From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Monday, October 21, 2013 3:35 AM To: Carey, Timothy (Timothy); philip.eardley@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Sorry - I've been away. I still think the best way is to simply report the= bytes of cross-traffic. What I tried to get across in my first response is= that the level I want to filter at is not simply dependent on the test bei= ng operated. It will also depend on what I am trying to do with the data. I= t is a simple approach that covers all possible eventualities. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 17 October 2013 12:37 To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments You could but then you have to specify the domain of what is suspected. It = would be list because there could be multiple conditions. From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Thursday, October 17, 2013 1:32 PM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Perhaps a 'suspect code' rather than a boolean [cross-traffic, CPU on MA, o= verload on Measurement Peer, etc] ? From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 17 October 2013 12:27 To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Yes that is the way I have seen the Suspect Boolean used. From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Thursday, October 17, 2013 11:56 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I wonder if both things are valid: - For all (?) tests, it would be interesting to report that the MA su= spects the results may be dodgy. - For specific tests it may be interesting to know the amount of cros= s-traffic. A lot of cross-traffic may or may not indicate that the result i= s dodgy phil From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 11 October 2013 15:43 To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments Trevor, But isn't what you are describing elements of what would be considered the = "context" of the test result; which changes based on the test I would imagi= ne. Maybe that is all that is necessary is to flush out all the elements yo= u want to place in the context? BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Friday, October 11, 2013 4:08 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I think that cross-traffic should not be a simple Boolean, nor subsumed int= o a general 'suspect' parameter. It needs to be a counter such as bytes of traffic sent/received over the WA= N interface. The reason for this is that the level of traffic needs to be c= aptured to determine the impact on different tests and different results. T= he threshold will be varied depending on both the test that was running and= the analysis being performed. Furthermore it can also be used to determine the effectiveness of test back= -off procedures in the presence of user traffic and to analyse the impact t= he tests are having on user experience. Trevor. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 09 October 2013 20:57 To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771FA8BDUS70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

So then what do we do = about measurements that are suspect for other conditions than cross traffic= ?

 

Could you provide a go= od, description that could be used in the Information model for Cross Traff= ic that would cover all possible eventualities.

The reason for the des= cription is that we would want developers to implement the element in such = a way that 2 implementations would have the same result for the same test i= nstance….

 

BR,<= /p>

Tim<= /p>

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Monday, October 21, 2013 3:35 AM
To: Carey, Timothy (Timothy); philip.eardley@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments

 

Sorry&n= bsp; - I’ve been away. I still think the best way is to simply report= the bytes of cross-traffic. What I tried to get across in my first respons= e is that the level I want to filter at is not simply dependent on the test being operated. It will also depend on what I am try= ing to do with the data. It is a simple approach that covers all possible e= ventualities.

&n= bsp;

Trevor.=

&n= bsp;

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

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this infor= mation is prohibited. If you've received this email in error, please let me= know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: Carey, T= imothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: 17 October 2013 12:37
To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.o= rg
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

You could but then you= have to specify the domain of what is suspected. It would be list because = there could be multiple conditions.

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, October 17, 2013 1:32 PM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

Perhaps a ̵= 6;suspect code’ rather than a boolean [cross-traffic, CPU on MA, over= load on Measurement Peer, etc]<= o:p>

?

 

From: Carey, T= imothy (Timothy) [mailt= o:timothy.carey@alcatel-lucent.com]
Sent: 17 October 2013 12:27
To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

Yes that is the way I = have seen the Suspect Boolean used.

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, October 17, 2013 11:56 AM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

I wonder if bot= h things are valid:

-       For all= (?) tests, it would be interesting to report that the MA suspects the resu= lts may be dodgy.

-       For spe= cific tests it may be interesting to know the amount of cross-traffic. A lo= t of cross-traffic may or may not indicate that the result is dodgy

 

phil=

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 11 October 2013 15:43
To: Burbridge,T,Trevor,TUB8 R; lmap= @ietf.org
Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comme= nts

 

Trevor,

 

But isn’t what y= ou are describing elements of what would be considered the “context&#= 8221; of the test result; which changes based on the test I would imagine. = Maybe that is all that is necessary is to flush out all the elements you want to place in the context?

 

BR,<= /p>

Tim<= /p>

 

 

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Friday, October 11, 2013 4:08 AM
To: Carey, Timothy (Timothy); lmap@= ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

I think= that cross-traffic should not be a simple Boolean, nor subsumed into a gen= eral ‘suspect’ parameter.

&n= bsp;

It need= s to be a counter such as bytes of traffic sent/received over the WAN inter= face. The reason for this is that the level of traffic needs to be captured= to determine the impact on different tests and different results. The threshold will be varied depending on bot= h the test that was running and the analysis being performed.

&n= bsp;

Further= more it can also be used to determine the effectiveness of test back-off pr= ocedures in the presence of user traffic and to analyse the impact the test= s are having on user experience.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 09 October 2013 20:57
To: lmap@ietf.org
Subject: [lmap] LMAP Information Model - BBF Questions and Comments<= o:p>

 

Hello,

 

During the 3Q2013 BBF meeting, the BBHome group had = an opportunity to review the LMAP information model.

I have tried to incorporate the comments and questio= ns here:

 

1)      It was unclear what the definition was for the Cros= sTraffic attribute.

Upon further discussion in the group we thought that= the CrossTraffic parameter was an indication that the Result of a measurem= ent might be suspect because there was other traffic detected by the measur= ement agent that might cause an invalid measurement.

 

If this is true – should we rename this attrib= ute to something like SuspectResult and type it as a Boolean?

 

I also suggest this description:

This parameter indicates if the measurement agent has determined th= at the result may be suspect. Events that cause a result to be suspect is specific to the implementation of the measurement agent b= ut may include events such as indications of other traffic or an unusual CP= U load that may interfere with test.

 

2)   = ;  In the Measurement Ag= ent there is an attribute supported measurements that is a list of entries = to the Registry

This seems fine; the group di= d ask for a clarification if a device could support more than one Measureme= nt Agent.

 

3)   = ;  When we reviewed the = Options for a Task we were not sure if this was something where each option= was a Name/Value pair that could be individually maintained or if they options should be maintained as a bulk list of Name/Value pairs= . What this would mean is if you wanted to add, edit or delete on option yo= u have to resend entire option list.

 

 

Thoughts?

 

Thanks,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F771FA8BDUS70UWXCHMBA05zam_-- From trevor.burbridge@bt.com Mon Oct 21 03:52:48 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7372C11E826B for ; Mon, 21 Oct 2013 03:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ohv9B6nWewX for ; Mon, 21 Oct 2013 03:52:39 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5CC11E8197 for ; Mon, 21 Oct 2013 03:52:30 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 21 Oct 2013 11:52:29 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.44]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 21 Oct 2013 11:52:29 +0100 From: To: , , Date: Mon, 21 Oct 2013 11:52:28 +0100 Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwBNwgFQAAu9HOABI66CwAADTIjgAAAg/nAAADVZEADCwa6AAAQH12AAAKj2QA== Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F56FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F8721@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F8757@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771FA8BD@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F771FA8BD@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72C30114CB8EMV64UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 10:52:48 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72C30114CB8EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What other MA-reportable conditions (other than cross-traffic)? If the case is strong enough then I'd say these need to be additional colum= ns in the measurement report. For cross traffic it would probably be total bytes sent/received over the b= roadband interface (that the test was using) for the duration of the test. = This could be total bytes (from which we then subtract test traffic, but wo= uld be better pre-calculated as bytes of non-test traffic (so the test does= not need to report test bytes sent/received if not otherwise desired). Trevor. From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 21 October 2013 11:31 To: Burbridge,T,Trevor,TUB8 R; Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Trevor, So then what do we do about measurements that are suspect for other conditi= ons than cross traffic? Could you provide a good, description that could be used in the Information= model for Cross Traffic that would cover all possible eventualities. The reason for the description is that we would want developers to implemen= t the element in such a way that 2 implementations would have the same resu= lt for the same test instance.... BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Monday, October 21, 2013 3:35 AM To: Carey, Timothy (Timothy); philip.eardley@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Sorry - I've been away. I still think the best way is to simply report the= bytes of cross-traffic. What I tried to get across in my first response is= that the level I want to filter at is not simply dependent on the test bei= ng operated. It will also depend on what I am trying to do with the data. I= t is a simple approach that covers all possible eventualities. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 17 October 2013 12:37 To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments You could but then you have to specify the domain of what is suspected. It = would be list because there could be multiple conditions. From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Thursday, October 17, 2013 1:32 PM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Perhaps a 'suspect code' rather than a boolean [cross-traffic, CPU on MA, o= verload on Measurement Peer, etc] ? From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 17 October 2013 12:27 To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Yes that is the way I have seen the Suspect Boolean used. From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Thursday, October 17, 2013 11:56 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I wonder if both things are valid: - For all (?) tests, it would be interesting to report that the MA s= uspects the results may be dodgy. - For specific tests it may be interesting to know the amount of cro= ss-traffic. A lot of cross-traffic may or may not indicate that the result = is dodgy phil From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 11 October 2013 15:43 To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments Trevor, But isn't what you are describing elements of what would be considered the = "context" of the test result; which changes based on the test I would imagi= ne. Maybe that is all that is necessary is to flush out all the elements yo= u want to place in the context? BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Friday, October 11, 2013 4:08 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I think that cross-traffic should not be a simple Boolean, nor subsumed int= o a general 'suspect' parameter. It needs to be a counter such as bytes of traffic sent/received over the WA= N interface. The reason for this is that the level of traffic needs to be c= aptured to determine the impact on different tests and different results. T= he threshold will be varied depending on both the test that was running and= the analysis being performed. Furthermore it can also be used to determine the effectiveness of test back= -off procedures in the presence of user traffic and to analyse the impact t= he tests are having on user experience. Trevor. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 09 October 2013 20:57 To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72C30114CB8EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What other MA-reportable conditions (other than cross-traffic= )?

=  

If the case is strong enough then I’d say these need to be additi= onal columns in the measurement report.

 

For cross traffic it would proba= bly be total bytes sent/received over the broadband interface (that the tes= t was using) for the duration of the test. This could be total bytes (from = which we then subtract test traffic, but would be better pre-calculated as = bytes of non-test traffic (so the test does not need to report test bytes s= ent/received if not otherwise desired).

 

Trevor.

 

 

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
<= b>Sent: 21 October 2013 11:31
To: Burbridge,T,Trevor,TUB8 R; = Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: LMAP Informa= tion Model - BBF Questions and Comments

 

Trevor,

 

=

So then wha= t do we do about measurements that are suspect for other conditions than cr= oss traffic?

 

Could you provide a good, descripti= on that could be used in the Information model for Cross Traffic that would= cover all possible eventualities.

The reason for the description= is that we would want developers to implement the element in such a way th= at 2 implementations would have the same result for the same test instance&= #8230;.

 

BR,

Tim

=

 =

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.c= om]
Sent: Monday, October 21, 2013 3:35 AM
To: Car= ey, Timothy (Timothy); philip.eard= ley@bt.com; lmap@ietf.org
Su= bject: RE: LMAP Information Model - BBF Questions and Comments

 = ;

Sorry&= nbsp; - I’ve been away. I still think the best way is to simply repor= t the bytes of cross-traffic. What I tried to get across in my first respon= se is that the level I want to filter at is not simply dependent on the tes= t being operated. It will also depend on what I am trying to do with the da= ta. It is a simple approach that covers all possible eventualities.

 = ;

Trevor= .

<= o:p> 

Trevor Burbrid= ge
Network Infrastructure & Innovation | BT Innovate & DesignTel: 01473 645115
Fax: 01473 640929

This email contains BT information, which may be pr= ivileged or confidential. It's meant only for the individual(s) or entity n= amed above. If you're not the intended recipient, note that disclosing, cop= ying, distributing or using this information is prohibited. If you've recei= ved this email in error, please let me know immediately on the email addres= s above. Thank you.
We monitor our email system, and may record your ema= ils.
British Telecommun= ications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Reg= istered in England no: 1800000

 

= From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
<= b>Sent: 17 October 2013 12:37
To: Eardley,PL,Philip,TUB8 R; B= urbridge,T,Trevor,TUB8 R; lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comment= s

 

You could= but then you have to specify the domain of what is suspected. It would be = list because there could be multiple conditions.

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
= Sent: Thursday, October 17, 2013 1:32 PM
To: Carey, Timoth= y (Timothy); trevor.burbridge@bt= .com; lmap@ietf.org
Subject:= RE: LMAP Information Model - BBF Questions and Comments

 

Perhaps a ‘suspect code’ rat= her than a boolean [cross-traffic, CPU on MA, overload on Measurement Peer, etc]

?<= span style=3D'font-size:12.0pt;font-family:"Arial","sans-serif";color:blue'= >

 

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

From: Care= y, Timothy (Timothy) [m= ailto:timothy.carey@alcatel-lucent.com]
Sent: 17 October 201= 3 12:27
To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; = lmap@ietf.org
Subject: RE: L= MAP Information Model - BBF Questions and Comments

 

Yes that is the way I have seen the= Suspect Boolean used.

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, Oct= ober 17, 2013 11:56 AM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: LMAP Information= Model - BBF Questions and Comments

 

I wonder if both things are valid:

<= ![if !supportLists]>-        = For all (?) tests, it would be interesting to rep= ort that the MA suspects the results may be dodgy.

-        <= /span>For specific tests it may be interesting to= know the amount of cross-traffic. A lot of cross-traffic may or may not in= dicate that the result is dodgy

<= span style=3D'font-size:12.0pt;font-family:"Arial","sans-serif";color:blue'= > 

phil<= /p>

 

=

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timo= thy (Timothy)
Sent: 11 October 2013 15:43
To: Burbridge= ,T,Trevor,TUB8 R; lmap@ietf.org
= Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments=

 

Trevor,

 

But isn’t what you are describing elements o= f what would be considered the “context” of the test result; wh= ich changes based on the test I would imagine. Maybe that is all that is ne= cessary is to flush out all the elements you want to place in the context?<= o:p>

 

BR,

Tim

 

 

From:= trevor.burbridg= e@bt.com [mailto:trevor.burb= ridge@bt.com]
Sent: Friday, October 11, 2013 4:08 AM
T= o: Carey, Timothy (Timothy); lmap@ietf= .org
Subject: RE: LMAP Information Model - BBF Questions and = Comments

 

I think that cross-traffic should not be a simple Boolean, nor= subsumed into a general ‘suspect’ parameter.=

 

It needs to be a= counter such as bytes of traffic sent/received over the WAN interface. The= reason for this is that the level of traffic needs to be captured to deter= mine the impact on different tests and different results. The threshold wil= l be varied depending on both the test that was running and the analysis be= ing performed.

 

Furthermore it can also be used to determine the effectiven= ess of test back-off procedures in the presence of user traffic and to anal= yse the impact the tests are having on user experience.

 

Trevor.=

 

&nbs= p;

From:= lmap-bounces@ietf= .org [mailto:lmap-bounces@ietf= .org] On Behalf Of Carey, Timothy (Timothy)
Sent: 09 O= ctober 2013 20:57
To: lmap@ietf.= org
Subject: [lmap] LMAP Information Model - BBF Questions an= d Comments

 = ;

Hello,=

 

During the 3Q2013 BBF meeting, the BBH= ome group had an opportunity to review the LMAP information model.

I have tried to incorp= orate the comments and questions here:

 

1)    &nb= sp; It was unclear what t= he definition was for the CrossTraffic attribute.

Upon further discussion in the group we= thought that the CrossTraffic parameter was an indication that the Result = of a measurement might be suspect because there was other traffic detected = by the measurement agent that might cause an invalid measurement.

 

If this is true – should= we rename this attribute to something like SuspectResult and type it as a = Boolean?

=  

I also sugge= st this description:

This parameter indicates if the = measurement agent has determined that the result may be suspect. Events tha= t cause a result to be suspect is specific to the implementation of the mea= surement agent but may include events such as indications of other traffic = or an unusual CPU load that may interfere with test.=

 

= 2)     In the Measurement Agent there is an attribute supported measurements that= is a list of entries to the Registry

This seems fine; the group did ask for a clarification= if a device could support more than one Measurement Agent.

 

3)  =    When we reviewe= d the Options for a Task we were not sure if this was something where each = option was a Name/Value pair that could be individually maintained or if th= ey options should be maintained as a bulk list of Name/Value pairs. What th= is would mean is if you wanted to add, edit or delete on option you have to= resend entire option list.

 

 

Thoughts= ?

 

Thanks,=

Tim=

= --_000_ED51D9282D1D3942B9438CA8F3372EB72C30114CB8EMV64UKRDdoma_-- From timothy.carey@alcatel-lucent.com Mon Oct 21 03:55:12 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DB011E8396 for ; Mon, 21 Oct 2013 03:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.428 X-Spam-Level: X-Spam-Status: No, score=-9.428 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bnT6pd7jHbe for ; Mon, 21 Oct 2013 03:54:57 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C665C11E8190 for ; Mon, 21 Oct 2013 03:54:55 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9LAsppE012848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Oct 2013 05:54:51 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9LAsoTY016843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 06:54:50 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 21 Oct 2013 06:54:50 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: LMAP Information Model - BBF Questions and Comments Thread-Index: Ac7FKbhJj9RDr8+bRqmjCzepA0tzbwBNwgFQAAu9HOABI66CwAADTIjgAAAg/nAAADVZEADCwa6AAAQH12AAAKj2QAAAQ1Pw Date: Mon, 21 Oct 2013 10:54:49 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F771FA9BC@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F771F3EFE@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F56FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F8721@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771F8757@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F771FA8BD@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F771FA9BCUS70UWXCHMBA05zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 10:55:12 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F771FA9BCUS70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable High CPU load in the MA or MA peer for one, right? From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Monday, October 21, 2013 5:52 AM To: Carey, Timothy (Timothy); philip.eardley@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments What other MA-reportable conditions (other than cross-traffic)? If the case is strong enough then I'd say these need to be additional colum= ns in the measurement report. For cross traffic it would probably be total bytes sent/received over the b= roadband interface (that the test was using) for the duration of the test. = This could be total bytes (from which we then subtract test traffic, but wo= uld be better pre-calculated as bytes of non-test traffic (so the test does= not need to report test bytes sent/received if not otherwise desired). Trevor. From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 21 October 2013 11:31 To: Burbridge,T,Trevor,TUB8 R; Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Trevor, So then what do we do about measurements that are suspect for other conditi= ons than cross traffic? Could you provide a good, description that could be used in the Information= model for Cross Traffic that would cover all possible eventualities. The reason for the description is that we would want developers to implemen= t the element in such a way that 2 implementations would have the same resu= lt for the same test instance.... BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Monday, October 21, 2013 3:35 AM To: Carey, Timothy (Timothy); philip.eardley@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Sorry - I've been away. I still think the best way is to simply report the= bytes of cross-traffic. What I tried to get across in my first response is= that the level I want to filter at is not simply dependent on the test bei= ng operated. It will also depend on what I am trying to do with the data. I= t is a simple approach that covers all possible eventualities. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 17 October 2013 12:37 To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments You could but then you have to specify the domain of what is suspected. It = would be list because there could be multiple conditions. From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Thursday, October 17, 2013 1:32 PM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Perhaps a 'suspect code' rather than a boolean [cross-traffic, CPU on MA, o= verload on Measurement Peer, etc] ? From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: 17 October 2013 12:27 To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments Yes that is the way I have seen the Suspect Boolean used. From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Thursday, October 17, 2013 11:56 AM To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I wonder if both things are valid: - For all (?) tests, it would be interesting to report that the MA su= spects the results may be dodgy. - For specific tests it may be interesting to know the amount of cros= s-traffic. A lot of cross-traffic may or may not indicate that the result i= s dodgy phil From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 11 October 2013 15:43 To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comments Trevor, But isn't what you are describing elements of what would be considered the = "context" of the test result; which changes based on the test I would imagi= ne. Maybe that is all that is necessary is to flush out all the elements yo= u want to place in the context? BR, Tim From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Friday, October 11, 2013 4:08 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments I think that cross-traffic should not be a simple Boolean, nor subsumed int= o a general 'suspect' parameter. It needs to be a counter such as bytes of traffic sent/received over the WA= N interface. The reason for this is that the level of traffic needs to be c= aptured to determine the impact on different tests and different results. T= he threshold will be varied depending on both the test that was running and= the analysis being performed. Furthermore it can also be used to determine the effectiveness of test back= -off procedures in the presence of user traffic and to analyse the impact t= he tests are having on user experience. Trevor. From: lmap-bounces@ietf.org [mailto:lmap-boun= ces@ietf.org] On Behalf Of Carey, Timothy (Timothy) Sent: 09 October 2013 20:57 To: lmap@ietf.org Subject: [lmap] LMAP Information Model - BBF Questions and Comments Hello, During the 3Q2013 BBF meeting, the BBHome group had an opportunity to revie= w the LMAP information model. I have tried to incorporate the comments and questions here: 1) It was unclear what the definition was for the CrossTraffic attribu= te. Upon further discussion in the group we thought that the CrossTraffic param= eter was an indication that the Result of a measurement might be suspect be= cause there was other traffic detected by the measurement agent that might = cause an invalid measurement. If this is true - should we rename this attribute to something like Suspect= Result and type it as a Boolean? I also suggest this description: This parameter indicates if the measurement agent has determined that the r= esult may be suspect. Events that cause a result to be suspect is specific = to the implementation of the measurement agent but may include events such = as indications of other traffic or an unusual CPU load that may interfere w= ith test. 2) In the Measurement Agent there is an attribute supported measurement= s that is a list of entries to the Registry This seems fine; the group did ask for a clarification if a device could su= pport more than one Measurement Agent. 3) When we reviewed the Options for a Task we were not sure if this was= something where each option was a Name/Value pair that could be individual= ly maintained or if they options should be maintained as a bulk list of Nam= e/Value pairs. What this would mean is if you wanted to add, edit or delete= on option you have to resend entire option list. Thoughts? Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F771FA9BCUS70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

High CPU load in the M= A or MA peer for one, right?

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Monday, October 21, 2013 5:52 AM
To: Carey, Timothy (Timothy); philip.eardley@bt.com; lmap@ietf.org Subject: RE: LMAP Information Model - BBF Questions and Comments

 

What ot= her MA-reportable conditions (other than cross-traffic)?<= /p>

&n= bsp;

If the = case is strong enough then I’d say these need to be additional column= s in the measurement report.

&n= bsp;

For cro= ss traffic it would probably be total bytes sent/received over the broadban= d interface (that the test was using) for the duration of the test. This co= uld be total bytes (from which we then subtract test traffic, but would be better pre-calculated as bytes of non-= test traffic (so the test does not need to report test bytes sent/received = if not otherwise desired).

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

From: Carey, T= imothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: 21 October 2013 11:31
To: Burbridge,T,Trevor,TUB8 R; Eardley,PL,Philip,TUB8 R; lmap@ietf.o= rg
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

Trevor,

 

So then what do we do = about measurements that are suspect for other conditions than cross traffic= ?

 

Could you provide a go= od, description that could be used in the Information model for Cross Traff= ic that would cover all possible eventualities.

The reason for the des= cription is that we would want developers to implement the element in such = a way that 2 implementations would have the same result for the same test i= nstance….

 

BR,<= /p>

Tim<= /p>

 

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Monday, October 21, 2013 3:35 AM
To: Carey, Timothy (Timothy); philip.eardley@bt.com; lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

Sorry&n= bsp; - I’ve been away. I still think the best way is to simply report= the bytes of cross-traffic. What I tried to get across in my first respons= e is that the level I want to filter at is not simply dependent on the test being operated. It will also depend on what I am try= ing to do with the data. It is a simple approach that covers all possible e= ventualities.

&n= bsp;

Trevor.=

&n= bsp;

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

This email contains BT inform= ation, which may be privileged or confidential. It's meant only for the ind= ividual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this infor= mation is prohibited. If you've received this email in error, please let me= know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

&n= bsp;

From: Carey, T= imothy (Timothy) [mailt= o:timothy.carey@alcatel-lucent.com]
Sent: 17 October 2013 12:37
To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

You could but then you= have to specify the domain of what is suspected. It would be list because = there could be multiple conditions.

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, October 17, 2013 1:32 PM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

Perhaps a ̵= 6;suspect code’ rather than a boolean [cross-traffic, CPU on MA, over= load on Measurement Peer, etc]<= o:p>

?

 

From: Carey, T= imothy (Timothy) [mailt= o:timothy.carey@alcatel-lucent.com]
Sent: 17 October 2013 12:27
To: Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

Yes that is the way I = have seen the Suspect Boolean used.

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, October 17, 2013 11:56 AM
To: Carey, Timothy (Timothy); trevor.burbridge@bt.com; lmap@ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

I wonder if bot= h things are valid:

-       For all= (?) tests, it would be interesting to report that the MA suspects the resu= lts may be dodgy.

-       For spe= cific tests it may be interesting to know the amount of cross-traffic. A lo= t of cross-traffic may or may not indicate that the result is dodgy

 

phil=

 

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 11 October 2013 15:43
To: Burbridge,T,Trevor,TUB8 R; lmap= @ietf.org
Subject: Re: [lmap] LMAP Information Model - BBF Questions and Comme= nts

 

Trevor,

 

But isn’t what y= ou are describing elements of what would be considered the “context&#= 8221; of the test result; which changes based on the test I would imagine. = Maybe that is all that is necessary is to flush out all the elements you want to place in the context?

 

BR,<= /p>

Tim<= /p>

 

 

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Friday, October 11, 2013 4:08 AM
To: Carey, Timothy (Timothy); lmap@= ietf.org
Subject: RE: LMAP Information Model - BBF Questions and Comments

 

I think= that cross-traffic should not be a simple Boolean, nor subsumed into a gen= eral ‘suspect’ parameter.

&n= bsp;

It need= s to be a counter such as bytes of traffic sent/received over the WAN inter= face. The reason for this is that the level of traffic needs to be captured= to determine the impact on different tests and different results. The threshold will be varied depending on bot= h the test that was running and the analysis being performed.

&n= bsp;

Further= more it can also be used to determine the effectiveness of test back-off pr= ocedures in the presence of user traffic and to analyse the impact the test= s are having on user experience.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 09 October 2013 20:57
To: lmap@ietf.org
Subject: [lmap] LMAP Information Model - BBF Questions and Comments<= o:p>

 

Hello,

 

During the 3Q2013 BBF meeting, the BBHome group had = an opportunity to review the LMAP information model.

I have tried to incorporate the comments and questio= ns here:

 

1)      It was unclear what the definition was for the Cros= sTraffic attribute.

Upon further discussion in the group we thought that= the CrossTraffic parameter was an indication that the Result of a measurem= ent might be suspect because there was other traffic detected by the measur= ement agent that might cause an invalid measurement.

 

If this is true – should we rename this attrib= ute to something like SuspectResult and type it as a Boolean?

 

I also suggest this description:

This parameter indicates if the measurement agent has determined th= at the result may be suspect. Events that cause a result to be suspect is specific to the implementation of the measurement agent b= ut may include events such as indications of other traffic or an unusual CP= U load that may interfere with test.

 

2)   = ;  In the Measurement Ag= ent there is an attribute supported measurements that is a list of entries = to the Registry

This seems fine; the group di= d ask for a clarification if a device could support more than one Measureme= nt Agent.

 

3)   = ;  When we reviewed the = Options for a Task we were not sure if this was something where each option= was a Name/Value pair that could be individually maintained or if they options should be maintained as a bulk list of Name/Value pairs= . What this would mean is if you wanted to add, edit or delete on option yo= u have to resend entire option list.

 

 

Thoughts?

 

Thanks,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F771FA9BCUS70UWXCHMBA05zam_-- From internet-drafts@ietf.org Mon Oct 21 08:52:42 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785BF11E81C4; Mon, 21 Oct 2013 08:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KChp3Gu+OnK; Mon, 21 Oct 2013 08:52:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF2521F9D18; Mon, 21 Oct 2013 08:52:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021155203.29521.23770.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 08:52:03 -0700 Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 15:52:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Large-Scale Measurement of Broadband Perf= ormance Working Group of the IETF. Title : A framework for large-scale measurement platforms (LMAP) Author(s) : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-01.txt Pages : 40 Date : 2013-10-21 Abstract: Measuring broadband service on a large scale requires standardisation of the logical architecture and a description of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (large-scale measurement platforms). The document is a contribution towards the LMAP working group's milestone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-framework-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-framework-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From marcelo@it.uc3m.es Mon Oct 21 12:29:19 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E5C11E85D7 for ; Mon, 21 Oct 2013 12:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.166 X-Spam-Level: X-Spam-Status: No, score=-103.166 tagged_above=-999 required=5 tests=[AWL=3.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odpWC8PnRuIb for ; Mon, 21 Oct 2013 12:29:15 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 0466211E8242 for ; Mon, 21 Oct 2013 12:29:12 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DDA0CCD6B25 for ; Mon, 21 Oct 2013 21:29:10 +0200 (CEST) X-uc3m-safe: yes Received: from [163.117.203.238] (unknown [163.117.203.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id B612CCB7E8C for ; Mon, 21 Oct 2013 21:29:10 +0200 (CEST) Message-ID: <52658086.2050103@it.uc3m.es> Date: Mon, 21 Oct 2013 21:29:10 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "lmap@ietf.org" References: <20131021185529.32508.89992.idtracker@ietfa.amsl.com> In-Reply-To: <20131021185529.32508.89992.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131021185529.32508.89992.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Mon, 21 Oct 2013 21:29:10 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20234.001 Subject: [lmap] Fwd: I-D Action: draft-burbridge-lmap-information-model-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:29:20 -0000 Hi, We have submitted a new version of the information model. This new version has a few changes from the previous one, including the generalization of the channels to express the different communication channels with the controller and collector for instructions, capabilities discovery and logging as well report. Comments are welcome. Regards, marcelo -------- Mensaje original -------- Asunto: I-D Action: draft-burbridge-lmap-information-model-01.txt Fecha: Mon, 21 Oct 2013 11:55:29 -0700 De: internet-drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Author(s) : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-burbridge-lmap-information-model-01.txt Pages : 17 Date : 2013-10-21 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the MA or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the MA that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-burbridge-lmap-information-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-burbridge-lmap-information-model-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-burbridge-lmap-information-model-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From bclaise@cisco.com Fri Oct 25 07:32:51 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8134911E8381 for ; Fri, 25 Oct 2013 07:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQnm5fVEWLyO for ; Fri, 25 Oct 2013 07:32:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E5CC611E8316 for ; Fri, 25 Oct 2013 07:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2919; q=dns/txt; s=iport; t=1382711565; x=1383921165; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LKJHutkIh0YsRh6S8W332a9xm3nAHRAqkhypm6jHds0=; b=GInsUvOhtibf1gEOU9KIeQ7roypMnu0UZhLSe6jG/HwTLTKpHpGwoRFB Ig2VPBWi77B4JW83g0bg2i6i6px281a+96glnJdjUnvNsMpbWeMlYw1N3 FVoXfZfrh3LCSaT8AgOex17jDx5B1L6AqznaXFvOr+IBRh/cpegshvfr/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAPh/alKQ/khM/2dsb2JhbABZgwc4vx2BIhZ0giUBAQEEAQEBNRElCgEMBAsQAQQBAQoWCAcJAwIBAgEVHwkIBg0BBQIBAYgDDbk6j1MHBoQmA5gKgS+FDItMgyg6 X-IronPort-AV: E=Sophos;i="4.93,570,1378857600"; d="scan'208";a="87662001" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 25 Oct 2013 14:32:37 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9PEWYUp023499; Fri, 25 Oct 2013 14:32:35 GMT Message-ID: <526A8100.8020603@cisco.com> Date: Fri, 25 Oct 2013 16:32:32 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <6BECB2CA-D8CC-4562-A98B-661F37FDEEC7@jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA128DEAFA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128DEAFA@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bajpai, Vaibhav" , "" Subject: Re: [lmap] LMAP acronym X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Oct 2013 14:32:51 -0000 Dear all, Coming back to the LMAP WG acronym. While discussing with some regulators, I realized that there is some confusion coming from the WG name: Large-Scale Measurement of Broadband Performance. By simply reading the WG name, some people thought the WG was only involved in the broadband performance, ie the last mile metrics. The charter clarifies this: LMAP measurement system for performance measurements of broadband access devices Regards, Benoit > I suggest to use the expansion of acronyms in the charter. > > Regards, > > Dan > > > > >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >> Bajpai, Vaibhav >> Sent: Thursday, September 19, 2013 1:07 PM >> To: >> Cc: Bajpai, Vaibhav >> Subject: [lmap] LMAP acronym >> >> LMAP, >> >> What does the acronym LMAP stand for? I ask because I see a bunch of >> expansions used in the current documents (below). Wouldn't it be nice to >> sync this into one expansion? >> >> Thanks! >> >> Best, Vaibhav >> >> - Webpages: >> >> lmap -- Large-Scale Measurement of Broadband Performance [1] lmap -- >> Large Scale Measurement of Access network Performance [2] >> >> [1] http://datatracker.ietf.org/wg/lmap/charter >> [2] https://www.ietf.org/mailman/listinfo/lmap >> >> - Internet Drafts: >> >> lmap -- Large MeAsurement Platforms [1,2] lmap -- Large-Scale >> Measurement Platforms [3,4] lmap -- Large-Scale Measurement of Broadband >> Performance [5,6,7,8] lmap -- Large scale Measurement of Access network >> Performance [9] lmap -- large scale measurement of broadband performance >> [10] >> >> [1] http://tools.ietf.org/html/draft-eardley-lmap-terminology-02 >> [2] http://tools.ietf.org/html/draft-bagnulo-lmap-http-00 >> [3] http://tools.ietf.org/html/draft-burbridge-lmap-information-model-00 >> [4] http://tools.ietf.org/html/draft-bagnulo-lmap-ipfix-01 >> [5] http://tools.ietf.org/html/draft-eardley-lmap-framework-02 >> [6] http://tools.ietf.org/html/draft-akhter-lmap-framework-00 >> [7] http://tools.ietf.org/html/draft-seedorf-lmap-alto-01 >> [8] http://tools.ietf.org/html/draft-schoenw-lmap-netconf-00 >> [9] http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00 >> [10] http://tools.ietf.org/html/draft-huang-lmap-data-collection-use- >> case-00 >> >> ----------------------------------------------------- >> Vaibhav Bajpai >> >> Research I, Room 86 >> Computer Networks and Distributed Systems (CNDS) Lab School of >> Engineering and Sciences Jacobs University Bremen, Germany >> >> www.vaibhavbajpai.com >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > . > From bclaise@cisco.com Fri Oct 25 07:50:02 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335ED21F9FCA for ; Fri, 25 Oct 2013 07:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eriDm5gUl9i7 for ; Fri, 25 Oct 2013 07:49:57 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id D3A1711E819B for ; Fri, 25 Oct 2013 07:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5735; q=dns/txt; s=iport; t=1382712595; x=1383922195; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=DY98fbPp/F6utFv2ITsYork9cPK0qvpVktrwNOOmm2s=; b=e8Roe+b21gweoSKKLVQEKxvvqnUwV1NTNxPIa6mscOepAwwDkkZI/urj AR7i58j/YE32pZBR6y+Cb9Cfz3bdnupW5cr6SruiMIXDTaZ8zZr1IHLkf XeVFwr9h3c5Wp0iw5abAk9CL1BGhzSn6Jx/Xl0savSkLt2vXJPqPt+C58 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAOaEalKQ/khR/2dsb2JhbABZgwc4iUS1WYEiFnSCJQEBAQR4AQwECxEEAQEKDAoIBwkDAgECATQIAQgGDQEFAgEBBRKHbA25K49TBwYEhCIDmAqGO4tMgWiBQDo X-IronPort-AV: E=Sophos;i="4.93,570,1378857600"; d="scan'208,217";a="18537813" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 25 Oct 2013 14:49:53 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9PEnmWw013482; Fri, 25 Oct 2013 14:49:50 GMT Message-ID: <526A850C.5050604@cisco.com> Date: Fri, 25 Oct 2013 16:49:48 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA1290F4A1@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1290F4A1@AZ-FFEXMB04.global.avaya.com> Content-Type: multipart/alternative; boundary="------------060808080504080804000909" Cc: "lmap@ietf.org" Subject: Re: [lmap] FW: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Oct 2013 14:50:02 -0000 This is a multi-part message in MIME format. --------------060808080504080804000909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I attended this NMRG meeting. Great content. A couple of high level points: - perfSonar, RIPE atlas, samknows, bismark, grenouille, etc: which one to chose? It's not easy. That stresses the need for LMAP standardization :-) - I liked very much this paper/presentation, which attempts to categorize the measurement agents: "Router-based and client-based platforms for performance measurement and censorship detection", by Alessio Botta 1. Server-based, ISP-based service-based core-based 2. router-based 3. host-based client-based web-based plugin-based embedded - When the control protocol, reporting protocol, and performance metrics will be standardized, the next task will be to have a standardized capability discovery. Maybe https://datatracker.ietf.org/wg/dnssdext/charter/ might help. - I like the fact that two research projects (mPlane and Leone) are actively participating in the group. mPlane was presented - There is an interesting paper (Designing Active Measurements for YouTube, Saba Ahsan) that tests the top videos from the youtube page. I've always wondering what could be a good universal test for all MAs, taking into account that we will have many MAs. Maybe that's a solution? Regards, Benoit > > > -----Original Message----- > From: nmrg-bounces@irtf.org [mailto:nmrg-bounces@irtf.org] On Behalf Of Juergen Schoenwaelder > Sent: Friday, October 18, 2013 3:32 PM > To: nmrg@irtf.org > Subject: Re: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements > > Hi, > > the slides presented on Monday have been uploaded to the IETF interim meetings tracker. You can find the material here: > > http://www.ietf.org/proceedings/interim/2013/10/14/nmrg/proceedings.html > > Thanks to everybody who participated in this meeting. > > /js > --------------060808080504080804000909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

I attended this NMRG meeting. Great content.

A couple of high level points:
- perfSonar, RIPE atlas, samknows, bismark, grenouille, etc: which one to chose? It's not easy.
  That stresses the need for LMAP standardization :-)
- I liked very much this paper/presentation, which attempts to categorize the measurement agents: "Router-based and client-based platforms for performance measurement and censorship detection", by Alessio Botta
    1. Server-based,
        ISP-based
        service-based
        core-based
    2. router-based
    3. host-based
        client-based
        web-based
                plugin-based
                embedded
- When the control protocol, reporting protocol, and performance metrics will be standardized, the next task will be to have a standardized capability discovery. Maybe https://datatracker.ietf.org/wg/dnssdext/charter/ might help.
- I like the fact that two research projects (mPlane and Leone) are actively participating in the group. mPlane was presented
- There is an interesting paper (Designing Active Measurements for YouTube, Saba Ahsan) that tests the top videos from the youtube page. I've always wondering what could be a good universal test for all MAs, taking into account that we will have many MAs. Maybe that's a solution?

Regards, Benoit


-----Original Message-----
From: nmrg-bounces@irtf.org [mailto:nmrg-bounces@irtf.org] On Behalf Of Juergen Schoenwaelder
Sent: Friday, October 18, 2013 3:32 PM
To: nmrg@irtf.org
Subject: Re: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements

Hi,

the slides presented on Monday have been uploaded to the IETF interim meetings tracker. You can find the material here:

http://www.ietf.org/proceedings/interim/2013/10/14/nmrg/proceedings.html

Thanks to everybody who participated in this meeting.

/js

--------------060808080504080804000909-- From jerome.benoit@grenouille.com Fri Oct 25 21:10:37 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B10411E80D9 for ; Fri, 25 Oct 2013 21:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_AFFORDABLE=1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DggW5PQWpA3A for ; Fri, 25 Oct 2013 21:10:33 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id BFE5C21F9AA2 for ; Fri, 25 Oct 2013 21:10:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id B61FD7F033 for ; Sat, 26 Oct 2013 06:10:28 +0200 (CEST) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIofBCLYPxfC for ; Sat, 26 Oct 2013 06:10:20 +0200 (CEST) Date: Sat, 26 Oct 2013 06:10:19 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: lmap@ietf.org Message-ID: <20131026061019.25539665@nemesis> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1290F4A1@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA1290F4A1@AZ-FFEXMB04.global.avaya.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/=RY2fuxS5+uKe=igkW_WS4x"; protocol="application/pgp-signature" Subject: Re: [lmap] FW: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 04:10:37 -0000 --Sig_/=RY2fuxS5+uKe=igkW_WS4x Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, 20 Oct 2013 08:22:34 +0000 in <9904FB1B0159DA42B0B887B7FA8119CA1290F4A1@AZ-FFEXMB04.global.avaya.com>, "Romascanu, Dan (Dan)" wrote: >=20 >=20 >=20 > -----Original Message----- > From: nmrg-bounces@irtf.org [mailto:nmrg-bounces@irtf.org] On Behalf Of J= uergen Schoenwaelder > Sent: Friday, October 18, 2013 3:32 PM > To: nmrg@irtf.org > Subject: Re: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale = network measurements >=20 > Hi, >=20 > the slides presented on Monday have been uploaded to the IETF interim mee= tings tracker. You can find the material here: >=20 > http://www.ietf.org/proceedings/interim/2013/10/14/nmrg/proceedings.html >=20 > Thanks to everybody who participated in this meeting. OK at a first run.=20 But after a review, how do handle measurement data abstraction ? Just review the RIPE data representation of tracerouting measurement ... how as the state state it stand, it will handle router load-balancing - it's just a binary tree with two state along the discovered path - ?=20 Can I be in an irreverence wheel beside the current WG LMAP orientation ?=20 "Availability should also be considered. While the loss of some MAs ... etc."=20 How many MAs are relevant to a specific measurement to be runt to give exploitable datas ? --> should be a configurable specific to a measurement.=20 How would you anonimyze data from a specific MA ?=20 I take the global architecture from the current draft :=20 https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ If I'm just mistaken about the current work on LMAP, just tell me to shout "down" the volume :=20 MA and MP should not the differentiated, it's just the same agent inside the measurement system that just do different things. That the all beauty to design an MA that just permit to do end to end measurement, MAs *all* plays different roles inside the measurement system, just like the end to end exchange protocol designed by researcher, engineer at IETF.=20 If you miss by design the the end to end design goal aspect of the LMAP architecture ... you just miss the Internet design .... and missing the Internet design inside a measurement system that should assess the quality of end to end communication inside a commuted/switched packet network design that cherish end to end exchange is just like missing to design a wheel on a car (ok, enough of sophisms to sustain my point of view) :=20 Do not do differentiate MA and MP functionalities inside the Large-Scale measurement system, it's just a design mistake that will go so far far away from the UDP or TCP design choices.=20 First of all, a packet is a packet, its being NATed, its being QoSed, its being emitted from the CPE, its being proxyed ... I just do not care, it's just a another information : MA should care about the different aspect of emission or reception traceability, what I think the LMAP should just care is about end to end aspects of gathering metrics about a very simple packet emission and reception.=20 How do you conceive just a ICMP, UDP, TCP ping measurement between two MAs in the current Internet network in the G8 countries inside the current LMAP framework ? ('cause, do not mistake on the economic aspect of the LMAP work, it's just for the G8 countries where BW is not the bottleneck, technically and financially, all the other countries just have to sit and wait for an affordable BW to begin with, yes I'm digressing and who cares ?). So to design an LMAP that will fit different goals, just :=20 - do not miss end to end aspects of current running Internet;=20 - do not miss end to end aspects of current running Internet;=20 - do not miss end to end aspects of current running Internet in G8 countries. repeat: begin with simple IPPM measurements and ask yourself : how I implement it inside the LMAP point by point, technical aspect by aspect, design choice by design choice ?;=20 goto repeat;=20 then=20 factorize design aspects, measurements by measurements.=20 What I'm just telling you : take the conception problem from the other side. That's all :) Have a lot of fun.=20 I will try to stay in background to review everything I can from LMAP and IPPM WGs, in details. Not just from the an high and comfortable place : criticize work and do not participate :) Cheers.=20 --=20 J=E9r=F4me Benoit aka fraggle OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/=RY2fuxS5+uKe=igkW_WS4x Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlJrQKsACgkQ+qDLUJ/pFh3HmwCgjtUX2fW0JQp5NXrRQ7wfaBkl A1AAoK4FQD24ohsDD9XG7Lr6rgC0pVll =5pyF -----END PGP SIGNATURE----- --Sig_/=RY2fuxS5+uKe=igkW_WS4x-- From dromasca@avaya.com Mon Oct 28 04:05:30 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5297911E811D for ; Mon, 28 Oct 2013 04:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, GB_AFFORDABLE=1, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z2PEPnnlubS for ; Mon, 28 Oct 2013 04:05:24 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 10C2A11E8175 for ; Mon, 28 Oct 2013 04:05:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgILAHNEblKHCzI1/2dsb2JhbABZgmYhOFSpd5RtgSEWdIIlAQEBAQMMBhVeBAIBCA0EAQMBAQEKHQcyFAMFAQgCBAESCAEZh2UBDJtJnEgXjyQ4BoMZgQ0DiQeVZYslgWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,585,1378872000"; d="scan'208";a="34258619" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 28 Oct 2013 07:05:20 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Oct 2013 06:55:38 -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.0146.000; Mon, 28 Oct 2013 12:05:15 +0100 From: "Romascanu, Dan (Dan)" To: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= , "lmap@ietf.org" Thread-Topic: [lmap] FW: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements Thread-Index: AQHO0gFIZq3M49xyakSsIdGd4gPk05oJ9p7g Date: Mon, 28 Oct 2013 11:05:14 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12919E48@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA1290F4A1@AZ-FFEXMB04.global.avaya.com> <20131026061019.25539665@nemesis> In-Reply-To: <20131026061019.25539665@nemesis> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] FW: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 11:05:30 -0000 Hi Jerome,=20 Can you clarify what you are exactly commenting about?=20 I am confused because you respond with a message which has content and subj= ect line related to the NMRG workshop, but your comments seem to be rather = about the LMAP architecture.=20 Thanks and Regards, Dan > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > J?r?me Benoit > Sent: Saturday, October 26, 2013 6:10 AM > To: lmap@ietf.org > Subject: Re: [lmap] FW: [nmrg] 31st NMRG meeting - 1st NMRG workshop on > large scale network measurements >=20 > On Sun, 20 Oct 2013 08:22:34 +0000 in > <9904FB1B0159DA42B0B887B7FA8119CA1290F4A1@AZ-FFEXMB04.global.avaya.com>, > "Romascanu, Dan (Dan)" wrote: >=20 > > > > > > > > -----Original Message----- > > From: nmrg-bounces@irtf.org [mailto:nmrg-bounces@irtf.org] On Behalf > > Of Juergen Schoenwaelder > > Sent: Friday, October 18, 2013 3:32 PM > > To: nmrg@irtf.org > > Subject: Re: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large > > scale network measurements > > > > Hi, > > > > the slides presented on Monday have been uploaded to the IETF interim > meetings tracker. You can find the material here: > > > > http://www.ietf.org/proceedings/interim/2013/10/14/nmrg/proceedings.ht > > ml > > > > Thanks to everybody who participated in this meeting. >=20 > OK at a first run. >=20 > But after a review, how do handle measurement data abstraction ? > Just review the RIPE data representation of tracerouting measurement ... > how as the state state it stand, it will handle router load-balancing - > it's just a binary tree with two state along the discovered path - ? >=20 > Can I be in an irreverence wheel beside the current WG LMAP orientation > ? >=20 > "Availability should also be considered. While the loss of some MAs ... > etc." >=20 > How many MAs are relevant to a specific measurement to be runt to give > exploitable datas ? --> should be a configurable specific to a > measurement. >=20 >=20 > How would you anonimyze data from a specific MA ? >=20 > I take the global architecture from the current draft : > https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ >=20 > If I'm just mistaken about the current work on LMAP, just tell me to > shout "down" the volume : >=20 > MA and MP should not the differentiated, it's just the same agent inside > the measurement system that just do different things. That the all > beauty to design an MA that just permit to do end to end measurement, > MAs *all* plays different roles inside the measurement system, just like > the end to end exchange protocol designed by researcher, engineer at > IETF. >=20 > If you miss by design the the end to end design goal aspect of the LMAP > architecture ... you just miss the Internet design .... and missing the > Internet design inside a measurement system that should assess the > quality of end to end communication inside a commuted/switched packet > network design that cherish end to end exchange is just like missing to > design a wheel on a car (ok, enough of sophisms to sustain my point of > view) : >=20 > Do not do differentiate MA and MP functionalities inside the Large-Scale > measurement system, it's just a design mistake that will go so far far > away from the UDP or TCP design choices. >=20 > First of all, a packet is a packet, its being NATed, its being QoSed, > its being emitted from the CPE, its being proxyed ... I just do not > care, it's just a another information : MA should care about the > different aspect of emission or reception traceability, what I think the > LMAP should just care is about end to end aspects of gathering metrics > about a very simple packet emission and reception. > How do you conceive just a ICMP, UDP, TCP ping measurement between two > MAs in the current Internet network in the G8 countries inside the > current LMAP framework ? ('cause, do not mistake on the economic aspect > of the LMAP work, it's just for the G8 countries where BW is not the > bottleneck, technically and financially, all the other countries just > have to sit and wait for an affordable BW to begin with, yes I'm > digressing and who cares ?). So to design an LMAP that will fit > different goals, just : >=20 > - do not miss end to end aspects of current running Internet; > - do not miss end to end aspects of current running Internet; > - do not miss end to end aspects of current running Internet in G8 > countries. >=20 > repeat: > begin with simple IPPM measurements and ask yourself : how I implement > it inside the LMAP point by point, technical aspect by aspect, design > choice by design choice ?; goto repeat; then factorize design aspects, > measurements by measurements. >=20 > What I'm just telling you : take the conception problem from the other > side. That's all :) >=20 > Have a lot of fun. >=20 > I will try to stay in background to review everything I can from LMAP > and IPPM WGs, in details. Not just from the an high and comfortable > place : criticize work and do not participate :) >=20 >=20 > Cheers. >=20 > -- > J=E9r=F4me Benoit aka fraggle > OpenPGP Key ID : 9FE9161D > Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D From dromasca@avaya.com Mon Oct 28 09:18:58 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B87721F9EB5 for ; Mon, 28 Oct 2013 09:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.794 X-Spam-Level: X-Spam-Status: No, score=-102.794 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyViPJwOefjX for ; Mon, 28 Oct 2013 09:18:52 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id ED75111E8170 for ; Mon, 28 Oct 2013 09:18:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAGAI+NblKHCzI1/2dsb2JhbABZgmYhOFS+ZIEmFm0HgicBAQMSKFEBFRUUQiYBBBsah2UBDJcchEicewSPJINXgQ0DnmyLJYMmgio X-IronPort-AV: E=Sophos;i="4.93,586,1378872000"; d="scan'208";a="34309050" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 28 Oct 2013 12:18:49 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Oct 2013 12:09:11 -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.0146.000; Mon, 28 Oct 2013 12:18:47 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: final agenda? Thread-Index: Ac7T+RDBHSSocYN7TCmJckilzXROVQ== Date: Mon, 28 Oct 2013 16:18:47 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1291A811@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] final agenda? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:18:58 -0000 Today is the cut-off date for submitting the revised WG agendas for IETF-88= . Are there any changes and additions required relative to the agenda now a= vailable at https://datatracker.ietf.org/meeting/88/agenda/lmap/ ?=20 Thanks and Regards, Dan From jerome.benoit@grenouille.com Tue Oct 29 23:55:40 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A38B21E80D5 for ; Tue, 29 Oct 2013 23:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxDXpT62cBCf for ; Tue, 29 Oct 2013 23:55:35 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id D346811E80F5 for ; Tue, 29 Oct 2013 23:55:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id BB5F07F760; Wed, 30 Oct 2013 07:55:09 +0100 (CET) X-Virus-Scanned: spam & virus filtering at laposte.grenouille.com Received: from laposte.grenouille.com ([127.0.0.1]) by localhost (ns37873.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmC53E5d4AEq; Wed, 30 Oct 2013 07:55:07 +0100 (CET) Date: Wed, 30 Oct 2013 07:55:06 +0100 From: =?iso-8859-1?B?Suly9G1l?= Benoit To: "Romascanu, Dan (Dan)" Message-ID: <20131030065506.GA3923@nemesis> References: <9904FB1B0159DA42B0B887B7FA8119CA1290F4A1@AZ-FFEXMB04.global.avaya.com> <20131026061019.25539665@nemesis> <9904FB1B0159DA42B0B887B7FA8119CA12919E48@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12919E48@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "lmap@ietf.org" Subject: Re: [lmap] FW: [nmrg] 31st NMRG meeting - 1st NMRG workshop on large scale network measurements X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 06:55:40 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le Mon, Oct 28, 2013 at 11:05:14AM +0000, Romascanu, Dan (Dan) a =E9crit: > Hi Jerome, o Hello. >=20 > Can you clarify what you are exactly commenting about?=20 When time permit, I will do.=20 >=20 > I am confused because you respond with a message which has content and su= bject line related to the NMRG workshop, but your comments seem to be rathe= r about the LMAP architecture.=20 >=20 Mainly because there's talks about measurement system from the end point inside. Cheers. --=20 J=E9r=F4me Benoit aka fraggle OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlJwrUoACgkQ+qDLUJ/pFh3sxACcC04hoXcHWSbI/YJzqQ8PERrS dDIAoIUoD2C80XLzXtI010vDFX4uuh2f =B9qW -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From frode.sorensen@npt.no Wed Oct 30 07:55:16 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5704211E824A for ; Wed, 30 Oct 2013 07:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLxlKEirx9GE for ; Wed, 30 Oct 2013 07:55:06 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.250]) by ietfa.amsl.com (Postfix) with ESMTP id E704E11E822D for ; Wed, 30 Oct 2013 07:55:05 -0700 (PDT) Received: from [85.158.143.35:10043] by server-3.bemta-4.messagelabs.com id D6/4A-21600-8CD11725; Wed, 30 Oct 2013 14:55:04 +0000 X-Env-Sender: frode.sorensen@npt.no X-Msg-Ref: server-4.tower-21.messagelabs.com!1383144903!1460595!1 X-Originating-IP: [213.225.64.154] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4951 invoked from network); 30 Oct 2013 14:55:04 -0000 Received: from unknown (HELO EXCAS.npta.no) (213.225.64.154) by server-4.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 30 Oct 2013 14:55:04 -0000 Received: from EXMBX01.npta.no ([10.10.2.97]) by EXCAS.npta.no ([fe80::b007:5474:dccd:c4dd%11]) with mapi id 14.02.0347.000; Wed, 30 Oct 2013 15:55:04 +0100 From: =?iso-8859-1?Q?S=F8rensen=2C_Frode?= To: "lmap@ietf.org" Thread-Topic: LMAP regulator use case Thread-Index: Ac7VfioGb4cSexizQzSZrQa31mFanA== Date: Wed, 30 Oct 2013 14:55:02 +0000 Message-ID: <793D91975B99224DA9777562FF192808A27468CB@exmbx01> Accept-Language: nb-NO, en-US Content-Language: nb-NO X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.8.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 30 Oct 2013 08:03:06 -0700 Subject: [lmap] LMAP regulator use case X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 14:57:30 -0000 Marc, Phil, Trevor, all, I have prepared a proposed description of a regulator use case for the LMAP= use case ID. I noticed the "advertisement" for further input from regulato= rs for the use case a couple of weeks ago. Finally I have managed to find s= ufficient time to contribute to the ID, supported by a couple of "regulator= friends" from the Net Neutrality Working Group of the BEREC organization, = representing European national regulators. The proposal consists of two par= ts; a modification of section 2.2 "Regulators", plus a new chapter after ch= apter 3 "Details of ISP use case", titled "Details of regulator use case".= =20 Thanks, Frode Proposed update: 2.2 Regulators ------------------- Regulators in jurisdictions around the world are responding to consumers' a= doption of Internet access services for traditional telecommunications and = media services by promoting competition among providers of electronic commu= nications, to ensure that users derive maximum benefit in terms of choice, = price, and quality. Some jurisdictions have responded to a need for greater information about I= nternet access service performance in the development of regulatory policie= s and approaches for broadband technologies by developing large-scale measu= rement programs. Programs such as the U.S. Federal Communications Commissio= n's Measuring Broadband America, European Commission's Quality of Broadband= Services in the EU reports and a growing list of other programs employ a d= iverse set of operational and technical approaches to gathering data to per= form analysis and reporting on diverse aspects of broadband performance. While each jurisdiction responds to distinct consumer, industry, and regula= tory concerns, much commonality exists in the need to produce datasets that= are able to compare multiple Internet access service providers, diverse te= chnical solutions, geographic and regional distributions, and marketed and = provisioned levels and combinations of broadband Internet access services. = In some jurisdictions, the role of measuring is provided by a measurement p= rovider. Measurement providers measure network performance from users towards multip= le content and application providers, included dedicated test measurement s= ervers, to show a performance of the actual Internet access service provide= d by different ISPs. Users need to know the performance that are achieving = from their own ISP. In addition, they need to know the performance of other= ISPs of same location as background information for selecting their ISP. M= easurement providers will provide measurement results with associated measu= rement methods and measurement metrics. >From a consumer perspective, the differentiation between fixed and mobile (= cellular) Internet access services is blurring as the applications used are= very similar. Hence, similar measurements will take place on both fixed an= d mobile Internet access services. Regulators role in the development and enforcement of broadband Internet ac= cess service policies also require that the measurement approaches meet a h= igh level of verifiability, accuracy and provider-independence to support v= alid and meaningful comparisons of Internet access service performance=20 LMAP standards could answer regulators shared needs by providing scalable, = cost-effective, scientifically robust solutions to the measurement and coll= ection of broadband Internet access service performance information. Proposed new chapter:=20 4 Details of regulator use case --------------------------------------- 4.1 Promoting competition through transparency --------------------------------------------------------------- Competition plays a vital role in regulation of the electronic communicatio= ns markets. For competition to successfully discipline operators' behaviour= in the interests of their customers, end users must be fully aware of the = characteristics of the ISPs' access offers. In some jurisdictions regulator= s mandate transparent information made available about service offers.=20 End users need effective transparency to be able to make informed choices t= hroughout the different stages of their relationship with ISPs, when select= ing Internet access service offers, and when considering switching service = offer within an ISP or to an alternative ISP. Quality information about ser= vice offers can be provided based on performance measurements of the servic= es provided in the market. A set of measurement parameters and associated measurement methods are used= over time, e.g. speed, delay, and jitter. Then the measurement raw data ar= e collected and go through statistical post-processing before the results c= an be published in an Internet access service quality index to facilitate e= nd users' choice of service provider and offer. In order to make information on offerings more meaningful and comparable to= end users, common frames of reference on Internet access service quality m= etrics are essential. An example would be that in relation to access speed,= the actual download and upload speeds are measured and published, not only= the maximum speed.=20 A measurement system that monitor Internet access services and collect qual= ity information can typically consist of a number of measurement probes and= one or more test servers located at peering points. The system can be oper= ated by a regulator or a measurement provider. Number and distribution of = probes follows specific requirements depending on the scope and the desired= statistical reliability of the measurement campaign.=20 In many test configurations, the measurement results will only reflect the = performance of ISP's own network. However, the quality of an Internet acces= s service is also determined by the connectivity to the rest of the Interne= t. Therefore test configurations which measure beyond the ISP's own network= may also be relevant in some cases. 4.2 Promoting end user empowerment -------------------------------------------------- In addition to the advantages that end users receive from the competition i= n the market, through availability of a plethora of ISPs and Internet acces= s service offers, facilitated by transparent quality information about thes= e offers at a general level, end users would further leverage on informatio= n about specific services they subscribe to, or which they are considering = to subscribe to.=20 Performance of Internet access service offers vary based on where the servi= ce is provided (geographical and topological aspects), how it is provided (= e.g. access technology and ISP's interconnection to the Internet) and when = it is provided (variation through the day and over the week). Therefore the= re is a need to obtain more detailed quality information about specific ser= vice offers. Quality measurement tools can be made available for end users to monitor th= eir Internet access service, giving information about the speed and other q= uality metrics of the subscribed service. Speed meters and similar tools ca= n be provided by regulators or other third parties, but also directly by th= e ISP for the benefit of the subscriber. Such measurement tools assist end users in verifying the performance of the= Internet access service provided, comparing the measurement results achiev= ed with the information given in the contract. If the contracted service qu= ality level is not met, end users can use these results when complaining to= the ISP to achieve improvement and compensation. It may also help end users to assess whether they have chosen the package w= hich best suits their specific needs. With their performance results at han= d, they can benefit from quality evaluation guides, which offer comparisons= based on their specific usage profiles. This may enable them to check whet= her their current subscription is the most appropriate, and assist them to = switch package or provider if it is in their best interest.=20 When provided by regulators and other third parties, such quality measureme= nt tools can also be used to compare performance between ISPs. It should, t= hough, be recognised that measurement results can be affected by factors ou= tside the ISP's control, related for instance with local network connection= (e.g. Wi-Fi), equipment and software being used. 4.3 Monitoring overall market development --------------------------------------------------------- Governments sometimes set strategic goals for high-speed Internet access pe= netration as an important component of the economic, cultural and social de= velopment of the society. To evaluate the effect of the stimulated growth o= ver time, broadband Internet access take-up and penetration of high-speed a= ccess can be monitored through measurement campaigns. An example of such an initiative is the "Digital Agenda for Europe" which w= as adopted in 2010, to achieve universal broadband access. The goal is to a= chieve by 2020, access for all Europeans to Internet access speeds of 30 Mb= ps or above, and 50% or more of European households subscribing to Internet= connections above 100 Mbps. To monitor actual broadband Internet access performance in a specific count= ry or a region, extensive measurement campaigns are needed. A panel can be = built based on operators and packages in the market, spread over urban, sub= urban and rural areas. Probes can then be distributed to the participants o= f the campaign. Periodic tests running on the probes can for example measure actual speed a= t peak and off-peak hours, but also other detailed quality metrics like del= ay and jitter. Collected data goes afterwards through statistical analysis,= deriving estimates for the whole population which can then be presented an= d published regularly.=20 Using a harmonized or standardised measurement methodology, or even a commo= n quality measurement platform, measurement results could also be used for = benchmarking of providers and/or countries.=20 4.4 Detecting degradation of the Internet access -------------------------------------------------------------- Regulation related to net neutrality and the open Internet has been introdu= ced in some jurisdictions' Internet policy, and monitoring methods for dete= ction of potential net neutrality breaches is needed to follow up such regu= lations with concrete actions. Net neutrality is typically related to equal treatment of traffic transmitt= ed over the Internet access service, while other traffic transmitted in par= allel over the end user's broadband connection e.g. to provide IPTV in IP n= etworks separated from the Internet (also referred to as "closed IP network= s") can be exempted from net neutrality regulation. Services provided in pa= rallel to the Internet access services are referred to as specialised servi= ces (ref. BEREC and FCC). In order for such regulatory service architecture to protect net neutrality= and the open Internet, it is essential that the specialised services are n= ot provided at the expense of the Internet access service. Therefore regula= tors may need to measure performance of the Internet access service over ti= me, and thereby detect whether this service is becoming degraded.=20 When regulators monitor this development to ensure net neutrality and the o= pen Internet, they can check e.g. whether Internet access service performan= ce and level of quality reflect advances in technology and that this is not= impaired by specialised services. Comparison between ISPs or between diffe= rent countries may also be relevant for this kind of evaluation. Based on such Internet access service quality monitoring, regulators will t= ypically report results and findings regularly, e.g. on an annual basis. In= some jurisdictions regulators may also eventually impose minimum quality o= f service requirements on ISPs in order to prevent degradation of Internet = access services. 4.5 Detecting degradation of specific applications --------------------------------------------------------------- In the regulatory context related to net neutrality and the open Internet, = in addition to the monitoring to detect potential degradation of the access= service as a whole described above, it is essential to perform monitoring = to detect potential degradation of individual applications using the Intern= et access.=20 Since net neutrality relates to equal treatment of traffic transmitted over= the Internet access service, the treatment of different applications' traf= fic is in the core of net neutrality. When traffic originating from differe= nt applications are treated independent of which application each IP packet= belongs to, this is referred to as application agnosticism. Examples of departure from application agnosticism are blocking or throttli= ng of traffic from specific applications, but also preferential treatment o= f specific applications. If traffic is forwarded at different priority leve= ls, traffic having higher priority level implies that other traffic has low= er priority. Detection of such traffic management practices does not necess= arily imply breaches to net neutrality, but these observations can be used = as an input to the regulatory evaluation of the practice. When regulators monitor traffic management practices to ensure net neutrali= ty and the open Internet, they can check compliance with criteria defining = what is considered reasonable traffic management. Measurement systems desig= ned to monitor this kind of effects need to send application-specific traff= ic and then measure in detail the behaviour of the different packets receiv= e when transferred over the Internet access service. Today there exist measurement tools that can detect differentiated treatmen= t of individual applications. Another method that can be used is to measure= performance at application layer, e.g. assisted by content and application= providers, but also passive measurements are foreseen as a promising appro= ach for monitoring of application-specific treatment. From dromasca@avaya.com Thu Oct 31 05:24:46 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E4611E832E for ; Thu, 31 Oct 2013 05:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.805 X-Spam-Level: X-Spam-Status: No, score=-102.805 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtX0UPsO82pt for ; Thu, 31 Oct 2013 05:24:40 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id F0B4711E8121 for ; Thu, 31 Oct 2013 05:24:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIGAPhKclKHCzI1/2dsb2JhbABZgmYhgQy/aoEkFm0HgicBAQMSKFEBFRUUQiYBBBsah2UBmiyESJ0jjx6DWIEOA55viyWDJoIq X-IronPort-AV: E=Sophos;i="4.93,608,1378872000"; d="scan'208";a="34938267" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 31 Oct 2013 08:24:39 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 Oct 2013 08:14:55 -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.0146.000; Thu, 31 Oct 2013 13:24:37 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: preparing the wg meeting in Vancouver Thread-Index: Ac7WNBN8V5W6GSunTEmU2gRlf6p43Q== Date: Thu, 31 Oct 2013 12:24:37 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1291ED12@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] preparing the wg meeting in Vancouver X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 31 Oct 2013 12:24:46 -0000 In preparation for the next week WG meeting in Vancouver the chairs would l= ike to remind the participants the following:=20 - we need presentations to be submitted in advance so that they can be uplo= aded and made available for remote participants=20 - we need at least two minutes takers and one jabber scribe for the meeting= - please volunteer in advance Thanks and Regards, Jason and Dan